Gtkdialog Development

[thunor]

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: Select all

1
200
30

but you would actually want to sort them like this:

Code: Select all

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.

Regards,
Thunor

[thunor]

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

[frafa]

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

[thunor]

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

[01micko]

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!

[zigbert]

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: Select all

#!/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

[thunor]

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

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: Select all

#!/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

[zigbert]

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

[thunor]

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

[zigbert]

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

[zigbert]

Here is Pburn with expand/fill = TRUE

[zigbert]

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

[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

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

[thunor]

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.

[technosaurus]

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]

[thunor]

Overhauled the widget packing method

From the ChangeLog:

• Added command-line option --space-expand to set the widget packing expand state at the project level.
• Added command line option --space-fill to set the widget packing fill state at the project level.
• Added the "space-expand" custom tag attribute for the h/vbox widgets to set the widget packing expand state at the container level.
• Added the "space-fill" custom tag attribute for the h/vbox widgets to set the widget packing fill state at the container level.
• Added the "space-expand" custom tag attribute for all other widgets to set the widget packing expand state at the widget level.
• Added the "space-fill" custom tag attribute for all other widgets to set the widget packing fill state at the widget level.
• By default the original quirky widget packing method is used.
• Project level --space-expand/fill override the original method.
• Container level "space-expand/fill" override the project level method and the original method.
• Widget level "space-expand/fill" override the container level method, the project level method and the original method.

Look here for an explanation of expand and fill. An important point to remember is that if expand is false then fill has no effect.

Widgets are packed into containers and they may expand into and fill their allocated space. For Gtkdialog, containers means hbox and vbox but there's one embedded unreachable vbox inside the frame widget which is a pain because it's not possible to add tag attributes to the frame or embedded vbox to set expand and fill at the container level although the widget level and project level are fine. The way around this is to place a vbox inside the frame so that you have control over it. The frame widget really needs to be replaced but that's a job for another day.

The Original Method
It's a bit quirky and possibly there's an error in it but it's the default method and used by every single Gtkdialog application until now.

The frame widget and every widget normally placed inside a default scrolled window (edit, tree, list, table and optionally the h/vbox) are packed with expand and fill set to true, otherwise widgets are packed with expand and fill set to false. The possible error I've found is that the hbox uniquely packs the entry widget by default with expand and fill set to true.

The Project Level Method
The command-line options --space-expand=true/yes/1/false/no/0 and --space-fill=true/yes/1/false/no/0 will override the original method for all widgets at the project (application) level. --space-expand=true is the key to creating resizable applications.

The Container Level Method
The custom tag attributes space-expand="true/yes/1/false/no/0" and space-fill="true/yes/1/false/no/0" will override the original method and the project level method for widgets at the container level i.e. <vbox space-expand="true" space-fill="true"> will set expand and fill to true for all the widgets inside this particular vbox but not recursively into v/hboxes nested within.

The Widget Level Method
The custom tag attributes space-expand="true/yes/1/false/no/0" and space-fill="true/yes/1/false/no/0" will override the original method, the project level method and the container level method for individual widgets.

Example (examples/miscellaneous/expand_and_fill):

Code: Select all

#!/bin/sh

export GTKDIALOG=gtkdialog

funcExampleCreate() {
	if [ $1 = 0 ]; then echo '
<window title="Expand and Fill - Original Method" resizable="true">'
	elif [ $1 = 1 ]; then echo '
<window title="Expand and Fill - --space-expand" resizable="true">'
	elif [ $1 = 2 ]; then echo '
<window title="Expand and Fill - --space-expand + --space-fill" resizable="true">'
	else echo '
<window title="Expand and Fill - --space-expand + --space-fill + tweaks" resizable="true">'
	fi
	echo '
	<vbox>
		<hbox>
			<tree stock-id="gtk-select-color"><item>tree widget</item></tree>
			<vseparator></vseparator>
			<vbox>
				<entry><default>entry widget</default></entry>
				<hseparator></hseparator>
				<text label="text widget"></text>
			</vbox>
		</hbox>
		<hseparator></hseparator>
		<hbox>
			<vbox>
				<spinbutton></spinbutton>
				<hseparator></hseparator>'
	if [ $1 -lt 3 ]; then echo '
				<colorbutton use-alpha="true">'
	else echo '
				<colorbutton space-expand="false" use-alpha="true">'
	fi
	echo '
					<default>#'$(for f in 0 1 2; do printf "%02x" $(($RANDOM % 256)); done)'|43934"</default>
				</colorbutton>
			</vbox>
			<vseparator></vseparator>
			<edit><default>edit widget</default></edit>
		</hbox>
		<hseparator></hseparator>'
	if [ $1 -lt 3 ]; then echo '
		<hbox>'
	else echo '
		<hbox space-expand="false">'
	fi
	echo '
			<button image-position="1">
				<label>Next example</label>
				<input file stock="gtk-go-forward"></input>'
	if [ $1 = 0 ]; then echo '
				<action>$GTKDIALOG --space-expand=true --program=CLI_EXPAND_METHOD &</action>'
	elif [ $1 = 1 ]; then echo '
				<action>$GTKDIALOG --space-expand=true --space-fill=true --program=CLI_EXPAND_PLUS_FILL_METHOD &</action>'
	elif [ $1 = 2 ]; then echo '
				<action>$GTKDIALOG --space-expand=true --space-fill=true --program=CLI_EXPAND_PLUS_FILL_PLUS_TWEAKS_METHOD &</action>'
	else echo '
				<sensitive>false</sensitive>'
	fi
	echo '
			</button>
			<button use-stock="true" label="gtk-ok"></button>
		</hbox>
		<statusbar><label>statusbar widget</label></statusbar>
	</vbox>
	<action signal="hide">exit:Exit</action>
</window>
'
}

export ORIGINAL_METHOD="$(funcExampleCreate 0)"
export CLI_EXPAND_METHOD="$(funcExampleCreate 1)"
export CLI_EXPAND_PLUS_FILL_METHOD="$(funcExampleCreate 2)"
export CLI_EXPAND_PLUS_FILL_PLUS_TWEAKS_METHOD="$(funcExampleCreate 3)"

$GTKDIALOG --program=ORIGINAL_METHOD

Regards,
Thunor

[thunor]

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]

Hi technosaurus

GTK+ supports drag 'n' drop. Widgets currently accept data from various sources but it's always all or nothing. There's no mechanism within Gtkdialog for inserting data from one widget into another at a certain position. Well, actually somebody has started to code an <action>insert:sourcevar,destvar</action> function for win32 only but it appears to be appending rather than inserting. So drag 'n' drop would need to be set-up between the source and target widgets which would emit a signal on drop and then an "insert" action would need to be executed -- a lot of work. The tree widget would be the place to start but as I've mentioned a few times before, it uses the wrong model (TreeStore instead of ListStore) which causes items to get grouped and branches open which the code doesn't support, so a new <listview> widget needs to be written first.

GTK+ depends on libxml2 but Gtkdialog uses Flex (lexical analyser) and Bison (parser generator). Gtkdialog's XML-like syntax is custom. It's not valid XML nor is it XML. The reason why "<vseparator/>" isn't accepted is because Gtkdialog's parser doesn't know what it is.

Regards,
Thunor

[thunor]

MAXWIDGETS

Last night I committed the expand_and_fill example and I when I was working on the widget packing I noticed that the maximum number of widgets Gtkdialog accepted was 256 (16^) so I've increased it to 529 (23^). Using the expand_and_fill example this takes virtual memory usage from 21MB to 25MB (1024 (32^) widgets would've taken it to 34MB) so I hope this is OK for everyone. Ideally the widget pointer array would increase dynamically but it hasn't been written like that so this increase will do for now.

Regards,
Thunor

[zigbert]

Scaling is fun
...and Pburn will sure benefit of it. Thank you Thunor.
Though there are one irritating issue with the new fill/expand option (I know, I know.... it's just me being a fool - not getting it all, but still irritating....

Here is the case:



Last time I showed a pic of Pmusic it used the scrollable option to keep scaling. It worked fine, but with fill/scale the box-border is gone, and it looks cleaner.

BUT, the pic shows how Pmusic starts even if geometry settings is smaller. There is not defined any space between the back-button and the info-button. It auto-scales at startup to the size it would have had without decreasing the button-area by scaling="0" for all buttons. It seems to me like the hardcoded spacing="5" is overwritten fine in the gui itself, but not for the function that defines the shown size of the window.

No problem for me, - I just return to scrollable, but thought I would mention. If you want more info, I could make a test-script.


Sigmund

[thunor]

Hi Sigmund



I don't know if you've played with the expand_and_fill example or not but GTK+ allocates space completely differently when expand is true. I have offered as many ways as possible to attempt to control the widgets but ultimately GTK+ does things by its rules.

When testing I found once that a button in an hbox with space-expand=false was still expanding in the vertical dimension because they were inside a vbox that had space-expand=true. I stopped this behaviour by wrapping the hbox inside another vbox. I realised then that some work might be required in isolating widgets using different methods.

All I've done is present an interface to the expand and fill parameters of the widget packing functions, but if you want to create an example then I'd be interested in looking at it.

Regards,
Thunor