gtkdialog1-1.4

[goingnuts]

I have almost finalized a wrapper for the gtk2 syntax:
gtk_image_new_from_stock

which will support the script syntax:

<input file stock="gtk-zoom-out"></input>

and

<input file icon="about_kde"></input>

so at least the image files are recognized and used if found.

[amigo]

Super! I've got your 0.59.8b running here. notebook widget seems to be fine.

I see you've even got some text functions in your wrapper -very nice!

[goingnuts]

The wrapper for
gtk_image_new_from_file and gtk_image_new_from_stock
works now - and gives the gtk1 version support for stock and icon syntax.
Some of the examples wont run as we have disabled the chooser, gvim and tree. Thought that we should fix the code so the scripts run...
If the fileselect widget could be embedded it might replace chooser. I have to get a gvim to see if it is actually working already...and for the tree -
First try below:

[amigo]

"disabled the chooser, gvim and tree" still enabled in the parser, so you only need to remove the ifdefs in the variuos spots in automaton.c

Yes, a fileselector could be used as the chooser -it is implemented but as an action so it's in action.c. I think the right form for the chooser would be to use gtk_fileselection_hide_fileops instead of gtk_fileselection_new

Nice about the tree -I figured you were gonna get there. Looking forward to a tarball soon so I can update stuff there. BTW, I had left out a couple of extra block of code where you added some actions to some widget -a quick comparison with your original sources will show them, or I'll look back and find them if you don't. Looking really great, man!

[technosaurus]

looks nice!
you know ... putting some of these nuance macros (the general gtk1-gtk2 ones) into a single header file "gtk2compat.h" could be portable to other apps as well and significantly reduce the porting time for mainstream apps (not to mention making it easier to add to individual files within the project, just by adding a single #include) I'd be interested to take a look at this whenever you push another tarball.

[goingnuts]

I might have given the impression that the tree is running - its not. Above image is a hard coded tree...but the structure should be there. I think it is even more complex than the tree in 0.59.8 which seems to be more or less like a table...no sub levels as far as I can see - EDIT: wrong - there are sublevels.
I will try to pipe tree-requests to the table widget - script syntax seems to be equal. EDIT: Did not work.
I think I might have found a good gtk1 replacement for the chooser in amigos repo: mytreefilesel. Image of it running below EDIT:Removed image. It will add to the size but should be possible to embed it. And it looks good!
EDIT: mytreefilesel is also a topwidget (as the fileselect widget) so wont easily embed in the main window (its a pop up/dialog...). Found a way to embed fileselect widget and the method should work for myfileselect as well. Still having problems with the signal connections though..but below the present parts of the gtk1 chooser wrapper:

Code: Select all

{
Widget=gtk_hbox_new(FALSE, 5);
GtkWidget* filesel = gtk_file_selection_new ("File selection");
gtk_file_selection_hide_fileop_buttons(GTK_FILE_SELECTION(filesel));
gtk_object_destroy(GTK_FILE_SELECTION(filesel)->ok_button);
gtk_object_destroy(GTK_FILE_SELECTION(filesel)->cancel_button);
GtkWidget* file_main_vbox = GTK_FILE_SELECTION(filesel)->main_vbox;
gtk_widget_ref( file_main_vbox );
gtk_container_remove( GTK_CONTAINER(filesel), file_main_vbox);
gtk_box_pack_start(GTK_BOX(Widget), file_main_vbox, TRUE, TRUE, 0);
gtk_widget_unref( file_main_vbox );
gtk_widget_show( file_main_vbox );
}
push_widget(Widget, Widget_Type);	

Image of the example chooser_test running with the embedded fileselect below.
Also attached the present source - still some fine tuning of the gtk1 needed - the label and images on buttons need careful alignment/padding to look good. Also the content in compat.c could be tighter and cleaner but thats for another day. It builds both in gtk1&2 but some warnings introduced...

[amigo]

I was just hacking around on mytreefilesel yesterday in fact, to clean up the interface abit. Thta comes from the sources of gtk-extra -I split it out long ago. Yes, it is lovely compared to anything else out there -it would be so nice to get this hacked into gtk itself as the file selector. It also gives some ideas on how to give rox a tree-view -as an option.

Note that, internally, mytreefilesel uses a ctree instead of a regular tree.

[goingnuts]

Ok - I am stuck. Have spend a lot of time trying to modify the gtk1 fileselect popup-dialog to be more like the gtk2-chooser. The problem is how to get the path of the selected file. I have the code to get the filename but cant figure how to pull the path. Cant set up the right gtk_signal_connect it seems. The path is present in the pulldown_hbox and in the selection label, both are updated when directory are changed...

A have attached a simple example script which demonstrate the reparent process of the fileselect-popup to a main-widget and the callback that gets the filename (run it from console to view filename selected).

Any help would be appreciated. Basically 0.59.8 chooser only do the following as far as I can see:

GTK_FILE_CHOOSER_ACTION_OPEN
Indicates open mode. The file chooser will only let the user pick an existing file.

So its just a file chooser - but embedded in the main gtkdialog window - and not a pop-up dialog.

[technosaurus]

This link led me to dir_list
http://www.gtk.org/tutorial1.2/gtk_tut-9.html#ss9.14

found an example (gimp_path_editor_get_path) here:
http://www.rpi.edu/dept/acm/packages/gi ... theditor.c

but maybe this is better as it does the base_dir
http://fossies.org/linux/misc/gcombust- ... file_set.c

gtk_file_selection_set_filename(GTK_FILE_SELECTION(sel), "");
dir_base = gtk_file_selection_get_filename(GTK_FILE_SELECTION(sel));

gtk-server had better explanations for gtk1 than gtk's site
http://www.gtk-server.org/gtk1/gtk/gtkf ... ction.html

I haven't played with Clists, but you may need to check first if it exists and then GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER or GTK_FILE_CHOOSER_ACTION_SAVE (this will let you pick an existing or create one ... is that the easy way?)

[goingnuts]

technosaurus: Thanks! Your links brought me further - what a great place this is! I will post the working inline/embedded fileselect-example later today (will try to do some modifications of the widgets places first).

It now gives the full path + filename when the "selection_entry" change.

Update: Attached source for the skeleton code for the fileselect gtk1 widget that might be the chooser wrapper.

[goingnuts]

I have the gtk1 chooser working. I have tested the gvim - and chosen to leave it out as gvim seems to be a poor replacement for other editors - easier to launch geany or mp via action command. Implemented a label-widget instead that inform user that it is disabled.

I have worked with the tree and found the 0.59.8 version to be buggy (the gtk2-build) - cant handle multiple levels and does not report values of variables and selections. The Xdialog tree is a real tree whereas the gtkdialog seems more oriented on the ability to show icons in a list - and do we need that?

One way to make most scripts using the tree work, is to pipe the tree to a table (which is a clist). This also makes the normal actions work but remove the input from file option (but with a buggy widget...who cares?). By changing lexer.l as below the tree syntax works like a table:

Code: Select all

\<tree\>     { Token="<tree>"; return(TREE);     }
\<\/tree\>   { Token="</tree>"; return(ETREE);   }

change to:

Code: Select all

\<tree\>     { Token="<table>"; return(TABLE);  	}
\<\/tree\>   { Token="</table>"; return(ETABLE);  	}

This also works with gtk2 - but not icons then.
I haven't found a way to use #ifdef in lexer.l - anyone knows if its possible at all?
So everything but the above seems in place - should we make this the first release? And any improvements after that (additional actions, bug fixes etc.) as standalone patches?
I also would like to test some "real" scripts for this version of gtkdialog - any suggestions?

[amigo]

Excellent! You have been quiet for a few days, so I was expecting some good news when you came back...

"show icons in a list" I mentioned in an earlier post the possibibilty of creating 'trees' from something besides a directory listing. database?, filer with a further-abstracted view? flow-chart?

The gvim widget seems out-of-place compared with the rest of them which are more generic. However, the really interesting thing about it is it demonstrates the use of sockets. I use a patched version of sylpheed-claws, the GTK1 version of course, which adds the abiltity to run an instance of dillo in the sylpheed mail window - in a socket. We could probably pretty easily create other similar widgets which migth be useful -a browser in our gtkdialog window... what could we do with that??

I already saw that ifdef'ing wouldn't work in the *.l files. Perhaps we should just leave the tree out until it is really working -it might only be worth fixing in the 0.7.20 version. I think we can do without it -having at least a chooser is great. Or have a closer look at how to fix the gtk2 icon-display so that it works like the gtk1 version. I think it best not to include any widgets which don't work the same for both versions, using the same syntax.

Xdialog tree? I'm not sure I was aware of that. I use Xdialog a lot, along with dialog sometimes. 3 'toolkits' available with the same scripts...

I'm all for making it a 'release'. Post or PM me a snapshot and I'll fix it up. I'll probably be coming up with some 'real' scripts pretty soon - I can use this tool in lots of places. I just never started using it because it didn't fit with my gtk1 scheme-of-things

[disciple]

We could probably pretty easily create other similar widgets which migth be useful -a browser in our gtkdialog window... what could we do with that??

I think some people would be quite keen on a video in a gtkdialog window

[goingnuts]

amigo: I have send you the c-version.
disciple: There was a gtk-script that showed tv-programs from www - Pstreamvid v 1.3 - Streaming Video Controller - but it plays in gxine...

What we actually need is a "swallow"-widget...maybe the "gtk_socket_steal" could do it. The gvim only works as it is build to do it.

My P412 has some gtkdialog2 scripts which all runs ok with the gtkdialog1 gtk1 version (wakepup2, connectwizard, dotpup, input-wizard, petget, puppyinstaller, xorgwizard, xserverwizard) but they all have additional scripts in gtk2...Would be nice to have some useful apps all in gtkdialog1 (2).

[amigo]

You might look at the code for some of the wmaker (or other) DockApps which 'swallow' app windows...

Your snapshot is looking okay, so far. I did find a few error messages I hadn't seen before when using the original examples -I'm gonna invetsigate them a bit more.

Meanwhile, I've had an idea for awhile and implemented it. Have you noticed that you can't embed comments inside the xml-ish code for gtkdialog? There was even a posting about it in zigberts gtkdialog tips thread. At the time I thought: How difficult could that be to implement -a tag which does nothing? Of course, our flex/bison skills are null, but still... Anyway, today I started having a look. At first the syntax wasn't be accepted and I thought I needed some kind of dummy widget or to have some code in several places. Turned out to need only a one-line patch -in fact it only takes 14 chars of code to implement:

Code: Select all

--- ./src/lexer.l.00	2012-03-19 12:40:28.000000000 +0000
+++ ./src/lexer.l	2012-03-21 20:23:05.000000000 +0000
@@ -33,6 +33,7 @@
 		 return TAG_ATTR_NAME;
                }
 
+\<!-.*-!\> { ; }
 
 \<title\>    { Token="<title>"; return(BEGINTITLE); }
 \<\/title\>  { Token="</title>"; return(ENDTITLE);   }

Shall we go ahead and include that in our API? Remember, it is ours/yours to declare (and support) as we see fit. I also think it would be fine to go ahead and include the couple of extras you had added (extra attributes and actions) to at least one widget.

So, that is the Xdialog tree widget. The gtkdialog 'tree' seems mis-named to me -I don't see any 'tree-ness' about it at all... I was expecting more like the image in your last post. But it's fine if that's what the gtk2 version does and looks like. Your version returns strange paths for selection-changed, etc (from some extra debugging-type statements in the code). But the final output is fine and correct(relative path elements are correctly resolved).

Sure, it will be nice when we have some real apps written to our spec. The trouble with most puppy apps using gtkdialog is that they have no usefulness on other systems and could even be damaging. I've been collecting them from the forum for years, but frankly am afraid to run *any* of them on my systems -puppy apps are too prone to doing weird things without any error-checking, temp-file cleanup, confirmation, etc. Still, any number of them could be used as a starting point for creating something useful. But most of them are simply trash with a gaudy interface...

I think I can get lots of usefulness out of this tool without using more than a few of the available widgets and without stretching the syntax to its' limits. Most of the existing apps are simply too greedy and ambitious. There was one which was supposed to be trashcan and wound up being a system snapshot, back-up, save-file-pimping monster... which was still a poor trashcan... I remember another which someone put together which looked just like the gtk_button_icons_apps example -a square box completely filled with just buttons with mysterious labels like 'do it', 'again', 'flounder', 'crash' and 'burn'. And another poster told him: "Man, That looks really Great! The Ultimate in clean design!" or something like that!

[goingnuts]

Thanks for testing amigo:

Code: Select all

<!- This is a comment in gtkdialog1 0.59.8 - The only gtkdialog accepting comments (atm & afaik). This is cool. Been missing that! Thanks amigo! And you can use all those weird things like:§!"#¤%&/()=?+}][{$£@;,:._-*^~¨| ...too :D   -!>

It must be included.
I have tried to get rid of the new warnings but with no luck so far. Seem to have appeared after moving things to the compat.c/h and making the gtk2-wrappers.

I agree that the widgets which are missing the obvious additional actions/tags we should include already - most stuff can be taken from the latest 0.58-source. My hack to the editor and fileselect in 0.58 we should leave out for now.

For useful examples the suggestions from technosaurus archive utility and a simple mp3 player using minimp3 and signals I could use as well in pupngo...also a GUI frontend for the pmirc or the ashirc or whatever it was named would be nice.

If we later could get a swallow widget working, the tree from Xdialog could be used - in fact - all the widgets from Xdialog could be integrated.

I have been looking at the 0.7.20 port again - atm stuck with some segfaults. I am tempted to focus on 0.59.8 and sort of adding/modifying to our needs.

Which bring back technosaurus idea of making a script to convert 0.7.20 syntax to 0.59.8 - we might give that a try? Even better if we could have it via the lexer - I guess your idea in the first place amigo?

I have also started to make a single script for test of all the widgets. Based on the notebook having each widget and its possible actions/tags on each page. Here the comment tag is an excellent tool as the script will be kind of BIG.

[vovchik]

Dear amigo,

That solution for comments in the code is brilliant. I would love it if Thunor would implement it in the GTK2 version, too.

With kind regards,
vovchik

[amigo]

Kudos accepted... A long overdue improvement for sure. Not being able to comment code is really bad.

I chose that particular syntax after trying a couple different ones. First I tried: '<!-- ... --!> like html comments. That showed the comments in gold text like for html, but the 'close' part of the tag didn't work, so the whole rest of the code would show in gold -checked using scite editor which should give similar results to geany. Anyway, finally found that <!- ... -!> would work -the comments get marked in red -I may try to find something which works better, but at least this is a start. In case the meaning of that code is not ultra-clear, in regex speak '.' means 'any character' and '*' means 'repeated any number of times'. As goingnuts has shown, the comment can be spread over multiple lines.

I'm going to recheck the couple of examples which are showing wierd output against out older 0.58.x version -we may have introduced a bug or it may be in the authors' code, or maybe the older version acts the same.

The compile warnings are mostly harmless and there are not too many of them compared to some sources. I noticed also that some of them came in when I tried moving the compat functions to a separate file -I thought they could be solved with some 'extern' voodoo or including the files in the right place, but I ran out of ideas to fix them...

As for back-porting scripts meant for later versions of gtkdialog using a script, it probaby won't work very well any new widgets used would be very difficult to transform.

As for a dir tree like the xdialog one, I have another gtk1 example I want to look at -the dir-selector for the 'gdmap' program. It took me about 8 years to find a gtk1-version of that very-nice program, but it has a very nice tree-style selector.

[goingnuts]

..As goingnuts has shown, the comment can be spread over multiple lines...

It actually was a one line comment - you just cant see that in the code-tag.

To get multiple line support this one can be used:
"<!-"(.|\n)*"-!>" { ; }
and if we would like to stick to xml comment syntax the following works:
"<!--"(.|\n)*"-->" { ; }

Both gives the opportunity to comment code out as well.

I always found the xml comment hard to remember and hard to type - the C-comment could be implemented using:
"/*"(.|\n)*"*/" { ; }

...easy to remember and easy to type..although it probably wont give you the colorful syntax highlight - but cant we live with that?

Or maybe just take all of them:
"/*"(.|\n)*"*/" { ; }
"<!-"(.|\n)*"-!>" { ; }
"<!--"(.|\n)*"-->" { ; }

[amigo]

It was the xml/html syntax I was looking for -I had an extra '!' in there which is why it wasn't lloking right here. What editor do you normally use?

I'd be all for accepting C-style, but then it looks like the 'meaty' code in <input> tags and elsewhere. I right away thought -what about bash-style comments? But that would most likely mess with the common use of an exported shell function as the MAIN_DIALOG. And besides, it display just like C-style. I like the gold xml-style comments as they then have a unique color as comments -when viewing as either xml or html. BTW, I maybe like the view as html instead of xml as it pairs at least some of the tags. All this is with the scite editor. I checked with geany and found it a pretty bare view -can the blue background be gotten rid of? I'll maybe check how shell/html/xml renders with nedit or some other small editors with syntax-highlighting support.

I'll put the correct xml-style in with multi-line support and the C-style also. BTW, I tried hard to include a comment above that new line in lexer.l, but didn't find the way... So, flex doesn't support ifdef's or comments either??

I've found 3 or 4 issues which the (authors') new examples show up. I've fixed a couple already and looking at the rest -I've made some notes about them which I'll post later from the other machine.