Re: Developing and Testing panel applets



Hi Sergey,

On Thu, 2002-12-19 at 17:19, Sergey V. Oudaltsov wrote:
> I 100% agree. But you don't want to save some user RAM, do you? And do
> not want people to be accurate writing applets, do you?

	I'm not interested in saving RAM no :-) I am particularly interested in
a bug-free and debuggable panel.

	+ 99.9% of Gnome users use the panel
	+ 1% of users use JimBobHackedLeetShLibApplet which corrupts
	  memory badly, uses global variables, can't cope with multiple
	  instances etc.
	+ 1% of users file "it crashes" type bugs with confusing 
	  back-traces on the panel - regularly.

	Thus we get screwed by people doing stupid things beyond our control.

> Well, is there any official policy statement in the gnome project: when
> developers should choose shlib over apps ?

	If you're applet is useful enough to be in the core distribution, it's
likely to be used enough and read enough to be sufficiently bug free
that it's worth making it a shlib component.

	Otherwise it's a really bad idea for everyone IMHO.

>  Also, why apps take so much
> memory - because they should load all the libs (i.e. their data
> segments) which already loaded by gnome-panel? I thinks there should be
> some statement on the subject...

	How are you measuring memory usage. Looking at memory usage I get (for
battstat-applet):

	Total 6.6Mb
	RSS   6.3Mb
	Share 5.4Mb

	So - yes, it seems that in real terms it consumes ~1Mb to run the
battstat applet. It would be interesting to see how that breaks down. [
the size goes up having used a dialog eg. ].

	I have various suspicious and prejudices, but run memprof on it and do
a module breakdown somehow, and we'll see.

	I'm suspicious of (in no particular order):

		gtkrc state
		GObject property strings
		i18n string tables
		gdkpixbufs

	do post a breakdown though, and we can look at the speed/size tradeoff
again with some good new data.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]