Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 21 Oct 2014, 01:17
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
GtkDialog1-1.3
Post new topic   Reply to topic View previous topic :: View next topic
Page 5 of 14 [207 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, ..., 12, 13, 14 Next
Author Message
disciple

Joined: 20 May 2006
Posts: 6447
Location: Auckland, New Zealand

PostPosted: Tue 06 Mar 2012, 00:41    Post subject:  

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 Smile

_________________
DEATH TO SPREADSHEETS
- - -
Classic Puppy quotes
- - -
Beware the demented serfers!
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 781

PostPosted: Tue 06 Mar 2012, 07:02    Post subject:  

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...
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Tue 06 Mar 2012, 08:32    Post subject:  

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

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.
GtkDialog1-0.58.10b.tar.bz2
Description  Includes discussed fix-ups from the last couple of days
bz2

 Download 
Filename  GtkDialog1-0.58.10b.tar.bz2 
Filesize  312.96 KB 
Downloaded  256 Time(s) 
Back to top
View user's profile Send private message 
Aitch


Joined: 04 Apr 2007
Posts: 6825
Location: Chatham, Kent, UK

PostPosted: Tue 06 Mar 2012, 11:34    Post subject:  

Quote:
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! Very Happy

Aitch Smile
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 781

PostPosted: Tue 06 Mar 2012, 12:08    Post subject:  

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 Smile ).
The "warning: assignment from incompatible pointer type" can be eliminated by changing configure.in:
Code:
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.
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Tue 06 Mar 2012, 13:03    Post subject:  

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.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Tue 06 Mar 2012, 13:58    Post subject:  

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?

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Tue 06 Mar 2012, 14:38    Post subject:  

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.
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 781

PostPosted: Tue 06 Mar 2012, 15:27    Post subject:  

Did a quick test to add a WIDGET_FILEBUTTON (been missing that!).
Added
Code:
\<button\ file\>      { Token="<button>"; return(BUTTONFILE);  }
to lexer.l
Code:

%token BUTTONOK BUTTONCANCEL BUTTONHELP BUTTONYES BUTTONNO BUTTONFILE

/*and later:*/

| BUTTONFILE attr EBUTTON     {token_store(PUSH | WIDGET_FILEBUTTON);}
to parser.y
Code:
#define WIDGET_FILEBUTTON     0x00320000
to automaton.h
Code:
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:
#define WIDGET_NOBUTTON       0x000D0000
#define WIDGET_YESBUTTON      0x000E0000
#define WIDGET_SCROLLEDW      0x000F0000


...the 0x000E0000...?? Or does it just have to be a unique identifier?
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Tue 06 Mar 2012, 16:07    Post subject:  

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)
pixbufs.tar.gz
Description 
gz

 Download 
Filename  pixbufs.tar.gz 
Filesize  3.24 KB 
Downloaded  257 Time(s) 

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 781

PostPosted: Tue 06 Mar 2012, 17:14    Post subject:  

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?
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Tue 06 Mar 2012, 18:12    Post subject:  

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.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Wed 07 Mar 2012, 02:01    Post subject:  

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:
#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.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Wed 07 Mar 2012, 09:37    Post subject:  

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!
GtkDialog1-0.58.10c.tar.bz2
Description  Release candidate 'c'
bz2

 Download 
Filename  GtkDialog1-0.58.10c.tar.bz2 
Filesize  433.82 KB 
Downloaded  256 Time(s) 
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 781

PostPosted: Wed 07 Mar 2012, 13:44    Post subject:  

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

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

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.
snap0006.png
 Description   gtk1 notebook
 Filesize   7.92 KB
 Viewed   479 Time(s)

snap0006.png

snap0003.png
 Description   gtk2 notebook
 Filesize   11.32 KB
 Viewed   475 Time(s)

snap0003.png

Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 5 of 14 [207 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, ..., 12, 13, 14 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1143s ][ Queries: 12 (0.0057s) ][ GZIP on ]