<kibomo>
is gtk the only good gui toolkit? a simple application uses up 50mb of memory while on osx system applications using cocoa api use 20-30mb
<dnkl>
Nulo: it is documented, in foot.ini(5), near the bottom of the "main" section.
<kibomo>
dnkl :( you know programming right? is gtk good stuff? does it just need to be improved or do we need a new gui toolkit?
<dnkl>
kibomo: I actually don't do that much GUI programming...
<dnkl>
from what I do know/have heard, there aren't really any good toolkits for Linux
<kibomo>
you made foot, its a beast of a terminal.
<kibomo>
good performance
<dnkl>
gtk's main problem is, afaik, that it is for GNOME mainly. Other projects may use it, but at their own risk
<dnkl>
kibomo: yeah, but foot doesn't use any toolkits
<kibomo>
and yambar
<kibomo>
you make good performant software
<dnkl>
none of my projects use any toolkits ;)
<kibomo>
keep it up
<dnkl>
kibomo: thanks, will try to :)
<kibomo>
would it make sense to make my own gui toolkit and render with vulkan?
<kibomo>
gtk isn't terrible i just feel like it could do better
<dnkl>
can't reallly answer that... vulkan is, from what it looks like, the future. So makes sense from that perspective. But a new toolkit is a *lot* of work...
<dnkl>
my main issue with gtk is how they handle bugs that don't directly affect gnome
<kibomo>
if im looking to make performant applications?
<kibomo>
currently compiling infrastructure is a bit lacking for rust but mmm it looks like the language could be faster
<cbb>
lol, GTK gets worse and worse as time goes on....the people running the project now act as if Microsoft is paying them off to destroy desktop Linux 😆
<kibomo>
yeah writing a gui toolkit sounds like it would take me 20 years haha
<rcf>
kibomo: while forcing GPU rendering might seem like a performance no-brainer, foot itself is an excellent counterexample by managing to outperform existing GPU terminals, and it avoids the hardware dependency that vulkan especially imposes.
<kibomo>
mmm yeah
<kibomo>
i think your just built different
<kibomo>
you're*
kibomo has quit [Quit: Leaving]
<rcf>
The hardware issue may not seem that significant until you look at things like ARM or its derivatives; the open source drivers (if they exist) simply will not support vulkan reliably any time soon, if they can do acceleration at all.
<dnkl>
even GL has been (is?) an issue on many SoCs, and x86 alternatives
<rcf>
OpenGL at least has software implementations if one desperately needs some application in a weird environment, regardless of the insanity of using an API for high performance with an implementation that guarantees you the worst.
<rcf>
Most fun on big endian systems where llvmpipe is broken horribly so you get an even worse result than the terrible one you expected.
<dnkl>
rcf: ah, yes, llvm on big-endian... I remember that from when I made foot big-endian compatible...
<rumpelsepp>
Read through the last conversation and especially this question comes to my mind: How did you guys even got started with coding graphical stuff (-> foot) with plain wayland interfaces? My background is networking and I find it … very difficult to even find some high level documentation of all the wayland stuff. I know drew's book, but it's more like a tutorial.
<dnkl>
rumpelsepp: hmm, I started by looking at two example hello world applications, copied the generic stuff and kind of went from there... pretty sure one of the examples was emersions
<dnkl>
I never read books... only code :)
<dnkl>
but, I've rewritten the low-level Wayland stuff several times
<dnkl>
the small examples are a bit too simplistic, compared to what e.g. foot needs to do
<dnkl>
(e.g. handling outputs coming and going, multi-seat etc)
<rumpelsepp>
Yeah, reading code is often the way to go. But when you do not know the concepts behind it, its useless to read code.
<ericonr>
I usually force myself to learn concepts by reading /writing new code. Find a small project I want to accomplish, and learn the necessary pieces as I go.
<rumpelsepp>
Yeah, I failed with this approach when I tried to write a Linux USB device driver and did not know what interrupt context means.^^
<dnkl>
rumpelsepp: I can image several books describing how to write a USB driver that simply assumes the reader is already familiar with interrupt context...
<dnkl>
I tend to read code first, then look for a textual description if I find myself not understanding the concepts
<rumpelsepp>
Yeah, you are right with this statement about textbooks. 😀
ecocode__ has quit [Ping timeout: 246 seconds]
cbb has quit [Ping timeout: 268 seconds]
<Nulo>
dnkl, either I can't see or it isn't on foot 1.10.0 on Alpine
<Nulo>
It seems everyone wants to write a GUI toolkit these days (me included)
<dnkl>
That's the 1.10.0 tag. I.e if you don't see it, it's either something on your end, or an Alpine packaging issue
<Nulo>
Yep you're right. For some reason mandoc is taking an old file..
<Nulo>
Somehow I have /usr/share/man/man5/foot.ini.5 and /usr/share/man/man5/foot.ini.5.gz
<Nulo>
Sorry!
<ericonr>
dnkl: speaking of distro packages, do you think you'll tag 1.10.1 this weekend? from comments here, I was holding the void package to update directly to 1.10.1
<ericonr>
no pressure, I'm asking just so I know to watch for it