Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XMLUI

blog.jonudell.net

Post reply on HN
Print view View original

291–300 of 345 posts

Re: XMLUI

#291

Post by badsectoracula »

mentos wrote: post #155
mnafees wrote: post #64

I wrote Qt C++ for 7 years as an open source contributor to KDE. This reminds me of QtWidgets’ .ui files—custom XML files following a specific schema. Later, Qt introduced QML, which I personally found unintuitive, and over time I lost interest in Qt altogether. That said, I still think XML for UI definitions makes sense, and it’s understandable that some larger environments continue to use it.

I believe the Blizzard game launcher uses QT? Blizzard to me has always had the best execution of UI in their software/games. Curious if there are any Qt projects you’d single out as being great?

AFAIK GOG Galaxy also uses Qt. In a game dev studio i worked on a few years ago the engine's editor was also written in Qt.

Re: XMLUI

#292

Post by notpushkin »

okanat wrote: post #288
nedt wrote: post #280

Earlier quoted context omitted.

Also Mozilla did their app in real XML UI with XUL. But even they themself stopped using it after 20 years.

AFAIK Mozilla still uses XUL to draw their browser UI.

It’s a mixture of XUL and HTML nowadays. The reason is, most of the things that were only available in XUL are now possible in HTML, and it’s eaaier to find developers who know HTML.

Re: XMLUI

#293

Post by joewalker »

okanat wrote: post #288
nedt wrote: post #280

Earlier quoted context omitted.

Also Mozilla did their app in real XML UI with XUL. But even they themself stopped using it after 20 years.

AFAIK Mozilla still uses XUL to draw their browser UI.

It's used for things like pop-up menus, (i.e. things that can't be done with HTML) and was recently used in some obscure parts of the UI e.g. certificate viewer (however I'm not even sure that's still XUL any more)

I think it's safer to say: It's almost all HTML these days. XUL is very much deprecated.

As we killed XBL, our XUL components because web components. https://briangrinstead.com/blog/firefox-webcomponents/

Re: XMLUI

#294

Post by schnable »

lmz wrote: post #224
1oooqooq wrote: post #209

Earlier quoted context omitted.

code currently only works on JS evergreen browsers. i guess like VB only worked with windows and if shipped with the right DLLs.

So, exactly like VB? (From memory it required a msvbvm DLL).

VBRUN300.DLL

Re: XMLUI

#295

Post by atbpaca »

To develop an app, today, one needs to know 3 programming languages: HTML + Javascript + CSS. XMLUI would downsize this requirement to 2, so a little better IMHO.

Re: XMLUI

#296

Post by cluckindan »

btown wrote: post #212
btown wrote: post #176

Earlier quoted context omitted.

Just ship https://github.com/NeilFraser/JS-Interpreter and you’re good to go! /s

As a follow-up: Angular actually did this! https://docs.angularjs.org/guide/expression > AngularJS does not use JavaScript's eval() to evaluate expressions. Instead AngularJS's $parse service processes these expressions.

Note that those are the AngularJS aka ”Angular 1” docs.

For Angular as in ”Angular 2” docs, see https://angular.dev/guide/templates/expression-syntax

Re: XMLUI

#297

Post by jeroenhd »

hn8726 wrote: post #126
jeroenhd wrote: post #104

Earlier quoted context omitted.

Before Compose took over as the new direction for Android app development, the Android Studio designer IDE had a very VB6-style designer where you could drag and drop components, while the underlying UI files were all XML based. The callback generation wasn't as easy as with VB, and different phone sizes meant you had to deal with resizing (which VB applications usually just didn't bother with), but the experience wa…

> Before Compose took over as the new direction for Android app development, the Android Studio designer IDE had a very VB6-style designer where you could drag and drop components, while the underlying UI files were all XML based. It's important to note that pretty much nobody used the visual designer though. The resulting xml was pretty terrible, writing the UIs manually (in xmls, while looking at preview) was infin…

Plenty of apps used the visual designer. You could tell because the UI would be a right mess the moment you didn't use the app on a screen that matched theirs.

Good apps were using semantically correct design layouts but there were, and still are, tons of bad apps out there, just like there were a ton of VB6 applications.

Re: XMLUI

#298

Post by jeroenhd »

optymizer wrote: post #204
jeroenhd wrote: post #104

Earlier quoted context omitted.

Before Compose took over as the new direction for Android app development, the Android Studio designer IDE had a very VB6-style designer where you could drag and drop components, while the underlying UI files were all XML based. The callback generation wasn't as easy as with VB, and different phone sizes meant you had to deal with resizing (which VB applications usually just didn't bother with), but the experience wa…

> but the experience was pretty good. Our experiences do not match. I used Borland Delphi to build business apps 20 years ago just using the UI builder. I've been using Android Studio to build apps at FAANGs for 10 years now and I cannot remember the last time the Design tab was useful - it was always faster and more reliable to just edit the XML file. Yes, Delphi didn't do resizing windows and crashed half the time,…

Android Studio had the exact WYSIWYG experience other toolkits used to have, it was just hidden behind an because designing mobile applications the way desktop applications used to be designed is an awful idea.

Drop an AbsoluteLayout into a design and you can drag, drop, and resize buttons to your hearts' content. You'd have the same problem with VB6 where your buttons would fall off the screen if someone ran your application at a lower resolution than you designed it for, but that was never a problem for the desktop designer.

For the same reason dumping buttons on an arbitrary coordinate and resizing by eye is no longer acceptable on desktop, that same ease of design died out in Android for any serious application developer. It stuck around a while longer on desktop, unfortunately, but modern frameworks pretty much all use declarative layouts these days.

Re: XMLUI

#299

Post by cik »

In 2004, we used this approach to drive QT to dynamically generate a UI for a (in retrospect) needlessly complex software installer. InstallShield use to make these horrifically difficult to maintain installers, combined with how visuals were stored in the MSI files. So, we then interpreted the XML back down to InstallShield dialogs, widgets, and their components. We extended the same to running pure QT on other platforms (Windows, at the time was problematic).

Using this approach (pre QT designer working this way), we were able to give the UX team the ability to move widget around in the installer, colour things, add images.. it actually worked incredibly well, to everyone's shock. I still remember the nightmare of dynamic signal and slot lookups.

Re: XMLUI

#300

Post by conradfr »

aa-jv wrote: post #290
conradfr wrote: post #271

Earlier quoted context omitted.

As a counterpoint, being primarily a web developer (although I did Windows desktop apps with Delphi in the 90s) I hard time doing UI with JUCE. It never really clicked with me and I had a hard time really aligning things, with their Flexbox thing etc, how you set graphic values outside vs inside component classes, being sometimes confused how paint() vs resized() affect things etc. Probably operator error but in the…

JUCE 8's WebView is an abomination that tarnishes an otherwise amazing framework. Yes, coming from the web, JUCE' Flexbox and paint()/resize() semantics are going to be 'weird' - but thats the point. You have the power to decide when/how to update your GUI, frame by frame - and for high performance GUI's, this is vital. These days it has to be said: you can get a LOT of your JUCE GUI work done for you by an LLM with…

Maybe but I actually got a ton of hallucination about the JUCE API with LLMs, as in they sometimes would just not produce workable code at all and invent functions repeatedly (endless infamous "you're right!").

My project is not a typical audio plugin so it's also why I was not benefiting as much about the graphic API as others may do.

But I'm not sure how the WebView is an abomination, it's actually a quite small API that works ... and is totally optional and didn't replace the original graphic API.

Post reply on HN