Keep up the good work. At some point I might work on patching the full sources so that config-time option for gtk1 can be used.

Text and tree code is the hardest to convert. For tips and example code, look at older source which allowed using either gtk1 or gtk1. rox-1.2.2 is one example. I'll have to dig to make more suggestions. even if you never get every possible widget working, having a few of the basics working will be great in order to use the same scripts with either toolkit.

Thank you amigo - your offer is much appreciated - and your input on the tree/text widgets have convinced me that at least the tree should be left out. Concerning using the gtk-pixbuffer: I have no clue how to do it. For me the main thing missing right now is to be able to use more image-types - not just xpm - so if that can be done easily (with or without) gtk-pixbuffer...?

Technosaurous: Thanks for the pointers - I will add those!

There are other low hanging fruits: word-wrap to the edit-widget + default value and the geometry switch also seems easy done.

I have not been making a lot of shell gtk scripts until now - and begin to understand your blended feelings about the "xml-syntax". Maybe a more stringent structure is needed. Haven't thought this totally through but it seems that some of the tags means different things depending on which widget they are serving. I have done a lot of html and do not find that hard to write/read and maybe a clean up of the tags are needed? Maybe only "clean" tags (<button> and no <button ok>, <input> and no <input file>)? Some of the tags express both what I would call state and value (ex: <default>)...

At least a mapping of the present hierarchy of widgets, childs, childs child, attributes and actions should be done.

As for other programs to "scrape" the Xdialog-2.3.1 is quite relevant.

For an example of stacking widgets, see greq:
http://distro.ibiblio.org/pub/linux/distributions/amigolinux/download/DeskTop/MsgDialog/greq-0.9.4/

It uses a little known feature of bash -PIPE_STATUS to return the results. It also lets you add a checkbutton after any normal widget.

As for re-inventing the wheel, it might be best to just hack one of the existing programs, but that's just me thinking. I'd really like to see a gtk1 version of gtkdialog which implements as many of the features of the gtk2 version as possible, using the same syntax. The dual-toolkit compatibility is the magic of it.

I think most of problem you are having with the includes must come from not having configuration done properly at the top-level of the sources. Most gtk1/gtk2 capable programs manage to live in the same files without having to do major re-writes -just some -maybe lots, of ifdefs.

I wish I could be more helpful but my hands are tied right now with other things.

I have built lots of small 'programs' using scriptable widgets made from Xdialog, greq, gtk-shell and the other things found here:
http://distro.ibiblio.org/pub/linux/distributions/amigolinux/download/DeskTop/MsgDialog/greq-0.9.4/

I like the ability to create more complex UI's that is possible with gtkdialog, but do not like the startup latency of any gtk2 apps. The libxml overhead is probably livable...

gdk-pixbuf should load any of the common types of images/icons -png-support would be the best choice if only one is to be supported. rox has good example of gdk-pixbuf support -if you look through my rox-1.2.2.x sources you'll find a patch where I made it use png toolbar icons instead of xpm's. I still think it might be a good idea to run the whole idea by thunor as he may be able to get some things going which are harder for you -maybe the whole enchilada...

technosaurus & amigo: Thanks for input! Might be difficult to make it gtk2 compatible as this include hacking the parser as far as I can see (to accept the newer script syntax). To start from scratch is tempting when one view the simple structure of the possible coding...but may be too big a project for now...
Spend some time in hacking the edit and fileselect to play well with a menu-driven small text-editor but hit a problem with interference with the event-triggers trying to implement a "save as..." function...
I miss the ability to assign values to internal variables from script, run an external function (script) to change/add values...or just an invisible widget or two that act as the normal widgets...

I am working on "sdialog" ... just to learn C really ... I have it set up to use simple templates for each widget. I did study the api enough to use an array of widgets so that they remain available for modification (it would be smaller/simpler to use a single widget pointer to temporarily store non-container type widgets, but then we couldn't reference them for change) , but correct me if this is wrong. It may be possible to emulate zenity/yad in this manner (syntactically, not necessarily graphically), but I was thinking more along the line of gtkdialog's ability to manipulate the interface.

I was considering using a pipe based interface such that we could pipe the output out to a fifo that could be read by a while-read-case loop that can output to another fifo that is used for interacting (via input from the fifo)

I know this seems ridiculous to write yet another dialog program, but none of them seem to be simple _and_ versatile.

The different action possibilities for the widget are a nice feature but we might have to modify/adjust them. The present problem with making a simple text editor for example seems to be that the <action>fileselect>/action> spawns the filedialog but does not wait for it to complete before running next action. The present code is below and I have tried to implement a wait for child process but without succes. Any hints are welcome:

Code:

if (strncasecmp(str, "fileselect:", 11) == 0) {
action_fileselect(button, &((char *) str)[11]);
//GN how to wait here for this to close before running further actions?
return;
}

I haven't messed much with fselect yet, but it must change some other values too, because the user may choose not to select a file and it would freeze... perhaps its return value_________________Check out my github repositories. I may eventually get around to updating my blogspot.

where act is the command and this is initially set to the button-actions...
Therefore it seems impossible to put execution on wait in any of the loops before or after the fileselect call. sleep just stops the execution at the specific point in the loop.

I guess that the signals for the other actions (after a button press) are just sitting there waiting to be fired (or already are starting execution) and the only thing one put to sleep is the actual fileselect call.

What was needed was a fileselect-call and after that an update-call (from the same button press) - but if you try to sleep and wait for the fileselect the dialog box never shows up and program "hangs".

the tutorial talks about timeouts and idle functions, which seem like they could be used for a hack, but I haven't played with them yet._________________Check out my github repositories. I may eventually get around to updating my blogspot.

Edit 200212: Uploaded new snapshot. Most warnings gone, deactivated tree. A lot of edits in sources...
Now an editor can be made, example in source. Modified afishe2000´s pmenu to test tables/buttons/actions ect. also attached in examples.
Now with build in images for the stock buttons to ease use.
Maybe a small comment on the fileselect action: Every call to fileselect widget causes the main loop to continue after gtk_signal_connect is run in the fileselect window. The ideal solution would be a capture of all actions meant to run after fileselect and then run them when file select done. To overcome some of this I hard coded capture of 1 instance of action save and 1 instance of action refresh. Also implemented an internal variable named OUTFILE that will hold last selected file and the value is exported as OUTFILE=$OUTFILE - so it can be used in the script globally (view some usage in the edit_test example).
Would have liked to include notebook but I just cant understand the parser system.
Below image of the modified pmenu running...

Fixed list widget so now should be working as intended.
Word-wrap now default for text. gvim widget compiles...have not testet as I do not have gvim.
Added gtkrc-file support.
Examples of pmenu, bootmanager, wideowizard and wakepup in examples.
Found that scripts for gtkdialog sometimes use the "export -f" leaving ash-people in the dark...

To convert the export -f the below is quite simple to do:
The bash version:

Guys, this is fantastic!
If you got this up to gtkdialog4 compatibility then a gtk1-only distro would be a really good proposition again._________________If you have or know of a good gtkdialog application, please post a link here

technosaurus: Thanks - the "-i" method is really sweet. Updated example above accordingly.
disciple: Guess that gtkdialog4 compatibility would be to hard/much work. If gtkdlg1 can run most scripts by (gentle) editing the script-syntax of scripts meant for younger gtkdialog versions - I am satisfied. Seems that the missing notebook-widget and the ability to use other image formates that xpm is the big missing things for now...

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