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

271–280 of 345 posts

Re: XMLUI

#271

Post by conradfr »

fxtentacle wrote: post #48

In my opinion, the best GUI approach is still JUCE. Every UI element is a C++ class with a drawing function. You create new UI elements by composing other elements to create another C++ class, for which the editor will auto-generate the source code. For buttons, you have a large if...else... area in the drawing function to handle different states like hover, pressed, active, disabled, etc. Behind the scenes, a thin d…

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 end I was happy to ditch it for the new WebView option in JUCE 8.

Re: XMLUI

#272

Post by rossant »

gmueckl wrote: post #147
david927 wrote: post #139

Earlier quoted context omitted.

I agree and that was a huge failure. One of the big reasons VB died, people will tell you, was the language. And that's true. But what they don't mention is that the other reason was the components. I'm not sure this is replicating a success story but rather failing to learn from what was not a success story.

I am not sure whether calling WPF a huge failure is justified. It works extremely well when everything is adaptable to its MVC-adjcent MVVM design pattern. In this case it's almost child's play to build rich and conplex GUIs that keep in sync with internal state. Microsoft dropped the ball when they rewrote WPF in incompatible forms for the web (Silverlight) and Windows Phone (WinUI) shortly after releasing WPF itsel…

I really liked WPF for Windows Phone back then. The tooling was great.

I bought a massive 1000+ page book, "Pro WPF in C# 2010," one day. I also had to buy "Home Maintenance For Dummies" the same day. The bookstore cashier laughed at me.

Re: XMLUI

#273

Post by mroche »

mnafees wrote: post #180
hermitcrab wrote: post #92

Earlier quoted context omitted.

Some of us are still programming in Qt using just C++ and .ui files. Never bothered to switch to QML. I wasn't convinced there were enough advantages to make it worth the effort.

Hah, that is awesome. How does Qt fare these days in the non-Linux world though?

Nearly every widely-used commercial or in-house tool in the VFX and Animation sector of M&E are Qt based. The main difference compared to tradition desktop developers is the general attitude of design; the industry takes the stance of providing the same application experience across platforms, rather than trying to adhere to each platforms' UI/UX guidelines.

Examples: Autodesk Maya, 3DS Max, Mudbox Foundry Nuke, Mari, Katana SideFX Houdini Substance Painter, Designer

Re: XMLUI

#274

Post by jdranczewski »

hermitcrab wrote: post #92
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.

Some of us are still programming in Qt using just C++ and .ui files. Never bothered to switch to QML. I wasn't convinced there were enough advantages to make it worth the effort.

I've been writing a UI framework for experiment automation and small tools using Qt Widgets with Python bindings (https://puzzlepiece.readthedocs.io) and it still works pretty well! I like the API, and it being immediately cross-platform is very useful. It does lack looks on Windows a little imo, but to be honest I'm not opposed to the utilitarian way the apps end up looking.

Re: XMLUI

#275

Post by Too »

So instead of ’const tubeStations = useDatasource()’ we now type ’’ and anything beyond this basic example is left as exercise for the reader.

Doesn’t seem like a big improvement? In fact the opposite. Sure, React’s stateful hooks mixing in a semi-declarative mode of programming in otherwise imperative code isn’t exactly intuitive, but the flexibility and familiarity you get from having full JavaScript at your fingertips is worth everything. Hands up anyone who want to learn how to make a for-loop with filter+map in xml syntax. Didn’t think so.

If you want to fix react what you should do instead is keep jsx and give stateful hooks a dedicated section that can’t be mixed up in rendering code.

Re: XMLUI

#276

Post by rcbdev »

cgannett wrote: post #106

I am simultaneously in the seemingly opposite camps of "haha we reinvent HTML lol" and "Actually this sounds immediately useful to me". To be human is to be multitudes.

"Only that, which carries contradiction within itself, is alive."

- G. W. F. Hegel

Re: XMLUI

#277

Post by lf-non »

I understand the motivation for this, but don't understand why this can't just be a collection of web components.

Re: XMLUI

#278

Post by fxtentacle »

password4321 wrote: post #223
fxtentacle wrote: post #48

In my opinion, the best GUI approach is still JUCE. Every UI element is a C++ class with a drawing function. You create new UI elements by composing other elements to create another C++ class, for which the editor will auto-generate the source code. For buttons, you have a large if...else... area in the drawing function to handle different states like hover, pressed, active, disabled, etc. Behind the scenes, a thin d…

Can anyone with experience share more about JUICE and accessibility?

It just works, in my experience, with Narrator on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. The graphical component editor lets you set stuff like labels and tab order and that's usually enough to make things work at least okay with a screen-reader. Getting things to work A+ requires more manual effort, such as implementing AccessibilityHandler for complex components. But the basic JUCE classes are usually much better than what you'd get from any "JavaScript inside WebView" GUI, precisely because you manually coordinate the presentation and the screenreader texts.

Re: XMLUI

#279

Post by aa-jv »

jonpalmisc wrote: post #226
MomsAVoxell wrote: post #135

Earlier quoted context omitted.

I have switched to JUCE as a total cross-platform GUI/high-performance general application development environment, having used it for 7 years in the audio realm I have attained that state, whatever it is, where I realize I can just use it for everything and it’ll be perfectly fine. Doesn’t take too much CMake wrangling either, and once you’ve got at least one half-decent, clonable JUCE -> CI pipeline working, the ho…

Is it still not possible to use JUCE for free/open-source without the pesky "Made with JUCE" popup? Or did they remove that?

The splash screen is a condition for using JUCE for free under the AGPLv3 license, particularly when distributing open-source projects or plugins without purchasing a commercial license.

Re: XMLUI

#280

Post by nedt »

esprehn wrote: post #196

This was tried with Polymer way back in 2014 too, ex. making network requests with - https://github.com/PolymerElements/iron-ajax There was also Adobe Flex of the similar era that exists these days as Apache Royale: https://apache.github.io/royale-docs/features/mxml There was also XAML and inside Microsoft they made NetUI and FlexUI to make Office 2007+ too. It all seems great on paper, but in practice the markup abs…

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