GTK2 tray applets a problem?

A couple of people have noted that Blinky is using twice the resources that it uses in 3.01. The reason for this is that Blinky in 3.01 is a GTK1 application and I ported it to GTK2 for Dingo.

The other GTK2 tray applet in Dingo is the volume control.

Does anyone think that the amount of resources that these are using will cause noticeable performance degradation on older PCs?

If so, then we should be looking at rewriting them to use Xlib only. There is already an earlier version of the volume control which uses Xlib.

I do cringe when I run 'top' and see those two applets right near the top. Daemons should really be low-resource things that hardly impact the system resources.

Posted on 23 Apr 2008, 8:16


Posted on 23 Apr 2008, 11:40 by Lobster
blinky daemon
I can control sound from hardware. If I am browsing I am connected. Knowing the time and free mem I think are useful and I refer to all the time. Volume and Blinky can be added as options but maybe the default should be off. I feel the reliability of browsers (there was a time when it was 100%) might return without blinky. I am now in the habit of turning blinky off. The other daemon is the CPU usage which has never, in my experience, given any useful feedback. If people are testing conky is good (I never use it personally). Hope that helps. Apologies to the developers, who have done a great job on these components.

Posted on 23 Apr 2008, 12:56 by ANOSage
Volume control
Yes. I've had a problem with the VC - it can only be set to zero or 100% recently.
As for gizmos, remove them - the big push has to be towards the 25Mb .iso target of SliTaz or 1.44Mb of Kolibri, albeit with assembler coding.

Posted on 23 Apr 2008, 15:22 by HairyWill
revert the volume control
I would be happy to see the volume control reverted. I've learnt a lot about gtk programming in creating it but its memory cost is too high. I've written it as efficiently as I know how. I suppose GTK applications have a fixed minimum memory use and I don't think there is anyway to reduce that. Also my understanding of the sound system is somewhat limited so I find it hard to fix individuals problems.

As by default it provides no monitoring capability there is no functional need for the volume control to be a daemon at all. It could just be an application launched by a TrayButton which can be placed on either the left or the right side of the tray.

Posted on 23 Apr 2008, 15:23 by HairyWill
revert the volume control
grr the maximum 1000 characters per post is rather limiting

Reverting to the original absvolume not to work as a trayicon but as a fixed icon traybutton using my cut down slider design and having it die on focus wouldn't be hard. There would be no memory or cpu usage unless you were using it but you would have the startup cost each time you clicked it and the memory/cpu usage whilst using the slider would only be reduced slightly.

I'm happy to put in the minimal effort to do the conversion but don't really mind either way.

Posted on 23 Apr 2008, 18:07 by BarryK
Re: volume control
Thanks for your constructive comments regarding the volume control. Yes, the "fixed icon traybutton" idea seems good.

Well, I'm aiming for 4.00 final to be out by about 3rd - 5th of May, so not looking at any major coding at this stage.

Your GTK2 applet is nice... for me personally though, your original version is quite satisfactory.

Posted on 23 Apr 2008, 18:15 by BarryK
Commentsnow 2000 chars
Ok, I have doubled the size allowed for comments, from 1000 to 2000 characters. I suppose the limit is there as a security measure.

Posted on 23 Apr 2008, 20:45 by HairyWill
minimal volume control
Here we go paired down to the minimum.
It can be started from a jwm button.
7K stripped.
I should have started here ;-)

Posted on 23 Apr 2008, 22:19 by kirk

I sent you a PM that has another version of Blinky attached. Top shows it using 2% memory and 0% cpu.

Posted on 24 Apr 2008, 2:51 by melhundo
The XCB library is an attempt to replace Xlib.