Thank you, Thank you, Thank you.
I should mention that I only found one thing that evidently was messing with me running your example.
In your modified example in line 23 loaded in Geany, you had "GTKDIALOG=gtkdialog3"
For me, that meant I was trying to run it with the version of gtkdialog that comes with Puppy and nothing seemed to work.

I realized that upon examining your code change and changed the line to "GTKDIALOG=gtkdialog to use the newest version courtesy of thunor and everything then worked!

But to anyone that tries that script, be sure to use the latest version of gtkdialog or you may have to kill the script or restart x to recover.

I still have to look again at the code as it, for me is a learning experience.

Again, Thank you!

And while I am at it, I again want to thank thunor for all the work he has done and again, in case he did not get my latest post on the google code site, I again offer my sincerest apologies to him as I will admit, I must have been a real pain in the a**.

Hi guys, are the tree widget selection modes working correctly? When I run the tree_selection_mode example with latest svn the "browse" and "single" modes seem to be the same. This surprised me, as I would have thought it was something you'd just pass straight on to GTK.

BTW the list selection modes also don't behave quite as I'd expect. Try running the list example, click on the first list item, drag, and release on the second list item. Then click on the second item, drag, and release on the third item. It always selects (or unselects) the item you click on, even if you don't release on it. Is this behaviour correct?_________________DEATH TO SPREADSHEETS
- - -
Classic Puppy quotes
- - -
Beware the demented serfers!

I've remembered something that I think isn't possible currently, and would be a big enhancement. Currently, I don't think there is any way of defining the type of data in a treeview column, or how it should be sorted when you click on the column header. e.g. if you have a column of file sizes, they would sort like this:

Code:

1
200
30

but you would actually want to sort them like this:

Code:

1
30
200

Because of this, in some apps people have implemented menu functions to sort and rebuild the treeview. This is not ideal
Firstly, does anyone know if I am wrong? Is there already a way to control how a column is sorted?
If not, do you think it would be feasible to implement it?_________________DEATH TO SPREADSHEETS
- - -
Classic Puppy quotes
- - -
Beware the demented serfers!

Just thought I'd share my script for updating gtkdialog from svn. It packs up the pets in $HOME, you can adjust it to get rid of the symlink to gtkdialog3 if you wish. Be aware that you must have already downloaded and compiled the first time.

Well, I now have seen 01micko's script, and big_bass's script, so I guess I will show you mine even though it is very simplistic. Also, I guess one could think it dangerous in that it does not allow for alerting one of compile errors. I am unsure if the script would be interrupted if a compiling error occurred.
I used another to initially download the source to /root/gtkdialog.
I then put this script which I called Keep_Current in the /root/gtkdialog directory.

But I was thinking, yeah I know that is dangerous, about uses for the type of code in the example I posted.
If one set the angle to either 90 or 180, it seems that it would display foreign, I forget if it is Chinese or Japanese characters that normally are printed Top to Bottom, Left to Right?
Anyway, it seems it could be used to display that text in the form in which it would normally be printed. The one thing I did not allow for is that the characters would have to be also rotated so that they would not display on their side.
Or am I shooting in the dark here?

Some of the new examples in the gtkdialog/examples directory are interesting as they bring up things I did not know about.
And the examples are still being updated.

01micko,
Why are you making the system link:
ln -s gtkdialog gtkdialog3

It seems to me that this would overwrite the original gtkdialog3 and in the process, defeat the idea of having two separate versions so as not to break some existing puppy scripts?
I am not complaining here, just noting that you have two links to the same updated gtkdialog file.

01micko,
Why are you making the system link:
ln -s gtkdialog gtkdialog3

It seems to me that this would overwrite the original gtkdialog3 and in the process, defeat the idea of having two separate versions so as not to break some existing puppy scripts?
I am not complaining here, just noting that you have two links to the same updated gtkdialog file.

I am refusing to use gtkdialog3 pets in Slacko (as in the old gtkdialog3 executable ), I figure, fix what's broken in the older apps. In the end, everyone's code will be better

I will make one point, piping to stdout is broken in gtkdialog3. The Moose On the Loose patch fixes it and is incorporated in thunor's revisions. As you know I spearheaded a campaign to get rid of gtkdialog2, this was the catalyst, as that's the main reason gtkdialog2 was kept in, so those ancient apps need gtkdialog4. Confused yet! (I am)

Well, I understand your explanation.
If I knew what applications are effected by just using the newest gtkdialog, and what is needed to make them work, I would go your route.
But for now, I have /usr/sbin/gtkdialog gtkdialog3 and a system link of gtkdialog4 pointing to gtkdialog.
I did not use a PET to install them. Rather, I did it directly.

I had found though that what I thought was an original gtkdialog3 file had in fact been modified by me before I reverted by not copying the compiled gtkdialog to /usr/sbin/gtkdialog3.
I went back and mounted an SFS with the original gtkdialog3 file and copied it over.

But till this all gets figured out as to what scripts are effected, I will remain with my present setup.

Use the "use-alpha" tag attribute to manage changing the alpha too (it's false by default)

The widget's variable will contain e.g. "#4488cc" without alpha, "#4488cc|32767" with alpha

The default signal is "color-set", emitted when the user selects a colour

frafa requested GtkColorSelection (GtkColorSelectionDialog as a widget) and I saw a recent Gtkdialog application (JWM Theme Maker) that uses a colour selection dialog from Xdialog so I decided to add this now as opposed to leaving it till the next development period.

GTK+ uses16bit colour components i.e. #rrrrggggbbbb (the dialog shows #rrggbb) but Gtkdialog expects it to be input and outputs it using the more useful #rrggbb.

GTK+ uses16bit alpha 0-65535 (the dialog shows 8bit 0-255) but Gtkdialog has to use 16bit because the GTK+ property "alpha" expects 0-65535.

You don't have to use the "alpha" GTK+ property though, you can pass it in via the e.g. <default>#4488cc|32767<default>, <input> or <input file> directives but it won't have an effect unless you've set the tag attribute use-alpha="true".

Since I found hardly anything on the net about converting between these formats, I worked it out in the end (#4488cc == #44448888cccc, 127 (0x7f) == 32639 (0x7f7f), so you can convert the alpha like this (integer arithmetic):

[EDIT] I'll expand on this so there's an example: suppose you chose the colour #99bfac and an alpha of 173 -- the widget's variable would contain "#99bfac|44461" -- so once you've isolated the alpha you can convert it like this (I've printed it in hex so you can see how the 16bit alpha value is constructed:

Hi guys, are the tree widget selection modes working correctly? When I run the tree_selection_mode example with latest svn the "browse" and "single" modes seem to be the same. This surprised me, as I would have thought it was something you'd just pass straight on to GTK.

BTW the list selection modes also don't behave quite as I'd expect. Try running the list example, click on the first list item, drag, and release on the second list item. Then click on the second item, drag, and release on the third item. It always selects (or unselects) the item you click on, even if you don't release on it. Is this behaviour correct?

The tree widget selection modes are working for me (I've just tried using r293). In Single mode you can deselect, in Browse mode you can't.

The list widget is created using gtk_list_new(), put in a scrolledwindow and that's it. Try the list_advanced example which I created to explore the widget's capabilites so that I could document it.

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