I started to learn it back then via ruby-gtk2. It was not
the best experience but I learned several key things
pertaining to widgets and the UI. Then came gtk3; it was
in some ways worse than GTK2, but it also brought a few
improvements such as the partial CSS support. I always
miss that when I use e. g. wxwidget.
Then came GTK4 though and things changed. Tons of old
things broke or no longer worked. Simple things such as
main_window_widget.move(0, 0) for top-left positioning
(I added an alias to this, .top_left in ruby and that
worked nicely); there are work-arounds to get the old
behaviour, but this is just one example of so many more
things that were eliminated. GTK4 is a GNOMEy-toolkit
and GTK5 will be even worse since it will be wayland-only.
"Interacting" with the GNOMEy-GTK devs is a total waste
of time and I am hardly the only one who had that
experience. For GNOMEys it may be a useful platform,
but GTK no longer is a general toolkit really, despite
claims by the current GTK devs otherwise. Why would
we non-GNOMEys want to keep GTK on life support? There
really needs to be a toolkit that can work in a much
more de-centralized way. Sadly I also don't have a good
idea here, since funding is an issue and GUIs seem to
have taken a huge hit ever since the world wide web
became dominating.
desktop and mobile browsers have a reader mode icon you can click. it is useful for 1) this 2) website blocking fully loaded content with some paywall popup 3) and more!
i've been writing Haskell GUIs for a few years and mostly stick to react-banana or reflex because wiring up gtk-gi signals manually gets messy fast. The Elm architecture pattern here looks clean on paper but I'm curious how you handle async events from the widget tree without ending up in callback hell. Did you end up wrapping all GI callbacks in a channel that feeds into your update loop?
Haskell packages in arch are dynamically, rather than statically, linked, which pulls in a large amount of transitive dependencies (reportedly in the neighborhood of a gigabyte). The maintainer has a pretty reasonable (to my eyes) explanation[1] as to why this is the case, but admittedly if I were an arch user I'd probably find it a bit annoying.
Are people still using gtk?
I started to learn it back then via ruby-gtk2. It was not the best experience but I learned several key things pertaining to widgets and the UI. Then came gtk3; it was in some ways worse than GTK2, but it also brought a few improvements such as the partial CSS support. I always miss that when I use e. g. wxwidget.
Then came GTK4 though and things changed. Tons of old things broke or no longer worked. Simple things such as main_window_widget.move(0, 0) for top-left positioning (I added an alias to this, .top_left in ruby and that worked nicely); there are work-arounds to get the old behaviour, but this is just one example of so many more things that were eliminated. GTK4 is a GNOMEy-toolkit and GTK5 will be even worse since it will be wayland-only.
"Interacting" with the GNOMEy-GTK devs is a total waste of time and I am hardly the only one who had that experience. For GNOMEys it may be a useful platform, but GTK no longer is a general toolkit really, despite claims by the current GTK devs otherwise. Why would we non-GNOMEys want to keep GTK on life support? There really needs to be a toolkit that can work in a much more de-centralized way. Sadly I also don't have a good idea here, since funding is an issue and GUIs seem to have taken a huge hit ever since the world wide web became dominating.
Replace `backdrop-filter` on `.backdrop::after` with `filter` on `.backdrop picture` for a free scrolling performance boost.
Indeed the scrolling performance is awful, makes reading it less enjoyable, especially when the topic is GUIs!
desktop and mobile browsers have a reader mode icon you can click. it is useful for 1) this 2) website blocking fully loaded content with some paywall popup 3) and more!
click it for a better time
> import GI.Awd qualified as Adw
please tell me that's a typo
possibly enabled by lsp (Adw.foo -> "foo found in GI.Awd, import it with the name you used?")
yeah seems to be a typo, it is "Adw" and not "Awd", phew
https://hackage.haskell.org/package/gi-adwaita
i've been writing Haskell GUIs for a few years and mostly stick to react-banana or reflex because wiring up gtk-gi signals manually gets messy fast. The Elm architecture pattern here looks clean on paper but I'm curious how you handle async events from the widget tree without ending up in callback hell. Did you end up wrapping all GI callbacks in a channel that feeds into your update loop?
Is Haskell in this case just binding a local HTTP port that users then hit with the browser? Or is it like a Tauri/Electron type of thing?
bro takes 2 years to make a todo list
Just keep in mind that some people like me avoid Haskell and the huge package mess it causes on Linux. Pandoc is infamous for that. Just stick to C++.
Does your distro not statically link Haskell libraries the way it’s meant to? Installing pandoc only requires libgmp.
That is entirely your distribution's fault. ArchLinux has a user-hostile packaging approach which I do not experience in Fedora.
What does Arch do in particular to cause a mess? It's been a hot minute since I last used it and surely didn't use pandoc back then.
Haskell packages in arch are dynamically, rather than statically, linked, which pulls in a large amount of transitive dependencies (reportedly in the neighborhood of a gigabyte). The maintainer has a pretty reasonable (to my eyes) explanation[1] as to why this is the case, but admittedly if I were an arch user I'd probably find it a bit annoying.
[1] https://www.reddit.com/r/linux/comments/9emwtu/comment/e5qss...
They build and link all Haskell libraries dynamically.
I completely avoid any haskell package in Arch and just build it with Stack, it's usually simple.