C programming with gtk using glade and glade-2

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#41 Post by technosaurus »

mjaksen wrote:I can certainly understand glade users wanting to use xml files rather than compiling C code. XML allows us to separate the program's behavior from the program's appearance. It allows the coding team to work concurrently with the GUI team. It also makes visual changes a breeze.
so does gui-gtk.c but then you can also have gui-agar.c, gui-qt.cpp and gui-fltk.cpp... a proper make file will only rebuild the changed code, so recompiling is quick (one file is recompiled - the slow part, and then all the objects are linked - fast in comparison) one side effect is that the young programmers that typically get stuck with the gui parts learn "actual programming" through exposure - they actually can see the callback functions etc... and may realize - "hey all of these on_button<*>_clicked are basically doing the same thing - I could just use a generic on_button_clicked callback"
I played around with bacon a bit, but found that I just hated the old basic syntax. But even old basic was better than trying to write GTK in proper C, with its horrid pointer syntax and casts. (for example, *(char***) yuck!)
.
So I reworked one of the bacon example programs (glade_demo.bac) into C, without the miles of wrapping code that bacon includes. Instead I abused the preprocessor and made an easy-to-read almost python-like syntax that anyone can live with. The bacon/tcc compiled executable for this program was 40K. The plain tcc version executable was 4K. (tcc also compiled it in less than a second)
Yes, pretty much every C programmer has the same complaint and the determined ones create their own form of low-level object system out of macros and/or a small library of functions
Though if you're so concerned with speed and size of GTK, why not just use John Murga's murgaLua? FLTK is super fast and Lua's syntax and extensibility is first rate.
from my experience, fltk is not very good at building dynamic guis (kind of important for a gui toolkit, but maybe I just overlooked something) - it is left to the programmer to deal with low level stuff like resizing on a resize event, so it appears to be targeted at embedded environments where this is uncommon - except that fltk and libstdc++ would be much larger than glib+gtk1 or libagar (if you want to use xml, check out goingnuts' backport of gtkdialog to gtk1 - its extremely small and fast and should work in any scripting language, I use a multicall bash script - there is also a C example)

My personal reason for wanting as much as possible in C (besides it being a good learning tool), was that I wanted to build a large project of multicall binaries for the desktop. With gtk1, tinyx11 and uclibc, we can get all the default desktop apps into a single static binary in ~2-3mb (maybe less with some code refactoring and a single shell script for support) Compilers do not know what is in your XML, so any decent optimizations will lose code that is only used in the gui - so clicking a button may do nothing (unless you go through a lot of hoops). Compilers also can't automatically refactor common layout code used in every single XML file, nor have I seen any tool that does so.... I guess you could use the same UI file for all of them and only load a particular set of objects ... but then it would read unnecessary XML (unless there is some way to #include a file in XML?) The underpowered PCs that I have (I have several DECTops with the geode gx2 w/ 128mb ram) take a while to do anything, so even parsing large amounts of XML makes them sluggish. To me, its just simpler if it is all in C... its hard(er) for my 5 and 6 yr old to mess up a file system with a single statically compiled binary, and easier for me to restore if they do. (I also use it as my fall-back in case some part of my shared lib tool chain breaks while I am updating libraries)[/quote]
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#42 Post by amigo »

technosaurus, I also have a couple of DECTOP units -one of them is still virgin with the winCE system. The other one has Slackware installed. I adapted the original DOS system used for 'unlocking' the BIOS, so that you can restore the original locked system or unlock it.
In case you are interested, you can find my decTOP stuff here:
http://distro.ibiblio.org/amigolinux/do ... ts/decTOP/

I still have in mind to try installing my KISS linux on one of the decTOP boxes -I chose the i586 kernel and toolchain architecture just to be able to use the system with geode CPU, but have never checked to see if it was working...

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#43 Post by technosaurus »

Mark Tyler (the mt in mtpaint) forked gtk1 (as mtk) to use Xft and some other bugfixes/improvements here:
https://sites.google.com/site/mtpaint2/
however, the only version I can find is the latest version (mtk-0.5), which for whatever reason, he relicensed gpl3 (not lgpl3) but maybe someone has v0.3/4 around somewhere otherwise its not quite as useful.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#44 Post by amigo »

Nice find there -maybe. Perhaps wjaguar would know or could find out where older copies of the sources are. Barring that, scanning the ChangeLog or diffs against original gtk1 sources might point to some good stuff...

Post Reply