gtkdialog1-1.4
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.
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.
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:
Now every code-snip of gtk2 like
is recognized by gtk1 and we avoid code like:
Same should be doable for functions - just put the bulk of the new functions in compat.c
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
Code: Select all
g_signal_connect(G_OBJECT(widget), "button-press-event",
(GCallback) (on_any_widget_button_pressed),
(gpointer) Attr);
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
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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)
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
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].
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...
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...
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?
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?
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:
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:
- Attachments
-
- snap0011.png
- (11.49 KiB) Downloaded 591 times
"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!
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
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.
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.
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].
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:
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...
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);
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...
- Attachments
-
- snap0013.png
- chooser_test running showing embedded fileselect
- (18.2 KiB) Downloaded 517 times
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.
Note that, internally, mytreefilesel uses a ctree instead of a regular tree.
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.
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.
- Attachments
-
- embedded_gtk1_fileselect.tar.gz
- (4.2 KiB) Downloaded 308 times
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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
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?)
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-server had better explanations for gtk1 than gtk's sitegtk_file_selection_set_filename(GTK_FILE_SELECTION(sel), "");
dir_base = gtk_file_selection_get_filename(GTK_FILE_SELECTION(sel));
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?)
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].
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.
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.
- Attachments
-
- gtk1_fileselect_inline.tar.gz
- (10.82 KiB) Downloaded 295 times
-
- snap0014.png
- (10.13 KiB) Downloaded 411 times
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:
change to:
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?
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); }
Code: Select all
\<tree\> { Token="<table>"; return(TABLE); }
\<\/tree\> { Token="</table>"; return(ETABLE); }
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?
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
"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
I think some people would be quite keen on a video in a gtkdialog windowWe could probably pretty easily create other similar widgets which migth be useful -a browser in our gtkdialog window... what could we do with that??
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
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).
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).
- Attachments
-
- treeview.png
- The Xdialog tree - 24 levels in 110 lines of code
- (5.8 KiB) Downloaded 622 times
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:
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!
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); }
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!