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.

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._________________Web Programming - Pet Packaging 100 & 101

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

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.

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.

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

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!

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.

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.

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:

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._________________Web Programming - Pet Packaging 100 & 101

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

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

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum