gtkdialog1-1.4

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:

#31 Post by technosaurus »

I put this notebook example together from glade-0.6 (not all the stuff is necessary, but I tried to get the equivalent actions to gtkdialog)

Code: Select all

#include <gtk/gtk.h>

int main (int argc, char *argv[]){
GtkWidget *window1, *notebook1, *frame1, *label4, *label1, *frame2, *label5, *label2;

gtk_set_locale ();
gtk_init (&argc, &argv);

window1 = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_set_name (window1, "window1");
gtk_object_set_data (GTK_OBJECT (window1), "window1", window1);
gtk_window_set_title (GTK_WINDOW (window1), "window1");

notebook1 = gtk_notebook_new ();
gtk_widget_set_name (notebook1, "notebook1");
gtk_widget_ref (notebook1);
gtk_object_set_data_full (GTK_OBJECT (window1), "notebook1", notebook1,
(GtkDestroyNotify) gtk_widget_unref);
gtk_widget_show (notebook1);
gtk_container_add (GTK_CONTAINER (window1), notebook1);

frame1 = gtk_frame_new ("frame1");
gtk_widget_set_name (frame1, "frame1");
gtk_widget_ref (frame1);
gtk_object_set_data_full (GTK_OBJECT (window1), "frame1", frame1,
(GtkDestroyNotify) gtk_widget_unref);
gtk_widget_show (frame1);
gtk_container_add (GTK_CONTAINER (notebook1), frame1);

label4 = gtk_label_new ("label4");
gtk_widget_set_name (label4, "label4");
gtk_widget_ref (label4);
gtk_object_set_data_full (GTK_OBJECT (window1), "label4", label4,
(GtkDestroyNotify) gtk_widget_unref);
gtk_widget_show (label4);
gtk_container_add (GTK_CONTAINER (frame1), label4);

label1 = gtk_label_new ("label1");
gtk_widget_set_name (label1, "label1");
gtk_widget_ref (label1);
gtk_object_set_data_full (GTK_OBJECT (window1), "label1", label1,
(GtkDestroyNotify) gtk_widget_unref);
gtk_widget_show (label1);
gtk_notebook_set_tab_label (GTK_NOTEBOOK (notebook1), gtk_notebook_get_nth_page (GTK_NOTEBOOK (notebook1), 0), label1);

frame2 = gtk_frame_new (NULL);
gtk_widget_set_name (frame2, "frame2");
gtk_widget_ref (frame2);
gtk_object_set_data_full (GTK_OBJECT (window1), "frame2", frame2,
(GtkDestroyNotify) gtk_widget_unref);
gtk_widget_show (frame2);
gtk_container_add (GTK_CONTAINER (notebook1), frame2);

label5 = gtk_label_new ("label5");
gtk_widget_set_name (label5, "label5");
gtk_widget_ref (label5);
gtk_object_set_data_full (GTK_OBJECT (window1), "label5", label5,
(GtkDestroyNotify) gtk_widget_unref);
gtk_widget_show (label5);
gtk_container_add (GTK_CONTAINER (frame2), label5);

label2 = gtk_label_new ("label2");
gtk_widget_set_name (label2, "label2");
gtk_widget_ref (label2);
gtk_object_set_data_full (GTK_OBJECT (window1), "label2", label2,
(GtkDestroyNotify) gtk_widget_unref);
gtk_widget_show (label2);
gtk_notebook_set_tab_label (GTK_NOTEBOOK (notebook1), gtk_notebook_get_nth_page (GTK_NOTEBOOK (notebook1), 1), label2);
gtk_widget_show (window1);

gtk_main ();
return 0;
}
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].

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#32 Post by goingnuts »

Thanks! The first problem is the parser part: notebook is first included in 59.2 but along with that some other changes to the syntax which I prefer to leave out if possible. I did try to use lexer, parser.c and parser.y from 59.2, got it to compile but notebook token was not recoqnized... Slightly reluctant to start learning lex and YACC just to get notebook on board...but maybe not too difficult in the end so lets see.

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

#33 Post by technosaurus »

Yes, the parser was what tripped me up before, and why I decided to just do a quicky using c's built in parsing. I think I could even make it compatible with gtk3 & gtk2, but gtkdialog is a better choice just by the fact that so many apps already use it, but I want to do it anyways. However if you get stuck on anything specific, please post ... If nothing else when you lose steam, dump a (preferably detailed) todo list ... It's not always intuitive to find corresponding code blocks.
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].

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#34 Post by goingnuts »

Haven't lost steam yet :). I finally got gdk-pixbuf working so now png/jpg/xpm can be used. Unfortunately it breaks my static build (builds ok but segfaults) so I wont post code or build before that is fixed. But below a preview...and I will try make a to-do list on my way...
Attachments
snap0005.png
(42.77 KiB) Downloaded 942 times

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

#35 Post by amigo »

Looking really good there -I'm still following this. About gdk-pixbuf, make sure you have the static version of the library present -many distros disable static libs as much as (what they think) is possible.

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

#36 Post by technosaurus »

It's been a while since I compiled gdkpixbuf, but I vaguely recall needing to specify builtin modules in gtk2 even though enable-static was supposed to have the same effect. I can't remember if 1.2 has a similar option, I'd have to grep for dlopen or dlsym to see what ifdefs envelop them.

Edit: you probably don't even want to compile gmodule for a static toolchain gdk-pixbuf-io.c has:
#ifdef USE_GMODULE
//bad stuff
#else
//good stuff
#endif

(it doesn't dlopen directly, it uses gmodule - another autotools failure I am sure)
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].

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#37 Post by goingnuts »

amigo&technosaurous: Thanks for the hints. My gtk-pixbuf static libs are build upon ulibc/tinyX11/xpm/gdk/gtk/gif/jpeg/png/libz/tiff so there are basis for something not working just because of that. Found that png/tiff/gif/xpm loads (and scales) but not the jpg. The static gtkdlg1 segfaults when gtk-pixbuf tries to load the jpg-image. So not likely that it is the gtkdlg1 code but more my toolchain and as the dynamic build does not have the problem...I will post present source and the static build (with the inability to handle jpg) asap.
Edit: The segfault was caused by a call to "gdk_pixmap_unref(mask)" where mask was NULL. The dynamic build does not care but the static build segfaults. Source and static build uploaded. Started a small todo list ...
Attachments
snap0007.png
(34.2 KiB) Downloaded 796 times

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

#38 Post by amigo »

GN, just wanted to report that the 230212 version builds fine here on my system -only two warnings about the lexer. I've only just noticed that you have uploaded your latest revision so I'll be checking that too.
I tried several of the examples but they seem to be a little incomplete -or maybe I don't understand enough of how you might use the output in scripts. Some of the examples I will not try because they are too Puppy-specific and might be 'unhealthy' for another system.

I'd like to see some more simple examples (alog the lines of the originals or those of Xdialog), which demonstrate fairly simple use of selected widgets. One of the things that I fear about thunor's work is that gtkdialog will get way over-bloated. For your project I'd really like to see that not happen.

For example, the 'tree' widget -I can send you or recommend some sources which demonstrate the tree as used in gtk1. But, I think that once you get to a certain level of complexity, then script-driven dialogs are not really the right tool. and the tree widget is just such an example, maybe.

I'd be especially interested to see examples which can use identical syntax and features as their gtkdialog counter-parts. To me, that is the best way to use this tool -so that one could use the same scripts with either gtk1 or gtk2. I'm working on two desktop versions for gtk1 and gtk2 which should duplicate the same functionality with the least work possible.

I will get around to auto-toolifying the sources (I can see Technosaurus cringing here) as it would make the sources much easier to use anywhere. Unfortunately, you have made some really major changes there, so it makes it a bit harder to back-track.

Please do keep posting the latest sources and preferably leave the old ones up also -at least for a while before removing the attachment. I like the way you are able to focus on this!

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#39 Post by goingnuts »

amigo: Thanks for testing and reporting! I do follow your view-point almost all the way. When I started this "project" I did not realize the size or potential - I "messed" up the code (in relation to making single standalone patches) as I found the traditional coding style confusing. On the other hand the huge amount of additions in the middle of the original code that is necessary might justify my coding style. You could argue that the additions could be placed in a new codefile and reffered to though...and that could be done as the last thing when everything works as wanted.

I did try to start fresh taking gtkdialog-0.7.20 as starting point but found it to be too GTK2ish (for me).
I will try to make a separate example collection with offset in the 0.7.20 examples. That also might pinpoint missing opportunities in the exsisting code.

As long as I do not control the parser we might be stuck with the syntax from 0.58.11 (which I like more and more...). Later versions introduce a lot of "=" tags in the syntax which I think is a mistake (<action>closewindow:EDIT</action> becomes <action type="closewindow">EDIT</action>). Harder to code/harder to read. But apart from things not yet implemented in gtkdlg1 that is one of the main syntax difference to gtkdialog2.
If gtkdlg1 is able to build both as gtk1 and gtk2 at least the syntax will be the same although you wont get fully compatibility with the real gtkdialog2. Might just be a reasonable compromise as I see no need for tree-widget (I agree with your views there) although I still miss the notebook-widget then...
I will post new source in bulk of thread as well but keep updating to newest source in start of thread. If you need some of the older sources I still have them.

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

#40 Post by amigo »

I see that you've basically re-written the thing. Have you studied much code which is written for either gtk1 or gtk2? Usually lots of ifdefs in there. It would be very handy if it would work for both toolkits, but making it compatible for last gtk2 versions would be ugly.

Uh, I spent a long time today trying to get your files to configure and work in a modified autools of the original sources. I finally got everything configuring and starting to make, but the parser.o build is messing up. Just what did you do to the parser files? And which ones did you alter? I mean parser.c parser.h parser, and the lexer.c and lexer.l files. I've nearly got it working but hanging a bit there.

It really would be great if you could go back over it and make the changes a little more orderly now that you've got it working. Instead of deleting chunks of the original it makes an easier-to-read-and-port-forward diff if you simply comment the lines. Then when you add small bits or change small bits it is easier to see them. It also will make it easier for you to backport fixes or changes from later original versions. I#m gonna work on this more tomorrow.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#41 Post by goingnuts »

lexer.l is unmodified. parser.y has additional "int yylex(void);" replacing blank line 30.
parcer.c and parser.h is generated from make file replacing the original coming with the source. Try "make clean" after configure in original source but before running "make" - parser.c and parser.h gets deleted.

After building the gtk2 version I use the generated parser.c and parser.h in home brewed makefile. I might have added minor changes to parser.c and parser.h but cant remember...

I think "make" start with lexer.l and create lex.yy which is used to create the parser.c and parser.h, maybe using parser.y as well but I might be totally wrong here.

If I could get an idea of what the parser parses I would prefer to create a plain c-parser - the syntax and rules seems quite limited. This also would open for a more gtk2 compatible version...
ex.pseudocode:

Code: Select all

if (<action>closewindow:EDIT</action>) || <action type="closewindow">EDIT</action>) {"do your things";}
Anyway THANKS for using time on this - hopefully you get it running.

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

#42 Post by technosaurus »

I just finished a parser that converts a string read from stdin into argc, argv format (for the mcb project to start an app from a running copy) it is all written in c so I may be able to help if you know the output format.
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

#43 Post by amigo »

I took another tack late last night and simply worked on your existing Makefile to make it more portable -I figured I'd avoid technosaurus cringing that way by leaving autotools out of it.

I found some small bits to clean up here and there along the way. I'll post the patches a little later.

A couple of suggestions: dating your tarball versions using this format:
20120226 will let them sort themselves naturally. Otherwise, it is hard to see which is the latest. Also, how about calling the thing gtkdialog1. I've already fixed a couple of spots where gtkdialog was still being used, but on second though maybe you'd like gtkdialog1 okay as the name. Puppy has gtkdialog(1,2,?). Since the thing is based on the original gtkdialog, I guess it wouldn't matter to use gtkdialog1 -easier to relate its' functionality to recognized tools that way.

I'm looking at cleaning up the old info page also. Are all the functions available in the original now working here? Or, do I need to cut some sections from the info page?

I really like the way this is looking and working -and I especially like the startup time! I'll have a look and see how it compares to an early gtk version -have to find out which is the oldest that will still build with gtk+-2.24

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

#44 Post by technosaurus »

What about doing a sed script to convert from gtkdialog4 syntax to gtkdialog1?
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].

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#45 Post by goingnuts »

technosaurus: I do not know the formate of the parser output...but the idea of making a gtkdialog4-3-2 pre-filter/translater sounds great! Could be a general useful utility also for the official gtkdialogs I think.

amigo: If gtkdialog1 is an option as name so be it! I am working on an overview of widgets/attributes/actions that works - and the syntax needed. I do not have the full overview myself yet...so please be patient and don't through too much work in it now...
I am also working on making gdk-pixmap an option at compile time as well as getting the present code to compile with gtk2.
I wont have too much time to work on it for the next days but haven't lost steam :)

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

#46 Post by amigo »

"overview of widgets/attributes/actions" The parser is for the xml 'tags', so any time a new tag is added the parser needs to be re-generated. The best way to see how one gets added is to study the diffs between some of the original versions -the changelog will help you pinpoint when a new tag is added and show exactly where code needs to be added.

I've gotten this configuring, compiling and running using the original autoconf setup, with so far limited capabilities. You seem to have already backported some stuff from later versions of the original sources, correct?

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#47 Post by goingnuts »

amigo wrote:"overview of widgets/attributes/actions" The parser is for the xml 'tags', so any time a new tag is added the parser needs to be re-generated. The best way to see how one gets added is to study the diffs between some of the original versions -the changelog will help you pinpoint when a new tag is added and show exactly where code needs to be added.
Yes but one thing is what the parser accepts another thing is what the code actually supports. Parsing <action>removeselected:COMBOWIDGET</action> is accepted by the parser but nothing in the code supports the removal of an item in the COMBO-list.
I have tried to do more generic scripts to exercise the widgets (se below image). The code is more or less the same and its is quick to test if thing works as expected:

Code: Select all

#! /bin/sh
export MAIN_DIALOG='
 <vbox>
  <frame Combo>
   <combobox>
    <variable>COMBO</variable>
     <visible>enabled</visible>
     <item>First item</item>
     <item>Second item</item>
     <item>Third item</item>
     <action>echo You selected $COMBO</action>
   </combobox>
   <hbox>
   <button>
    <action removeselected>COMBO</action>
    <label>removeselected</label>
   </button>
   <button>
    <action clear>COMBO</action>
    <label>clear</label>
   </button>
   <button>
    <action refresh>COMBO</action>
    <label>refresh</label>
   </button>
   <button>
    <action>disable:COMBO</action>
    <label>disable</label>
   </button>
   <button>
    <action>enable:COMBO</action>
    <label>enable</label>
   </button>
   <button>
    <action>append:ENTRY,COMBO</action>
    <label>add</label>
   </button>
  </hbox>
 </frame>
 <hbox>
  <text>
   <label>Item to add: </label>
  </text>
  <entry>
   <variable>ENTRY</variable>
  </entry>
 </hbox>
 <hbox>
  <button ok></button>
  <button cancel></button>
 </hbox>
</vbox>
'
.././gtkdialog1  --program MAIN_DIALOG
Only minor things to change when another widget is to be tested.

Today I added limitation to the actions refresh, clear, removeselected and append: They did not evaluate if a widget was disabled before running which I think is wrong - so fixed that.
amigo wrote:I've gotten this configuring, compiling and running using the original autoconf setup, with so far limited capabilities. You seem to have already backported some stuff from later versions of the original sources, correct?
Thats very good! Yes I have backported code from newer versions. I also got the thing to compile with both gtk1 & 2 now and having gdk-pixbuf as an option for the gtk1 version.
Attachments
snap0008.png
(125.92 KiB) Downloaded 649 times

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

#48 Post by technosaurus »

There are a couple of options for not-yet-supported tags...
Temporarily map them to existing similar supported widgets.
Ignore them silently.
Fail and exit.
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

#49 Post by amigo »

Of course I understand the code must support new tags and attributes. What I meant was that you'd save editing parser.c and parser.h each time. I was unable to get them to rebuild the same as yours even after down-grading bison and flex to the same versions as yours -there were still a couple of differences which would not resolve properly with your code. I am also unable to build the gtk2 version here because I have gtk-2.24.x

But, I started over several times and finally got your code transplanted into the autoconf framework so that the parser rebuilds correctly. I had already gotten the original 0.58.10 version to compile and run with very minimal changes -by simply commenting out all the gtk2 stuff which didn't work. Of course lots of stuff was not working. Notice that the 0.58.11 version introduced two new widgets, the 'tree' and 'gvim' neither of which was working. You had added a very large chunk of code as an attempt at a gtk1 tree, but since you ifdef'ed it out I figured you wouldn't mind.

So what I did was take all the tree and gvim stuff and then it was working -there were a couple of minor other changes to your code to eliminate the config.h and a couple of places where the parser.h was being included -their inclusiong early in the build was preventing the parser files from being built -they come pretty late.

I really hope you'll try to work from this new tarball -it comes 'repo clean' -there is no configure script or Makefile.in files in the tarball. This makes it easier to really see what is going on when you create a patch -only the 'meat' of the code shows up without all the changes which are made when you run configure, use another bison version, etc. I've included an autogen.sh script or you can also run 'autoreconf -if' in the raw sources. After that everything should just work.

As I said before, if you'll go over just a couple of the diffs which technosaurus posted in the 'history' archive, you'll see that it's pretty easy to add widgets. Yes, you have to provide support code, but changing the parser is achieved by adding just a couple of lines to lexer.l Note that the author was also working with raw sources -only when finalizing a release would he run the autoconf commands in the sources. So, if you are comparing diffs between release tarballs, there is a lot of the diff which can be ignored -all the Makefile.in code, all the parser.h and parser.c stuff. by lookinh just at the other *.c files and lexer.l you can see what has really been added -and it's lots simpler than trying to manually alter the parser code.

I'm attaching the first tarball I've created. Please post some more adequate text for the Authors and ChangeLog files -I've just put some place-marker items in there.

Can you create and attach the tarball of your latest changes? I'll roll them into what I've started with, if so. And I'll look at implementing a feature or two from the follwoing versions so we can see how easy it should be. You've already done most of the hard parts as far as basic functionality with images, etc. I think that many of the new tags and bugfixes from later versions will port fairly easily. I really could care less about it supporting gtk2 -as I said it won't work with my later version yet. And I have not added the autoconf stuff to let you choose which toolkit. I will work on that, though. Still, the GTK2 tags in the code serve as good place-markers when trying to backport code from later versions.

if you re-base to using this archive I'll be more able to help you out.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#50 Post by goingnuts »

Amigo...thank you! You must have thrown hours in this! I will try using your tarball and follow your guidelines - although I might not understand everything yet. Attached the present code, stripped for examples as I plan to post them separately, and with 2 Makefiles (for gtk1 and gtk2). The gtk2 builds with a few errors - some widgets do not work but haven't tested much there.

I have altered the pixmap code a bit, fixed the height of buttons without image to be same height as the ones with images, added action to combo-widget, removed some of my commented trial-codes, changed the alignment for some of the widgets so they better follow hbox and vbox logic and as told above avoided some actions running on most disabled widgets.

How do I build in you tarball? I tried to run the autogen.sh but got below output:

Code: Select all

./autogen.sh 
/usr/share/aclocal/nspr.m4:8: warning: underquoted definition of AM_PATH_NSPR
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE
aclocal:configure.in:22: warning: macro `AM_PATH_GTK' not found in library
configure.in:22: error: possibly undefined macro: AM_PATH_GTK
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
UPDATE:Got him running - had to symlink /usr/local/share/aclocal/gtk.m4 to /usr/share/aclocal/gtk.m4. Symlinked gdk-pixbuf.m4 as well. Now I only gets the warnings from autogen.sh. configure turns up and after running that make do the rest. :D

Post Reply