Puppy Linux Discussion Forum

[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

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

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:

[Aitch]

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

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

[technosaurus]

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

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

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

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

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

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

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

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.