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
wjaguar
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

#21 Post by wjaguar »

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
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#22 Post by amigo »

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
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

#23 Post by wjaguar »

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
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#24 Post by amigo »

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
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

#25 Post by wjaguar »

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.

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

#26 Post by technosaurus »

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
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].

snayak
Posts: 422
Joined: Wed 14 Sep 2011, 05:49

#27 Post by snayak »

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
[Precise 571 on AMD Athlon XP 2000+ with 512MB RAM]
[Fatdog 720 on Intel Pentium B960 with 4GB RAM]

[url]http://srinivas-nayak.blogspot.com/[/url]

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

#28 Post by technosaurus »

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)
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].

wjaguar
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

#29 Post by wjaguar »

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
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#30 Post by amigo »

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

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#31 Post by disciple »

as what just happened with CUPS attests
What's that? I obviously missed it.
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

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

#32 Post by technosaurus »

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)
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].

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#33 Post by disciple »

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.
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#34 Post by disciple »

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?
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

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

#35 Post by amigo »

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.

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

#36 Post by technosaurus »

If you look at the release notes for gcc (where libstdc++ originates), it becomes apparent. In nearly every release, there is some deprecation(s) and new compliant behavior that breaks code.

I'm not a C++ fan either ... Note its absence in the title
Glib has object code if that is all you want, but I have found uclibc++ without rtti or exceptions (otherwise you need parts of libstdc++) to be a good alternative for building C++ code to be much smaller.

Edit: my biggest complaint about gtk (all versions) is addressed in this excellent video on immediate mode gui
http://mollyrocket.com/861
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].

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

#37 Post by technosaurus »

I want to allow the gui interface to act as a server by only doing a printf to stdout for callbacks (callbacks are functions that get called when the user does something, or something occurs) and monitoring stdin for action events from the client.

This will allow a single generic interface to manipulate internal widgets from any programming language that supports streams (I can't think of any that don't)

The problem is that in C everything reads in as a long string, but I wanted a snippet that could read from stdin (user input or pipe or redirection) and parse the string into the same format as main's argc and argv so that I could use some of the same functions to operate on them.

Here is a snippet of what I came up with so far (note that multiple separators will cause the next arg to get skipped ... todo - until then only use 1 space, tab or newline)

Code: Select all

#include <string.h>
#include <stdio.h>
#define write1(s) write(1, s, strlen(s))

int main(int argc, char *argv[]){
char s[255],  av[255][255];
unsigned char i=0, pos=0, ac=0;

//open a file ./apipe and store its file descriptor in variabla apipe
//use mkfifo /tmp/apipe to create it ... or you can use stdin
//FILE * apipe = fopen("/tmp/apipe","r");;
fgets(s,255,stdin);

while (i<strlen(s)) {
	switch ( s[i] ) {
	case ' ':
	case '\t' :
	case '\n' :
	av[ac][pos] = '\0';
		ac++;
		pos = 0;
	break;
	default :
		av[ac][pos] = s[i];
		pos++;
	break;
	}
	i++;
}
//printf("%d, %s\n",ac, av[ac-1]);
//printf("%d, %s\n",argc, argv[argc-1]);
}
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].

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#38 Post by vovchik »

Dear technosaurus,

Have you thought about using Peter van Eerten's gtk-server? It supports any programing language that can write and read fifo - and a slew of ther interfaces, including TCP. It also compiles to a gtk1 version. All gtk widgets are available. You just have to know how to call them. The URL is here: http://www.gtk-server.org/.

With kind regards,
vovchik

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

#39 Post by technosaurus »

I have and I even ported some of the ksh and bash srcipt to work with busybox ash and hush, but you must know a lot about gtk in order to program with it. You may have noticed that I like to simplify things to the point where they are usable by the masses. The other side to what I am trying to do is abstract the basic widgets in such a way that I can use multiple backends (gtk1,2,3 and libagar are planned so far)

BTW agar is written in C, cross-platform and has a permissive bsd license (which works well for me since I do a lot of static multicall binaries and I am licensing all of my work as permissively as possible)

Edit: updated snippet for parsing args from stdin

Code: Select all

#include <stdio.h>

void argsfromstdin(void){	/* TODO accept a function pointer to run ac, av */
char s[255],  av[255][255];
unsigned char i=0, pos=0, ac=0;
enum quotes_t{QUOTED=0,UNQUOTED}quotes=UNQUOTED;

//open a file ./apipe and store its file descriptor in variable apipe
//use mkfifo /tmp/apipe to create it ... or you can use stdin
//FILE * apipe = fopen("/tmp/apipe","r");;
fgets(s,255,stdin);

while (i<strlen(s)) {
	/* '!'=33, 'ÿ'=-1, '¡'=-95 outside of these are non-printables */
	if ( quotes==UNQUOTED && ((s[i] < 33) && (s[i] > -1) || (s[i] < -95))){ 
		av[ac][pos] = '\0';
		if (av[ac][0] != '\0')	ac++;
		pos = 0;
	}else{
		if (s[i]=='"'){  /* support quoted strings */
			if (pos==0){
				quotes=QUOTED;
			}else{		/* support \" within strings */
				if (s[i-1]=='\\'){
					av[ac][pos-1] = '"';
				}else{	/* end of quoted string */
					quotes=UNQUOTED;
				}
			}
		}else{			/* printable ascii characters */
			av[ac][pos] = s[i];
			pos++;
		}
	}
	i++;
}
/* TODO accept a function pointer to run ac, av */
#ifdef DEBUG
#include <string.h>
#define write1(s) write(1, s, strlen(s))
while (ac-->0) {write1(av[ac]);write1("\n");}
#endif

}

int main(int argc, char *argv[]){
argsfromstdin();
}
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].

mjaksen
Posts: 45
Joined: Fri 06 Jun 2008, 09:36

#40 Post by mjaksen »

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.

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)

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.
Attachments
glade-demo.zip
glade_demo.bac from bacon website, written in a simplified C
(5.21 KiB) Downloaded 382 times

Post Reply