Is a widget a monad? Anyway, the examples in this tutorial are another proof that Haskell is the best imperative language!
matja 6 hours ago [-]
A GtkWidget is just a GObject in the category of C-style cast macros
, what's the problem? :)
black_knight 1 days ago [-]
It really is a great imperative langue! The IO monad is basically a better C, if you know how to wield the FFI.
_jackdk_ 19 hours ago [-]
It really is funny how you go through learning all these fantastic abstractions, and then at the end your line-of-business code ends up looking a lot like it always did. But expecting your data structures and control-flow functions to behave according to laws makes things so much more predictable and easier to wrangle.
WillAdams 12 hours ago [-]
>"Algorithms + Data Structures = Programs." — Niklaus Wirth
IceDane 13 hours ago [-]
No, a widget is not a monad. I think you should rather think of it as just the description of how to draw a UI - it's a GTK concept, not a Haskell concept.
Something that could be a monad is some sort of widget builder. You would be able to imperatively describe the construction of a widget. Then "running" that monadic computation would return a widget, or something along those lines. That monad would then most likely just be some sort of state/writer monad.
Vosporos 1 days ago [-]
Widget is not quite a Monad, in this instance it's a newtype around a pointer and classes that mimic GTK's own class hierarchy.
jaen 11 hours ago [-]
This seems to rebuild the entire view from scratch on every model update? Or is there some diffing magic that's not shown in the article?
This loses all non-persistent UI state such as scroll positions, half-entered text etc. etc.
Not really a workable architecture for a real app. React was invented because of this problem (how to make functional-style view building actually work...)
seba_dos1 1 days ago [-]
Replace `backdrop-filter` on `.backdrop::after` with `filter` on `.backdrop picture` for a free scrolling performance boost.
nh2 1 days ago [-]
Indeed the scrolling performance is awful, makes reading it less enjoyable, especially when the topic is GUIs!
grimgrin 1 days ago [-]
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
nh2 22 hours ago [-]
"better time" = the syntax highlighting is gone and the code is no longer monospace?
Anyway, the website seems to be fixed now, nice!
grimgrin 3 hours ago [-]
I did leave out the disclaimer. we can't please everyone can we
with segments of code, I'll read it w/o syntax highlighting. i'll even think of the people who prefer it that way all the time
alpinisme 21 hours ago [-]
Syntax highlighting does go, but at least on iOS the reader still uses a monospace font for the code blocks.
6 hours ago [-]
shevy-java 1 days ago [-]
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.
gen2brain 1 days ago [-]
Well, it is what was always considered to be a default toolkit. Sure, I like Qt and prefer such apps but you got a have the GTK installed anyway. It was always difficult to have general toolkit with it when you depend on dozens of dependencies, collection of libraries, not big fat libraries like in Qt, that you can deploy.
GTK4 changed a lot though, like they do not even try anymore, deprecated font dialog because that is better done with XDG portals, but such thing does not even exist. How will that work on macOS and Windows, it cannot? Or what they did with the menus. Toolkits should be user oriented and should not have vision, it just needs to work and provide controls, events, etc., you cannot even position windows in macOS and Windows with GTK4, that is not toolkit that works for users.
I am working on the IUP fork here https://github.com/gen2brain/iup-go , one toolkit to handle them all, and I did my best for GTK4 backend, but from 14 drivers/backends I worked on, it was the worst experience and I had to fight battles with it.
nine_k 23 hours ago [-]
GTK2 tried to be more general-purpose, while GTK4 is more about serving the vision of Gnome the platform.
I hope that, if desktop / laptop as a platform remains, there will appear an interpreted, platform-independent toolkit / language for GUI specifically, along the lines of Tk, or QML, but much lighter weight than HTML+CSS.
skavi 19 hours ago [-]
I will continue using GTK until QT decides to stop being ugly (by default).
rubymamis 17 hours ago [-]
Qt is ugly only when you don't have aesthetical taste. Here are my Qt apps:
vox looks great! actually kind of reminds me of the look that elementaryOS goes for with the subtle drop shadows and the softer coloring. or maybe older macOS.
at the same time, vox doesn't really look like a lot of other QT apps (whereas a lot of modern GTK apps tend to have very similar designs).
notes seems like a great app. ux seems great from the demo reels. but it doesn't look quite as nice to me. the drop shadows (on click and drag) seem off. many things are very flat and wireframe looking. the icons look "cheap" (trashcan and slider/config particularly). i am unsure on how you choose between full black and dark grey in your design system but it feels a bit inconsistent.
all that said, i think the animations look great. very smooth.
nick_g 8 hours ago [-]
You might want to add the `playsinline` attribute to the videos on get-notes.com. Each video opened in fullscreen for me after the previous was closed and I had to dismiss them all before reading the website (iOS)
Bootvis 10 hours ago [-]
I don’t think the apps are ugly at all but the kerning of the first letter of the headers feels very off on the website. Maybe it’s intentional but I find it distracting and inappropriate for a note taking app. (latest iOS, Firefox, iPhone 17)
nechuchelo 17 hours ago [-]
Not to offend anyone but those apps still look and feel like QT apps. Not particularly pretty
rubymamis 14 hours ago [-]
I'll take the criticism but can you please be specific and constructive? What exactly look and feel like Qt apps? What's not pretty?
jaffa2 9 hours ago [-]
What makes them look like QT apps ? To me I can't see anything identifiable, they look like generic web apps with a mac OS border.
GTK3 has nice, conventional looking interfaces. Developing for it always felt insane, but the advent of AI has completely removed the friction so I've had Claude build me quite a few apps using it because I like the look and it's easy to navigate.
pluc 1 days ago [-]
> import GI.Awd qualified as Adw
please tell me that's a typo
1 days ago [-]
tensegrist 1 days ago [-]
possibly enabled by lsp (Adw.foo -> "foo found in GI.Awd, import it with the name you used?")
pluc 1 days ago [-]
yeah seems to be a typo, it is "Adw" and not "Awd", phew
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?
_jackdk_ 19 hours ago [-]
I haven't seen anyone write about wiring FRP systems to traditional GUI toolkits. Do you have a blog?
freedomben 1 days ago [-]
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?
codebje 23 hours ago [-]
It's a native desktop app, so none of the above.
mintik 1 days ago [-]
[dead]
beanjuiceII 1 days ago [-]
bro takes 2 years to make a todo list
drnick1 1 days ago [-]
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++.
black_knight 1 days ago [-]
My Haskell experience on NixOS is wonderful!
I think it depends on your district. On some distros (looking at you arch!) I think GHCup and keeping things in /home and out of your system package manager is the better approach.
That said, I never had issues with Pandoc on any distribution. But I have struggled with Pandoc extensions, before I got NixOS (and flakes).
rgoulter 21 hours ago [-]
On the one hand, NixOS can have a steep learning curve. (Although if you're willing to use LLM coding agents, I bet "steep learning curve" turns into "be curious and ask the LLM how it works").
On the other, I bet anyone curious about Haskell would love NixOS.
In regards to Haskell not being trouble, though: I'm not too familiar, but I thought stackage & the 'stack' tool would ease over any pain.
kccqzy 1 days ago [-]
Does your distro not statically link Haskell libraries the way it’s meant to? Installing pandoc only requires libgmp.
Vosporos 12 hours ago [-]
Archlinux is (in)famous for not doing so
kccqzy 8 hours ago [-]
Good thing I don’t use Arch.
Vosporos 1 days ago [-]
That is entirely your distribution's fault. ArchLinux has a user-hostile packaging approach which I do not experience in Fedora.
Ambolia 1 days ago [-]
I completely avoid any haskell package in Arch and just build it with Stack, it's usually simple.
klez 1 days ago [-]
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.
nimih 1 days ago [-]
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.
They build and link all Haskell libraries dynamically.
ivanjermakov 1 days ago [-]
Arch Linux approach to python/haskell packaging is a great case study of what not to do...
rmunn 19 hours ago [-]
Can confirm, every time I run `pacman -Syu` and see a hundred `haskell-foo` packages being updated I think "Oh yeah, those are all dependencies of that one app I still use. Got to remember to find an alternative, then I can stop getting lost in a maze of twisty little packages, all different." But I never do remember to switch away from that app.
Vosporos 12 hours ago [-]
I'm sorry this is your experience. Considering that by default GHC (the Haskell compiler) statically links Haskell dependencies of an application, this is a subpar way of doing things that your distro's packagers have decided to inflict on you. I won't tell you to migrate, but Archlinux has been one of the worst PR for Haskell in ages. :(
Vosporos 24 hours ago [-]
Quite right, indeed
ivanjermakov 22 hours ago [-]
It even puts pressure on Linux package managers to support special mode where packages are handled by pacman intead.
Rendered at 22:31:13 GMT+0000 (Coordinated Universal Time) with Vercel.
Something that could be a monad is some sort of widget builder. You would be able to imperatively describe the construction of a widget. Then "running" that monadic computation would return a widget, or something along those lines. That monad would then most likely just be some sort of state/writer monad.
This loses all non-persistent UI state such as scroll positions, half-entered text etc. etc.
Not really a workable architecture for a real app. React was invented because of this problem (how to make functional-style view building actually work...)
click it for a better time
Anyway, the website seems to be fixed now, nice!
with segments of code, I'll read it w/o syntax highlighting. i'll even think of the people who prefer it that way all the time
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.
GTK4 changed a lot though, like they do not even try anymore, deprecated font dialog because that is better done with XDG portals, but such thing does not even exist. How will that work on macOS and Windows, it cannot? Or what they did with the menus. Toolkits should be user oriented and should not have vision, it just needs to work and provide controls, events, etc., you cannot even position windows in macOS and Windows with GTK4, that is not toolkit that works for users.
I am working on the IUP fork here https://github.com/gen2brain/iup-go , one toolkit to handle them all, and I did my best for GTK4 backend, but from 14 drivers/backends I worked on, it was the worst experience and I had to fight battles with it.
I hope that, if desktop / laptop as a platform remains, there will appear an interpreted, platform-independent toolkit / language for GUI specifically, along the lines of Tk, or QML, but much lighter weight than HTML+CSS.
https://www.get-vox.com/
https://www.get-notes.com/
at the same time, vox doesn't really look like a lot of other QT apps (whereas a lot of modern GTK apps tend to have very similar designs).
notes seems like a great app. ux seems great from the demo reels. but it doesn't look quite as nice to me. the drop shadows (on click and drag) seem off. many things are very flat and wireframe looking. the icons look "cheap" (trashcan and slider/config particularly). i am unsure on how you choose between full black and dark grey in your design system but it feels a bit inconsistent.
all that said, i think the animations look great. very smooth.
Manifestly yes. There's even a list of GTK4/Adwaita apps available here: https://arewelibadwaitayet.com/
please tell me that's a typo
https://hackage.haskell.org/package/gi-adwaita
I think it depends on your district. On some distros (looking at you arch!) I think GHCup and keeping things in /home and out of your system package manager is the better approach.
That said, I never had issues with Pandoc on any distribution. But I have struggled with Pandoc extensions, before I got NixOS (and flakes).
On the other, I bet anyone curious about Haskell would love NixOS.
In regards to Haskell not being trouble, though: I'm not too familiar, but I thought stackage & the 'stack' tool would ease over any pain.
[1] https://www.reddit.com/r/linux/comments/9emwtu/comment/e5qss...