What's old is new again. It's Adobe Flex for the kids. I like it.
XMLUI
201–210 of 345 posts
Re: XMLUI
#202The browser platform with HTML/CSS is fundamently legacy over legacy and broken for most application styles ( not general pages ), and incurs insane development costs for even simple things ( been there done that for close to 17 years ) The current best option IMO is: Open Full Browser window size canvas (with webgl, webgpu backend graphics ) and draw everyhing yourself ( meaning with something else than the browser…
> Full Browser window size cancas ... and draw everything yourself This was already tried to some extent with Flash. Many sites were a single Flash module (or multiple). Implementing accessibility then required maintaining an invisible DOM representation of the Flash canvas. I personally don't want to return to the era where login and register buttons were dedicated Flash modules (MegaUpload did this back in ~2009) a…
I agree with you that these things are important. However they are ( in implementation terms ) rather small issues, and determining i rather pay 4-8x more in development and maintenance costs just for this, while you can go the other way and make those features a bit hardware to implement seems like a not so good business case to me.
e.g we are using Avalonia. Of course everything is drawn in a scalable way, with responsive design etc... Accessibility is built in of course ( with integration with the relevant browser apis ) screenreaders work perfectly as do other accessibility features ) Its not the hap hazard way that flash did this (before there were relevant standards for these features anyways ) Invoking a brower api / interop is easy, the difference is we do not need to compromise our productivity for small things.
Re: XMLUI
#203The browser platform with HTML/CSS is fundamently legacy over legacy and broken for most application styles ( not general pages ), and incurs insane development costs for even simple things ( been there done that for close to 17 years ) The current best option IMO is: Open Full Browser window size canvas (with webgl, webgpu backend graphics ) and draw everyhing yourself ( meaning with something else than the browser…
Bye bye ad blocks?
Re: XMLUI
#204Using VB as a reference seems incorrect. Much of the appeal of Visual Basic, and Delphi, was the UI builder. Just click a button to create new project and you already had a window ready to go. Drag and drop in components, click buttons and what-not to wire up functionality. The barrier to entire was so incredibly low, having to edit XML files feels miles away from that ease of use. That being said Visual Basic also c…
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, but I was pretty happy with the WYSIWYG / UI building functionality for production apps.
Android Studio's UI builder is nowhere near that level of usefulness. I have a hard time believing anyone is using the UI builder in Android Studio for anything other than tutorials or entry level Android apps. It doesn't render the layout properly 90% of the time, or just renders some placeholders with no content and calls it a day.
For a modern IDE, Android Studio is somewhere between just OK and bad, mostly because it has features the other IDEs didn't at the time, but the dev experience is behind Turbo Pascal in the 90s on MS DOS. The editor is laggy. The debugger is slow and hangs often. The list goes on, but I'll stop the rant here.
Re: XMLUI
#205I'm trying to build something very much like this, except that it's based on standard HTML, web components, and signals - it's called Heximal: https://heximal.dev/ I think HTML with expressions, templates, reactivity, and components is a really great substrate for these very modular, declarative apps and pages. And a lot of the things added on top of HTML could conceivably be standardized.
I think this could catch on, very much like C++ caught on. It’s very powerful to be backwards compatible.
Re: XMLUI
#206This combined with something like Datasette¹ would be a really nice toolbox for quickly developing simple database applications.
Re: XMLUI
#207Earlier 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?
This weekend I asked Gemini Pro to create a Python Qt app (a serial file sender- something you'd use to send g-code files to a CNC machine or laser cutter). I did most of the dev on Windows but the app will run exactly the same on all 3 main platforms. Eventually I asked Gemini to extract the UI to its own .ui file, which it did. The resulting app worked better than the previous one I had coded myself (handling some various race conditions and other challenging issues much more quickly than me).
If I wanted, I coudl ask gemini to port the app to C++. (Gemini isn't the point here- that's just speeding up what I would have done on my own).
Re: XMLUI
#208I dunno. I pretty much skipped over XAML, which is very similar for .NET desktop UI. Maybe this sticks better because it’s not MS? I certainly think current frameworks tend to be too much cruft for LOB/forms-on-data apps. But a special xml seems wrong to me.
Re: XMLUI
#209Jon has been around for a long time, and I've been a long-time fan. He's a bit of an elder: he's seen a lot of things, and he's worth listening to. > I’m a fan of web components but it’s the React flavor that dominate and they are not accessible to the kind of developer who could productively use Visual Basic components back in the day. I think this is the most important statement in the piece. The rest of the post e…
code currently only works on JS evergreen browsers. i guess like VB only worked with windows and if shipped with the right DLLs.
Re: XMLUI
#210The browser platform with HTML/CSS is fundamently legacy over legacy and broken for most application styles ( not general pages ), and incurs insane development costs for even simple things ( been there done that for close to 17 years ) The current best option IMO is: Open Full Browser window size canvas (with webgl, webgpu backend graphics ) and draw everyhing yourself ( meaning with something else than the browser…
Alan Kay in 1997: > I really would like you to contrast that with what you have to do with HTML on the Internet. Think about it. HTML on the Internet has gone back to the dark ages because it presupposes that there should be a browser that should understand its formats. This has to be one of the worst ideas since MS-DOS. [Laughter] This is really a shame. It's maybe what happens when physicists decide to play with co…
And yet in the nearly thirty years since he said that, the browser has come to dominate how people interact with UIs. Both in terms of sheer popularity (not only do we have complex applications on the web, but we also package complex applications with browsers as desktop applications) as well as influence (SwiftUI, Flutter, and Jetpack Compose all borrow heavily from frameworks developed primarily for the web).
I think a lot of this has to do with the idea that Kay is criticising here: HTML as a mechanism for building applications has been so successful because it needs to be interpreted by a browser. That provides a tremendous level of sandboxing that makes it a lot easier to trust whatever website you're loading than the application you're installing. It also provides a grab-bag of useful controls and elements, while still being completely flexible with creating new ones without needing to resort to OOP inheritance chains or raw graphics drawing APIs. This is all to say nothing of accessibility, which is practically built into the browser.