gtkdialog1-1.4

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

[goingnuts]

amigo: I use Geany...

I got comment to work:

Code: Select all

 /* amigo 20120322 comment handling */

"/*"(.|\n)*"*/" { ; }
"<!--"(.|\n)*"-->" { ; } 

Important to have space or tab before the first "/*".

"#ifdef" should be possible - the 0.7.20 uses it - but I haven't got it working.

Looking forward to here about your findings and fixes - thanks again for your valuable support!

I have the raw code for a swallow widget - at least I am able to swallow things:

[amigo]

Is that (swallow) using Xlib?
It is something useful and tempting for a few cases, but it might be overused also... This program already loads very slowly if there is any work to do at all...

Anyway, here are my notes:

###
gtk_button, gtk_complex
Various examples throw 'sh' errors:
bash-4.1# ./gtk_button
sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `locate /(null)'

Do they have something in common? Yes!
This error shows when an 'input file' is
not found.
> operator error -fixed as a HINTS entry

###
In GTK1 'entry' widgets, 'max_length' does not work:
Gtk-WARNING **: gtk_object_set(): could not find argument "max-length" in the `GtkEntry' class ancestry
> fixed by commenting out, unless you want to try to implement it.

###
menu_test error with 'input' tag:
Warning: Could not stat 'Command:ls'.
Hmm, this seems to be simply wrong-usage in the example
from the original author. It happens in the <edit> widget
when '<input>ls</input>' is called.
> author's error

###
chooser_test and many others:
Using tags like '<label>gtk-no</label>'
inside <menuitem> tags shows stock icons in the menu pop-ups,
with standard text and accelerator keys activated.
gtk1 build does not do this, but simply shows the label 'gkt-no'
This traces back to automaton.c create_menuitem where GTK2
uses: gtk_image_menu_item_new_from_stock
and GTK1 uses:
gtk_menu_item_new_with_label
The function gtk_image_menu_item_new_from_stock is found
in the GTK2 sources includefile: gtkimagemenuitem.h:70
The menu items with icons are nice -maybe we could include
the source for gtk_image_menu_item_new_from_stock in compat.c ??

###
gtk_edit is not working. How do you save or display an edit?

If the edit widget is useless as is, then we need to fix it or get rid of it, I guess.

Nice work with the comments in lexer.l - I hadn't noticed ifdef's in the 0.7.20 flex code. Still, I think the reason we needed them means we shouldn't use them. It may be that we can't get every GTK2 feature supported by the original code to function the same and look at least similar in the gtk1 version. In those cases we should not support the feature at all -so no ifdef'ing would be needed for the parser files. I think that a single feature-set and syntax for both toolkits is central to this thing... I don't mind if it means we miss some minor feature available in gtkdialog -we'll never match what thunor is doing anyway by trying to support every gtk2 feature.

BTW, looking at gdmap chooser /tree proved not useful -it's a dir-select-only widget -maybe just right as the left-side of a rox/afx-filer tree-wiew, though...
The code from Xdialog would probably be better suited for inclusion in our tool if we want such a tree-view-dir-file-selector.

[goingnuts]

Thanks amigo! Its a pure gtk-swallow using "gtk_socket_steal". Very close to the gvim socket code - and is quite swift running here. But I have to hard code the windowID as I haven't figured how to get a windowID_by_name via gtk...
Well - it is just a try and maybe not so usable right now.

I will look through your list - I think I have the code to get edit working - and some of the errors might be a missing "locate" program? I created a script in /usr/bin/locate holding only:

Code: Select all

#!/bin/sh
echo ""

- it wont locate anything but I think the locate function is just taking up execution time. If an image is not where you told it to be - you will notice and fix the script-reference...

For the not supported images in menus and other placed I think we should replace the "gtk-" with "".

I will look at the things during the weekend.

[disciple]

BTW, looking at gdmap chooser /tree proved not useful -it's a dir-select-only widget -maybe just right as the left-side of a rox/afx-filer tree-wiew, though...

Another possible source for that is gwhere - I've never used it with gtk1.2, but I presume it must be possible, as they still have a poll on the website asking which gtk people use it with...

[goingnuts]

disciple: Thanks for pointing at gwhere - seems to be a gently modded fileselect - but without trees and icons.

But its a great day:

Final release of gtkdialog1-1.0 - after 3 months of work - posted at the start of this thread.

[jpeps]

Required configuring --with-gtk=2.0 (since 2.0 uses a different configuration system re glib-config). I installed to a /tmp folder and tried it out.

Code: Select all

/tmp/gtkdialog1-1.0/usr/local/bin/gtkdialog1: unrecognized option '-G'

Probably DESTDIR didn't get all the needed files ?

edit: Oh....I see...still testing....

Seems like I'd have to rewrite all the scripts to even test it out. No geometry,
etc.,etc.,

Code: Select all

Error in line 2, near token 'window title=': syntax error

[goingnuts]

jpeps: Thanks for testing! Its puppy gktdialog2...

Geometry is supported - use "-g" - ex.:

Code: Select all

-g +400+200

Maybe try the examples to get an idea of what is running?

I will add that to the printout of gtkdialog1 --help in next update.

[jpeps]

gtkdialog geometry requires -G to run.

next:

Code: Select all

Error in line 2, near token 'window icon-name=': syntax error

Removed icon-name, then

Code: Select all

Error in line 2, near token '<window>': Unknown tag.

removed <window> blocks, then

Code: Select all

Error in line 24, near token 'fs-action=': syntax error

I was more interested in how it works with the present scripts.

[amigo]

You will no doubt find many, many things that do not work if trying it with recent gtkdialog(3) or gtkdialog(4) scripts. gtkdialog3 (thats from 0.7.0 to 0.7.20 adds a few widgets and subtly uses extra attributes which are not supported by this version. gtkdialog4 (thunor's work) adds widgets *by the dozens*. We will porbably never catch up with that, although we are planning to backport fetures adn fixes from the 0.7.x series, at least.

The point of this tool is to be able to use the same scripts with either the gtk1 or gtk2 toolkit -without needing to make any changes to the scripts. Probably only the earliest puppy gtkdialog scripts will work unchanged with this tool as it is now. As goingnuts said, see the included examples to see what should be working -there is lots of room for improvement in the examples and documents which we are working on.

[jpeps]

gotcha....thanks