The time now is Sun 19 May 2013, 17:05
All times are UTC - 4 |
|
Page 22 of 54 [801 Posts] |
Goto page: Previous 1, 2, 3, ..., 20, 21, 22, 23, 24, ..., 52, 53, 54 Next |
| Author |
Message |
thunor

Joined: 14 Oct 2010 Posts: 342 Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
|
Posted: Tue 20 Sep 2011, 12:56 Post subject:
|
|
| disciple wrote: | 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:
but you would actually want to sort them like this:
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.
Regards,
Thunor
|
|
Back to top
|
|
 |
thunor

Joined: 14 Oct 2010 Posts: 342 Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
|
Posted: Tue 20 Sep 2011, 13:36 Post subject:
|
|
| vovchik wrote: | Dear thunor,
Thanks for the colorselect function. Brilliant!
With kind regards,
vovchik
PS. Would fontselect be too much to ask for? |
Hi vovchik
You're welcome
Funnily enough earlier today I created a feature request for the GtkFontButton
It'll be done next development period.
Regards,
Thunor
|
|
Back to top
|
|
 |
frafa

Joined: 04 Aug 2011 Posts: 10 Location: MONTPELIER
|
Posted: Tue 20 Sep 2011, 14:02 Post subject:
|
|
Hi Thunor
Thank you Thank you Thank you:)
for colorbutton and GtkFontButton
is too well
Congratulations for all the work you do on gtkdialog
it's really wonderful !
sorry for my broken english...
François
|
|
Back to top
|
|
 |
thunor

Joined: 14 Oct 2010 Posts: 342 Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
|
Posted: Tue 20 Sep 2011, 18:38 Post subject:
|
|
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.
Regards,
Thunor
|
|
Back to top
|
|
 |
01micko

Joined: 11 Oct 2008 Posts: 7017 Location: qld
|
Posted: Tue 20 Sep 2011, 21:29 Post subject:
|
|
| thunor wrote: | | 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
Cheers!
_________________ keep the faith .. 
|
|
Back to top
|
|
 |
zigbert

Joined: 29 Mar 2006 Posts: 5241 Location: Valåmoen, Norway
|
Posted: Wed 21 Sep 2011, 03:29 Post subject:
|
|
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.
| Code: | #!/bin/sh
export DIALOG='
<window default_width="500" default_height="300">
<vbox>
<text><label>How to scale a complex gui</label></text>
<hbox scrollable="true">
<edit></edit>
<edit></edit>
</hbox>
</vbox>
</window>
'
gtkdialog4 -p DIALOG |
Now it's time for the questions....
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....
Sigmund
_________________ Stardust resources
|
|
Back to top
|
|
 |
thunor

Joined: 14 Oct 2010 Posts: 342 Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
|
Posted: Wed 21 Sep 2011, 11:10 Post subject:
|
|
| 01micko wrote: | 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"):
| Code: | #!/bin/sh
GTKDIALOG=gtkdialog
functxtCreate() {
for f in 0 1 2 3 4 5 6 7 8 9; do
echo '<text wrap="false">
<label>'
for g in 0 1 2 3 4 5 6 7 8 9; do echo -n "$g$g$g$g$g "; done
echo '</label>
</text>
<hseparator></hseparator>'
done
}
export MAIN_DIALOG='
<window title="Scrollable Box Minimum Size">
<vbox>
<vbox scrollable="true">
'"$(functxtCreate)"'
</vbox>
<vbox scrollable="true" width-request="200" height-request="100">
'"$(functxtCreate)"'
</vbox>
<statusbar></statusbar>
</vbox>
<action signal="hide">exit:Exit</action>
</window>
'
$GTKDIALOG --program=MAIN_DIALOG |
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.
Regards,
Thunor
|
|
Back to top
|
|
 |
zigbert

Joined: 29 Mar 2006 Posts: 5241 Location: Valåmoen, Norway
|
Posted: Wed 21 Sep 2011, 11:57 Post subject:
|
|
Thunor
Thank you.
By setting height/width request to 1 (or something very small), I will never see the scrollbars. I will update the tips-thread.
Sigmund
_________________ Stardust resources
|
|
Back to top
|
|
 |
thunor

Joined: 14 Oct 2010 Posts: 342 Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
|
Posted: Wed 21 Sep 2011, 12:08 Post subject:
|
|
Sigmund,
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
|
|
Back to top
|
|
 |
zigbert

Joined: 29 Mar 2006 Posts: 5241 Location: Valåmoen, Norway
|
Posted: Wed 21 Sep 2011, 12:33 Post subject:
|
|
| thunor wrote: | Sigmund,
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
Sigmund
_________________ Stardust resources
|
|
Back to top
|
|
 |
zigbert

Joined: 29 Mar 2006 Posts: 5241 Location: Valåmoen, Norway
|
Posted: Wed 21 Sep 2011, 12:37 Post subject:
|
|
Here is Pburn with expand/fill = TRUE
_________________ Stardust resources
|
|
Back to top
|
|
 |
zigbert

Joined: 29 Mar 2006 Posts: 5241 Location: Valåmoen, Norway
|
Posted: Wed 21 Sep 2011, 12:42 Post subject:
|
|
Shouldn't this be first step to allow 'handgrips' to let user define the internal scaling.... ?
_________________ Stardust resources
|
|
Back to top
|
|
 |
thunor

Joined: 14 Oct 2010 Posts: 342 Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
|
Posted: Wed 21 Sep 2011, 12:52 Post subject:
|
|
| zigbert wrote: | 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
Sigmund |
I've reverted my modifications in r297 because this will break apps. I'll explain why:
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
I'll do it tonight.
Regards,
Thunor
|
|
Back to top
|
|
 |
thunor

Joined: 14 Oct 2010 Posts: 342 Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
|
Posted: Wed 21 Sep 2011, 13:42 Post subject:
|
|
| zigbert wrote: | | 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.
|
|
Back to top
|
|
 |
technosaurus

Joined: 18 May 2008 Posts: 3843
|
Posted: Wed 21 Sep 2011, 17:06 Post subject:
|
|
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]
 |
| Description |
this is just the gui part so far - no interactions etc.. thus why all the buttons are still grayed out |
| Filesize |
69.07 KB |
| Viewed |
439 Time(s) |

|
_________________ Puppy Web Desktop Now with pet packages - Pet Packaging 100 & 101
|
|
Back to top
|
|
 |
|
|
Page 22 of 54 [801 Posts] |
Goto page: Previous 1, 2, 3, ..., 20, 21, 22, 23, 24, ..., 52, 53, 54 Next |
|
|
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
|