Gtkdialog Development

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#321 Post by 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.

Image

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

User avatar
thunor
Posts: 350
Joined: Thu 14 Oct 2010, 15:24
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
Contact:

#322 Post by thunor »

01micko wrote:if you ever slip down to Oz, or me up to UK then I will gladly shout you a pint or three :wink:
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: 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

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#323 Post by zigbert »

Thunor
Thank you. :D
By setting height/width request to 1 (or something very small), I will never see the scrollbars. I will update the tips-thread.


Sigmund

User avatar
thunor
Posts: 350
Joined: Thu 14 Oct 2010, 15:24
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
Contact:

#324 Post by 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

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#325 Post by zigbert »

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


Sigmund

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#326 Post by zigbert »

Here is Pburn with expand/fill = TRUE :D

Image

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#327 Post by zigbert »

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

User avatar
thunor
Posts: 350
Joined: Thu 14 Oct 2010, 15:24
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
Contact:

#328 Post by thunor »

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


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

User avatar
thunor
Posts: 350
Joined: Thu 14 Oct 2010, 15:24
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
Contact:

#329 Post by thunor »

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.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#330 Post by 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]
Attachments
xarchive2.png
this is just the gui part so far - no interactions etc..
thus why all the buttons are still grayed out
(69.07 KiB) Downloaded 637 times
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
thunor
Posts: 350
Joined: Thu 14 Oct 2010, 15:24
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
Contact:

#331 Post by 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

User avatar
thunor
Posts: 350
Joined: Thu 14 Oct 2010, 15:24
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
Contact:

#332 Post by thunor »

technosaurus wrote: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

User avatar
thunor
Posts: 350
Joined: Thu 14 Oct 2010, 15:24
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
Contact:

#333 Post by 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

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#334 Post by 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.... :D

Here is the case:

Image

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

User avatar
thunor
Posts: 350
Joined: Thu 14 Oct 2010, 15:24
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
Contact:

#335 Post by thunor »

Hi Sigmund

Image Image

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

User avatar
thunor
Posts: 350
Joined: Thu 14 Oct 2010, 15:24
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
Contact:

#336 Post by thunor »

I've exported the wiki to html -- look in doc/reference.

Well, it's gone quiet so I'll take that to mean it's time to make a release.

Regards,
Thunor

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#337 Post by zigbert »

thunor wrote:Well, it's gone quiet so I'll take that to mean it's time to make a release.
:D

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#338 Post by 01micko »

Here's my latest for updating from svn, it gives you a choice at the woof level or the running system level to clobber gtkdialog3 or not, using Xdialog. Now the symlinks are not hard coded. It's not perfect but it suits me, also packages the html reference files.

Code: Select all

#!/bin/sh
#my script to update and package gtkdialog
[ -x src/gtkdialog ] && make clean
svn update
./autogen.sh && make
echo
echo "scroll up to get the svn version number"
echo -en "\033[0;31m""enter version";echo -e "\033[0m"
read VER
cd src
strip --strip-unneeded gtkdialog
mkdir -p $HOME/gtkdialog4-${VER}-s/usr/sbin
cp -af gtkdialog $HOME/gtkdialog4-${VER}-s/usr/sbin
#cd $HOME/gtkdialog4-${VER}-s/usr/sbin
#ln -s gtkdialog gtkdialog3
#ln -s gtkdialog gtkdialog4
#cd -
pwd
cd ..
mkdir -p $HOME/gtkdialog4_DOC-${VER}-s/usr/share/doc/gtkdialog/examples
cp -arf examples/* $HOME/gtkdialog4_DOC-${VER}-s/usr/share/doc/gtkdialog/examples/
cp -arf doc/reference $HOME/gtkdialog4_DOC-${VER}-s/usr/share/doc/gtkdialog/
rm -f $HOME/gtkdialog4_DOC-${VER}-s/usr/share/doc/gtkdialog/examples/Make*
echo '#!/bin/sh
#gtkdialog pinstall.sh
if [ "`pwd`" != "/" ];then
 #woof
 (cd ./usr/sbin ; ln -s gtkdialog gtkdialog4)
 Xdialog --title "gtkdialog3" --yesno "Do you want to link to gtkdialog3?" 0 0
  case $? in
  0) (cd ./usr/sbin ; ln -s gtkdialog gtkdialog3)
  echo "linked to gtkdialog3 and 4" ;;
  *) echo "not linked to gtkdialog3, linked to gtkdialog4" ;;
  esac
 else
#non-woof, running system
 (cd /usr/sbin ; rm -f gtkdialog4)
 (cd /usr/sbin ; ln -s gtkdialog gtkdialog4)
 if [ "$(file /usr/sbin/gtkdialog3|grep -iE "symbolic")" != "" ];then
  (cd /usr/sbin ; rm -f gtkdialog3)
  (cd /usr/sbin ; ln -s gtkdialog gtkdialog3)
  echo "Old gtkdialog3 removed, gtkdialog linked to gtkdialog3 and gtkdialog4"
  else
  Xdialog --title "gtkdialog3" --yesno "Do you want to clobber gtkdialog3?" 0 0
  case $? in
  0) (cd /usr/sbin ; rm -f gtkdialog3)
 (cd /usr/sbin ; ln -s gtkdialog gtkdialog3)
  echo "Old gtkdialog3 removed, gtkdialog linked to gtkdialog3 and gtkdialog4" ;;
  *) echo "not linked to gtkdialog3, linked to gtkdialog4" ;;
  esac
 fi
fi' > $HOME/gtkdialog4-${VER}-s/pinstall.sh
chmod 755 $HOME/gtkdialog4-${VER}-s/pinstall.sh
cd $HOME
dir2pet gtkdialog4-${VER}-s
dir2pet gtkdialog4_DOC-${VER}-s
echo done && exit 0
Puppy Linux Blog - contact me for access

User avatar
thunor
Posts: 350
Joined: Thu 14 Oct 2010, 15:24
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
Contact:

#339 Post by thunor »

0.8.0 released.

Cheers to everyone who was involved :)

I have other non-programming things that require my attention now but I'd like to write a simple game using Gtkdialog that I haven't written before.

Cheers,
Thunor

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#340 Post by 01micko »

LOL!!!

And I just was updating to 307.. is it identical?

Thanks!

EDIT: to answer my own Q.. No.. md5sum don't match

Cheers :)
Puppy Linux Blog - contact me for access

Post Reply