I'm new here, and here to cause some trouble. I just wrote my
first GTK+3 app - or rather, I adapted an existing C++ program
to give it a GUI with GTK+3, and the distinction is important
for reasons I'll make clear. It wasn't a fun experience, and
I'll try to keep ranting to a minimum, but I'm here to ask
people to seriously and thoughtfully consider that gtk+4 embrace
some new ideas.
1. Threads are here to stay
A number of years ago I was doing something in python and
tkinter, and got a crash out of tkinter. I dug a bit and
realized I'd found a tkinter issue, and there wasn't a
workaround. Since I was stuck - and annoyed - I wrote my own GUI
toolkit, specific to Windows (but using openGL) and python.
Frankly it looked like crap, but it had the feature of features
I'd always dreamed of - thread safety. Complete thread safety,
invisible to the coder. You could delete a widget from any
thread at any time, including from the click callback of the
widget itself, and it sorted everything out for you. No explicit
locking, no hangs or crashes.
I can't tell you how freeing this was or how much I've missed
it since. Widgets are just resources and should be like any
other resource. Think of files on linux. If one thread is
writing to a file and another decides to delete the file, well,
maybe you got what you wanted or maybe you didn't, but the
operating system does not refuse your request, hang or crash.
The file is your resource, and as such, you do what you want
with it, from any thread at any time. The resource manager, in
this case the OS, deals with it all, leaving you free to Just
Code(tm).
My C++ application is now riddled with gdk_threads_add_idle calls. It has to be. It
has a lot of threads, each doing independent tasks with sockets
and things, and sometimes they want to update a label with new
text or new colors. And instead of calling GTK and saying "do
this", I now have a bunch of functions that have to get injected
into GTK, each returning false. Now the code is ugly. And I'm
not going to redesign it around some central GTK world view; the
fact that it paints a screen with status is not the main point
of the application and GTK shouldn't demand a starring role.
Abolish the concept of a main gtk thread. "Anything anywhere
and real soon now" should be the motto.
2. My pixels, not yours. Hands off.
I know that Gtk has huge investment in flowing, springy, widget
layout. Yay adaptability to new screen sizes. But sometimes, you
know, I just want a widget to stay where I put it.
Sure, if you're writing an app that has to adapt to a 2x3"
phone's screen or a 20x8' foot, twenty billion pixel wall
screen, having the GUI engine manage sizing is nice. And
monitors keep getting bigger, so...
Except wait. They don't anymore. These days, there's small
screens, desktop screens, and massive wall displays, and
applications rarely cross from one to the other. When they do,
they're already coded to adapt, because layout is
philosophically different for a phone and a huge screen, and
different in ways that the GUI engine isn't likely to be smart
about without help.
In other words there's a place in the world for the ability to
Visual-Basic-Style-I-said-This-Big-And-Right-Here-and-no-backtalk-out-of-you
nailing down of widgets, for specific niche applications. Maybe
Glade can do this, but every time I Googled, I found threads
saying "that's not the Gtk way".
One True Wayism can have merits, but not in GUIs. Make a GTK
API that makes it easy to draw exactly what I want. My
application is a fixed display on a wall, and I'm not happy to
see fields shifting around because the very large Current Time
field ticked over to skinnier numbers. (I'm sure this is fixable
using the current toolkit - but apparently not trivially.)
3. I have to do what? Just to control colors and text in labels?
Maybe I did this wrong, but my goal was a black background, and
then a bunch of labels of various sizes. I need to be able to
update the text color and background color of the labels on the
fly; everything from slow adjustment of text color to indicate
changing states, to ohMyGoshAProblem! flashing labels at 4/sec
because something's badly wrong. Simple, no?
Simple not. It took a few days and I still didn't get exactly
what I wanted.
First of all, I learned the hard way that if you specify a
widget's background color in Glade, nothing you do at runtime
can change it. (That's probably overstated, but none of the
existing or depreciated calls I tried did anything.) That's just
a weird bug or documentation failure, but the upshot is that
it's critical to specify as little as possible in Glade and do
as much as possible in code. That's simply weird. And since
Glade isn't making it easy to get the layout I wanted anyway,
why did I bother with it?
Second, in other to get a black background everywhere, I had to
use css. Not a lot of it: *{background-color: black;} got it
done. But then there was learning curve with providers and those
are tricker than they should be; it was a great moment when the
window finally turned black. It should have taken ten seconds
boring seconds in Glade. Why did I need a css file? What is this
stuff about providers and screens?
And then there's coloring the text itself. In the end I
generated markup strings on the fly: <span yadda yadda>My
carefully escaped text because & happens</span>. They
worked (once I cleared all the attributes out of Glade). But why
am I generating instructions in a clumsy markup language, to be
grokked by some underlying interpreter (that can only run in a
thread that's not me)? I'm on a raspberry pi - I'd rather not
use cycles for unnecessary parsing. You used to have override
functions for this stuff. Simple, clear, here's the color I want
and I don't have to generate a goofy string to get it. Why on
earth are they depreciated?
And I still haven't gotten the entire label to change to the
background color I want - just the background of the text
itself, which doesn't always fill the label. Good enough for now
I guess.
So here's the upshot.
Simple things should be simple; setting colors of anything
should be trivial. Sometimes the programmer needs to be in
control of all the aspects of everything. CSS and markup
languages are great and all, and if you're coding apps that need
to play in a user-tweakable thematic playpen and be easy for
non-programmers to customize, they're great. But not everything
does or should work that way. Gtk+ 3 makes it hard to do
it any other way.
I realize this may be contentious. But while I'm not
fundamentally a GUI designer, I've been writing applications for
decades and have a pretty good idea what happens inside GUI
engines. I've used commercial ones (Visual Basic, Java), written
a couple, messed around with openGL. I know what I need to get
things done, and I've come to the conclusion that packages like
Gtk are designed around the convenience of the library coder
(make the user bring all his work to MY thread, muhahaha). I
think it's time for that to change, so I propose the change
starts with Gtk+4. Bring back simplicity and control and give me
true thread safety or give me, alright, not death, but maybe a
sympathetic implementation.
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list
