Hi,
I'd like to use GTK+-2.x with Pike, but besides GTK2 not working with Pike there are some design flaws in the current implementation (as long as I read the source the right way). It seems that you can only use 1.2 or 2.x because there's only one GTK module. This is no problem within one program, but you have to decide when compiling Pike. In GTK 1.2 there are some identifiers that are missing in GTK 2.x and in the 2.x tree there are more widgets than in 1.2 so if a user would use Pike programs using 1.2 and 2.x he/she would need two different builds of Pike. There should be a clean distinction between GTK implementations, that's why I would suggest having an own module for GTK2. Any comments or aspects I may have overlooked? I already started implementing GTK2 as it's own module and got to the point where I can show a window with a label in it. I just wanted to ask if this makes sense or if anyone has already done this before I get to the real work.
- Sebastian
Having a separate GTK2 module was the original plan. Since it never got carried out, I created a patch which allows the old GTK module to be linked against GTK2, but to avoid removing incentive for actually implementing a real GTK2 module, I did not commit it. :-)
If you want to implement the GTK2 module, go for it! If you also want to implement the compatibility layer once planned, even better. The idea was to write, in Pike code, an emulation of the old 1.2 API using the new 2.x API, to ensure compatibility with old programs even if you don't actually have GTK 1.2 on the machine. If the emulation is good enough, it would probably even be a good idea to use it over the old module on systems with both GTK 1.2 and GTK 2.x, in order to A) reduce compilation time and installation size, and B) unify settings etc, since GTK 1.2 and GTK 2.x have separate configuration files.
Just one thing to remember: AFAIK GTK 2.x uses UTF-8 internally, so strings need to be converted using f_string_to_utf8() and f_utf8_to_string() when passed to and from GTK functions. Simple to do, but boring if you forget it and have to add it everywhere afterwards.
If you use the generate-code-on-demand scripts in the GTK module, it's almost trivial to add.
Per Hedbor wrote:
If you use the generate-code-on-demand scripts in the GTK module, it's almost trivial to add.
First I thought of the generate-code-on-demand scripts negatively, because it's a little hard to understand and trace bugs at the beginning, but now I think the advantages are major.
Can't we copy the GTK module folder to GTK2 and apply Marcus Comstedt's patch and work from there on? Or is this just a kludge that needs to be completely rewritten?
Also, the GTK module's configure.in would need to be modified not to evaluate --with[out]-GTK2 and all obviously broken GTK2 features would need to be removed from the GTK module.
- Sebastian
Can't we copy the GTK module folder to GTK2 and apply Marcus Comstedt's patch and work from there on? Or is this just a kludge that needs to be completely rewritten?
You can probably pick out some parts like the signal code changes where reuse will be less work than a complete rewrite, but overall the kludge factor is major. My goal was simply to have the GTK 1.2 API with the GTK2 libs, to whatever extent was possible without too much work. This should not be the goal of a real GTK2 module.
pike-devel@lists.lysator.liu.se
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Per Hedbor () ＠ Pike (-) developers forum
-
Sebastian Kaminski