Gtkdialog Development
hi Barry
I don't know that anything can be done with <combobox> as it was deprecated as of gtk+-2.4. See here .. Thunor states this on page 1 of this thread.
I don't know that anything can be done with <combobox> as it was deprecated as of gtk+-2.4. See here .. Thunor states this on page 1 of this thread.
Puppy Linux Blog - contact me for access
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Oh, ok. I presume then that <comboboxtext> is using the new GtkComboBoxEntry functions.01micko wrote:hi Barry
I don't know that anything can be done with <combobox> as it was deprecated as of gtk+-2.4. See here .. Thunor states this on page 1 of this thread.
Then we still need to tackle, if possible, the double-popup problem if use <default> tag with <comoboboxtext>.
Oh yes, I got it wrong with Xdialog in BootManager. The drop-down list to add a new module is slow, but it is using Xdialog. So the slowness of long lists in the dropdown box applies to Xdialog also.
[url]https://bkhome.org/news/[/url]
- thunor
- Posts: 350
- Joined: Thu 14 Oct 2010, 15:24
- Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
- Contact:
Hi Barry
Sorry for the delay in replying as I'm busy looking for a new job and apartment which is consuming much of my time (and motivation)
I ran it from the terminal and it took about 13 seconds for the application to appear.
A normal length click on the first comboboxtext (262 items) took 1.46s to appear the first time but after that 0.8s.
Positioning the mouse over the arrows top or bottom of the list so that it scrolls as fast as possible uses 35% CPU.
A normal length click on the second comboboxtext (234 items) took 1.41s to appear the first time but after that 0.8s.
Positioning the mouse over the arrows top or bottom of the list so that it scrolls as fast as possible uses 33% CPU.
A normal length click on the third comboboxtext (44 items) took 0.64s to appear the first time but after that it was too fast to measure.
List scrolling can't be measured as it's not long enough.
There's no CPU usage if the application is not interacted with.
I did not experience the list appearing and then disappearing.
Holding down the mouse button works the same way as it does in menus i.e. you hold it down whilst traversing the list and when you let go the list closes. It's clearer to see this if you use the comboboxtext_advanced example which is a lot faster.
Therefore for me it's working as expected.
The <default> directive: right at the start before the user sees the application window, the comboboxtext widget is initialised with data and then the contents of the default directive are used to select a matching item. That's it, an iteration through the list and then a change of the selected item. That code is then finished with, GTK+ shows the application and the user interacts with it.
I want to do some quick tests on my lupu-520 anyway, but if I was to try Racy then which is the recommended version?
Regards,
Thunor
Sorry for the delay in replying as I'm busy looking for a new job and apartment which is consuming much of my time (and motivation)
I've just tried your attached application on my PIII 866MHz, lupu-520, GTK+ 2.20.0.BarryK wrote:...
Racy 5.1.110 has /usr/sbin/quicksetup that has <comboboxtext> tags, with quite a lot of items. It also uses the <default> tag.
However, when we click on one of these comboboxes, the list pops up then immediately disappears. We have to click again, then it pops up and stays up. However, if we press the left mouse button and hold it down, the list stays up.
Note, the list is quite long, goes right from top to bottom of screen.
I ran it from the terminal and it took about 13 seconds for the application to appear.
A normal length click on the first comboboxtext (262 items) took 1.46s to appear the first time but after that 0.8s.
Positioning the mouse over the arrows top or bottom of the list so that it scrolls as fast as possible uses 35% CPU.
A normal length click on the second comboboxtext (234 items) took 1.41s to appear the first time but after that 0.8s.
Positioning the mouse over the arrows top or bottom of the list so that it scrolls as fast as possible uses 33% CPU.
A normal length click on the third comboboxtext (44 items) took 0.64s to appear the first time but after that it was too fast to measure.
List scrolling can't be measured as it's not long enough.
There's no CPU usage if the application is not interacted with.
I did not experience the list appearing and then disappearing.
Holding down the mouse button works the same way as it does in menus i.e. you hold it down whilst traversing the list and when you let go the list closes. It's clearer to see this if you use the comboboxtext_advanced example which is a lot faster.
Therefore for me it's working as expected.
Using the comboboxtext_advanced example which includes the old combobox widget, the combobox gives me invalid "depressed" signal warnings and I have to fight for control of my window when manipulating the ones with tag attributes set, and as Mick has already indicated, GTK+ deprecated this a long time ago which equates to it not being maintained so that's why I'm not recommending it to Gtkdialog application developers.BarryK wrote:So, for Racy 5.2.1.90 I have changed to <combobox>, but that does not support <default> -- which is ok, I just put the default item first in the list.
However, after releasing latest Racy, testers have found that when a list is brought up, CPU usage becomes very high. On older CPUs, scrolling the list becomes extremely slow.
This morning I found a solution. I have gone back to <comboboxtext> but do not use the <default> tag. Now, do not get the double-popup problem. I have attached this latest script.
My question, are these two problems GTK problems, not specifically gtkdialog problems? in which case, nothing we can do. Or, can either of them be fixed in gtkdialog?
The <default> directive: right at the start before the user sees the application window, the comboboxtext widget is initialised with data and then the contents of the default directive are used to select a matching item. That's it, an iteration through the list and then a change of the selected item. That code is then finished with, GTK+ shows the application and the user interacts with it.
The fact that Xdialog's combobox (it looks like the old GtkComBox <combobox> widget) is faster is interesting.BarryK wrote:A further note on extreme slowness with <combobox>. It is not a specifically gtkdialog4 problem, gtkdialog3 exhibits it also.
Wary and Racy testers have reported the problem with /usr/sbin/remove_builtin and /usr/sbin/bootmanager, that use gtkdialog3.
I just checked bootmanager with my fast laptop, chose to add a new module, the dropdown list is quite long, yes, unbearably slow. Even on my fast machine.
I do not recall this problem before. Perhaps it is a problem with gtk 2.45.x -- well, most likely it is.
However, we can have long lists in Xdialog (with gtk 2.45.x), and they are not slow, nor do they hog the CPU. So, that would indicate that there is something that gtkdialog is doing that is causing the problem.
I want to do some quick tests on my lupu-520 anyway, but if I was to try Racy then which is the recommended version?
Regards,
Thunor
- thunor
- Posts: 350
- Joined: Thu 14 Oct 2010, 15:24
- Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
- Contact:
I've had a look on your blog and from what you've said here sounds like a GTK+ problem. I'd like to be able to experience these problems though so just post a link to a Racy ISO.BarryK wrote:Oh, ok. I presume then that <comboboxtext> is using the new GtkComboBoxEntry functions.
Then we still need to tackle, if possible, the double-popup problem if use <default> tag with <comoboboxtext>.
Oh yes, I got it wrong with Xdialog in BootManager. The drop-down list to add a new module is slow, but it is using Xdialog. So the slowness of long lists in the dropdown box applies to Xdialog also.
Is there another GTK+ non-Gtkdialog application that has a comboboxtext widget with lots of items that can be tested for comparison?
Regards,
Thunor
- thunor
- Posts: 350
- Joined: Thu 14 Oct 2010, 15:24
- Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
- Contact:
Your application wrote /var/local/quicksetup-timezone-table-x which is a list of 234 items so I'm loading that and multiples of that into a single 202px wide comboboxtext with a default "US/Samoa "." off" as a test.
On lupu-520, PIII 866MHz, GTK+ 2.20.0:
234 items in one comboboxtext:
App load time: 1.07s
comboboxtext list initial show time: 0.50s
comboboxtext list subsequent show time: 0.30s
CPU usage when scrolling: 32%
234x2 items in one comboboxtext:
App load time: 2.10s
comboboxtext list initial show time: 1.17s
comboboxtext list subsequent show time: 0.55s
CPU usage when scrolling: 52%
234x3 items in one comboboxtext:
App load time: 3.28s
comboboxtext list initial show time: 2.16s
comboboxtext list subsequent show time: 0.76s
CPU usage when scrolling: 60% to 70% but it gets erratic
234x4 items in one comboboxtext:
App load time: 4.58s
comboboxtext list initial show time: 3.21s
comboboxtext list subsequent show time: 1.19s
CPU usage when scrolling: 60% to 70% but it gets erratic
...
234x10 items in one comboboxtext:
App load time: 16.82s
comboboxtext list initial show time: 15.35s
comboboxtext list subsequent show time: 2.62s
CPU usage when scrolling: 60% to 70% but it gets erratic
This is my test app which uses a copy of /var/local/quicksetup-timezone-table-x as /tmp/test and just keep editing it and multiplying its contents:
Regards,
Thunor
On lupu-520, PIII 866MHz, GTK+ 2.20.0:
234 items in one comboboxtext:
App load time: 1.07s
comboboxtext list initial show time: 0.50s
comboboxtext list subsequent show time: 0.30s
CPU usage when scrolling: 32%
234x2 items in one comboboxtext:
App load time: 2.10s
comboboxtext list initial show time: 1.17s
comboboxtext list subsequent show time: 0.55s
CPU usage when scrolling: 52%
234x3 items in one comboboxtext:
App load time: 3.28s
comboboxtext list initial show time: 2.16s
comboboxtext list subsequent show time: 0.76s
CPU usage when scrolling: 60% to 70% but it gets erratic
234x4 items in one comboboxtext:
App load time: 4.58s
comboboxtext list initial show time: 3.21s
comboboxtext list subsequent show time: 1.19s
CPU usage when scrolling: 60% to 70% but it gets erratic
...
234x10 items in one comboboxtext:
App load time: 16.82s
comboboxtext list initial show time: 15.35s
comboboxtext list subsequent show time: 2.62s
CPU usage when scrolling: 60% to 70% but it gets erratic
This is my test app which uses a copy of /var/local/quicksetup-timezone-table-x as /tmp/test and just keep editing it and multiplying its contents:
Code: Select all
#!/bin/sh
GTKDIALOG=gtkdialog
## Create a temporary directory.
TEMP_DIR=$(mktemp -d)
if [ $? -ne 0 ]; then
echo "Error: Couldn't create temporary directory."
exit 1
fi
echo '
<window title="BarryK - comboboxtext speed issues" resizable="false">
<vbox>
<comboboxtext width-request="202">
<default>US/Samoa "." off</default>
<input file>/tmp/test</input>
</comboboxtext>
<hbox homogeneous="true">
<button ok></button>
</hbox>
</vbox>
<action signal="hide">exit:Exit</action>
</window>
' > $TEMP_DIR/dialog_main
## Run the main application.
$GTKDIALOG -f $TEMP_DIR/dialog_main
## Remove the temporary files.
rm -rf $TEMP_DIR
Thunor
- thunor
- Posts: 350
- Joined: Thu 14 Oct 2010, 15:24
- Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
- Contact:
I've created a feature request for itvovchik wrote:Dear thunor,
Would it be possible to add the following:to the window code so as to allow for user-defined pixmaps as window/taskbar icons? I have used that gtk call in progs in C and Bacon myself, so I know it is a cinch. All that is needed, apart from the imported function, is an appropriate tag_attr, which, along side the existing icon-name="gtk-xxxx" could be something like pixmap="path to img". Any thoughts?Code: Select all
gtk_window_set_icon_from_file(long,char*,void*)
With kind regards,
vovchik
Regards,
Thunor
- Argolance
- Posts: 3767
- Joined: Sun 06 Jan 2008, 22:57
- Location: PORT-BRILLET (Mayenne - France)
- Contact:
Hello Thunor,
This is what I noticed while testing/working with latest scripts given as examples 'v/hscale_advanced' from svn repository.
Wary 5.2.2 - gtk 2 24 8 - gtkdialog version 0.8.0 (C) 2003-2007 Laszlo Pere, 2011 Thunor. Could not compile gtkdialog version 0.8.1 from svn repository.
Console:
Puppy 431 - gtk 2 14 7 - gtkdialog version 0.8.1 (C) 2003-2007 Laszlo Pere, 2011 Thunor (self compiled from svn repository: november 21)
Any idea?
Regards.
This is what I noticed while testing/working with latest scripts given as examples 'v/hscale_advanced' from svn repository.
Wary 5.2.2 - gtk 2 24 8 - gtkdialog version 0.8.0 (C) 2003-2007 Laszlo Pere, 2011 Thunor. Could not compile gtkdialog version 0.8.1 from svn repository.
Console:
/usr/include/gtk-2.0/gtk/gtkinputdialog.h:64: error: duplicate member 'GSEAL'
/usr/include/gtk-2.0/gtk/gtkinputdialog.h:65: error: duplicate member 'GSEAL'
/usr/include/gtk-2.0/gtk/gtkinputdialog.h:65: error: duplicate member '({anonymous})'
/usr/include/gtk-2.0/gtk/gtkinputdialog.h:67: error: duplicate member 'GSEAL'
/usr/include/gtk-2.0/gtk/gtkinputdialog.h:67: error: duplicate member '({anonymous})'
/usr/include/gtk-2.0/gtk/gtkinputdialog.h:67: error: duplicate member '({anonymous})'
/usr/include/gtk-2.0/gtk/gtkinputdialog.h:68: error: duplicate member 'GSEAL'
/usr/include/gtk-2.0/gtk/gtkinputdialog.h:68: error: duplicate member '({anonymous})'
/usr/include/gtk-2.0/gtk/gtkinputdialog.h:68: error: duplicate member '({anonymous})'
/usr/include/gtk-2.0/gtk/gtkinputdialog.h:68: error: duplicate member '({anonymous})'
make[3]: *** [gtkdialog.o] Error 1
make[3]: Leaving directory `/root/gtkdialog/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/root/gtkdialog/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/gtkdialog'
make: *** [all] Error 2
- - Floating point value=point (example: 0.20) works with en locale, doesn't work when=comma (example: 0,20)
- Floating point value=point (example: 0.20) doesn't work with es, de, es locales, works when=comma (example: 0,20)
Puppy 431 - gtk 2 14 7 - gtkdialog version 0.8.1 (C) 2003-2007 Laszlo Pere, 2011 Thunor (self compiled from svn repository: november 21)
- - Floating point value=point (example: 0.20) doesn't work with en, es, de, fr locales.
(gtkdialog:26888): Gtk-CRITICAL **: IA__gtk_hscale_new_with_range: assertion `step != 0.0' failed
(gtkdialog:26888): Gtk-CRITICAL **: IA__gtk_range_set_value: assertion `GTK_IS_RANGE (range)' failed
**
ERROR:variables.c:113:variables_new_with_widget: assertion failed: (widget != NULL)
/root/gtkdialog/examples/hscale/hscale_advanced_point: line 103: 26888 Aborted
$GTKDIALOG --program=MAIN_DIALOG
Script completed hit RETURN to close window.
- - Floating point value=comma (example: 0,20) works with en, es, de, fr locales.
Any idea?
Regards.
- thunor
- Posts: 350
- Joined: Thu 14 Oct 2010, 15:24
- Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
- Contact:
Hi ArgolanceArgolance wrote:I am tearing my hair!
Any idea?
Regards.
I'm overloaded with things to do in my life. It looks like your GTK+ headers need looking at so you should focus your attention on that. "GSEAL" is not in Gtkdialog anywhere.
Just give me a very simple Gtkdialog example of what you want to do in your native locale and if it errors then show me the output.
Cheers,
Thunor
- Argolance
- Posts: 3767
- Joined: Sun 06 Jan 2008, 22:57
- Location: PORT-BRILLET (Mayenne - France)
- Contact:
Hello thunor,
While running the script below with Wary 5.2.2 - gtk 2 24 8 - gtkdialog version 0.8.0 (C) 2003-2007 Laszlo Pere, 2011 Thunor. Fresh install out of the box (live cd + save.3fs file)
More: Could not compile gtkdialog version 0.8.1 from svn repository, devx_wary_5.2.2.sfs installed.: See error message in my previous post.
Hope this is clear!
Best regards.
I read that somewhere on a thread... Sorry to stole a bit of your precious time. Good luck and success for what you are doing and thank you very much for your kind attention...I'm overloaded with things to do in my life.
While running the script below with Wary 5.2.2 - gtk 2 24 8 - gtkdialog version 0.8.0 (C) 2003-2007 Laszlo Pere, 2011 Thunor. Fresh install out of the box (live cd + save.3fs file)
Code: Select all
#!/bin/sh
GTKDIALOG=gtkdialog
export MAIN_DIALOG="
<window title=\" HScale comma test \" resizable=\"false\">
<vbox>
<frame hscale widget>
<hscale value-pos=\"0\" space-expand=\"true\" space-fill=\"true\" width-request=\"200\" height-request=\"20\" range-min=\"0,0\" range-max=\"30,0\" range-step=\"0,1\" range-value=\"15,0\">
<variable>VARIABLE</variable>
</hscale>
</frame>
<hbox homogeneous=\"true\">
<button ok></button>
</hbox>
</vbox>
<action signal=\"hide\">exit:Exit</action>
</window>
"
case $1 in
-d | --dump) echo "$MAIN_DIALOG" ;;
*) $GTKDIALOG --program=MAIN_DIALOG ;;
esac
- - Floating value=point (example: 0.1) works when Puppy is configured for en locales countries (en_US, en_GB...), doesn't work when floating value=comma (example: 0,1... see error message above in my previous post)
- Floating value=point (example: 0.1) doesn't work when Puppy is configured for locales fr, es, de, es (fr_CA, es_ES... see error message above in my previous post), works when floating value=comma (example: 0,1)
Code: Select all
#!/bin/sh
GTKDIALOG=gtkdialog
export MAIN_DIALOG="
<window title=\" HScale point test \" resizable=\"false\">
<vbox>
<frame hscale widget>
<hscale value-pos=\"0\" space-expand=\"true\" space-fill=\"true\" width-request=\"200\" height-request=\"20\" range-min=\"0.0\" range-max=\"30.0\" range-step=\"0.1\" range-value=\"15,0\">
<variable>VARIABLE</variable>
</hscale>
</frame>
<hbox homogeneous=\"true\">
<button ok></button>
</hbox>
</vbox>
<action signal=\"hide\">exit:Exit</action>
</window>
"
case $1 in
-d | --dump) echo "$MAIN_DIALOG" ;;
*) $GTKDIALOG --program=MAIN_DIALOG ;;
esac
Hope this is clear!
Best regards.
- thunor
- Posts: 350
- Joined: Thu 14 Oct 2010, 15:24
- Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
- Contact:
I asked Francois to test it on his Ubuntu computer.
I then thought why don't I change my lupu-520 system to French so I did that and it worked fine.
So, can you compile gtkdialog-0.8.0 on your computer? Download the source package and try it. All I've done between 0.8.0 and 0.8.1 is to remove a dodgy strlen() call from the XML-from-envar loading routine and update some examples. Nothing else.
I then thought why don't I change my lupu-520 system to French so I did that and it worked fine.
So, can you compile gtkdialog-0.8.0 on your computer? Download the source package and try it. All I've done between 0.8.0 and 0.8.1 is to remove a dodgy strlen() call from the XML-from-envar loading routine and update some examples. Nothing else.
- Attachments
-
- argolance-hscale-comma-issue.png
- HScale works in French using comma delimiters on lupu-520
- (35.2 KiB) Downloaded 1513 times
- Argolance
- Posts: 3767
- Joined: Sun 06 Jan 2008, 22:57
- Location: PORT-BRILLET (Mayenne - France)
- Contact:
Hello,
Inversly, HScale using point delimiters works fine in English but not in French (setup country locale fr_FR). The same in es, de, etc...
I have got this problem with too different PCs running Wary 5.2.2... and pemasu, who tested my scripts (using the same hscale code!) encountered this issue to!
Best regards
... Yes, and with Wary too! Here is not the problem I tried to explain above. This script using comma doesn't work in English (setup country locale en_US for example)... unless replacing commas to points.HScale works in French using comma delimiters on lupu-520
Inversly, HScale using point delimiters works fine in English but not in French (setup country locale fr_FR). The same in es, de, etc...
But did you simply try this "comma" script with English en_* locale?I then thought why don't I change my lupu-520 system to French so I did that and it worked fine.
I have got this problem with too different PCs running Wary 5.2.2... and pemasu, who tested my scripts (using the same hscale code!) encountered this issue to!
Best regards
- thunor
- Posts: 350
- Joined: Thu 14 Oct 2010, 15:24
- Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
- Contact:
I got a reply from Francois:
Good luck,
Thunor
I think that you should get another French user with the same distribution as you to test your example. Also try another locale that uses commas. I'm guessing that your GTK+ is unwell and it might be a good idea to post this problem in a wary 5.2.2 thread, perhaps this one.For me your code are ok
extract of my export cmd:
declare -x LANG="fr_FR.UTF-8"
declare -x LANGUAGE="fr_FR:en"
tested on Ubuntu 11.04 32bits
and gtkdialog version 0.8.0 (C) 2003-2007 Laszlo Pere, 2011 Thunor
Good luck,
Thunor
- Attachments
-
- hscale.gif
- (61.4 KiB) Downloaded 1452 times
- thunor
- Posts: 350
- Joined: Thu 14 Oct 2010, 15:24
- Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
- Contact:
I just had to have a look
I understand now what I need to do: The C functions cannot be expected to extract doubles from strings that could contain either separators in any locale. The string needs to match the locale. Therefore if you want portable Gtkdialog pseudo-XML then I'm going to have to convert the separators within the strings to match the locale! Blimey...
Bed time (and think time)...
I understand now what I need to do: The C functions cannot be expected to extract doubles from strings that could contain either separators in any locale. The string needs to match the locale. Therefore if you want portable Gtkdialog pseudo-XML then I'm going to have to convert the separators within the strings to match the locale! Blimey...
Bed time (and think time)...
- Argolance
- Posts: 3767
- Joined: Sun 06 Jan 2008, 22:57
- Location: PORT-BRILLET (Mayenne - France)
- Contact:
Hello,
@ thunor
Did you sleep with one eye opened or like a log?
For a long time, I noticed something else which has perhaps (in)directly something to do with the issue related above and concerning the latest release of JWM. In my xerrs.log, I am always getting these errors lines:
Bed time (and think time)... I then thought why don't I replace points of the opacity values with commas in the /root/.jwm/jwmrc-theme?
So I did that.
And it worked fine!
Regards!
@ thunor
Did you sleep with one eye opened or like a log?
I understand now what I need to do
For a long time, I noticed something else which has perhaps (in)directly something to do with the issue related above and concerning the latest release of JWM. In my xerrs.log, I am always getting these errors lines:
Tray and menu opacity did not work properly anymore!JWM: warning: invalid tray opacity: 0.8
JWM: warning: invalid menu opacity: 0.8
Bed time (and think time)... I then thought why don't I replace points of the opacity values with commas in the /root/.jwm/jwmrc-theme?
So I did that.
And it worked fine!
Code: Select all
. <TrayStyle>
<Background>#777777</Background>
<Opacity>0,5</Opacity>
</TrayStyle>
- thunor
- Posts: 350
- Joined: Thu 14 Oct 2010, 15:24
- Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
- Contact:
I've had a good think about this now.
The problem is that the C functions such as atof() and strtod() will be expecting the correct decimal separator for the user's locale, but the application will have been written using any locale which is unknown.
There are two ways I can currently think of to deal with this:
1. Pass the XML's locale as an option to gtkdialog on the command-line e.g. gtkdialog --source-locale=fr_FR -p MAIN_DIALOG. I've identified about 16 places within Gtkdialog's C code that will require modification for this, and I'll also need to add the code to support the "--source-locale" option. Is there a problem with this method? Well, there are a multitude of LC_* variables affecting localisation and I'm not realistically going to be able to support all those on the command-line. Also this doesn't deal with what the application developer is doing outside of Gtkdialog i.e. reading and writing files with decimal separators or using commands that output decimal separators.
2. Deal with this in the application script. The application developer reads LC_NUMERIC, LC_ALL and/or LANG and then decides which decimal separator to use within the script. So instead of hardcoding "0,1" in your XML you would instead set DS="," and then use "0${DS}1". If you the developer are reading and writing files and using commands that include decimal separators then you should be writing your application to deal with the user's locale.
Now, you might expect me to prefer method 2 as then I don't have to do any work But if you think about it, the XML/script and the developer's brain must operate in the user's locale, not expect the user's C library, executables and shell to be adjusted to deal with your script.
Let me know what you think or infact anyone who has an opinion on the matter.
Regards,
Thunor
The problem is that the C functions such as atof() and strtod() will be expecting the correct decimal separator for the user's locale, but the application will have been written using any locale which is unknown.
There are two ways I can currently think of to deal with this:
1. Pass the XML's locale as an option to gtkdialog on the command-line e.g. gtkdialog --source-locale=fr_FR -p MAIN_DIALOG. I've identified about 16 places within Gtkdialog's C code that will require modification for this, and I'll also need to add the code to support the "--source-locale" option. Is there a problem with this method? Well, there are a multitude of LC_* variables affecting localisation and I'm not realistically going to be able to support all those on the command-line. Also this doesn't deal with what the application developer is doing outside of Gtkdialog i.e. reading and writing files with decimal separators or using commands that output decimal separators.
2. Deal with this in the application script. The application developer reads LC_NUMERIC, LC_ALL and/or LANG and then decides which decimal separator to use within the script. So instead of hardcoding "0,1" in your XML you would instead set DS="," and then use "0${DS}1". If you the developer are reading and writing files and using commands that include decimal separators then you should be writing your application to deal with the user's locale.
Now, you might expect me to prefer method 2 as then I don't have to do any work But if you think about it, the XML/script and the developer's brain must operate in the user's locale, not expect the user's C library, executables and shell to be adjusted to deal with your script.
Let me know what you think or infact anyone who has an opinion on the matter.
Regards,
Thunor
- thunor
- Posts: 350
- Joined: Thu 14 Oct 2010, 15:24
- Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
- Contact:
Hi Argolance
I think we're posting at the same time again I've only just noticed that you posted before me.
I like to have a problem to sleep on. My head hits the pillow, I think how I'm going to solve the problem, I find a solution, and then I'm asleep
So then, using your opacity issue as an example, if the value within jwmrc-theme was modified using the wrong decimal separator by some Gtkdialog application then the application developer should make sure that he is using the correct decimal separator for the user's locale.
[EDIT] Since Puppy Linux is built so much from Gtkdialog apps, I'm sure that other folk have already trodden this path. It might be new for us to think about but I'm certain somebody has already dealt with this before.
Regards,
Thunor
I think we're posting at the same time again I've only just noticed that you posted before me.
I like to have a problem to sleep on. My head hits the pillow, I think how I'm going to solve the problem, I find a solution, and then I'm asleep
So then, using your opacity issue as an example, if the value within jwmrc-theme was modified using the wrong decimal separator by some Gtkdialog application then the application developer should make sure that he is using the correct decimal separator for the user's locale.
[EDIT] Since Puppy Linux is built so much from Gtkdialog apps, I'm sure that other folk have already trodden this path. It might be new for us to think about but I'm certain somebody has already dealt with this before.
Regards,
Thunor
- thunor
- Posts: 350
- Joined: Thu 14 Oct 2010, 15:24
- Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
- Contact:
This is how you could approach it:
Regards,
Thunor
Code: Select all
#!/bin/sh
GTKDIALOG=gtkdialog
funcDecimalMarkGet() {
local language
## LC_ALL takes precedence over LC_NUMERIC
## and if both are null then use LANG.
language=$LC_ALL
if [ -z "$language" ]; then language=$LC_NUMERIC; fi
if [ -z "$language" ]; then language=$LANG; fi
## language[_territory][.codeset][@modifier]
language=${language%@*}
language=${language%.*}
language=${language%_*}
language=`echo $language | tr A-Z a-z`
## This'll do for a start.
case "$language" in
en | jp | cn ) echo '.' ;;
*) echo ',' ;;
esac
}
DM=`funcDecimalMarkGet`
MAIN_DIALOG='
<window title="Decimal Mark Test" resizable="true">
<vbox>
<frame hscale widget>
<hscale space-expand="true" space-fill="true"
width-request="200" height-request="20"
value-pos="0"
range-min="0'$DM'3" range-max="30'$DM'7"
range-step="0'$DM'1" range-value="15'$DM'5">
<variable>HSCALE</variable>
</hscale>
</frame>
<hbox homogeneous="true">
<button ok></button>
</hbox>
</vbox>
<action signal="hide">exit:Exit</action>
</window>
'
export DM
export MAIN_DIALOG
$GTKDIALOG --program=MAIN_DIALOG
Thunor
Last edited by thunor on Wed 30 Nov 2011, 22:49, edited 1 time in total.