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:

#561 Post by zigbert »

thunor wrote:
sc0ttman wrote:Thanks for all the updates.. How do I get (checkout) a version older than the latest? Cos with r428 I have taller than usual <tree> entries... The height of each entry is larger than before... I would like to go back and build the latest rev where this doesn't happen, for now...
...

You might want to try:

Code: Select all

svn checkout -r 420 http://gtkdialog.googlecode.com/svn/trunk/ gtkdialog
This useful info should be available a more visited place.


Sigmund

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

#562 Post by zigbert »

Code: Select all

<action signal="changed">refresh:PIXMAP</action>
Well, I don't have the knowledge to tell, but could this reduce the cpu-usage by replacing <timers> with <action signal="changed">?

Sigmund

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#563 Post by sc0ttman »

You might want to try:

Code: Select all

svn checkout -r 420 http://gtkdialog.googlecode.com/svn/trunk/ gtkdialog
to take you back to before the tree widget update.
Thanks, that's what I was lookin for...
Can you please attach an image showing the taller rows. What version of Puppy are you using?
I am using Akita, based on pup420, but now wary5.1.x toolchain and libs, etc... I have attached the screenshots... The 1st is r420, showing normal height, the 2nd is r430, showing large heights..

EDIT: The change comes in at r428

Here is the code for <tree> in the PPM (I haven't changed it, it's original pup4 code):

Code: Select all

  <tree icon=\"pet48x\">
    <label>${Loc_Col_Package}|${Loc_Col_Description}|${Loc_Col_end}</label>
    <height>280</height><width>668</width>
    <variable>TREE1</variable>
    <input>cat /tmp/filterpkgs.results</input>
    <action signal=\"button-release-event\">/usr/local/petget/installpreview.sh</action>
    <action signal=\"button-release-event\">/usr/local/petget/findinstalledpkgs.sh</action>
    <action signal=\"button-release-event\">refresh:TREE2</action>
  </tree>
I notice the tree below doesn't change, here is the code for that one:

Code: Select all

  <tree icon=\"pet48x\">
    <label>${Loc_InstPack1}</label>
    <height>100</height><width>480</width>
    <variable>TREE2</variable>
    <input>cat /tmp/installedpkgs.results</input>
    <action signal=\"button-release-event\">/usr/local/petget/removepreview.sh</action>
    <action signal=\"button-release-event\">/usr/local/petget/findinstalledpkgs.sh</action>
    <action signal=\"button-release-event\">refresh:TREE2</action>
  </tree>
Attachments
r420.png
r420, normal heights
(101.53 KiB) Downloaded 639 times
r430.png
r430, large height of tree entries, first occurs r428
(73.55 KiB) Downloaded 648 times
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

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

#564 Post by thunor »

In r433, "auto-refresh" is now "file-monitor" to make it more generic so that I can add this functionality to other widgets later.

The monitor's "changed" signal is now a custom "file-changed" signal.

Nothing is auto-refreshed. If developers want to execute <action signal="file-changed">refresh:PIXMAP</action> then they now have the choice.

sc0ttman, try the latest r433 which will solve the tree issue. BTW the PPM looks really nice.

Going out jogging now...

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#565 Post by sc0ttman »

thunor wrote:sc0ttman, try the latest r433 which will solve the tree issue. BTW the PPM looks really nice.

Going out jogging now...
Doh... I was just coming on here to say how damn proud I am that I located the the problem myself, and even fixed it by editing the source code, (also) re-enabling the 'g_strstrip' stuff in widget_tree.c...

But now I see you beat me to it.. :roll:

BTW, I tested re-enabling all 3, which worked...
..but so did re-enabling only the 1st one, g_strstrip(oneline);

Thanks, enjoy the jog.
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

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

#566 Post by technosaurus »

thunor wrote:In r433, "auto-refresh" is now "file-monitor" to make it more generic so that I can add this functionality to other widgets later.

The monitor's "changed" signal is now a custom "file-changed" signal.

Nothing is auto-refreshed. If developers want to execute <action signal="file-changed">refresh:PIXMAP</action> then they now have the choice.

sc0ttman, try the latest r433 which will solve the tree issue. BTW the PPM looks really nice.

Going out jogging now...
I'll have to test it out. My idea was to allow basic board and grid games using svg's include capabilities to place sprites in a grid. I already have a basic framework including simple collision detection.

800ms should be fine for card, board and strategy games
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:

#567 Post by thunor »

sc0ttman wrote:Doh... I was just coming on here to say how damn proud I am that I located the the problem myself, and even fixed it by editing the source code, (also) re-enabling the 'g_strstrip' stuff in widget_tree.c...

But now I see you beat me to it.. :roll:

BTW, I tested re-enabling all 3, which worked...
..but so did re-enabling only the 1st one, g_strstrip(oneline);

Thanks, enjoy the jog.
When I recently updated the tree widget I saw those g_strstrips and as this isn't being done in other widgets, in the interests of performance I disabled them, but now we know g_strstrip strips [CR]LFs too (I ran some test code) so that's why that initial g_strstrip(oneline); was necessary. I've now replaced that with my usual [CR]LF stripping code and only used g_strstrip on the stock/icon-names if passed in because it's required. I've tested all sorts of weird rows with space and newlines scattered throughout and it renders as it should so I've committed that in r434 and it would be great if you could let me know if everything's ok.

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:

#568 Post by thunor »

zigbert wrote:

Code: Select all

<action signal="changed">refresh:PIXMAP</action>
Well, I don't have the knowledge to tell, but could this reduce the cpu-usage by replacing <timers> with <action signal="changed">?

Sigmund
I've just committed r436 and the file-monitor has been added to the [toggle]button and checkbox widgets. I can add it easily to the remaining widgets which I shall continue to do.

I was thinking when adding it to the checkbox that it would be quite useful for the conditional widget refreshing trick. Instead of having a timer refresh a checkbox once a second in case the checkbox's inputfile has changed, you'd do it on the file-monitor's "file-changed" signal which would refresh the checkbox only when necessary. So yeah, it will be more efficient.

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#569 Post by sc0ttman »

thunor wrote:I've now replaced that with my usual [CR]LF stripping code and only used g_strstrip on the stock/icon-names if passed in because it's required... so I've committed that in r434 and it would be great if you could let me know if everything's ok.

Regards,
Thunor
I built r444 and it works OK, no extra tall <tree> entries.. Thanks.

BTW, I think I saw earlier someone way they'd like the build time config options in the help info. I would like that too, but not as much as I'd like to see the revision number when using -v ... I like VLCs -vvv option...

Thanks again.
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

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

#570 Post by thunor »

sc0ttman wrote:I built r444 and it works OK, no extra tall <tree> entries.. Thanks.

BTW, I think I saw earlier someone way they'd like the build time config options in the help info. I would like that too, but not as much as I'd like to see the revision number when using -v ... I like VLCs -vvv option...

Thanks again.
Thanks sc0ttman for testing.

In r451:

Compiling from SVN results in:

Code: Select all

# gtkdialog -v
gtkdialog version 0.8.1 r451 (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
Built with additional support for: Glade, VTE.
Compiling from a [future] source package results in:

Code: Select all

# gtkdialog -v
gtkdialog version 0.8.2 release (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
Built with additional support for: Glade, VTE.
Cheers,
Thunor

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

#571 Post by thunor »

technosaurus wrote:I'll have to test it out. My idea was to allow basic board and grid games using svg's include capabilities to place sprites in a grid. I already have a basic framework including simple collision detection.

800ms should be fine for card, board and strategy games
For all widgets that support <input file> I've implemented a file-monitor tag attribute that emits a "file-changed" signal which developers can do what they like with, and an auto-refresh tag attribute that calls the widget's refresh function directly and which doesn't emit a signal.

On my computer (Intel Pentium Dual Core T2060 @ 1.6GHz) and with a test application of 256 buttons with 16x16 images I recorded 2.29s refreshing via the file-monitor's signal and 1.39s auto-refreshing.

I tried to write a game at the end of last year and slow refreshing was one issue, but the worst one was the difficulty in conditionally refreshing widgets. I think both of those should be solved now since it's now possible to choose to refresh a widget simply by updating its input file which means you can do that within the shell script.

I'm all up-to-date now with gtkdialog and I'm going to start preparing a source package release, so it would be a good idea for application developers to try it to make sure there aren't any overlooked issues.

Regards,
Thunor

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

#572 Post by 01micko »

r451 seems working well here. Checked quite a few guis and no issues to report.
Puppy Linux Blog - contact me for access

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

#573 Post by technosaurus »

thunor wrote: For all widgets that support <input file> I've implemented a file-monitor tag attribute that emits a "file-changed" signal which developers can do what they like with, and an auto-refresh tag attribute that calls the widget's refresh function directly and which doesn't emit a signal.

On my computer (Intel Pentium Dual Core T2060 @ 1.6GHz) and with a test application of 256 buttons with 16x16 images I recorded 2.29s refreshing via the file-monitor's signal and 1.39s auto-refreshing.

I tried to write a game at the end of last year and slow refreshing was one issue, but the worst one was the difficulty in conditionally refreshing widgets. I think both of those should be solved now since it's now possible to choose to refresh a widget simply by updating its input file which means you can do that within the shell script.

I'm all up-to-date now with gtkdialog and I'm going to start preparing a source package release, so it would be a good idea for application developers to try it to make sure there aren't any overlooked issues.

Regards,
Thunor
Would you be interested in Linux-specific #ifdef code that removes even the (up to) 800ms lag (using inotify directly instead of glib wrappers)?
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
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#574 Post by 01micko »

Just to let you know, r451 compiled and is working in raspbian [had to install about 50 deps! :roll: ]. Widget order is correct.
Puppy Linux Blog - contact me for access

User avatar
oldyeller
Posts: 889
Joined: Tue 15 Nov 2011, 14:26
Location: Alaska

#575 Post by oldyeller »

How do I update gtk for lupu 525?

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

#576 Post by thunor »

technosaurus wrote:Would you be interested in Linux-specific #ifdef code that removes even the (up to) 800ms lag (using inotify directly instead of glib wrappers)?
I tried this tonight using the inotify code you posted a while back and I wrote inotify equivalent functions to my file-monitor ones and auto-refreshing 100 16x16 pixmaps was so fast it would be difficult to measure it, but unfortunately I came across a limitation when I increased the number of pixmaps: there's a 128 file descriptor limit which is a shame -- see /proc/sys/fs/inotify/max_user_instances.

I've committed it to r454 and the code to enable it is in configure.in, so if you want to try it you should uncomment the code and run ./autogen.sh etc. and play with examples/pixmap/pixmap_auto_refresh which has width and height variables that you can modify.

Mick, thanks for the info and it's good that everything is fine.

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:

#577 Post by thunor »

Gtkdialog 0.8.2 Released

Changes:
* Added eventbox, expander and fontbutton widgets.
* Added a terminal widget -- requires libvte but is not mandatory.
* Added activate, grabfocus, hide, show, and presentwindow functions.
* Added widget signal emission on input file change (file-monitor).
* Added widget auto-refreshing on input file change (auto-refresh).
* Greatly improved the table and tree widgets including natural sorting.
* Greatly enhanced the performance of the table, tree and comboboxes.
* Greatly expanded the feature set of several incomplete widgets.
* Added many useful exported variables on button and key press events.
* Added the envvar GTKDIALOG_PIXMAP_PATH to help locate pixmaps.
* Re-engineered the launch and closewindow system to be more robust.
* Fixed the longstanding not exiting via the window manager bug.
* Fixed and improved the button horizontal image with label alignment.
* Fixed the Raspberry Pi's (ARM) incorrectly ordered widgets problem.
* Added build and extra library details to the --version argument.
* Added more than a dozen new examples.
* Added a default application icon.
* Fixed several bugs.

http://code.google.com/p/gtkdialog/downloads/list

Thanks to everyone who helped with feature recommendations and testing.

My turn to have a play now :)

Regards,
Thunor

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

resource usage of the new gtkdialog versus the old

#578 Post by mcewanw »

From running "top" I've noticed that the GUI for gtkdialog apps tend to consume around 70 to 75% more RAM (which is considerable) when running on Slacko-5.3.3 than on Wary 5.3. I believe the latter uses an older gtkdialog. From my quick checks, for example, the typical gtkdialog app GUI consumes around 20Mbyte RAM on Wary 5.3 but in Slacko-5.3.3 it consumes around 34Mbyte RAM. I presume that one of your newer gtkdialog is installed in Slacko than in Wary and that that is the reason for the increased resource usage?

I realise that the penalty for additional functionality is inevitably an increase in resource usage and computer systems grow in terms of resource availability anyway. However, could you state or confirm what the difference (as at least an approximation) in resource usage is for your new gtkdialog versus the one used before these developments began?

Generally speaking, I'm all for the new developments, however, except perhaps on lower-powered machines.
github mcewanw

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

#579 Post by thunor »

Let's test :)

http://bkhome.org/sources/alphabetical/ ... e-1.tar.gz
http://gtkdialog.googlecode.com/files/g ... 8.0.tar.gz
http://gtkdialog.googlecode.com/files/g ... 8.2.tar.gz

I have libglade and libvte on my system so the configure script finds them (the binary packages of these versions have libglade support built-in I believe) so after executing ./configure with 0.8.2 it's possible to disable libvte by using "make HAVE_VTE=0" (top tip).

"pkg-config --modversion gtk+-2.0" and "pkg-config --modversion glib-2.0" tell you which library versions you have installed.

Let's concentrate on htop's RES (resident memory) column -> VIRT, RES and SHR in top output

Code: Select all

export MAIN_DIALOG='<text label="Hello World"></text>'; gtkdialog -p MAIN_DIALOG
lupu 520 gtk+ 2.20.0 glib 2.24.0
gtkdialog3 0.7.20-patriot-e-1 -> VIRT=20732 RES=6852 SHR=5620
gtkdialog4 0.8.0 -> VIRT=25248 RES=6796 SHR=5556
gtkdialog 0.8.2 -> VIRT=22896 RES=7676 SHR=6176

In 0.8.0 I increased MAXWIDGETS so the widget array size increased, and then I discovered that it actually meant max widgets per container so in 0.8.2 it's now back down to its 0.7.20 size.

So far so good. I'm going to reboot into Slacko now...

In slacko 533, gtkdialog3 and gtkdialog4 are symlinks to gtkdialog 0.8.0 which gives identical results to the 0.8.0 I built for testing.

slacko 533 gtk+ 2.24.4 glib 2.28.6
gtkdialog3 0.7.20-patriot-e-1 -> VIRT=21620 RES=6876 SHR=5856
gtkdialog4 0.8.0 -> VIRT=26052 RES=6792 SHR=5768
gtkdialog 0.8.2 -> VIRT=22228 RES=7284 SHR=6040

So, apart from the temporary VIRT increase in 0.8.0 which would've been the bigger widget array, for all my work it's not really showing much of an increase -- it's just code.

User avatar
oldyeller
Posts: 889
Joined: Tue 15 Nov 2011, 14:26
Location: Alaska

#580 Post by oldyeller »

I have redone this pet, So know you can use all the examples and have fun creating great gtkdialog programs

This works on lupu 525, slacko, Dpup

Cheers
Attachments
gtkdialog-0.8.2-i486.pet
(183.98 KiB) Downloaded 547 times
Last edited by oldyeller on Sat 03 Nov 2012, 02:54, edited 1 time in total.

Post Reply