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:

#21 Post by technosaurus »

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.

Code: Select all

 
mkfifo /tmp/useractions
mkfifo /tmp/scriptactions

sdialog -args... </tmp/scriptactions >/tmp/useractions &

while read LINE; do
case "$LINE" in
...
esac
done </tmp/useractions >/tmp/scriptactions &
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:

#22 Post by goingnuts »

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: Select all

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;
	}

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

#23 Post by technosaurus »

did you try something like
while ( ! fd ) usleep (1000);

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

#24 Post by goingnuts »

Thanks - yes I did try that. After some more hours I think I got the answer: It might not be possible... The actions are fired by the

Code: Select all

gtk_signal_connect(GTK_OBJECT(Widget), "clicked", GTK_SIGNAL_FUNC (button_pressed), (gpointer) act);

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". :cry:

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

#25 Post by technosaurus »

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

#26 Post by goingnuts »

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...
Attachments
snap0004.png
(59.71 KiB) Downloaded 1624 times

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

#27 Post by goingnuts »

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:

Code: Select all

#!/bin/bash

my_func () { echo $1; }
export -f my_func

export MAIN_DIALOG='
<vbox>
 <frame List>
  <list>
   <variable>LIST</variable>
   <input>ls</input>
   <action>my_func "${LIST}"</action>
  </list>
 </frame>
</vbox>
'
.././gtkdlg1 --program=MAIN_DIALOG
...and the ash-version (updated according to Technosaurous post below):

Code: Select all

#!/bin/ash
echo '
my_func () { echo $1; }
#export -f my_func
' > /tmp/ashfunc

export MAIN_DIALOG='
<vbox>
 <frame List>
  <list>
   <variable>LIST</variable>
   <input>ls</input>
   <action>my_func "${LIST}"</action>
  </list>
 </frame>
</vbox>
'
.././gtkdlg1 --program=MAIN_DIALOG -i  /tmp/ashfunc
...the last could be the default method.
Last edited by goingnuts on Fri 24 Feb 2012, 06:21, edited 1 time in total.

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

#28 Post by technosaurus »

yeah, I had a similar workaround, but don't remember what script it is in. It went something like this though

export Myfunction='..... \
.....'

then use eval $Myfunction

btw, the whole premise of my bashbox stuff was to make this easier - you can call a function by

Code: Select all

bashbox <function>
... or just

Code: Select all

function
if there is a symlink to bashbox

that was before I discovered the -i argument (to include files)
just put all of your functions in a function file and use

Code: Select all

. functionfile
and

Code: Select all

gtkdlg1 -i functionfile ...
(no need to generate it on the fly if that is working)
(I swore I saw that in the gtkdlg1 sources but maybe I am misremembering ... that was the source vs. 'dot' patch I mentioned right?)
Attachments
source_gtklauncher.patch.gz
I guess I missed one
(272 Bytes) Downloaded 659 times
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].

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#29 Post by disciple »

Guys, this is fantastic!
If you got this up to gtkdialog4 compatibility then a gtk1-only distro would be a really good proposition again.
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

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

#30 Post by goingnuts »

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

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.

Post Reply