141–150 of 172 posts
Earlier quoted context omitted.
Honestly this looks like programming style from 90s. Why not design UIs in an editor that saves layout to XML?
xml is dated and gross
If you're like me and like pictures in your books: https://docs.gtk.org/gtk4/visual_index.html
This is a typical code snippet: final class Gtk.Label : Gtk.Widget implements Gtk.Accessible, Gtk.Buildable, Gtk.ConstraintTarget { /* No available fields */ } What language is that in?
If you're like me and like pictures in your books: https://docs.gtk.org/gtk4/visual_index.html
This is a typical code snippet: final class Gtk.Label : Gtk.Widget implements Gtk.Accessible, Gtk.Buildable, Gtk.ConstraintTarget { /* No available fields */ } What language is that in?
Earlier quoted context omitted.
It's a hidden gem, but gvsbuild [1] has made it easier again these days - I just discovered it ~a year ago and it's beautiful :) [1] https://github.com/wingtk/gvsbuild
sweet! I wonder if that can somehow be integrated with pygobject
Why use this when it implements one platform's GUI well, and for the others platforms (Windows, macOS) it does it very badly? At this point, you might as well use Tauri.
Earlier quoted context omitted.
I don't think I know what most people typically expect. I don't know what chrome is, and I'm all for flexibility, but short of some crazy winamp skins in the late 90s, I've never noticed anything being particularly more fancy than amiga500 widgets. Win95 added something. Osx added a bit more, but a box with a label that reverse highlights when I select it is really all I'm expecting. I rarely create guis, mostly just…
"Chrome" is the term for the OS provided border around the window. It offers anchoring points to resize the window; a place to click for dragging; as well as the buttons for closing, maximizing, minimizing. Without chrome, you can't do any of those things, so the window would be fixed in size and place. To get that functionality back, you have to manually code it into the app.
The 2013 Chromebook Pixel followed this naming theme. The screen was so dense that you couldn't see the pixels.
Earlier quoted context omitted.
I see it differently: UI needs have gotten more complex. Like how we used to have web sites that said "best viewed in 800x600 in Netscape Navigator" we rarely design one size fits all UIs any more like we did in Delphi.
There's nothing in "modern" UI that cannot be done with Lazarus GUI Builder: Dynamic layouts? check, anchors? check, flexbox? check, custom components? check nested hierarchies of elements? HIDPI? check Vector Graphics? check Multiresolution? check and so on. All of them compiled to native (and looking native) on every platform under the sun. As said before, GUI design peaked in the 90's
(Real questions, Lazarus was before my time)
Earlier quoted context omitted.
Since you link to the the web demo, I want to caution people: yes, egui can run on the web, but treat that as a demo only done over the web for the convenience of not having to download and run it natively. If you’re making something, do not use egui if you want to actively target the web, because it’s really bad there in fundamentally unfixable ways (given egui’s architecture). Egui is quite compelling on non-web pl…
> only done over the web for the convenience of not having to download and run it natively Isn't that the entire point of web apps for a lot of people, both users and developers? I'm still planning on implementing a web backend for AccessKit sometime in the next year, to make this type of application ported to the web as accessible as the strongly canvas-based approach will allow.
Earlier quoted context omitted.
I’m curious about this, because over the past decade or so, large parts of GTK’s cross-platform ability have been actively sabotaged . It used to be possible to style it to look native on Windows, with some feel problems but mostly comparatively minor. Now, well, no one has quite managed native look (whether or not it’s possible, and certainly I’ll allow that “native” is very ill-defined on Windows these days), and f…
This comment is not correct. GNOME Foundation didn't co-opt or sabotage GTK. For a very long time it's just been mostly GNOME people contributing. It's a known problem that GTK needs more people contributing to fix issues on other platforms. No one I've talked to at the Foundation is happy about this either. If you're bothered about this, you should consider showing up and start contributing. GTK4 and Adwaita apps ca…
To begin with, the onus of all of these things has been shifted to the app developer. Previously, a lot of it was up to the user or the desktop environment.
I said “basically force” because non-overlay scrollbars are possible, but getting them requires every app’s developer to change the property everywhere. If (I recall correctly, it’s not even a theme thing.) That’s completely unrealistic, quite apart from there being no convention. Firefox gets an “always show scrollbars” checkbox in its preferences, which you can manually tick; but I haven’t come across anything else exposing it.
Keyboard: I wasn’t speaking of keyboard shortcuts, actually but other details like what arrow keys do, how text is selected by keyboard (e.g. Ctrl+Shift+Left/Right: which punctuation marks word boundaries, what punctuation or whitespace do you include in the direction of selection). Windows has strong conventions on how those sorts of things work, and my recollection is that GTK does things the GNOME way rather than the Windows way when on Windows.
libadwaita: they said “we’ve split out GNOME HIG stuff into libadwaita, GTK is now more platform-neutral”. In practice, compared to GTK+ 2, even more GNOME HIG is baked into GTK, even more strongly: in the past, users and desktop environments could override various of the stuff; now, the app developer has to support it, or you have to maintain increasingly onerous patches against their source code. That’s the problem. As for what’s in libadwaita, it’s mostly just a few widgets, and various functionality such as colouring stuff that seems to me to pretty clearly belong in libgtk (because it’s useful almost everywhere, and other platforms have analogues which you want to be supported out of the box).
I’ve written more about the bad direction GTK has headed in: https://hn.algolia.com/?query=chrismorgan+gtk&type=comment
Earlier quoted context omitted.
Since you link to the the web demo, I want to caution people: yes, egui can run on the web, but treat that as a demo only done over the web for the convenience of not having to download and run it natively. If you’re making something, do not use egui if you want to actively target the web, because it’s really bad there in fundamentally unfixable ways (given egui’s architecture). Egui is quite compelling on non-web pl…
I didn't have any problems with fonts (I don't block Any), middle clicking opened in a new tab, egui supports context menus, just not the browsers (which is what I want from a webapp).
Font rendering is wrong, even if you aren’t an extremist like me. Stuff is just never going to feel right.
Middle clicking is wrong, it didn’t open in a background tab like it should have, and this is indicative of the fundamental problem, and you couldn’t right click on the link to get the browser’s context menu, which is what you want >99.998% of the time. Browser’s context menu is also rather important in things like text boxes.
Most people won’t be significantly affected by these issues, probably won’t even notice them, or disregard it if they do briefly. But quite a few will loathe your app, because it badly messes up their way of working in ways that no site on the internet does.