4 ms·

There's a severe lack of good libraries of this type; all the UI libraries want to invent their own controls and rendering instead. I think this is a shame, de

by comex 4y ago

There's a severe lack of good libraries of this type; all the UI libraries want to invent their own controls and rendering instead. I think this is a shame, demonstrating more than a small amount of NIH. Yes, different platforms have different widgets and different design guidelines, so a cross-platform UI using greatest-common-denominator set of native widgets will never look quite native. But at least text boxes will work the way text boxes should work, with keyboard shortcuts, the special characters menu, IME, the works. That already puts you ahead of most cross-platform UI frameworks that aren't browser engines! Menus will work the way menus should work. HiDPI will work (failing to support that is less common these days, but it still happens). Text rendering will look native. With custom rendering, you have to invest a mammoth amount of effort to even approach native platform behavior. Which means that most small UI libraries produce UIs that feel like toys, and even the big ones have an uncanny valley feel. With native controls, even with a relatively small library, you can make a UI that feels fundamentally _usable_. While this project is immature, I hope it has a bright future. If it matures into a high-quality library, I would learn Zig for the sole purpose of using it. I'm also keeping my eye on libui and libui-ng, similar libraries which are written in C.

abainbridge 4y ago
There is no consistent native look/behaviour on Windows. Even a single program (Excel), written by MS themselves, has no consistent style. I think I see 7 different styles in these search results: https://www.google.com/search?q=excel+%22save+changes%22+dialog https://www.google.com/search?q=excel+%22save+changes%22+dia... Maybe some of those variations are due to running the same Excel on different versions of Windows, and it conforming to what it thinks native looks like on each. It's hard to tell. If I redo the experiment on my own Windows 10 machine, I see 7 different kinds of save-changes dialogs, from these 7 programs: VS 2013, Notepad++, Paint.NET, Photoshop CS6, TextPad, UltraEdit and WordPad. Again, this isn't a perfect test because many of those programs are using non-native GUI frameworks. But my point is that as a Windows user, I can't tell what native is, because approximately every program looks different.
- ThinkBeat 4y ago
  There is a consistent native look in Windows which is the standard at least until Windows 2000. but has fallen out of use. Everyone wants to have a fancy, nonstandard UI with more freedom and options. It is still there.
  - alrlroipsp 4y ago
    That's just not true. Even in Win2k/NT you had the Windows 3 dialogs in some system apps. Some were still in Windows 10. https://old.reddit.com/r/Windows10/comments/l85hsx/windows_31_just_called_they_want_their_dialog_back/ https://old.reddit.com/r/Windows10/comments/l85hsx/windows_3...
    - usrusr 4y ago
      I'd say that's a Windows 3 era custom implementation of a file dialog, using fine grained controls that have nicely modernised. The buttons and the scroll bars certainly aren't contemporary with that cute folder control. In a way I see it as a demonstration of how it should be: the UI intended at the time of writing is presented using current controls.
      - mort96 4y ago
        But even the text is broken. The text in the window title bar is way sharper than the blurry mess in the window. If the text isn't even the right resolution, it's not using "current controls".
        usrusr 4y ago
        Oh, didn't even notice the title bar sharpness. The scaled new buttons look even worse than the scaled old pixel font elsewhere. But that doesn't really change the way I read that example, it's an old UI, running on new controls (where they have remained in maintenance, e.g. the button). Scaling is done to the whole window, including still-current controls, because the old code is free to do framebuffer-level work.
badsectoracula 4y ago
> There's a severe lack of good libraries of this type; all the UI libraries want to invent their own controls and rendering instead. I think this is a shame, demonstrating more than a small amount of NIH. There are a ton of reasons for a UI library to do their own controls and rendering instead of using the native, a big one being consistency across platforms and once you implement something on the UI, it is there on all platforms. In addition, some platforms - specifically Linux and to a lesser extent macOS - have a very awful track record of backwards compatibility, at least as far as "out of the box" setups are concerned (sure you can install, e.g., Gtk 1.2 on a modern Linux, but aside from Slackware no distro has that available out of the box - not to mention that even where it is available it still lacks a ton of features introduced in later yet backwards incompatible versions). So while it might be more work now to implement something, it saves you a ton of work later when inevitably someone will break something you rely on and you'll have to fix it on your side. Here is an example from my own experience working with and a bit of working on a library that does expose the "native" controls (LCL, the framework of Lazarus[0]): a couple of years ago or so i implemented MDI support for Win32 (the API was there for years, just never implemented). Spent some time reworking things and refactoring them on both the system agnostic and system specific parts and after a review it was merged. Yesterday i wanted to make a small tool where i thought MDI would fit, however nowadays i'm on Linux as my main OS. Gtk (specifically Gtk2 but in that case it doesn't matter) doesn't have any MDI support at all so of course that wouldn't work there, but fortunately LCL also has Qt backends and Qt does have MDI support - so i changed the LCL backend to Qt5 just for that tool, tried the MDI tool and... MDI for Qt5 support was very buggy. Things that i know worked on the Win32 backend (because i implemented) wouldn't work on the Qt backend. So now what? Well, i don't feel like fixing the Qt5 backend's MDI support (at least not anytime soon) but Qt itself does support MDI just fine. And thus i made the tool using C++ and Qt6 instead (i had Qt6 Creator installed and decided to go with that since i already had it available). And of course the tool would work fine under Win32 and probably macOS too because Qt does implement and render its own controls. Note that this is just one example from my very recent experience. Also it isn't specific to LCL, i had similar experiences with wxWidgets -which also does similar wrapping- at the past. That is not to say that there are no positives to having native controls, but in my experience the only platform where that works reliably and with little fuss in the long term is Win32, everything else is a PITA, even if you decide to be as conservative as you can (e.g. LCL has its own DPI scaling support but HiDPI scaling in LCL with the Gtk2 backend under KDE/Wayland doesn't work because it seems to lie to the X clients about DPI - it does work fine under KDE/X11 however). [0] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
potamic 4y ago
I didn't realize libui was forked. What happened to the original project and author?
Abishek_Muthian 4y ago
I was pleasantly surprised to learn that Fluffychat[1] - A Matrix client, Was written using Flutter when I used it on a Linux smartphone(pmos). It's faster and more intuitive than any other GTK apps there (incl. Those purpose built for mobile) while it being built for desktop Linux. I knew Flutter supports Linux, I used to check on its status every now and then and found that canonical had been collaborating with them; But didn't expected it to have come this far, Of course the credit goes to the developer. It's not perfect, There are quirks like button presses hanging the app but I presume it's largely because the Linux smartphone community is small and there haven't been enough contribution in terms of issue reports, fixes. [1] https://fluffychat.im/ https://fluffychat.im/

by comex 4y ago

abainbridge 4y ago

There is no consistent native look/behaviour on Windows. Even a single program (Excel), written by MS themselves, has no consistent style. I think I see 7 different styles in these search results: https://www.google.com/search?q=excel+%22save+changes%22+dialog https://www.google.com/search?q=excel+%22save+changes%22+dia... Maybe some of those variations are due to running the same Excel on different versions of Windows, and it conforming to what it thinks native looks like on each. It's hard to tell. If I redo the experiment on my own Windows 10 machine, I see 7 different kinds of save-changes dialogs, from these 7 programs: VS 2013, Notepad++, Paint.NET, Photoshop CS6, TextPad, UltraEdit and WordPad. Again, this isn't a perfect test because many of those programs are using non-native GUI frameworks. But my point is that as a Windows user, I can't tell what native is, because approximately every program looks different.

ThinkBeat 4y ago
There is a consistent native look in Windows which is the standard at least until Windows 2000. but has fallen out of use. Everyone wants to have a fancy, nonstandard UI with more freedom and options. It is still there.
- alrlroipsp 4y ago
  That's just not true. Even in Win2k/NT you had the Windows 3 dialogs in some system apps. Some were still in Windows 10. https://old.reddit.com/r/Windows10/comments/l85hsx/windows_31_just_called_they_want_their_dialog_back/ https://old.reddit.com/r/Windows10/comments/l85hsx/windows_3...
  - usrusr 4y ago
    I'd say that's a Windows 3 era custom implementation of a file dialog, using fine grained controls that have nicely modernised. The buttons and the scroll bars certainly aren't contemporary with that cute folder control. In a way I see it as a demonstration of how it should be: the UI intended at the time of writing is presented using current controls.
    - mort96 4y ago
      But even the text is broken. The text in the window title bar is way sharper than the blurry mess in the window. If the text isn't even the right resolution, it's not using "current controls".
      - usrusr 4y ago
        Oh, didn't even notice the title bar sharpness. The scaled new buttons look even worse than the scaled old pixel font elsewhere. But that doesn't really change the way I read that example, it's an old UI, running on new controls (where they have remained in maintenance, e.g. the button). Scaling is done to the whole window, including still-current controls, because the old code is free to do framebuffer-level work.

badsectoracula 4y ago

> There's a severe lack of good libraries of this type; all the UI libraries want to invent their own controls and rendering instead. I think this is a shame, demonstrating more than a small amount of NIH. There are a ton of reasons for a UI library to do their own controls and rendering instead of using the native, a big one being consistency across platforms and once you implement something on the UI, it is there on all platforms. In addition, some platforms - specifically Linux and to a lesser extent macOS - have a very awful track record of backwards compatibility, at least as far as "out of the box" setups are concerned (sure you can install, e.g., Gtk 1.2 on a modern Linux, but aside from Slackware no distro has that available out of the box - not to mention that even where it is available it still lacks a ton of features introduced in later yet backwards incompatible versions). So while it might be more work now to implement something, it saves you a ton of work later when inevitably someone will break something you rely on and you'll have to fix it on your side. Here is an example from my own experience working with and a bit of working on a library that does expose the "native" controls (LCL, the framework of Lazarus[0]): a couple of years ago or so i implemented MDI support for Win32 (the API was there for years, just never implemented). Spent some time reworking things and refactoring them on both the system agnostic and system specific parts and after a review it was merged. Yesterday i wanted to make a small tool where i thought MDI would fit, however nowadays i'm on Linux as my main OS. Gtk (specifically Gtk2 but in that case it doesn't matter) doesn't have any MDI support at all so of course that wouldn't work there, but fortunately LCL also has Qt backends and Qt does have MDI support - so i changed the LCL backend to Qt5 just for that tool, tried the MDI tool and... MDI for Qt5 support was very buggy. Things that i know worked on the Win32 backend (because i implemented) wouldn't work on the Qt backend. So now what? Well, i don't feel like fixing the Qt5 backend's MDI support (at least not anytime soon) but Qt itself does support MDI just fine. And thus i made the tool using C++ and Qt6 instead (i had Qt6 Creator installed and decided to go with that since i already had it available). And of course the tool would work fine under Win32 and probably macOS too because Qt does implement and render its own controls. Note that this is just one example from my very recent experience. Also it isn't specific to LCL, i had similar experiences with wxWidgets -which also does similar wrapping- at the past. That is not to say that there are no positives to having native controls, but in my experience the only platform where that works reliably and with little fuss in the long term is Win32, everything else is a PITA, even if you decide to be as conservative as you can (e.g. LCL has its own DPI scaling support but HiDPI scaling in LCL with the Gtk2 backend under KDE/Wayland doesn't work because it seems to lie to the X clients about DPI - it does work fine under KDE/X11 however). [0] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/

potamic 4y ago

I didn't realize libui was forked. What happened to the original project and author?

Abishek_Muthian 4y ago

I was pleasantly surprised to learn that Fluffychat[1] - A Matrix client, Was written using Flutter when I used it on a Linux smartphone(pmos). It's faster and more intuitive than any other GTK apps there (incl. Those purpose built for mobile) while it being built for desktop Linux. I knew Flutter supports Linux, I used to check on its status every now and then and found that canonical had been collaborating with them; But didn't expected it to have come this far, Of course the credit goes to the developer. It's not perfect, There are quirks like button presses hanging the app but I presume it's largely because the Linux smartphone community is small and there haven't been enough contribution in terms of issue reports, fixes. [1] https://fluffychat.im/ https://fluffychat.im/