(old)Puppy Linux Discussion Forum

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

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.

Can you please attach an image showing the taller rows. What version of Puppy are you using?

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

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

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

Going out jogging now...

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...

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..

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.

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

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

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.

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

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

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

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

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)?