gtkdialog1-1.4

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#61 Post by disciple »

Just to complete what I was thinking about when I asked: it might be worth asking Thunor if it could be added to the main gtkdialog svn repo at google code.
Personally I find it much easier to keep something in svn :)
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:

#62 Post by goingnuts »

I think this projects aim and target user differ from the ones of the official gtkdialog. So linking it to that might be to overdo (or even miss do) things. This backport is in the category "hobby-project" - propably with a very limited audiens now and audiens will probably be decreasing as time goes by. Using depreciated toolkits seems not to be attractive nowadays.

The strength of the backport should be speed, size, limited number of dependencies and shared syntax for the gtk1 & 2 version.

The new gtkdialog versions implement many usefull things but also get more and more complex. In the end its a balance between the usefullness of making toolkits on toolkits on toolkits, the ease of making the software "from-scratch" and your target users.

If we can carry this thing up to the level where it accepts syntax up to the 0.7.20 version (without support for every syntax/widget there) and a resonable number of usefull widgets keeping the compatability with gtk1 & 2 - I quess thats it.

I have thought of whether the project even qualify being on this forum - but as the main content here will be related to programming (depreciated) gtk - I guess it does in some sense...

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#63 Post by amigo »

I agree. I was just taking a peek into thunors repo and noticed this:
"This release adds 14 new widgets, 37 new examples, a full widget reference, and much more." Sounds a bit out-of-hand to me. Don't get me wrong I think thunor is doing a fine job -I just question the utility of many of the widgets for this type of tool. There comes a point where the complexity of writing a sane script-based GUI is cumbersome, at best, and maybe disastrous at worst. People shouldn't really be trying to code a file manager or something like that in shell anyway.

GN, I'm glad to see you pin this down:"syntax up to the 0.7.20 version"
And a agree that it would be st to leave out any widgets implemented up to that point which can't be implemented well for gtk1, like the 'tree' widget which we are currently leaving out. There are new widgets which are introduced before 0.7.20 which may be interesting. One of them is the 'notebook'. technosaurus has posted some code for that which could probably be wrangled in. The 'tree' code for gtk1 would also be interesting, if you ever figure that out. Especially interesting because if you figure it out, you may be able to do a long-sought-trick and add a tree-view to the rox filer. Lots of people have wished for that.

I think that once the feature-richness is up to an acceptable level, it would be fairly easy to review thunors code for any bug-fixes which would apply to the older sources.

Another day, another archive. Attaching latest tarball

It contains the latest fixes you sent me, and I have moced the rox pixbuf-scaling routines into a separate file misc.c

This builds and runs fine here for both gtk1 and gtk1, but I do get these warnings when compiling for gtk2:
automaton.c: In function 'xpm_label_box':
automaton.c:99:8: warning: assignment from incompatible pointer type
automaton.c:101:8: warning: assignment from incompatible pointer type
automaton.c:103:8: warning: assignment from incompatible pointer type
automaton.c:105:8: warning: assignment from incompatible pointer type
automaton.c:111:17: warning: assignment makes pointer from integer without a cast
automaton.c:127:18: warning: assignment makes pointer from integer without a cast
automaton.c:128:18: warning: assignment makes pointer from integer without a cast
automaton.c:130:18: warning: assignment makes pointer from integer without a cast
automaton.c: In function 'create_menuitem':
automaton.c:585:3: warning: passing argument 3 of 'gtk_signal_connect_full' from incompatible pointer type
/usr/include/gtk-2.0/gtk/gtksignal.h:119:8: note: expected 'GCallback' but argument is of type 'void (*)(struct GtkWidget *, struct AttributeSet *)'
actions.c: In function 'action_fileselection_made':
actions.c:181:5: warning: passing argument 2 of 'fill_edit_by_file' discards qualifiers from pointer target type
widgets.h:38:6: note: expected 'char *' but argument is of type 'const gchar *'
actions.c:189:5: warning: passing argument 2 of 'variables_set_value' discards qualifiers from pointer target type
variables.h:39:11: note: expected 'char *' but argument is of type 'const gchar *'
They are the same as before, except the 'integer without a cast' ones which result when having moved the scaling code from automaton.c to misc.c. Perhaps you can clean up my mess, if needed. Also, couldn't the USEPIXBUF simply be eliminated if we are always using it anyway?

Apart from that, this is ready to be released, I think.

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

#64 Post by Aitch »

The 'tree' code for gtk1 would also be interesting, if you ever figure that out. Especially interesting because if you figure it out, you may be able to do a long-sought-trick and add a tree-view to the rox filer. Lots of people have wished for that
Oh yes! :D

Aitch :)

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

#65 Post by goingnuts »

amigo: Well done - we fix this as a starting point! Found again that make goes into an endless loop but after running "touch" on all the source files everything works (you are somewhere in the future and my make seems not to like that :) ).
The "warning: assignment from incompatible pointer type" can be eliminated by changing configure.in:

Code: Select all

if test "$ac_cv_gtkversion" = "2.0"; then
	dnl support for gtk+2-2.24 is going to need PIXBUF setup
	dnl since it has been split from gtk sources (again)
	AC_DEFINE(USE_GTK2)
	AC_DEFINE(USEPIXBUF)
fi
The " warning: assignment makes pointer from integer without a cast" I will have to look into. I already spotted some bugs in action windowclose for gtk2 and the save action for both gtk1&2. I will work on those.

Next step besides testing gtk2 versus gtk1 will be to control the parser. Think it is important to verify that we can add widgets or expand the syntax..

Aitch & amigo: The tree...that is probably another project.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#66 Post by amigo »

As for the parser, just have a look at the last patch from 0.58.10 to 0.58.11 where the tree and gvim widgets were added. You'll see a pretty good overview of what has to be changed in parser.y and lexer.l. The next patch from 0.58.11 to 0.59.0 also has an example of just changing parser.y -to add an attribute to some tag IIRC. It may be that parser.y dose not change everytime -parser.y seem to describe the language syntax at a higher level and lexer.l describes the tags.
You might try adding the gvim widget back in as an exercise in patch-reading. The bison/flex language does look funny, but I think the official patches provide plenty of examples to show how to add either attributes or tags.

"you are somewhere in the future" Hehe, people used to say I was ahead of my time. Now they say I am 'old for my years'. Like fine wine, my tarballs must mature, for at least an hour anyway -as a form of protest against the twice-yearly time changes I never reset my computers' clock and don't set it up to adjust automatically either. Sorry. Next time I'll create it at the end of a day and post it the following morning... You hadn't mentioned the problem before.

If/when you ever get interested in the tree widget again, I'll point you to two or three sources with example implementations.

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

#67 Post by technosaurus »

amigo wrote:"you are somewhere in the future" Hehe, people used to say I was ahead of my time. Now they say I am 'old for my years'. Like fine wine, my tarballs must mature, for at least an hour anyway -as a form of protest against the twice-yearly time changes I never reset my computers' clock and don't set it up to adjust automatically either. Sorry. Next time I'll create it at the end of a day and post it the following morning... You hadn't mentioned the problem before.
That makes 2 of us, but a year or 2 ago, I intentionally changed mine to build a fresh tarball from a different time zone and didn't want to wait to build it. but found that a workaround would have been:
touch `find .`
and yet I am still in the future looking back at now

btw what is the "gvim" widget?
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].

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#68 Post by amigo »

The gvim widget is an editor widget -I haven't looked forward too much to see whether it was made to work well or was eventually ditched. It was a new widget in 0.58.11 as was the tree. We have simply cut them both out for now. Glad to see you are still interested in this. BTW, you are in the AUTHORS file and ChangeLog -care to PM me your preferred entry there? Name, email, etc -if you want.

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

#69 Post by goingnuts »

Did a quick test to add a WIDGET_FILEBUTTON (been missing that!).
Added

Code: Select all

\<button\ file\>      { Token="<button>"; return(BUTTONFILE);  }
to lexer.l

Code: Select all

%token BUTTONOK BUTTONCANCEL BUTTONHELP BUTTONYES BUTTONNO BUTTONFILE

/*and later:*/

| BUTTONFILE attr EBUTTON     {token_store(PUSH | WIDGET_FILEBUTTON);}
to parser.y

Code: Select all

#define WIDGET_FILEBUTTON     0x00320000
to automaton.h

Code: Select all

case WIDGET_FILEBUTTON:	//20120306 add
		type = "FILEBUTTON";
		break;
to widgets.c

plus the needed support code and pixmaps to automaton.c.
...it works...

Do you know if the values assigned in automaton.h for each widget have any meaning:

Code: Select all

#define WIDGET_NOBUTTON       0x000D0000
#define WIDGET_YESBUTTON      0x000E0000
#define WIDGET_SCROLLEDW      0x000F0000
...the 0x000E0000...?? Or does it just have to be a unique identifier?

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

#70 Post by technosaurus »

I've been meaning to take a look at the builtin xpm images again because I wondered if it would be nicer to only use a file (probably in usr/share/pixmaps?) instead of a built-in image by default ... if the file doesn't exist, we could use the builtin or my preference would be to use a null image. This would make it more "theme-able" than even the gtk2 version.

static char *null_xpm[] = {"1 1 1 1"," c None"," "};

Edit:
here is a tarball with pixbufs.h containing the const char version with ifdef to include the actual pixmaps as necessary
(having it in the image breaks mtpaint's ability to read them)
I also cut the file sizes in half first (64 colors should be plenty for 20 by 20)
Attachments
pixbufs.tar.gz
(3.24 KiB) Downloaded 364 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].

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

#71 Post by goingnuts »

technosaurus: Elegant - thanks! I will add that. I will replace the cancel.xpm with a fileopen.xpm as no.xpm covers the cancel.xpm.
Concerning theme-able...the colors can be controlled by the .gtkrc-file but I wonder how to implement the GTK_STOCK_XXXX function from gtk2 to gtk1? We might point to gtk2 image source but on a gtk1 only system that wouldn't work...

Is gtk1 theme-able by icons at all?

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

#72 Post by technosaurus »

Can we just use a corresponding xpm from /usr/share/pixmaps?
That would allow the theming I was talking about, just by using a custom icon set. one of Zigbert's tools can even modify the overlay colors.
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].

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#73 Post by amigo »

I've also thought about themeability. One could copy the 'create_from_stock' code from gtk into our misc.c file for use with gtk. Or implement it ourselves using a create_pixmap_from_file to llok for a *.png image. The best location,if using png's, might be under /usr/share/icons/default/16x16/? or some such location. Maybe /usr/share/gtkdialog/default/ would be even better -it's just a few 'stock' icons anyway. I believe we already have code there which tries to load an external image and falls back to the internal one if not found.

Code: Select all

#define WIDGET_NOBUTTON       0x000D0000 
#define WIDGET_YESBUTTON      0x000E0000 
#define WIDGET_SCROLLEDW      0x000F0000
Unfortunately I have not figure out what significance those values have yet. It does look like one could simply follow the above with:
0x000G0000 -but probably not as hex has no 'G'! Look further ahead in the series to see what they do there?

I think we should just get rid of the '#ifndef USEPIXBUF' sections since they are unused.

No, gtk1 is not themeable. This is why I mentioned adding some code from gtk2 for STOCK icons. One of the ideas that I've always had about modernizinh gtk1 itself would be to add themeable stcok icon support, maybe the ctree and newer text code(which would need pango)....

BTW, last night I downloaded the rest of the original tarballs through 0.7.20. Starting with 0.7.4, and through to 0.7.20, there is glade support we'd want to get rid of. Between 0.59.8 and 0.7.4 there is also a lot of re-written/re-organized code so it gets a little confusing trying to compare with the base we are currently using. The number of added widgets/tags is pretty small though.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#74 Post by amigo »

Here's the latest tarball which uses the pixmaps from a header, removing the old images. It also removes the unfinished gtk2-notebook code, a rule in lexer.l which throws warnings from later versions of flex, and a couple of unused declarations.

This compiles without any gcc warnings at all for gtk1. If this looks alright to you, then I'll prepare it as a release tarball with the generated autotool files left intact for normal use. I suspect that new code is going to come in an ad-hoc order, so maybe there is no sense in shadowing the original versions at all, so we could just call this 1.0, if you like. Then we can get on with the fun!

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

#75 Post by goingnuts »

Update: Tested the new tarball - build errorfree gtk1 and works. gtk2 have a few errors still but works! Well done again amigo! :)

Still working in the b-version trying to control the parser. The problem is that syntax changes a bit going from 0.58 to 0.59. I have the notebook working with gtk1 & gtk2 in b-version - but have problems with the label names.

The widgets we miss to get to same level as 0.7.20 seems just to be the notebook. Well...if we leave WIDGET_MENUSEP and WIDGET_PROGRESS out which would not be a big loss I think. The progress can be handled by Xdialog if it turns out to be difficult for gtk1.

Some bugs found in the b-version: gtk2 closewindow: Comment out the gtk2 code for now and use the gtk1 method.

fileselect give some casting error when file is selected in gtk2. I haven't looked into that. And for both gtk1&2 we end in endless loop if filesave is not chosen by the fileselector (but hard-scripted as an action).

Also some fixes for the button alignment/label justification between the gtk1&2 need to be done (differs if in hbox and vbox between the to gtk versions).

technosaurus pixbuf.h works fine. :)

I think we should stay close to the 0.58.10 and make things working there or - start all over from 0.7.20. If target is syntax compatibility starting all over might be the right thing to do.

I will not have too much time to focus on this for the next 3-4 days but will try catch up when ever time permits it.
Attachments
snap0006.png
gtk1 notebook
(7.92 KiB) Downloaded 571 times
snap0003.png
gtk2 notebook
(11.32 KiB) Downloaded 521 times

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#76 Post by amigo »

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
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#77 Post by goingnuts »

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

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

#78 Post by technosaurus »

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

#79 Post by goingnuts »

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
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#80 Post by amigo »

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?

Post Reply