Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 21 Apr 2018, 21:45
All times are UTC - 4

 Forum index » Advanced Topics » Cutting edge
Gtkdialog Development
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 39 of 56 [833 Posts]   Goto page: Previous 1, 2, 3, ..., 37, 38, 39, 40, 41, ..., 54, 55, 56 Next
Author Message
thunor


Joined: 14 Oct 2010
Posts: 350
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
PostPosted: Wed 19 Sep 2012, 18:32    Post subject:  
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
Back to top
View user's profile Send private message Visit poster's website 
01micko


Joined: 11 Oct 2008
Posts: 8670
Location: qld
PostPosted: Thu 20 Sep 2012, 01:43    Post subject:  
r451 seems working well here. Checked quite a few guis and no issues to report.
_________________
Puppy Linux Blog - contact me for access
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4786
Location: Kingwood, TX
PostPosted: Thu 20 Sep 2012, 03:02    Post subject:  
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 github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
01micko


Joined: 11 Oct 2008
Posts: 8670
Location: qld
PostPosted: Thu 20 Sep 2012, 08:11    Post subject:  
Just to let you know, r451 compiled and is working in raspbian [had to install about 50 deps! Rolling Eyes ]. Widget order is correct.
_________________
Puppy Linux Blog - contact me for access
Back to top
View user's profile Send private message Visit poster's website 
oldyeller


Joined: 15 Nov 2011
Posts: 888
Location: Alaska
PostPosted: Thu 20 Sep 2012, 19:21    Post subject:  
How do I update gtk for lupu 525?
Back to top
View user's profile Send private message 
thunor


Joined: 14 Oct 2010
Posts: 350
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
PostPosted: Thu 20 Sep 2012, 21:26    Post subject:  
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
Back to top
View user's profile Send private message Visit poster's website 
thunor


Joined: 14 Oct 2010
Posts: 350
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
PostPosted: Fri 21 Sep 2012, 13:37    Post subject:  
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 Smile

Regards,
Thunor
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3194
Location: New Zealand
PostPosted: Fri 21 Sep 2012, 19:38    Post subject: resource usage of the new gtkdialog versus the old  
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.
_________________
SomeOfMyWork with links:
dCoreDog
weX, scrox, Precord, Premote, fokSyfEyeR, xhippo-mod, flite_hts_pet
Back to top
View user's profile Send private message Visit poster's website 
thunor


Joined: 14 Oct 2010
Posts: 350
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
PostPosted: Sat 22 Sep 2012, 11:28    Post subject:  
Let's test Smile

http://bkhome.org/sources/alphabetical/g/gtkdialog3-0.7.20-patriot-e-1.tar.gz
http://gtkdialog.googlecode.com/files/gtkdialog-0.8.0.tar.gz
http://gtkdialog.googlecode.com/files/gtkdialog-0.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:
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.
Back to top
View user's profile Send private message Visit poster's website 
oldyeller


Joined: 15 Nov 2011
Posts: 888
Location: Alaska
PostPosted: Sat 22 Sep 2012, 13:22    Post subject:  
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
gtkdialog-0.8.2-i486.pet
Description 
pet

 Download 
Filename  gtkdialog-0.8.2-i486.pet 
Filesize  183.98 KB 
Downloaded  453 Time(s) 

Last edited by oldyeller on Fri 02 Nov 2012, 22:54; edited 1 time in total
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 3194
Location: New Zealand
PostPosted: Wed 26 Sep 2012, 20:15    Post subject: gtkdialog memory usage: new versus old versions  
thunor wrote:
Let's test :)
...
Let's concentrate on htop's RES (resident memory) column -> VIRT, RES and SHR in top output


gtkdialog memory usage. My results aren't quite so kind. Using some actual gtkdialog3 (ver 0.7.20) compatible apps:

On slacko-5.3.3 with supplied gtkdialog version 0.8.0

Precord-8.0.8: VIRT:34768 RES:8486 SHR:6984
Pwsget: VIRT:34300 RES:8316 SHR:6872
Pfetch: VIRT:34856 RES:8788 SHR:7188
-----

On slacko-5.3.3 with oldyeller compiled gtkdialog 0.8.2

Precord-8.0.8: VIRT:30440 RES:8976 SHR:7484
Pwsget: VIRT:30408 RES:8844 SHR:7372
Pfetch: VIRT:30580 RES:9072 SHR:7468
-----

On Wary 5.3 with supplied gtkdialog3 version 0.7.20

Precord-8.0.8: VIRT:20344 RES:7820 SHR:6464
Pwsget: VIRT:20396 RES:7704 SHR:6340
Pfetch: VIRT:20464 RES:8024 SHR:6504

So main increase in resource usage is in VIRT. But still around one MByte increase for each running gtkdialog application for the RES portion. The increase probably doesn't matter on most people's systems though and the programmer can certainly do a lot more with the new version.
_________________
SomeOfMyWork with links:
dCoreDog
weX, scrox, Precord, Premote, fokSyfEyeR, xhippo-mod, flite_hts_pet
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4786
Location: Kingwood, TX
PostPosted: Thu 27 Sep 2012, 17:50    Post subject:  
comparing apples to oranges I see... the entire backend environment was different (look at the difference between any gtk program between those systems)

Anyhow that's not why I came ... beginning of gtkbuilder transition - got the gui to display but still need to figure out the signals (I couldn't find a 1 to 1 replacement, so I used my best guess and apparently guessed wrong)

just open up existing glade files with glade-3 and save-as then click gtkbuilder and overwrite the existing file

Edit: I wanted to clarify that this will remove glade support an replace it with gtk's builtin gtkbuilder but is not finished (callbacks aren't working and the build system still checks for glade, I removed libglade from the final link manually when I built it)
gtkbuilder.diff.gz
Description 
gz

 Download 
Filename  gtkbuilder.diff.gz 
Filesize  1.8 KB 
Downloaded  272 Time(s) 

_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3194
Location: New Zealand
PostPosted: Fri 28 Sep 2012, 01:13    Post subject:  
technosaurus wrote:
comparing apples to oranges I see... the entire backend environment was different (look at the difference between any gtk program between those systems)


Yes, of course. That explains the difference indeed. It isn't the version of gtkdialog being used that changes the resource usage, it is the background environment between these puppies. I feel at peace with using Thunor's new one now, which was a great deal of good work on his part! :-)

Alas that Linux more generally bloats over time too.
_________________
SomeOfMyWork with links:
dCoreDog
weX, scrox, Precord, Premote, fokSyfEyeR, xhippo-mod, flite_hts_pet
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4786
Location: Kingwood, TX
PostPosted: Sat 29 Sep 2012, 02:09    Post subject:  
I have gtkbuilder figured out - the handler callback requires this format:

Code:
static gboolean
gtk_button_signal_handler_connector(
      GtkBuilder *builder,
      GObject *object,
      const gchar *signal_name,
      const gchar *signal_handler,
      GObject *connect_object,
      GConnectFlags flags,
      gpointer user_data){
   gint n;
   gchar *signal_names[] = {
      "activate", "clicked", "enter", "leave", "pressed", "released", NULL };


for (n = 0; signal_names[n] != NULL; ++n) {
      if (g_ascii_strcasecmp(signal_name, signal_names[n]) == 0) {
         g_signal_connect(object,
               signal_names[n],
               G_CALLBACK(on_any_button_clicked),
               g_strdup(signal_handler));
         return TRUE;
      }
   }
   return FALSE;
}


static gboolean
signal_handler_connector(
      GtkBuilder *builder,
      GObject *object,
      const gchar *signal_name,
      const gchar *signal_handler,
      GObject *connect_object,
      GConnectFlags flags,
      gpointer user_data)
{


   if (GTK_IS_TOOL_BUTTON(object))
      if (gtk_button_signal_handler_connector(builder,
         object,
         signal_name,
         signal_handler,
         connect_object,
         flags,
         user_data))
         return; //may need TRUE?
}
The rest _could_ just be cut/paste, but it looks like it could use stuff from automaton.c, but the functions are declared static, so the question is move it to automaton so that we can use the code and keep it static to help the compiler keep it small? leave it as is and write a bunch of duplicate functions? or add some function headers to automaton.h and remove some static declarations? I'm going to stop here until further input, but I am leaning toward putting it in automaton.
_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
thunor


Joined: 14 Oct 2010
Posts: 350
Location: Minas Tirith, in the Pelennor Fields fighting the Easterlings
PostPosted: Sat 29 Sep 2012, 18:00    Post subject:  
Thanks technosaurus, added to issue tracker for a future update.

http://code.google.com/p/gtkdialog/issues/detail?id=12
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 39 of 56 [833 Posts]   Goto page: Previous 1, 2, 3, ..., 37, 38, 39, 40, 41, ..., 54, 55, 56 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group

[ Time: 0.1931s ][ Queries: 13 (0.1105s) ][ GZIP on ]