C programming with gtk using glade and glade-2

Message

disciple · #16 Post by **disciple** » Sun 12 Feb 2012, 00:58

People might also be interested in this vala based project, too: http://code.google.com/p/gladev/
I don't know how usable it is - it didn't last long.

technosaurus · #17 Post by **technosaurus** » Sun 12 Feb 2012, 19:10

This whole little experiment got me thinking what if??? (you know something is wrong when technosaurus starts thinking - even worse when he refers to himself in the 3rd person)
what if we ported gtk2 to use gtk1 as its base (vs cairo, pango, atk,...) and then maybe gtk3?
here is what I mean take most of (and only) the new widgets/functions etc that are in gtk2 where practical
and build them on top of gtk1 widgets/functions into a separate library that has the new widgets and links in gtk1
such that when you link with -lgtk-x11-2.0 it links in the library with the new widgets and its -lgtk dependency (this will allow gtk1 and gtk2 programs to share overhead)
... same for glib1/2
once that is working, the same thing could be done with many gtk3 widgets/functions
sure there would be some functionality loss in what atk, pango and cairo do, but IMHO those usually aren't essential to an applications functionality ... more importantly it would reduce the resource consumption by ~500% and allow more applications to be used on the much lighter gtk1 base

amigo · #18 Post by **amigo** » Sun 12 Feb 2012, 21:10

It's an idea, but I think you've got it backwards. What would be nice is to have gtk with *some* forward-compatibility for gtk-compatible programs. Particularly the text and tree widgets -we've been talking about them lately, huh.

In order to convince you think about this: Why is gtk2 so undesirable?
1. lots of overhead (size). Needs atk, cairo and pango (now gdk-pixbuf2 which has been (again) split out from gtk.
2. Long startup latency. Much of this is due to the extra time needed to link the external libs mentioned above. part is due to the larger size of the libs, so simply including everything in a smaller number of libs won't help there. The other thing that makes gtk2 slow is themeable icons. A nice feature, but costly vis-a-vis latency. I could see this pretty dramatically with the gtk1 version of sylpheed mail. When I started using/hacking the gtk1 sylpheed-*claws* version, the raw startup time went from less than a half-second to a couple of seconds.

I used to dream of back-porting some gtk2 code to gtk1, but just didn't have the code fu to make it happen. One might take some of the earliest gtk2 code and start from there -actually I mean from gtk-1.3 which used pango -no cairo IIRC and I'm not sure about atk. The thing that pango makes possible is bi-directional text.

Over the years I've found some hacks and tweaks which improve some of the old-fashionedness of gtk1. Patched to make the colors look more pleasing, tweaks for using utf8-encoded fonts, using xft for anti-aliased fonts.

Since I was always looking for enough tools to make a real desktop, I was dissapointed when I'd find small gtk2 apps which used the text or tree widgets, beacuse of the difficulty of porting them, so it seemd like the 'low-fruit' might be to incorporate those widgets into gtk1.

I want to repeat how excited I am that you and goingnuts are *really* interested in gtk1 -because you both are more capable than I am of getting something done there. I do run a highly-patched version of gkt1 which includes *all* the known bug-fixes from every distro out there, plus some attractive added features from selected distros.

There were so many apps written for gtk1 that it still seems viable to use, right? But for modern systems where multi-language support is expected, it starts to fall short. And there were a few drawbacks to it. But I've often thought how great it would be if someone updated it *slightly*. It's one of truly-lightest-weight TK's ever written. Of course now they've even abandoned gtk2 for gtk3. Actually the worst thing about gtk2 is that the API was broken so many times during its' lifetime. I'm sure they'll do the same with gtk3...

Another change to gtk1 that might be nice, would be to incorporate a more user-friendly file-selector -like that used by mtpaint. Pretty low-hanging for someone like you... The version I use does have an improved file-selector, but something more like mt-style might be better.

Hope I gave you something to think about, but please resist the urge to do *full retail plus shipping* changes to the original sources -think about it as if someone else might want to use it. Whatever you decide to do, it would be really beneficial to start off by using my patchset which includes *lots* of patches. Most of them are pretty small, but I spent a lot of time to re-factor them so they all work together -good starting point anyway.

I think trying do things the other way and get gtk2 apps to link back to gtk1 would only bring misery -there are just too many changes. But giving gtk1 forward-capable widgets would make it much easier to back-port simple gtk2 apps. Oh, another thing you'd want to look at would be gtk-extra -some extra widgets that do some of what you allude to. They were mostly widgets which somewhat mimicked some of the gnome1 widgets -for data-plotting, etc. At the least, it provides a framework or example of how you could add extra widgets. There is also the gdkxft library which I am using -it could use a little love for some apps and fonts, but the substitue code could also be folded into the main gdk code for anti-aliased support. As it is, it 'shadows' some gdk font functions using LD_PRELOAD. Using it *really* makes things look a lot better and modern -unless you hate anti-aliasing, so having it as an option via LD_PRELOAD is nice, too.

Another thing, there wass something called 'easygtk' which was a small library which wrapped gtk1 functions for easier widget creation. It could easily do 'wizard'-style widgets and other things. i have it around here but it is not on my site, I think.

Looking at my site I also found this, which I had forgot:
http://distro.ibiblio.org/amigolinux/do ... vas-0.1.1/
Backport of gnome-canvas for gtk1! Maybe we don't need cairo after all.

Let me explain a bit what I said about 'full retail plus shipping' changes. Another of my favorite pices of software is WindowMaker. Of course the original devs gave up on it nearyl 10 years ago. It sat there un-maintained until about 4-5 years ago, when a fellow named Carlos Mafra created a new branch and began working on it. He's gotten *lots* of help and interest from others and they have done huge amounts of work on it. But, along the way, I got disssillusioned with his branch because he kept *removing* things that were working perfectly well. Then once, he decided that the code indentation-style didn't suit him, so he re-indented the whole thing -the diff for just that change was over *500,000* lines long. Having done that, it made it very hard work to incorporate any of the stray patches that were around for the original version. And there were lots of good strays out there which never made it into the upstream. Those strays comprise a large part of the changes that I have applied to my wmaker branch. One of the handiest things I've learned when creating and modifying patches, is to keep the changes extremely well separated -coding-style and whitespace changes should be kept separate from diffs which include real meat. And each bug-fix or feature-addition should be in a separate patch. Just makes it easier to manage the changes. Also, very important to keep autoconf or whatever working correctly so that you can be more versatile and upgrade easier.

Kudos!

technosaurus · #19 Post by **technosaurus** » Mon 13 Feb 2012, 01:16

you hit on most of what I was thinking except that my reason for having just a compatibility layer on top of gtk1 was so that we would still have backwards compatibility with gtk1 apps with no additional overhead, but still be compatible with gtk2 VIA the compatibility layer (much like x11-xcb) then we could have a gtk3 layer on top of that. (it would be doable to do this by minor version adding widgets as they were originally, and let the linker do the work)
ex
ldd gtk-2.0
would be just libgtk and its deps
ldd gtk-2.2
would give libgtk-2.0, libgtk...
and so on for up to 2.16 ...
then the same for gtk3 where the minor versions could be shared/static, but preferring a shared lib for the 2.16 layer and latest 3 series (the linker will do most of the work here)

amigo · #20 Post by **amigo** » Mon 13 Feb 2012, 08:28

Sounds pretty complicated to get and keep working... -even though gtk1 and gtk2 are no longer 'moving targets', gtk3 is and will be for its' whole life. I think that anyone who insists on running an app should be willing to have the libs for it installed as well -nothing is for free. for instance, I use only gtk1 apps for everything on the basic desktop. But, if I want seamonkey to work then I have to pay the 'gtk2 price' for it -it needs still other stuff anyway.

The challenge for me was to find enough of the right gtk1 apps to have something complete enough for daily use, or as a starter system. You can even get several small browsers within that. You can use anyone of those to install a real browser of the users' choice.

I am also working out a similar list of gtk2 apps to comprise a nice starter desktop. Window Managers are handled similarly, so that any combination of WM, graphics toolkit and starter apps all work together using a common underlying system.

I hope you don't spread yourself too thin with all the different ideas...

wjaguar · #21 Post by **wjaguar** » Mon 13 Feb 2012, 13:33

technosaurus wrote:you hit on most of what I was thinking except that my reason for having just a compatibility layer on top of gtk1 was so that we would still have backwards compatibility with gtk1 apps with no additional overhead, but still be compatible with gtk2 VIA the compatibility layer (much like x11-xcb) then we could have a gtk3 layer on top of that.

This is pure fantasy.

GTK+1 and GTK+2 have several nasty low-level differences, and code which depends on these things working as they should in GTK+2, will break in interesting ways with such a "compatibility layer". And vice versa, if you change these underpinnings in your version of GTK+1, there will be a notable possibility of breaking native GTK+1 apps.

Here are some examples which I found, the hard way, while working on mtPaint. And I absolutely guarantee that the list below does NOT contain every trap there is; likely, not even half of them.

- GTK+1 widgets use some signals which GTK+2 doesn't have, and vice versa; examples: "draw", "draw_focus", "draw_default", "focus_in_event", "focus_out_event" - vs "add_accelerator", "remove_accelerator", "mnemonic_activate", "scroll_event";
- "focus" signal in GTK+1 is in GtkContainer class, in GTK+2 it's in GtkWidget;
- GTK+1 doesn't do double buffering when handling expose events, and so its widgets' default GCs don't automagically get correctly clipped to update region and don't get automagically reset if modified;
- GtkObject class is differently structured on the lower level in GTK+1 and GTK+2, which affects the style of direct method calls;
- same thing with GdkEvent;
- same thing with GtkStyle;
- "realized" and "mapped" state propagation is done inside gtk_widget_set_parent() in GTK+2, but not in GTK+1 where it remains the responsibility of each container's "add" function;
- GTK+1 doesn't enable automatic mouse grab on click, while GTK+2 does;
- resize process in GTK+1 is done through an entirely different route compared to GTK+2 - among other idiosyncrasies, it does not really honor requeuing a resize from within a "size_request" or "size_allocate" handler unless a very obscure workaround is implemented;
- GtkViewport's default "size_request" handler is buggy in different ways in GTK+1 and GTK+2;
- GtkCombo widget's entry part is updated from open popup continuously in GTK+1, but only on popdown in GTK+2;
- in GTK+1, if processing of a signal needs be terminated, it must be done explicitly with gtk_signal_emit_stop_by_name() - returning TRUE will only prevent propagation to parent widget, unlike in GTK+2 where it also skips all further handlers in the current widget's handler chain;
- in GTK+2, accelerator keys & window mnemonics get handled before the keypress is passed to the focus widget's signal handler - unlike in GTK+1.

-= With best regards, Dmitry Groshev, maintainer of mtPaint =-

amigo · #22 Post by **amigo** » Mon 13 Feb 2012, 15:36

Very glad that you bring up these concrete examples for technosaurus. I've done enough back-porting to know about some of these problems, but haven't done enough lately to be able to enumerate so many of the obvious ones. I hope your post puts our techno friend back on the path of practicality and productivity.

I think I mentioned this to you before, wjaguar -any way to convince you to hack the mtpaint file-chooser into gtk1 itself??? I have a nice pimped-up version already which would look even lovelier with your file-chooser... Or maybe we could simply wrap the code into an executable file-selection widget -I hadn't thought of that before, but that would let us use, for example, as a pop-up 'Run with' chooser or something similar.

wjaguar · #23 Post by **wjaguar** » Tue 14 Feb 2012, 10:36

amigo wrote:any way to convince you to hack the mtpaint file-chooser into gtk1 itself???

In principle, GtkFileSelection API is simple enough to reproduce without much effort. But the GtkFileSelection struct is another matter. Not every widget in GtkFileSelection dialog has an 1:1 counterpart in mtPaint's file selector; and if some program tries manipulating those widgets directly... results can be rather undesirable.
And access to struct fields cannot be intercepted and redirected on library level, so the source code of programs will need to be inspected to find such accesses - and possibly patched if there is no way to satisfactorily emulate the expected behavior.

amigo · #24 Post by **amigo** » Tue 14 Feb 2012, 14:02

Hmm, IIRC, sometimes the applications call the widget in a way so that the 'create new directory' part of the widget is not shown, but I'm not aware of other quirky calls to the widget. I don't remember off-hand what the option is called...

There is another replacement file-selector out there which is part of the guitar program - a three-paned selector. Also, I had mentioned gtk-extra before. It contains an alternative file-selector which shows a tree on the left side and an icon window on the right side which looks and works somewhat like a rox window.

The gtk file-selector widget has always been the subject of lots of criticism -as being ugly and hard-to-use. Any improvements would be welcome.

wjaguar, what do you think generally of our idea to use and improve gtk1 for wider use? I know you know the score better than I do, so I'd be interested to know.

wjaguar · #25 Post by **wjaguar** » Thu 16 Feb 2012, 20:57

amigo wrote:There is another replacement file-selector out there which is part of the guitar program - a three-paned selector. Also, I had mentioned gtk-extra before. It contains an alternative file-selector which shows a tree on the left side and an icon window on the right side which looks and works somewhat like a rox window.

Neither of them tries to be a binary compatible drop-in replacement for the original widget, so they cannot help any on that front.

wjaguar, what do you think generally of our idea to use and improve gtk1 for wider use? I know you know the score better than I do, so I'd be interested to know.

I think it is a hobby project, aka a waste of time.

Thing is, foundation libraries do NOT compete on merit, but on popularity - and for there to be a successful fork, the core project's leadership needs to do something sickening from an ideological point of view. Otherwise, any number of idiotic technical decisions, while leading to project's slow death, will make coders migrate to another workalike instead of supporting a fork - simply because the workalikes are in package repositories, if not preinstalled, while the fork is on some obscure site no one knows about.
That said, GTK+1 is not bad - it does not waste system resources, and that is appeling to an oldskool coder lile myself.

But I have to say that on the low level, GTK+2 initially was cleaner - a number of design mistakes in GTK+1 which only became apparent with practice, were rectified in GTK+2. I think that from the design standpoint, the peak was GTK+ 2.6 series - the last before Cairo.
Specifically, the expose and resize handling in GTK+1 is blood-curdling.

And it cannot be fixed without loss of compatibility

because people who had been bitten by its idiosyncrasies (including myself) have devised and used workarounds which rely on specifics of the implementation, to overcome its inherent shortcomings. Switching that implementation to a better, but different, one will break such code.

technosaurus · #26 Post by **technosaurus** » Fri 17 Feb 2012, 04:44

wjaguar wrote:I think it is a hobby project, aka a waste of time. Thing is, foundation libraries do NOT compete on merit, but on popularity - and for there to be a successful fork, the core project's leadership needs to do something sickening from an ideological point of view. Otherwise, any number of idiotic technical decisions, while leading to project's slow death, will make coders migrate to another workalike instead of supporting a fork - simply because the workalikes are in package repositories, if not preinstalled, while the fork is on some obscure site no one knows about.

By ideological, do you mean something like (just an example) more permissive licensing such as implementinting the gtk api on top of bsd licensed code base such as tinyX11+tinygl(with glx)+libagar (libagar _appears_ to be quite similar to gtk at a glance and supports several backends)

re:waste of time ... yes, but a fun learning experience

btw if you get curious and build agar the include dirs end up in $includedir/agar/agar instead of just $includedir/agar

snayak · #27 Post by **snayak** » Fri 17 Feb 2012, 06:09

Hi All,

I would like to learn GUI programming on linux.

Which gui tool kit be better/easier to use?

Sticking to C/C++ for gui programming is good ?
Or other easier language exist with gui tool kit ?

What is glade ?

Sincerely,
Srinivas Nayak

technosaurus · #28 Post by **technosaurus** » Fri 17 Feb 2012, 06:47

glade is a gui generating gui that generates C code for gtk+ and gtk2 (these versions do anyways) similar to the fltk's fluid (except that fltk is c++, so you get c++ code) or one of the development apps that is included with Qt (I forget the name of their gui gui)

wjaguar · #29 Post by **wjaguar** » Tue 21 Feb 2012, 18:52

technosaurus wrote:By ideological, do you mean something like (just an example) more permissive licensing such as implementinting the gtk api on top of bsd licensed code base such as tinyX11+tinygl(with glx)+libagar (libagar _appears_ to be quite similar to gtk at a glance and supports several backends)

Yes, something like but in reverse - forks happen promptly when the core team relicenses the project: like with XFree86, or OpenOffice.org.
While making a BSD-licensed reimplementation of something can indeed cause BSD fans to flock to the project... but there aren't that many of them in the first place

let alone good coders among them. The many failed attempts at a BSD-licensed compiler attest to that. (And currently with LLVM/Clang they are at the complete mercy of Apple... which is a precarious situation to be in, as what just happened with CUPS attests.)

btw if you get curious and build agar the include dirs end up in $includedir/agar/agar instead of just $includedir/agar

Yes, thanks for telling me about this project. Will be interesting to try to port mtPaint's GUI to it.
I long wanted to abstract mtPaint's backend from frontend, for all this GTK+3 transition and talks of GTK+4 already, having an absolute dependence on this library does seem risky; but all alternative crossplatform GUI libs are in C++ and offer a C++ API - and I consider C++ disgusting.

And Agar is crossplatform and in C, so I like it already.

amigo · #30 Post by **amigo** » Tue 21 Feb 2012, 20:18

"I consider C++ disgusting"
+1
Thanks very much for sharing your educated opinion about gtk1 and other commnets above

disciple · #31 Post by **disciple** » Wed 22 Feb 2012, 03:01

as what just happened with CUPS attests

What's that? I obviously missed it.

technosaurus · #32 Post by **technosaurus** » Wed 22 Feb 2012, 03:37

Basically, they are planning to drop a bunch of linux stuff and focus on osx.
Fork is already planned, but I hope they revert most of the C++ code introduced in 1.4 .... It's silly to have cupsd requiring libstdc++ (i hacked it out once, but cups is a difficult beast that I try to avoid)

disciple · #33 Post by **disciple** » Wed 22 Feb 2012, 09:32

Thanks, now that I've read up on what's happening, it could be a fantastic development, if it spawns the right type of fork. But I guess CUPS is such a monster it could need someone BIG to sponsor it... here's hoping.

disciple · #34 Post by **disciple** » Sun 26 Feb 2012, 08:49

amigo wrote:"I consider C++ disgusting"
+1
Thanks very much for sharing your educated opinion about gtk1 and other commnets above

Speaking of C++, it seems to me that both QT and wxWidgets apps tend to become unbuildable very quickly once they become unmaintained. Have you guys noticed this? Is it something to do with being written in C++, or is it because g++ or the toolkits or something just have poor backward compatibility?

amigo · #35 Post by **amigo** » Sun 26 Feb 2012, 12:32

Yes it is because of frequent changes in the C++ standard and/or lack of binary-compatibility between different versions of the C++ libs.

If you have a program written in C and compile it against a certain version glibc it will usually run on a machine with an older version of glibc within some limits or on a machine with a newer glibc. With programs that use libstdc++ this is rarely true. At compile-time, the differences in the code show up. Since I don't like or read much C++, these kinds of erros get on my nerves -I try to avoid stuff that uses C++ whenever possible.

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

C programming with gtk using glade and glade-2