gtkdialog1-1.4

Message

amigo · #76 Post by **amigo** » Wed 07 Mar 2012, 20:52

I'm anxious to see your notebook code.

This afternoon I took another tactic. I looked pretty hard at the 0.7. x series code and from the very first 0.7.4 it has really big changes all the way through, while 0.59.8 still looks much the same as 0.58.11. So, I started over with fresh 0.59.8 sources and did as I had with 0.58.1. I simply changed the configure.in and src/Makefile.am so that it would configure for gtk1. Then, I started running 'make 2> errors.txt' and looked at the result. For each error I found the spot in the sources and put 'ifdef USE_GTK' around the non-working lines. After about a half hour I had the thing compiling and linking -with nearly nothing working of course. Then, I cross-referenced with the last code from 0.58.10c and started pasting in your working code for the '#else'. In some places you seem to have replaced the original gtk2 with an equivalent which would work for either gtk1 or gtk2 -which is porbably a good thing in the long run. However, for now I have left the original gtk version and added the '#else' for your working gtk1/dual code. I also added in the pixmaps.h and misc.c which now holds the pixbuf-scaling routines. After just a little while I had the thing compiling and able to run the most basic widgets like the buttons, pixmaps, etc. I think there is still more to be done in some of the other files, but it will have to wait till tomorrow. I've left the original stuff in place with hardly any formatting changes (just a few of the same ones you had changed).

I think that it may be helpful to get this working and then aim for the 0.7.x series from this starting point. The changes in 0.7.x are, from the first, too many and complex for my abilities. You might find it easy enough to simply jump to 0.7.20 and dig in as you did before. Or it might be easier to start from this new base and work up through the original changes.

If you do start from 0.59.8, I'd recommend that you go through each official patch one-by-one and incorporate all the upstream changes, plus any minor details to make gtk1 work there as well. Hold off on adding extra features and even fixes for potential problems you see, until you get to the last version you want to target. Then, go through the whole code, make the formatting changes you want as a single patch/release without any real code changes *at all* -just formatting, whitespace, etc, whatever bother you. Then, go through again and start adding the fixes that see are useful, and then, finally, add in any extra features you have dreamed up along the way.

You don't need to make a new release for *every* one of the official versions which you have upgraded to -but I would, if I were you. Keep your versions limited to a manageable size, keep them easy to get an overview of and you won't be sorry. Usually when I do something like this, I create intermediate patches for each feature or fix which I implement. The patches may be useful to you later when you work on something else. Having each one contain just one 'bite', but a complete 'bite' of code which does just one thing, makes this lots easier.

We'll see how I do on the rest of 0.59.8 tomorrow. If it seems to be mostly working, we can easily switch to working there. If you have a chance to post or PM me your notebook code, I'll look at putting it into the base I am currently on -at the moment it is disabled, as are any other widgets which don't have corresponding gtk1 code.

goingnuts · #77 Post by **goingnuts** » Fri 09 Mar 2012, 15:52

I am touching the 0.7.20... Following amigos advices above to leave the original code intact if possible. On top of that I would like to make a more general approach to back porting. So to avoid some of the "#ifdef USE_GTK2 stuff" and rewriting for (almost) simple syntax differences between gtk1&2 I have been experimenting with redefining gtk2 stuff that gtk1 does not understand. Made a new code and a new header file, compat.c and compat.h. compat.h is included in gtkdialog.h (just add #include "compat.h" to gtkdialog.h).
Content in compat.h is like this:

Code: Select all

#ifndef USE_GTK2
#define G_OBJECT	GTK_OBJECT
#define GCallback	GtkSignalFunc
#define g_signal_connect	gtk_signal_connect	

#define G_CALLBACK GTK_SIGNAL_FUNC

#endif

Now every code-snip of gtk2 like

Code: Select all

g_signal_connect(G_OBJECT(widget), "button-press-event", 
			(GCallback) (on_any_widget_button_pressed), 
			(gpointer) Attr);

is recognized by gtk1 and we avoid code like:

Code: Select all

#ifdef USE_GTK2
	g_signal_connect(G_OBJECT(widget), "button-press-event", 
			(GCallback) (on_any_widget_button_pressed), 
			(gpointer) Attr);
#else
gtk_signal_connect(GTK_OBJECT(widget), "button-press-event", 
			GTK_SIGNAL_FUNC (on_any_widget_button_pressed),
			(gpointer) Attr);
#endif

Same should be doable for functions - just put the bulk of the new functions in compat.c

technosaurus · #78 Post by **technosaurus** » Sat 10 Mar 2012, 03:50

aren't macros great!
I was doing about the same thing with sdialog, but got sidetracked so its not very useful as is, but may save you time looking it up...
some(/most?) of them may actually need to be functions (if one function maps to several like gdk_atom_*) or at least have the function parameters defined in the macro (where number/position of args changes)

Code: Select all

/*
This data was gleaned from
http://developer.gnome.org/gtk/2.24/api-index-deprecated.html
http://developer.gnome.org/gtk/2.24/gtk-changes-2-0.html
http://developer.gnome.org/gtk/2.24/api-index-2-2.html and 2-4...2-24
and google search for gtkcompat.h turned up several hits
*/

#ifndef USE_GTK2
//this is just a bunch of stubs, using it will likely fry your box :P
#define 	G_PARAM_READABLE			GTK_ARG_READABLE
#define		G_PARAM_WRITABLE			GTK_ARG_WRITABLE
#define		G_PARAM_CONSTRUCT			GTK_ARG_CONSTRUCT
#define		G_PARAM_CONSTRUCT_ONLY		GTK_ARG_CONSTRUCT_ONLY

#define		g_signal_connect			gtk_signal_connect
#define		G_CALLBACK					GTK_SIGNAL_FUNC
#define		g_signal_emit_by_name		gtk_signal_emit_by_name
#define		gtk_adjustment_get_value(adj)	adj->value
#define 	gtk_binding_entry_remove	gtk_binding_entry_clear
#define		gtk_binding_entry_add		gtk_binding_entry_clear
#define 	g_type_check_instance_cast	gtk_type_check_object_cast
#define		g_type_check_class_cast		gtk_type_check_class_cast
#define 	g_type_children				gtk_type_children_types
#define 	g_enum_register_static		gtk_type_register_enum
#define 	g_flags_register_static		gtk_type_register_flags
#define 	g_type_parent				gtk_type_parent_class
#define 	g_type_class_peek_parent	gtk_type_parent_class
#define 	g_type_class_ref			gtk_type_class
#define 	g_type_class_unref			gtk_type_class
#define 	g_type_class_peek			gtk_type_class
#define 	gtk_window_list_toplevels	gtk_container_get_toplevels
#define 	GPatternSpec				GtkPatternSpec
#define 	G_TYPE_FUNDAMENTAL			GTK_FUNDAMENTAL_TYPE
#define 	G_TYPE_DERIVE_ID			GTK_TYPE_MAKE
#define 	G_TYPE_BRANCH_SEQNO			GTK_TYPE_SEQNO
 
#define 	GTK_<OBJECT>_GET_CLASS(object)	object->klass //todo
#define 	GTK_CLASS_TYPE (class)		object->type

#define 	gdk_drawable_get_size		gdk_window_get_size
#define 	gdk_window_get_window_type	gdk_window_get_type
#define 	gdk_drawable_get_colormap	gdk_window_get_colormap
#define 	gdk_drawable_set_colormap	gdk_window_set_colormap
#define 	gdk_drawable_get_visual		gdk_window_get_visual
#define 	gdk_gc_unref				gdk_gc_destroy
#define 	gdk_drawable_unref			gdk_window_unref
#define 	gdk_image_unref				gdk_image_destroy
#define 	gdk_cursor_unref			gdk_cursor_destroy
#define 	gdk_draw_pixmap(drawable,gc,source_drawable,source_x,source_y,x,y,width,height) \
				gdk_window_copy_area(drawable,gc,x,y,source_drawable,source_x,source_y,width,height)
#define 	gdk_rgb_get_colormap		gdk_rgb_get_cmap
#define 	gtk_toolbar_new()			gtk_toolbar_new( GTK_ORIENTATION_HORIZONTAL , GTK_TOOLBAR_BOTH )
#define 	gtk_widget_child_focus		gtk_container_focus
#define 	set_child_property			set_child_arg
#define 	get_child_property			get_child_arg
#define 	gtk_container_class_install_child_property	gtk_container_add_child_arg_type
#define 	gtk_container_class_list_child_properties	gtk_container_query_child_args
#define 	gtk_container_child_set_property			gtk_container_child_setv
#define 	gtk_container_child_get_property			gtk_container_child_getv	
#define 	gtk_container_add_with_properties			gtk_container_add_with_args
#define 	gtk_container_add							gtk_container_addv
#define 	gtk_container_child_set_property			gtk_container_addv
#define 	gdk_drawable_get_image				gdk_image_get
#define 	gtk_widget_set_size_request			gtk_widget_set_usize
#define 	gtk_image_new_from_image			gtk_image_new
#define		MULTIPLE							GTK_SELECTION_EXTENDED
#define		gdk_x11_get_default_screen			gdk_screen
#define		gdk_x11_get_default_root_xwindow	gdk_root_window
#define		gdk_get_default_root_window			gdk_root_parent
#define		gdk_get_display						gdk_display_name

void gdk_atom_intern (s, bool)	{
		//switch (s[3]) case D,T,P ????
		//"WM_DELETE_WINDOW"	gdk_wm_delete_window();
		//"WM_TAKE_FOCUS"		gdk_wm_take_focus()
		//"WM_PROTOCOLS"		gdk_wm_protocols()
}

#endif //USE_GTK2

goingnuts · #79 Post by **goingnuts** » Sat 10 Mar 2012, 09:19

technosaurus: Yes they are - and thanks for the list!
Now most of the pieces are in place - amigos 0.59 takes unmodified syntax (that is gtkdialog2 in puppy-world) and runs most of the widgets!
(@amigo: I revised it and have send the source).

The 0.7.20 compiles and takes original syntax as well (that is gtkdialog3 in puppy-world) although the widgets are hardly working and somewhat unstable...

amigo · #80 Post by **amigo** » Sun 11 Mar 2012, 09:15

Sorry guys, I've been out of the loop since Thursday -having some blood-pressure problems. I owe you both a PM.

Technosaurus, that compat-header is a great idea and a great compendium of differences between gtk1/gtk2. Could we add some psuedo-stock-icon support got gtk1 in there?

About the syntax -is it just the '--program ???' vs. '--program=???' (MAIN_DIALOG as default) or are there other differences? Could a snippet be written which would accept either syntax?

goingnuts · #81 Post by **goingnuts** » Sun 11 Mar 2012, 10:49

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 · #82 Post by **amigo** » Sun 11 Mar 2012, 13:25

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 · #83 Post by **goingnuts** » Sun 11 Mar 2012, 19:25

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 · #84 Post by **amigo** » Sun 11 Mar 2012, 19:45

"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 · #85 Post by **technosaurus** » Sun 11 Mar 2012, 19:59

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 · #86 Post by **goingnuts** » Mon 12 Mar 2012, 18:47

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 · #87 Post by **amigo** » Tue 13 Mar 2012, 06:43

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 · #88 Post by **goingnuts** » Wed 14 Mar 2012, 19:35

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 · #89 Post by **technosaurus** » Wed 14 Mar 2012, 21:42

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 · #90 Post by **goingnuts** » Thu 15 Mar 2012, 06:00

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 · #91 Post by **goingnuts** » Mon 19 Mar 2012, 19:44

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 · #92 Post by **amigo** » Tue 20 Mar 2012, 08:51

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 · #93 Post by **disciple** » Tue 20 Mar 2012, 09:53

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 · #94 Post by **goingnuts** » Tue 20 Mar 2012, 16:49

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 · #95 Post by **amigo** » Wed 21 Mar 2012, 18:50

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!

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

gtkdialog1-1.4