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?

All user cells are type string which I guess is why they sort like strings (GTK+ manages the sorting).

Yeah, it would improve the widget to be able to specify the column data types so I'll add a feature request for this.

Thanks François, and thanks to everybody who has been encouraging, involved in requesting new features, suggesting improvements and testing everything I've really enjoyed it and it's been such a rush. Funny thing is I originally investigated Gtkdialog so that I woudn't have to learn GTK+ to write a simple generic emulator GUI and then I ended up understanding GTK+ at a level I never would've imagined (I'm a big SDL fan really)

The wiki widget reference is now complete, the project is stable and in my opinion greatly improved over version 0.7.20 so I'm now going to focus on making an 0.8.0 source package release (I'll try and convert the wiki to html first and include it in the package) and then take a break.

I'll wait for a short while to make sure that the new colorbutton widget is fine.

The wiki widget reference is now complete, the project is stable and in my opinion greatly improved over version 0.7.20 so I'm now going to focus on making an 0.8.0 source package release (I'll try and convert the wiki to html first and include it in the package) and then take a break.

And a well earned break at that!

Thank you mate!

if you ever slip down to Oz, or me up to UK then I will gladly shout you a pint or three

Hello Thunor and the gang
I have 2 questions.
But first a longer introduction....

New features gives new inspiration
The focus of Pmusic 2.1.0 is at gui-enhancement. The new features that Thunor has given us makes the gui less cluttered and more powerful.

An interesting thing I must share... the scrollable attribute for <hbox/vbox> gives new possibilities to make complex guis scalable. Normally we can put a scalable <tree> widget inside _one_ <hbox/vbox>. The scrollable attribute resets this. - which means that the following example scales nicely. Remove the scrollable attribute to see how it normally will act. I will update the gtkdialog-tips.

1.)
It would be great if we could set the minimum size of the scrollable field. That would prevent my Pmusic gui to be filled with scrollbars when users shrinks the window below its required size.

2.)
Another small (I think it's small) irritating issue. If you look at the Pmusic screenshot, you'll see that the left margin in the <tree> widget is wider than it has to be. To me, it looks like a simple bug in gtkdialog....

if you ever slip down to Oz, or me up to UK then I will gladly shout you a pint or three

Cheers Mick, sounds good to me

zigbert wrote:

1.)
It would be great if we could set the minimum size of the scrollable field. That would prevent my Pmusic gui to be filled with scrollbars when users shrinks the window below its required size.

2.)
Another small (I think it's small) irritating issue. If you look at the Pmusic screenshot, you'll see that the left margin in the <tree> widget is wider than it has to be. To me, it looks like a simple bug in gtkdialog....

Hi Sigmund

1. Does this example help (you can take it to the extreme by setting width/height-request="1"):

2. I mentioned this somewhere before: there are two models that the tree widget can use: the ListStore model for lists and the TreeStore model for trees. The tree widget was created using the [wrong] TreeStore model and the gap down the left-hand side is for the expanders. If you set reorderable="true" and drag an item onto another so that the branch opens you'll see the expander appear and fill this space. My opinion is that development of the tree widget should cease and a new <listview> widget should be created using the correct model. There's an interesting GtkTreeView tutorial here with a few images showing the gapless ListStore TreeView and the TreeStore TreeView with expanders open. I've created issue 36 for this.

Check-out r296. I saw this a while ago: the original author couldn't get the expand and fill to work when packing widgets so he set them to FALSE and that's why only a few widgets expanded properly. I've now set expand and fill to TRUE so that everything now resizes

[EDIT] I'm noticing a few issues with buttons at the moment so I'll see if I can resolve it.

Check-out r296. I saw this a while ago: the original author couldn't get the expand and fill to work when packing widgets so he set them to FALSE and that's why only a few widgets expanded properly. I've now set expand and fill to TRUE so that everything now resizes

[EDIT] I'm noticing a few issues with buttons at the moment so I'll see if I can resolve it.

Regards,
Thunor

This is really great news. I made a brief test, and it works as expected.

BUT
Be aware that many guis will scale differently than intended. This because they misses height/width definition. This has not been common because they didn't scale anyway.

I could be stated that this breaks backward compatibility. But WOW....
... I have some work to do

Currently with resizing not working properly, if the widget is a frame or something that is placed inside a scrolled window (tree, edit, list, table, vbox and hbox optionally) then its expand and fill properties are both TRUE when being packed inside its parent widget, otherwise both expand and fill are FALSE. Therefore so as not to interfere with the existing system I shall need to create two custom tag attributes that you can use to override the defaults

Shouldn't this be first step to allow 'handgrips' to let user define the internal scaling.... ?

When widgets are packed inside containers, two values need to be set: expand and fill --this is done in the code. A handgrip on a statusbar doesn't set any properties, it only expands the window enabling widgets to expand and fill into the space.

I need to create "space-expand" and "space-fill" custom tag attributes to override the existing hardcoded values. Trouble is it might be a chore applying these to every widget so I'm thinking about creating super-attributes to set expand to TRUE/FALSE and/or fill to TRUE/FALSE for every widget and then you'll have less widgets to micro-manage.

I know we can use dragndrop from an external programs, but do/could any widgets support it?

If so, there is a tiny file manager in my head just waiting to be freed, and I am certain Zigbert's apps could greatly benefit (though he has made great use of the right click menus).

[sidebar]I am really horrible at leaving code format unreadable from cutting/pasting etc & would love to use xmllint -format on the gtkdialog "xml" code, but certain parts are flagged as "invalid" (which is probably why libxml2 is required vs glib or expat) The biggest one I recall is <input file ...>file</input> (space before but no ="" after file)
IIRC, someone posted a code cleanup script that does work with gtkdialog, but I seem to have lost it.
On the other side of things some tags that _are_ usually considered valid xml aren't accepted by gtkdialog such as <vseparator/> instead of <vseparator></vseparator> (not like you can put anything between it anyways)[/sidebar]

xarchive2.png

Description

this is just the gui part so far - no interactions etc..thus why all the buttons are still grayed out

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