Re: Developing and Testing panel applets
- From: Michael Meeks <michael ximian com>
- To: "Sergey V. Oudaltsov" <sergey oudaltsov clients ie>
- Cc: Paulo Pinto <paulo pinto altitude com>, gnome-devel-list <gnome-devel-list gnome org>
- Subject: Re: Developing and Testing panel applets
- Date: 20 Dec 2002 20:20:48 +0000
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]