Re: Drive applet by default
Is another daemon going to be created in order to do this, something like ejectable-device-manager? Regardless of any usability issues, this needs to be doable without a new process on the desktop, so that we don't waste memory. -b On Thu, 14 Sep 2006, David Prieto wrote: I've noticed that some people coming from windows have trouble removing USB devices and the like, because they don't quite know what to do to safely remove the device. They come from windows and they're used to look into the system tray to unmount removable. There's no way for them to know that they have to right-click the desktop icon, then navigate the options they're given until they find the secret (as in doesn't show on any other desktop icon) eject option. The drive applet offers a handy solution for those people, and remains unobstrusive because you don't even see it unless there's a device in, but you can access it anytime without having to show the desktop. So I think it would be a good thing to have it included on the panel by default. Another good solution would be to get a notification balloon each time a USB device is inserted, to inform the user about the needed procedure, and a second one to inform them that the device can be removed, just like windows does. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Sun, 23 Jul 2006, Eugenia Loli-Queru wrote: Miguel wrote: I would be interested in understanding what the issues of non-splitting are, from the GNOME point of view. For one, if in the future Gnome would like to provide an embedded version (there was some talk about it already), it would be easier to pick and choose components as seen fit. In a 64 MB firmware you can't fit everything, usually... Of course, I don't think that this means that you need 3 different tarballs instead of 1. As long the selective functionality is present in your current tarball (via an autoconf option), I don't see why it should be physically split in different tarballs. But some form of seperation must exist as the rest of the Gnome is very modular in its nature. This can be done today. Look at: http://svn.myrealbox.com/viewcvs/trunk/gtk-sharp/configure.in.in?rev=56950view=auto and notice how the build *won't* fail if optional stuff isn't there. Lastly, I believe that having a modular GTK# is better for GTK# itself. Think about it: a third party embedded company wants to use it, but it This can be done today! Please refer to the email I sent yesterday. You can still offer a migration path to your existing apps and maintain it as long as you see fit or needed. Not all is lost. It's already possible to link just to Gtk+. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Fri, 21 Jul 2006, Jason D. Clinton wrote: On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: * Should applications built with anything in the Bindings suite be accepted into the Desktop suite? - short to medium term - do we want the central components of our software to potentially be written in five to ten different languages and/or runtimes/platforms? - this leads very neatly into the next question * Is it time to redefine the suites and/or 'franchise' the release process? - medium term - this is not just about new suites, it's about redefining the current Desktop suite by its integration interfaces and central components; we need to make current suites serve us better before kicking off new stuff - http://perkypants.org/blog/2005/05/19/1116533413/ (last few paras) - start slow: don't even create new suites to begin with, just make sure the small number of apps that want to adopt our process and standards right now can do so - new/further governance of suites can come later Regarding just the above two issues: What if there is a bilateral subdivision of the desktop suite which helps *distributors* distinguish between applications that support being compiled AOT (C, C++, Mono AOT, Java GCJ, D?) and applications that run JIT'd/VM'd (Mono JIT, Java JRE, Python, Ruby, Perl). It seems to me that, at least conceptually if not technically, the division between the two camps above is one of AOT/native compilation versus JIT/VM'd/interpreted compilation. I don't think this is an item worth dividing on. For languages like Mono (and Java with GCJ), the compile or JIT (for Mono) or interp (for GCJ) is purely a case-by-case performance decision. Notice that both Java and Mono could be in either camp depending on how the project's Makefiles are written ... in both the Mono AOT and Java GCJ cases, libraries in use are shared between processes. Execution performance is also (generally) higher. The statement that performance is generally higher isn't quite correct. However, it's completely besides the point for this discussion. It would be interesting to get Miguel's take on whether or not Mono AOT usage should be encouraged. In the Java GCJ case, it is encouraged for use by its authors. Again, completely besides the point. The decision to AOT would be based on measurements. It doesn't address any of the issues in Jeff's email. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Fri, 21 Jul 2006, Jason D. Clinton wrote: On Fri, 2006-07-21 at 13:39 -0400, Ben Maurer wrote: I don't think this is an item worth dividing on. For languages like Mono (and Java with GCJ), the compile or JIT (for Mono) or interp (for GCJ) is purely a case-by-case performance decision. ... The statement that performance is generally higher isn't quite correct. However, it's completely besides the point for this discussion. ... Again, completely besides the point. The decision to AOT would be based on measurements. It doesn't address any of the issues in Jeff's email. Well I respectfully disagree and I find your statements that my statements don't address any issues raised by Jeff very puzzling as they were specifically influenced by the framing Jeff did in the issue directly above the two I quoted. Quoth Jeff: * Should Gtk#/Mono applications be accepted into the Desktop suite? ... - performance (memory and cpu) is a red herring here; we all *know* that ... - can we resolve the dissonance between delivering a coherent Desktop (a goal of the Desktop suite) and suggesting that vendors deliver multiple vm/language/binding/runtime platforms to satisfy it, and demand that users stomach it too? (this has also been raised as a performance issue) You are, of course, welcome to disagree with my suggestion. I have no idea if it's a good one or not but I thought it was worth bringing up. I think that inventivizing projects to push toward an AOT approach could be one way to help allay the people pounding their fists over the perceived performance of the desktop OOTB. AOT is *not* always faster. There are lots of variables. For example, at JIT time, the compiler can make some assumptions that AOT can not (for example, if you have a static readonly field [static final in java], JITs can inline the constant value because it will never change. AOT can't do this because the value is computed in the static constructor). In some cases, AOT can incresae startup time becasue the assembly used by CPUs is generally larger than the IL in a JIT. In these cases, it can be *faster* to compile than it is to read more from the disk see: http://blogs.msdn.com/ricom/archive/2004/10/18/244242.aspx for a bit about this. We should encourage performance. However, making divisions based on specific optimization techniques is the wrong direction. Also, getting off track and talking about specific optimization techniques while making high level decisions isn't going to help. If you want to talk more about AOT in Mono (or other runtimes), this is simply not the list to do it. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
Hey, On Wed, 19 Jul 2006, Jani Monoses wrote: the GnomeClient API is for some apps the single Gnome dependency that has no GTK equivalent and that keeps said apps tied to the 25 or so platform libraries. Other libgnome(ui) uses are gnome_program_init() and Yes! Fixing this will be very good for GNOME, and greatly reduce the cost of some our daemons. gnome_help_display() which can be replaced by gtk_init variants and directly spawning gnome-open or yelp. Well, the other thing that the gnome_program_init provides (as I understand it) is the bug-buddy hooks. However, IMHO, this is more of a distro thing. Ubuntu's solution (https://wiki.ubuntu.com/AutomatedProblemReports) seems to be better here, as distro specific stuff can make great efforts to get symbols, etc. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing the splashscreen for 2.16
Hey, On Fri, 14 Jul 2006, Soeren Sandmann wrote: I would like to turn off the login splashscreen by default, for the following reasons: - login is somewhat faster - the 'progress' icons in the splashscreen don't reflect the time it actually takes to login. On my system, the login process is like this: ... The splash screen just doesn't serve any purpose. The progress it shows has nothing to do with reality, and the splash screen itself isn't even visible for more than 25% of the login time. The times might be much longer for some users -- eg, somebody with an NFS home. 36 seconds (from your measurement) is a *long* time to go without feedback of any sort. I really wish GDM took care of the UI and made the transition to the desktop smooth. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Fri, 14 Jul 2006, Murray Cumming wrote: And while there were almost no objections to Python, there are clearly many objections to Mono. What objections? So far, the only two objections I've heard are: 1. Performance -- I feel that I've addressed this in other emails. 2. Vague references to TLAs such as ISV, OEM, API, ABI without refering to specific problems. Mono provides a very strong ABI in the base class libraries (we implement the same API as the .NET framework). For mono specific libraries, Mono commits to a similar stability level. Further, the objections mentioned all seem to apply equaly to python and mono. Python is allowed for desktop apps already. If nobody can come up with objections to mono that don't apply equally to python, it would seem that mono and python should be on equal footing. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Fri, 14 Jul 2006, Murray Cumming wrote: I don't believe that you've adressed the memory problems, though these are not specific to Mono. We maybe can handle one highlevel runtime, but 2 highlevel runtimes seems to be getting silly. If exactly one runtime needs to be choosen, making python that choice seems relativly narrow sighted. Python provides *only* a scripting like environment. It does not seem that the project wants to provide (or should provide) more than that. Mono provides a framework that has been proven to be capable of supporting many languages (including python, in fact!). In all honesty, I see Python as being popular for short lived applications (a menu editor, etc). While deskbar is contrary to this, that applet seems to be more of a prototype (especially given it's memory usage). The argument that we can fix performance later is not going down well with lots of users, though it makes sense in many ways. What do we say now to the people who say The sticky notes applet now takes up XX megabytes more than before and makes GNOME start up much slower. Those people don't care about anybody's favorite programming language. This is not really as much Mono as it is Tomboy (though both have room for optimization). However, we have been accepting many things that continue to add memory usage (g-power-manager adds yet another daemon taking ~2 MB of memory for EVERYONE, not just sticky users. network maanger, which will probably be accepted for the next cycle will add another process, notifications another). If everyone who has spent so much energy on this thread puts just a bit into performance, we'll have a very cool and very light tomboy. GNOME opening it's arms to Tomboy and other Mono apps will likely motivate the authors to do things that meet GNOME's goals. We want to have it both ways, but we can't right now, so we must make the difficult decision between these pros and cons. It's not helpful to pretend that the decision doesn't exist. Keeping the status quo is also a decision (granted a passive one) the ramifications of which must too be considered. Right now, there are C# apps that overlap with some of the functionality in the official GNOME desktop, rhythmbox and banshee come to mind. The longer GNOME is indecisive, the more effort is put into *both* applications. Also, Tomboy is an applet, intended to replace the commonly-used sticky notes applet, so it's likely to take up memory all the time. (I haven't had a response to my notes-tomboy transistion questions [1] but that's a non-mono issue.) Given the lateness in the release cycle, it would seem reckless to *remove* sticky notes. What about accepting Mono and Tomboy for this release cycle and keeping sticky notes. Then, for the next release cycle, there is the confidence that a silly flamewar on d-d-l won't keep the applications out of GNOME, encouraging the authors do meet GNOME's needs. deskbar-applet has the same problem, of course. When we approved python I don't think we necessarily approved this particular use. That was a separate thing. Then why can't Tomboy be accepted on the same terms as deskbar. And you are ignoring the objections to relying on a techology that is controlled by Microsoft, who: ... understand why it is necessary for some people to pretend that they are not real concerns. Apparently, neither Novell, Red Hat nor Ubuntu considers the risks enough to prevent them from shipping Mono. As for your flames about Microsoft's technical competence, rather than making an attack on Microsoft, say something about the .NET framework. We could spend all day insulting and making generalizations. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
On Fri, 14 Jul 2006, Nate Nielsen wrote: Steve Frécinaux wrote: Iain * wrote: As for .NET, even Microsoft themselves had to pull back from using it for core functionality due to performance reasons - why do we think we will do any better? As someone who is running mono based applications fairly regularly, I haven't noticed any major performance issues. We're not talking here about replacing the core libraries with c# based ones, we're talking about applications, and for me the mono based apps are just as fast as the C based ones. I'm not really against having C# apps in the core (in fact I don't really mind), what I'm more frightening about is having applications that run all the time, using managed languages, and, as a consequence, taking up a fairly large amount of memory, from the computer start to the shutdown. That's what I'm against including libraries, daemons or applets written either in C#, or in python, while having small apps you close once you're done (like alacarte) is fine. Perhaps daemons, applets and core libraries should evaluated on their performance merit independent of the language they're written in or the framework that they use. I'd imagine that those who have worked so hard on GNOME performance issues would be disappointed if they saw a C applet take 18 - 20 megs (resident) or take 10 seconds to load. PLEASE learn how to measure memory. Resident is *NOT* a good measure of memory. You must use smaps to even begin getting an accurate measurement. Not a single person other than Federico and myself have used a number about performance that is relevant. This suggests that there are many people `me too'ing and not thinking about what they are saying. If you want to make groundless claims, comment on slashdot. If the GNOME desktop becomes dependent on one single process like that, it wipes out most of what so many people have worked hard step by step to gain as far as startup speed and memory usage. As you might realize, I'm one of those people. IMHO, having applications written in a framework that encourages maintainable, clean code is a step forward for performance. Do some of the Mono based applications need profiling: yes. Should we use performance as an excuse for not having Mono: no. I don't think we should cut slack for a particular applet or daemon because it happens to be written using an inefficient platform. If its I did not hear anybody suggest that. We're not cutting slack for anyone. performance issues are not up to snuff, then it shouldn't be included as part of the GNOME desktop. Should it be included by *default*: probably not. It needs to be clear that Mono applications will be accepted without bias as to their language. This is what is being requested. That said, I bet the Mono guys could prove everyone wrong by optimizing managed code to where it approaches the startup speed and memory usage of lower level frameworks. That would be lovely. But it might mean not trying to emulate every last 'innovation' in MS .NET C# 3.0 etc... :) Please show benchmarks that show issues here. Banshee and other c# apps seem to startup very fast. While memory usage isn't as good as it could possibly be, we're not talking about a huge amount here (see numbers from myself, federico). Again, in the long term, a moving GC will help us return memory to the system. -- Ben___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
On Fri, 14 Jul 2006, Alvaro Lopez Ortega wrote: Yeah, 100% agree. That is exactly the problem: applications would use another framework rather than the one that they are suppose to use (we are speaking about GNOME apps). libxml is an XML library for *C* apps. It's not designed to be usable in any other language. I understand the desktop framework as the common infrastructure in which almost all the desktop applications are based on. If we move from a scheme in which there is an unique group of common stuff to one in which there are a few of them (GNOME, Python, Mono, Java?) it may become a little messy. IMO. We're not proposing Java. Don't try to inflate your numbers by putting stuff not under consideration in there. First, let's observe that almost everyone seems to desire a move in the managed code direction. Microsoft has invested quite a bit of engineering effort into their Vista based framework. Sun is investing by improving Java on the desktop (including by making Swing apps look native in gtk, for Mustang/Java 6. This work is very impressive). Novell's desktop now includes many Mono based applications. GNOME is not going to survive in C. Will we continue to have a nice desktop environment, yes. However, we are not going to make a computing ecosystem by sitting in our C shells. Embracing python is a good step forward. Embracing Mono will allow the innovations that Novell has made in terms of search, music and photos to be a part of GNOME. Further, because the CLI has a bytecode that supports many languages, it opens up these applications to plugins written in any language from C# to Python. Most of the Mono based apps provide functionality that GNOME never *really* had (a usable music playter that syncs to ipods, etc; a photo manager; desktop search). Multi-user setups (such as those used by your company, Sun), these applications need not be used. Innovation will continue in Mono with or without GNOMEs blessing. GNOME is what will be missing out by being stalled on a silly flamewar started by a small number of people. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Joe Shaw wrote: It is a very different situation. While the power manager support provides new functionality, GTK# would only provide duplicate functionality for another development framework that overlaps with GNOME. Perhaps I am misunderstanding, but this argument doesn't make any sense to me. Gtk# isn't an application, so by itself it's not useful and doesn't really duplicate anything. It does provide a native API to Gtk#, but traditionally language bindings have been considered a strength of GNOME. Gtk# calls into Gtk+, so it's not like we have two competing implementations of the toolkit here. I don't see the duplicate functionality here. My mistake, I didn't explain it correctly. What I meant was that the group of Gtk# plus Mono overlaps with a big chunk of the desktop. My understanding is that GNOME is a development framework and Mono is another one completely unrelated. Both of them have quite big class libraries: XML parsers, string management, asynchronous I/O, etc. There are some overlaps. However, I don't think we want to restrict GNOME to unmanaged code for the end of time. The substantial resources spent by Sun, Microsoft, and Novell on managed code for the desktop seem to suggest that all think that this is the way of the future. Innovative applications have been developed by using Mono that clearly would have taken much, much longer without the help of this framework. It's hard to call the C libraries we have a development framework. The environment they provide is simply not comparable to that of Python or C# Of course it is possible to use both of them for writing a single cool application, although it doesn't seem to be technically correct because of all the duplicate code: there would way too many unneeded possible failure points and wasted resources. Mono will *not* be taking resources from the current GNOME community. Even if there is on occasion, a but in Mono that needs to be fixed, it seems that this is a net win given the increased development speed. I'm sure Joe Shaw, Aaron Bockover, and Larry Ewing (among many others) would attest to the benefit which Mono has provided as they developed applications. It makes increasingly less sense to write applications in C. If you look at where the interesting and innovative development has been in terms of applications in GNOME, virtually zero of them are C apps. They're all either Python or Mono. This isn't a coincidence. For me the problem is not the language, but the addition framework. So, given the choice of: - virtually zero...interesting and innovative development or - Two frameworks You are suggesting less innovative development? There is absolutely nothing suggesting that over the next 5 years, C applications will become easier to develop. On the other hand, substantial improvements in managed languages (such as generics, and the many enhancements coming in C# 3.0). Also, it may become increasingly hard to attract new developers to GNOME if we only support C. Most universities (including my own, CMU) focus their cirriclum on managed languages. Does it make sense to you to use have three or four different DOM parsers in memory at the same time? (libxml2, python, mono and java for example). First, java is not under consideration at this point. Let's not cloud the discussion with off-topic issues. Currently, python and mono are where the innovation that Joe has been talking about is happening. This statement shows a clear misunderstanding of where the performance issues are in todays desktop. Much of the memory that comes from loading multiple frameworks is shared between processes. In addition, where framework bloat is causing an issue in the GNOME desktop is in places that get loaded by 20 processes (for example, GNOME-VFS). I can't imagine photo management, music playing, desktop search, and desktop wiki-notes on a low memory computer -- in C, Mono or Python. In all honesty, our biggest performance problem is coming from applications that leak. This problem won't be made worse by Mono (in fact, I believe that Mono's ease of development will help developers spend more time profiling). It should also be pointed out that Mono provides an environment for many different languages. While choices of .NET-using languages among GNOME desktop apps needs to be decided (having everone choose their own language would be a issue), Mono will allow the freedom of choosing the best tool for the task while at the same time, providing a single framework. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Hi On Fri, 14 Jul 2006, [ISO-8859-1] Steve Fr?cinaux wrote: Iain * wrote: I'm not really against having C# apps in the core (in fact I don't really mind), what I'm more frightening about is having applications that run all the time, using managed languages, and, as a consequence, taking up a fairly large amount of memory, from the computer start to the shutdown. Think about it: having an application you run a short time do not really impact on your available memory, so it's not a real issue on low-memory system (like mine: 224 Megs are not much memory these days), but long-running ones do. Please read my previous emails. Designing everything in C will not help. Evolution, OpenOffice and Firefox are evidence that writing your app in C does not make it memory efficient. In the long term, a moving GC may be beneficial. At some point, we also have to realize that users with less memory do need to make compermises. For example, such a user might want to choose not to use Beagle. -- Ben___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
On Fri, 14 Jul 2006, [ISO-8859-1] Steve Fr?cinaux wrote: Andrew Cowie wrote: Which, to be honest, I feel makes this whole discussion a bit pointless. I realize that GNOME release engineering is holy ground, but don't you see? Everyone already ships Beagle. Which means they ship Mono. Which means it's a part of the GNOME desktop. fait accompli. Not really. In fact, blessing an app in the desktop has the immediate consequency that other apps can depend on it in a non-conditional way. For instance, a few distros already ship beagle by default, but most only ship it. And I just can't run beagle on my box, it eats up too much memory. So if it was proposed for inclusion, including it would mean that some Gnome apps would depend on it more or less inconditionally and I couldn't run these apps anymore. That's the kind of problem we want to avoid here. This is completely besides the point. Nobody is proposing that beagle be made a requirement for GNOME. I agree, this would cause a problem for many low memory users. Please limit this discussion to things that are being suggested. -- Ben___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
On Fri, 14 Jul 2006, [ISO-8859-1] Steve Fr?cinaux wrote: Ben Maurer wrote: Please read my previous emails. Designing everything in C will not help. Evolution, OpenOffice and Firefox are evidence that writing your app in C does not make it memory efficient. In the long term, a moving GC may be beneficial. Does using a GC really mean you have to use a big bloated memory-hungry virtual machine ? Here we go with the X is bloated track again. I'm sure that gtk+ is very bloated because evolution is memory hungry. Well, no. Inkscape uses a GC, and it is written in C++. It's fairly hard to do this. A moving gc in C++ would be even harder. If ever VM were able to share libs, it would be a great improvement, but currently they can't. It means the managed part of the code is loaded Mono can do this. Read about AOT for every managed app you launch. Which is far from optimal in the case of permanently running apps. Even when we are not AOTing, the amount of ram dedicated to JITed code is small. If you are going to bitch, bitch with NUMBERS. The only performance data on this thread was the vmsize of a few applets, which means absolutely nothing. Just as a number for starters: when launching banshee without AOT, it takes 600 kb of JITd code space. Let's say it's really more like 1 MB after lots of use (probably higher than it actually is). Maybe there are 4 managed apps (Banshee, F-Spot, Beagle, Tomboy). That's 4 MB vs 1 MB if 100% of it was shared as in C. Not a lot. In the long term, we'll probably get more of a win with compacting from a GC than this. What's more: we can do better. When Mono improves it's code generation, every app benefits. In addition, AOT can reduce this problem. At some point, we also have to realize that users with less memory do need to make compermises. For example, such a user might want to choose not to use Beagle. I don't use Beagle, and in fact I hope the alternate Tracker project will solve this problem. I don't use deskbar as well, nor banshee since the player is at the limit between a daemon and a classical app. Just because GNOME has program X doesn't mean you have to use it. For example, having Evince doesn't prevent anyone from using acroread. -- Ben___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gpm] Re: Gnome 2.16 Module Proposal: GNOME Power Manager
On Mon, 10 Apr 2006, Rodrigo Moya wrote: since there is already a daemon (HAL and underlying power save software, like pmu, powersave, etc), why do we need another daemon? I think the current g-p-m architecture, with the 'daemon' being also the notification icon makes a lot of sense. If adding the tray icon on startup is wrong, then I guess we can easily delay the addition of the icon, like we do with the typing break, for instance. I'd point out that (as mentioned on my blog) using `daemons' that are tasked with putting an icon in the panel cause extra memory usage. On my laptop, this is responsible for 3MB of private, dirty rss. My laptop is *plugged in* and it is using this. The task of `display an icon on the panel when battery is being used' should not require this amount of memory. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
