Re: [Deskbar] Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Fri, 2005-10-28 at 23:12 -0500, Travis Watkins wrote: On 10/28/05, Benoît Dejean [EMAIL PROTECTED] wrote: what the difference between your search engine and beagle's ? This one does more than beagle, can use beagle if it's available, and can actually be included in a GNOME release? Yes. Our current backens are: * Static backends like 'Search xx with yy' where yy can be beagle, gnome-dict, gnome-search-tool,.. * Index .desktop files in english and locale, and allow to launch a program by typing some descriptive words, for example typing 'text' returns gedit, gvim, ... but you can also type 'editeur' in french and get the same results. * Launch command line applications with any arguments: 'killall evolution', 'sitecopy -uo mysite' * Open directories/files by typing a full path, or relative to home dir * Open nautilus bookmarks and computer volumes (with network places) by name * Send mail by typing an email address, open a webpage by typing an address * With evolution-data-server, type an name or address and send mails to your addressbook contacts * With libbeagle, show a small selection of beagle result for typed word * Perform google queries with typed word, and show the results in the list * Browser integration (epiphany, galeon, and mozilla/firefox): index the bookmarks title and url, also index the history, and smart bookmarks/search engines. * Network places and mounted volumes. Fx. an audio cd will show up if you type cd or au. -- and it's dead easy to implement new backends. Also if you stick stick a new backend in ~/.gnome2/deskbar-applet/handlers it will automagically show up in the deskbar prefs. Cheers Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Thu, 2005-10-27 at 17:07 +0200, Benoît Dejean wrote: Le jeudi 27 octobre 2005 à 16:51 +0200, Rodrigo Moya a écrit : On Thu, 2005-10-27 at 15:39 +0100, Jamie McCracken wrote: (I think how to optimize C applets is a different topic) as a first step, doing all applets .so bonobo components instead of processes should save a lot of memory also. that would be great and easy to do (iirc). There's always though the problem that if one applet crashes, all the panel would crash May be should start doing this with panel-applets ? yes, I think so. -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Hi, Straying from the topic a little bit... On Sat, 2005-10-29 at 14:19 +0200, Raphael Slinckx wrote: It's also worth mentionning that in theory, deskbar could work with beagle only, but in practice, beagle isn't installed by default everywhere, beagle is not production ready, and filtering the returned results vie the libbeagle seems uneasy. Beale indexes browser bookmarks, history and .desktop files (at least it used to, now it doesn't seem to do it) These days indexing of .desktop files is handled by a system-wide indexer which is run from cron, so that they can be shared by all users on the system. So that might be why you're not seeing them. As for filtering things out, you can specify what hit types and mime types you want back, so you should be able to query only against web history and applications and get back what you want. This is what we're doing for nautilus now (only querying/displaying files). We can discuss it more on dashboard-hackers or privately if you need more or a different API. :) Joe ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Deskbar] Re: Gnome 2.14 Module Proposal: Deskbar Applet
We are aware of memory- and startup issues, but you surely know that premature optimisation is a top-three killer in free software projects. The question is Can you optimise it and fix the problem. If you use a python vm and the answer is no, how do you propose to fix the problem when it isnt premature We will work on these issues, but it's also granted that we can only optimise to a certain point since deskbar relies on a bunch of indexes. You can optimise enormously by minimising the amount of index touched by a search, by normal operation when not being prodded by the user to do stuff and when updating. In all cases doing the minimal touching of existing data will reduce the working set size, which is far more critical than total ram usage. ie an app with a lot of resources that sit happily on disk all day is a lot better than one that keeps touching them and keeping them in ram ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Sat, 2005-10-29 at 00:29 +0200, Benoît Dejean wrote: what the difference between your search engine and beagle's ? Just to make things clear: We do not *want* to index anything, we are just a front-end, an UI for the broad range of services offered in a nearly-stock gnome desktop, allowing to use a power command line tool. The fact we need to index .desktop and browser bookmarks is just a side-effect, and really we shouldn't have to do that, browsers should offer a service to allow querying the bookmarks, just like evo-d-s does it with contacts/calendars/mails. The way we index the above files is extremely uneffective, basically, we read the sentence we want to index, split it around spaces and punctuation, the store in a hashtable each (word - match). I don't think you can do something less efficient than that. What are our other options ? Using a lucene-like full text engine ? unfortunately no python version exist for it, and is it worth the overhead ? Using any custom full text engine written in python, i've looked at pyndex, but it seems not very operational. Another option would be to make a gnome-data-server, that maintains what we want, like .desktop indexes, and epiphany bookmarks. Suggestions ? Raf ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Thu, 2005-10-27 at 17:03 +0200, Benoît Dejean wrote: Le mardi 25 octobre 2005 à 00:35 +0200, Benoît Dejean a écrit : Le dimanche 23 octobre 2005 à 19:19 +0200, Raphael Slinckx a écrit : Raphael, do you how much memory takes the in-memory cache ? How can i know that ? More generally, are there good python performance/memory profilers ? Raf ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Thu, 2005-10-27 at 13:32 +0100, Gustavo J. A. M. Carneiro wrote: It's possible, and I know how. Say you have 10 python applets. Now, it should be feasible to leverage the bonobo component system to make them all share the same process, like this: 1. Create a special exe factory, which is a python program; 2. This special factory, for each OAFIID to activate, would: i) import a module with the same name as the iid; ii) call a predefined get_object() function on this module; 3. Each python applet would install a .server file that would reference the python factory IID; 4. Each python applet would install it's code as a python module/package with the name of the IID; The result: a single process (per user, per display), and a single main loop, for all applets. Of course this means if one applet deadlocks or dies, they all die. But at least dying in python is not so easy. You usually get only an exception that is ignored. Deadlock is easier if they use threads. This can be a solution, but it won't help unless there are more than 1 pyhon applet running :) Anyway if this ever get implemented i'll be the first one to use it. Concerning the if one dies all dies, that won't happen with python, since you can always try/catch at the topmost level and remove the dying applet easily. Deadlock is another thing, i don't know if applets often deadlock.. Raf ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Thu, 2005-10-27 at 23:28 +0800, Davyd Madeley wrote: Maybe replacing the run dialog with deskbar (at least by default) is going a bit too far. But, please, shipping one more optional applet is not going to hurt anyone. This would certainly be a nice touch. Maybe with some time, it would be possible to do this. Or through the abuse of Bonobo, do it if you have opted to run the applet (load the BonoboControl if the factory is already running or you have specified a specific I have memory key). Ok, i like the approach of an expermiental gconf key to enable alt-f2 replacement, maybe we can try to make that happen, it won't hurt anybody, and yet will allow to receive feedback from user who choose to activate it. A question though, wouldn't this require to disable alt-f2 if the specific key is found (by patching wherever alt-f2 lives, where ?) ? Also it woud require the deskbar core to be launched automatically at session startup and not only on applet addition, bonobo does that ? I'm feeling i don't grasp the entire subtleties of bonobo, so again if there is any help or doc out there :) I would like to propose it gets renamed however. To simply 'Deskbar', or as I always wanted 'Auric'. Yes Deskbar is a very bad name for a lot of reasons, it is not really original, it does not represent very well what the application is about, and google also uses the term deskbar. Shall we rename this Auric ? I don't know what that means though :) Maybe someone has another good name ? Raf. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Raphael Slinckx wrote: On Sat, 2005-10-29 at 13:01 +0100, Jamie McCracken wrote: Tracker is still under developement and for 2.14 I am hoping to optionally integrate Tracker into Nautilus (for metadata and search) and possibly Gnome-VFS to get Vfolders style functionality. That is fantastic, exactly the kind of thing we would need ! I suppose adding browser stuff in it wouldn't be much of a pain. no not at all! Its a piece of cake to store this stuff in a relational database. I will add tables for your stuff (.Desktop file contents and web bookmarks) to its DB for future use. If there's anything else you need indexing let me know... -- Mr Jamie McCracken http://www.advogato.org/person/jamiemcc/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On 10/29/05, Raphael Slinckx [EMAIL PROTECTED] wrote: Ok, i like the approach of an expermiental gconf key to enable alt-f2 replacement, maybe we can try to make that happen, it won't hurt anybody, and yet will allow to receive feedback from user who choose to activate it. A question though, wouldn't this require to disable alt-f2 if the specific key is found (by patching wherever alt-f2 lives, where ?) ? Alt-F2 is a global metacity keybinding; when Metacity detects that keypress, it sends a message to the root window that gnome-panel monitors for; gnome-panel then launches the run application dialog. One possibility (though I don't know how difficult this would be to do) would be having gnome-panel detect if deskbar is running and forward any open-run-dialog messages to it instead of what it normally does; if deskbar isn't running, then gnome-panel could just launch the normal dialog it has. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le vendredi 28 octobre 2005 à 00:29 +0800, Davyd Madeley a écrit : On Thu, 2005-10-27 at 11:05 +0200, Benoît Dejean wrote: perhaps we can afford to spend a little bit of memory to get some really kick arse features. define little. 22MB is not little for me and a lot of users. Most applications don't use 22MB of memory. -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Thu, 27 Oct 2005 00:51:54 +0200, Michael Banck wrote: It is unclear to me how you could achieve this in the context of the GNOME project. Even if you frob python to behave on your box, that will still leave users with default python installation on all the other distributions. Last time I checked there was no rule saying GNOME hackers could only hack GNOME ;) Anyway, the ideas we were discussing on IRC were a variety of hacks that could be directly integrated into deskbar itself. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Deskbar] Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le jeudi 27 octobre 2005 à 21:04 +0200, Mikkel Kamstrup Erlandsen a écrit : (What about beagle ?) We have a beagle plugin based on libbeagle (by Raphael Slinckx) -bindings. An it rocks I might add; I had no idea beagle was this fast. I mean seriously fast. what the difference between your search engine and beagle's ? -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Deskbar] Re: Gnome 2.14 Module Proposal: Deskbar Applet
On 10/28/05, Benoît Dejean [EMAIL PROTECTED] wrote: what the difference between your search engine and beagle's ? This one does more than beagle, can use beagle if it's available, and can actually be included in a GNOME release? -- Travis Watkins http://www.realistanew.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Wed, 2005-10-26 at 19:18 +0200, Benoît Dejean wrote: Le mercredi 26 octobre 2005 à 19:04 +0200, Thomas Vander Stichele a écrit : Hi, But are you sure that 10 python applets would each consume 22 MB ? How much of this 22 MB would be shared among python applets ? In my my first email, i reported that deskbar-applet takes 22MB RES : 10MB are writable and can't be shared. Ok, so the non-sharable part is about what you would accept as an applet's consumption ? Further, there are ways to make the applets share the python process space, which would make them share a big chunk of the 10 MB non-shareable space. But I'm a little confused as to what alternative you are proposing exactly - are you saying that all applets should be written in C until the end of time ? I don't see any other way to avoid incurring some memory loss for applets. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ -*- thomas (dot) apestaart (dot) org -*- My shite shits on your shite -*- thomas (at) apestaart (dot) org -*- URGent, best radio on the net - 24/7 ! - http://urgent.fm/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le jeudi 27 octobre 2005 à 10:32 +0200, Thomas Vander Stichele a écrit : On Wed, 2005-10-26 at 19:18 +0200, Benoît Dejean wrote: Le mercredi 26 octobre 2005 à 19:04 +0200, Thomas Vander Stichele a écrit : Hi, hi But are you sure that 10 python applets would each consume 22 MB ? How much of this 22 MB would be shared among python applets ? In my my first email, i reported that deskbar-applet takes 22MB RES : 10MB are writable and can't be shared. Ok, so the non-sharable part is about what you would accept as an applet's consumption ? yes. But keeping in mind that other applets take 10MB shared + private Further, there are ways to make the applets share the python process space, which would make them share a big chunk of the 10 MB non-shareable space. Share with which other processes ? I'm very curious about this. And as i explained, i did a lot of python, and i don't know how reduce memory usage (especially how to reduce private memory usage). So i think it's very unlikely to happen. But I'm a little confused as to what alternative you are proposing exactly no inclusion of VM-based/high-memory-consumption program for long-running application. - are you saying that all applets should be written in C until the end of time ? No. But VM-based languages are problematic. It's OK to run 1 or 2 VM on your desktop for real applications. But i can't think about running 10 VM. But even if deskbar-applet was written in C, if its memory usage was 22MB, i would be against. The problem is high memory consumption. The cause is the implementation. I don't see any other way to avoid incurring some memory loss for applets. waste :) come on : open gnome-system-monitor / top and sort by resident memory usage :) -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Qui, 2005-10-27 às 11:05 +0200, Benoît Dejean escreveu: Le jeudi 27 octobre 2005 à 10:32 +0200, Thomas Vander Stichele a écrit : On Wed, 2005-10-26 at 19:18 +0200, Benoît Dejean wrote: Le mercredi 26 octobre 2005 à 19:04 +0200, Thomas Vander Stichele a écrit : Hi, hi But are you sure that 10 python applets would each consume 22 MB ? How much of this 22 MB would be shared among python applets ? In my my first email, i reported that deskbar-applet takes 22MB RES : 10MB are writable and can't be shared. Ok, so the non-sharable part is about what you would accept as an applet's consumption ? yes. But keeping in mind that other applets take 10MB shared + private Further, there are ways to make the applets share the python process space, which would make them share a big chunk of the 10 MB non-shareable space. Share with which other processes ? I'm very curious about this. And as i explained, i did a lot of python, and i don't know how reduce memory usage (especially how to reduce private memory usage). So i think it's very unlikely to happen. It's possible, and I know how. Say you have 10 python applets. Now, it should be feasible to leverage the bonobo component system to make them all share the same process, like this: 1. Create a special exe factory, which is a python program; 2. This special factory, for each OAFIID to activate, would: i) import a module with the same name as the iid; ii) call a predefined get_object() function on this module; 3. Each python applet would install a .server file that would reference the python factory IID; 4. Each python applet would install it's code as a python module/package with the name of the IID; The result: a single process (per user, per display), and a single main loop, for all applets. Of course this means if one applet deadlocks or dies, they all die. But at least dying in python is not so easy. You usually get only an exception that is ignored. Deadlock is easier if they use threads. Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Iau, 2005-10-27 at 13:32 +0100, Gustavo J. A. M. Carneiro wrote: The result: a single process (per user, per display), and a single main loop, for all applets. Of course this means if one applet deadlocks or dies, they all die. But at least dying in python is not so easy. You usually get only an exception that is ignored. Deadlock is Which means all the applets run in the same security context which like all the assumptions about root in other threads is a bad idea. To apply good security policies you need isolation not amorphous blobs. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le jeudi 27 octobre 2005 à 13:32 +0100, Gustavo J. A. M. Carneiro a écrit : Qui, 2005-10-27 às 11:05 +0200, Benoît Dejean escreveu: The result: a single process (per user, per display), and a single main loop, for all applets. Of course this means if one applet deadlocks or dies, they all die. But at least dying in python is not so easy. You usually get only an exception that is ignored. Deadlock is easier if they use threads. We don't do it for C applets because if one applet deadlocks or dies, they all die. But thanks for raising the problem of many VM-based applets : currently, 3 applets would take ~ 50MB of RES memory. But before trying to run each applet on a common interpreter, you need to get sure that the current situation: 12MB readonly/shared + (N applets * 10MB private) would turn into : 12MB readonly/shared + 10MB shared + (N applets * 3MB private) Which would eventually make python applets lighter than C applets (and maybe leakproof). But again, one applet deadlocks or dies, they all die. Here again, i have some bad memories about nasty desklets / 3rd party desklets in gdesklets that screwed the whole program. -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Benoît Dejean wrote: Le jeudi 27 octobre 2005 à 13:32 +0100, Gustavo J. A. M. Carneiro a écrit : Qui, 2005-10-27 às 11:05 +0200, Benoît Dejean escreveu: The result: a single process (per user, per display), and a single main loop, for all applets. Of course this means if one applet deadlocks or dies, they all die. But at least dying in python is not so easy. You usually get only an exception that is ignored. Deadlock is easier if they use threads. We don't do it for C applets because if one applet deadlocks or dies, they all die. But thanks for raising the problem of many VM-based applets : currently, 3 applets would take ~ 50MB of RES memory. Yes the real problem with panel applets is that they are out of process apps which regardless of the language they are written in are always going to be inefficient memory wise to some degree even when written in C. The best solution is to run all panel apps in-process in their own threads (IE make a panel applet a GTKWidget that's threadsafe). We also get rid of Corba/bonobo by doing so which is always a plus. The drawbacks as stated should not really be a problem if the applets are properly debugged (at least so they dont seg fault) -- Mr Jamie McCracken http://www.advogato.org/person/jamiemcc/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Qui, 2005-10-27 às 16:09 +0200, Christophe Merlet escreveu: GNOME must be light and simple. GNOME must be accessible and must be able to run on little hardware (old computer and assistant like nokia 770) Then, GNOME should not have big dependencies like Python, Perl, C# or other in order to work. Then deskbar-applet should not be included in the next GNOME desktop release. There are some years, a full OS with graphical desktop and utilities was able to run in only 8 MB (Windows 95, System 7.5, ...). How can you accept today to see simple applet consume more than 22 MB It's UNACCEPTABLE First of all, the applet is not simple. Maybe it helps to consider it as a complex indexing and launcher application which just happens to have an applet interface. Even if the applet is included with GNOME, nobody forces anybody to use it. Guess what? GNOME ships with a Contact Lookup Applet. It consumes 14 MB of resident memory. Yet, I *choose*[1] to not use it, so I don't care if it ships with GNOME, I don't waste any memory because of it. Maybe replacing the run dialog with deskbar (at least by default) is going a bit too far. But, please, shipping one more optional applet is not going to hurt anyone. Regards. [1] Choose because I don't need it, not because it is too big. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Thu, 2005-10-27 at 15:39 +0100, Jamie McCracken wrote: Benoît Dejean wrote: Le jeudi 27 octobre 2005 à 13:32 +0100, Gustavo J. A. M. Carneiro a écrit : Qui, 2005-10-27 às 11:05 +0200, Benoît Dejean escreveu: The result: a single process (per user, per display), and a single main loop, for all applets. Of course this means if one applet deadlocks or dies, they all die. But at least dying in python is not so easy. You usually get only an exception that is ignored. Deadlock is easier if they use threads. We don't do it for C applets because if one applet deadlocks or dies, they all die. But thanks for raising the problem of many VM-based applets : currently, 3 applets would take ~ 50MB of RES memory. Yes the real problem with panel applets is that they are out of process apps which regardless of the language they are written in are always going to be inefficient memory wise to some degree even when written in C. The best solution is to run all panel apps in-process in their own threads (IE make a panel applet a GTKWidget that's threadsafe). We also get rid of Corba/bonobo by doing so which is always a plus. The drawbacks as stated should not really be a problem if the applets are properly debugged (at least so they dont seg fault) as a first step, doing all applets .so bonobo components instead of processes should save a lot of memory also. There's always though the problem that if one applet crashes, all the panel would crash -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le mardi 25 octobre 2005 à 00:35 +0200, Benoît Dejean a écrit : Le dimanche 23 octobre 2005 à 19:19 +0200, Raphael Slinckx a écrit : - Memory usage on startup : 22MB RES this is the highest memory usage after X on startup. (for the record, the second biggest applet is wnck-applet with 8MB RES) let's have a look : python -c import operator, gtop; print reduce(operator.add, [(m.end - m.start) for m in gtop.proc_map(`pgrep python`) if m.perm gtop.MAP_PERM_WRITE]) 10412032 ~10 MB of writable/unshared memory. Raphael, do you how much memory takes the in-memory cache ? -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Deskbar] Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le jeudi 27 octobre 2005 à 14:06 +0200, Mikkel Kamstrup Erlandsen a écrit : We are aware of memory- and startup issues, but you surely know that premature optimisation is a top-three killer in free software projects. of course. It's also premature to say 'we can do much better, later'. We will work on these issues, but it's also granted that we can only optimise to a certain point since deskbar relies on a bunch of indexes. If you wan't on-the-fly querying on tons of different sources you will have to index some of them, load libs to read others, etc., and there's not much you can do about it. The question is Do Gnome want a multi-backend find-as-you-type search bar?. If the answer is yes, then it will come at a price no matter the implementation. Is deskbar-applet designed so that other programs in other languages can make searches ? Is there a seperate backend ? (What about beagle ?) But note that this price will only be paid if the user wants to. If the answer is no, well, then users just wan't have fast versatile searches on a stock gnome install. deskbar-applet / fast versatile searches on a stock gnome seems a very nice feature to me. -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Gustavo J. A. M. Carneiro wrote: First of all, the applet is not simple. Maybe it helps to consider it as a complex indexing and launcher application which just happens to have an applet interface. This is no way an excuse to make fat applications/applets/whatever. What makes applets complex enough for such a memory usage ? Even if the applet is included with GNOME, nobody forces anybody to use it. Guess what? GNOME ships with a Contact Lookup Applet. It consumes 14 MB of resident memory. Yet, I *choose*[1] to not use it, so I don't care if it ships with GNOME, I don't waste any memory because of it. So, you are using the excuse of an already 14MB applet existing, opening the doors to somebody using the 22MB excuse latter. Maybe replacing the run dialog with deskbar (at least by default) is going a bit too far. But, please, shipping one more optional applet is not going to hurt anyone. Yes it is going to hurt everybody. Especially at a time where all GNOME developers must focus on optimisation. There is a difference between having applets somewhere and having the officialy inside the desktop environment. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Thu, Oct 27, 2005 at 04:09:41PM +0100, Gustavo J. A. M. Carneiro wrote: Qui, 2005-10-27 ?s 16:09 +0200, Christophe Merlet escreveu: Even if the applet is included with GNOME, nobody forces anybody to use it. Guess what? GNOME ships with a Contact Lookup Applet. It consumes 14 MB of resident memory. Yet, I *choose*[1] to not use it, so I don't care if it ships with GNOME, I don't waste any memory because of it. Actually. It doesn't ship with that applet. I was going to merge it, however in the end deskbar implements the features set I want (along with that of gdict-applet). Your point is correct and well taken however. Maybe replacing the run dialog with deskbar (at least by default) is going a bit too far. But, please, shipping one more optional applet is not going to hurt anyone. This would certainly be a nice touch. Maybe with some time, it would be possible to do this. Or through the abuse of Bonobo, do it if you have opted to run the applet (load the BonoboControl if the factory is already running or you have specified a specific I have memory key). I would like to propose it gets renamed however. To simply 'Deskbar', or as I always wanted 'Auric'. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Thu, 2005-10-27 at 11:05 +0200, Benoît Dejean wrote: come on : open gnome-system-monitor / top and sort by resident memory usage :) Quite simply. We do, and we don't care. There are some things that are so incredibly cool and featureful, that perhaps we just have to take the memory hit. If you want to run an operating system written in 1995, please feel free. 10 years on, perhaps we can afford to spend a little bit of memory to get some really kick arse features. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Fri, 2005-10-28 at 00:29 +0800, Davyd Madeley wrote: On Thu, 2005-10-27 at 11:05 +0200, Benoît Dejean wrote: come on : open gnome-system-monitor / top and sort by resident memory usage :) Quite simply. We do, and we don't care. There are some things that are so incredibly cool and featureful, that perhaps we just have to take the memory hit. If you want to run an operating system written in 1995, please feel free. 10 years on, perhaps we can afford to spend a little bit of memory to get some really kick arse features. One thing to consider is that this might make for a good experiment to see how this affects GNOME's user base. It might be worth it to include the applet and see what kind of response there is. It might be worthwhile to consider adding a beta module to gnome that lets users try the coolest new features of GNOME and let them comment on their thoughts. My point here is that keeping memory usage and performance at a reasonable level is important, but only in within the scope of a user's experience. Saying 22 Mb of memory is too much because it is 22 Mb doesn't make sense. Saying 22 Mb is too much because most users average 256 Mb of memory and run OO.o along with firefox and evolution, making paging to the disk consistent is a much more powerful argument. Of course there is no way to test this or get these statistics but it would make sense to have a census of sorts to count what our averages really are. Specifically with the deskbar applet, I think the fact that it is only an applet that is not required, makes it an excellent candidate to include as a beta for users to see what the response is. Eric ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Deskbar] Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Thu, 2005-10-27 at 17:17 +0200, Benoît Dejean wrote: Is deskbar-applet designed so that other programs in other languages can make searches ? Is there a seperate backend ? The current architecture is quite flexible. The core of deskbar basically consists of a ModuleList/ModuleLoader and a plugin api. You can initialize the whole shebang (async/sync backends and callbacks) with 10 lines of python, and be ready to search. At the moment of writing the GUI is not *completely* separated from the searching interface, but that is likely (and easy) to change... Exporting services over dbus will not be a major undertaking - I haven't discussed this with the other devs though, but I will. (What about beagle ?) We have a beagle plugin based on libbeagle (by Raphael Slinckx) -bindings. An it rocks I might add; I had no idea beagle was this fast. I mean seriously fast. Cheers Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Wed, Oct 26, 2005 at 11:08:57PM +0100, Mike Hearn wrote: Something like Python eats your memory, now here's how we're going to solve it was what I was after. It is unclear to me how you could achieve this in the context of the GNOME project. Even if you frob python to behave on your box, that will still leave users with default python installation on all the other distributions. Michael -- The hotel's valet attendant seemed confused by the text on my shirt, but I couldn't think of how to explain to him what JÖRG SCHILLING ATE MY GPL meant. -- Erinn Clark ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Please, let's stop cross-posting, and settle on desktop-devel-list. There is a difference between having applets somewhere and having the officialy inside the desktop environment. That's a good point. Currently, Deskbar (which hopefully will be the hot new verb of 2006 :-) is hosted on GNOME CVS, tracks issues with GNOME Bugzilla, and discussions take place on a GNOME mailing list. Even if it does not make part of the official GNOME 2.14 module set, I would like to release 1.0 at the same time as GNOME 2.14, and be of comparable quality. Contact-lookup-applet is similarly in GNOME CVS, but out of the official GNOME desktop, and my distribution ships it as part of a standard GNOME install. That's all good. So what gain would Deskbar have to be stamped as officially Part Of GNOME? One is bigger exposure of (in my humble, biased opinion) useful functionality. Two is simply bragging rights and some Wow in What's new in GNOME 2.14. More subtly, other applications can then rely on the Deskbar being part of GNOME. It's extensible, so that, for example, Tomboy can supply a Deskbar back-end - simply a page or two's worth of Python in the right place - so that you can type a fragment of a note title to jump to that note. Downsides? It pulls in the Python gnomeapplet bindings as a dependency, but I believe that this is not an issue. It duplicates some existing functionality (mini-commander, contact-lookup-applet) although I would like to think that Deskbar is better and others can be deprecated. Inclusion in GNOME adds an expectation that it will be maintained in the future, as part of GNOME 2.16, 2.18, and so on. I'm happy with that. It's also a bit of a power user feature, and probably won't help me get laid [1]. :) And of course, there are quality (i.e., performance) concerns - memory consumption and startup speed. Like everybody, I would like smaller and faster, but I don't think that the Deskbar is fundamentally problematic, PROVIDED that it is an optional feature, and not part of the default desktop experience (and therefore not replace the Alt-F2 run dialog, at this point in time). Some people have tried it and found it wanting by their standards, and they would decline the option. That's fine by me. Nigel. [1] http://www.jwz.org/doc/groupware.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Tue, 25 Oct 2005 19:16:20 +0100, Jamie McCracken wrote: That could be worse! Compacting GC's require twice the memory of a non-compacting one. (you dont know how much garbage you have when you walk the heap to GC so you need another empty heap of the same size to copy everything into it) Yes, I know, but it's only temporary. After that the other side of the heap can be unmapped in one go. Anyway, I think everybody knows GC is not a magic solution, but for a language like Python it seems you really do need at least some way to compress heap usage to a minimum and compacting GC does this quite well. Mono and most other GC languages (gcj/java et al) also suffer from memory leaks due to the boehm GC not being precise enough. The MS.NET GC is precise and does not leak. Given that Boehm GC can be given type info for where pointers are I don't see any reason why it *must* be this way, just that maybe Boehm GC isn't the right library for Mono yet. The right solution is to not use a GC langugae for these kinds of apps (unless they offer manual freeing of objects in addition to GC which the boehm GC supports). Well, it's definitely true that many GCd platforms have quite poor performance unless you have tons of memory, but on the other hand we have to move on some time :) Anyway. I don't think this problem can be easily be solved, it's more important that people are aware of it and take it into consideration when using Python. thanks -mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Tue, 25 Oct 2005 22:26:19 +0200, Raphael Slinckx wrote: I think the point is clear, python eats your memory, live with it. That's not a particularly great answer ... * We propose deskbar to become an applet, nothing more, nothing less, applets are optionally used by users, and by using them users are accepting the consequences. But this is reasonable. After all, Apple shipped Dashboard which is notorious for eating vast quantities of memory for something that is arguably less useful. I hate to say it but that does set a precedent for adding features that are known to eat tons of resources as long as they're optional. On the other hand, if it goes in then putting it in the panel by default would be quite tempting for vendors (because it's a nice feature and adding applets isn't very discoverable), and then people who don't use it would pay the price. Worse they'd never be able to figure out why their computer is so slow because swap overhead is not at all intuitive. Though presumably if they never use it, it'd be swapped out at the start then never swapped in again. thanks -mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le mardi 25 octobre 2005 à 22:26 +0200, Raphael Slinckx a écrit : Hi ! i meant 6s startup with CPU 100% Yes that's a problem and we will be fixing it, but if you install the applet you are accepting it's drawbacks. You said : This mail introduces the deskbar-applet, and officially propose its inclusion in the gnome 2.14 desktop release ! so i'm not accepting anything, you are proposing for inclusion. Having the desktop or email program (*hint* /me looks at evolution *hint*) start fast is crucial. Hey look, THEY do 'bad' things, so you wont mind if i do the same Having an applet start slow is just a problem for those who care about performance. but i tought that Having the desktop [...] start fast is crucial ? That excludes lots of users, me being the first. I'm sad to here it. Fully understood : you don't care about many of us (users. You don't mind ruining everyone else improvements. You're right, time is not to improvements, please everyone unsuscribe performance-list. * Most users don't care about an applet taking a bit more memory than others, most will not even see it. This is wrong. Most users do care about performance. Many users switch from KDE because GNOME runs smoother on their computer. Many users switch to XFCE for the same reason. And 22MB is not a bit more. This is more than every other gnome application (excluding evolution). Often more than X. Concerning the startup time (i do not have any figures to back this up, just my intuition) (also most of the time deskbar will be launched when the caches are 'cold'): Are you suggesting me to start deskbar-applet twice so it loads faster ? :) * 1 second to launch python/bonobo * 1 second to init pygtk * 1 second to init misc lib stuff * 3 seconds to index - .desktop files (also lot of IO here) - browser bookmarks, search engines - browser history The first three points can hardly be trimmed down. that's the problem. (lease keep the debate 'python will eat your ass' closed now, we *know* python eats memory, cope with it) No. -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Wed, 2005-10-26 at 12:03 +0100, Mike Hearn wrote: On Tue, 25 Oct 2005 22:26:19 +0200, Raphael Slinckx wrote: I think the point is clear, python eats your memory, live with it. That's not a particularly great answer ... Why not ? It is not different for any other language you could be using except for C and C++. What sort of answer would be better (and still truthful) ? Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ -*- thomas (dot) apestaart (dot) org -*- The blood before me makes me open up my heart again And I feel it coming over like a storm again -*- thomas (at) apestaart (dot) org -*- URGent, best radio on the net - 24/7 ! - http://urgent.fm/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Hi, That excludes lots of users, me being the first. I'm sad to here it. Fully understood : you don't care about many of us (users. You don't mind ruining everyone else improvements. You're right, time is not to improvements, please everyone unsuscribe performance-list. You are overreacting a little. Raphael is making the point that this is optional - if you don't add the appet to your panel, you won't incur the memory loss. So how would he be ruining other people's improvements ? If I choose to run a program on my GNOME desktop today that does nothing else than stat() and read() every file on my harddisk in an endless loop, it does not ruin other people's improvements to GNOME. I'll just have a slow desktop, that's all. * Most users don't care about an applet taking a bit more memory than others, most will not even see it. This is wrong. Most users do care about performance. Many users switch from KDE because GNOME runs smoother on their computer. Many users switch to XFCE for the same reason. He did not say users do not care about performance. He is saying that there are a lot of users that accept the tradeoff if they would use the applet. Obviously, you are not such a person, which is fine - you would not be using the applet. Settle down - you're being too antagonistic about this and it's making the discussion go nowhere. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ -*- thomas (dot) apestaart (dot) org -*- My shite shits on your shite -*- thomas (at) apestaart (dot) org -*- URGent, best radio on the net - 24/7 ! - http://urgent.fm/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le mercredi 26 octobre 2005 à 18:32 +0200, Thomas Vander Stichele a écrit : Hi, That excludes lots of users, me being the first. I'm sad to here it. Fully understood : you don't care about many of us (users. You don't mind ruining everyone else improvements. You're right, time is not to improvements, please everyone unsuscribe performance-list. You are overreacting a little. Raphael is making the point that this is optional - if you don't add the appet to your panel, you won't incur the memory loss. So how would he be ruining other people's improvements ? Of course i'm overreacting. I'm quotting Davyd : Inclusion into Desktop should not be a sign of any particular standard or quality, but simply that it is a critical piece of software that a desktop should not be without. Settle down - you're being too antagonistic about this and it's making the discussion go nowhere. then don't tell me the discussion about VM-based languages is over. I started answering this thread with real statistics about memory usage. I then said i don't think deskbar-applet will one day take less than 20MB or resident memory. So my real point is : __I__ think 22MB of memory usage for a single applet (applet according Davyd's definition) is unaffortable. No applet should take more than 10MB (shared and non-shared). I'm running 10 applets, how could i run 10 applets each taking 22MB ? -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Hi, Settle down - you're being too antagonistic about this and it's making the discussion go nowhere. then don't tell me the discussion about VM-based languages is over. Ok, I won't. Also note, I didn't. I started answering this thread with real statistics about memory usage. I then said i don't think deskbar-applet will one day take less than 20MB or resident memory. So my real point is : __I__ think 22MB of memory usage for a single applet (applet according Davyd's definition) is unaffortable. No applet should take more than 10MB (shared and non-shared). I'm running 10 applets, how could i run 10 applets each taking 22MB ? But are you sure that 10 python applets would each consume 22 MB ? How much of this 22 MB would be shared among python applets ? Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ -*- thomas (dot) apestaart (dot) org -*- If you go go for good don't fucking joke you know I would -*- thomas (at) apestaart (dot) org -*- URGent, best radio on the net - 24/7 ! - http://urgent.fm/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le mercredi 26 octobre 2005 à 19:04 +0200, Thomas Vander Stichele a écrit : Hi, But are you sure that 10 python applets would each consume 22 MB ? How much of this 22 MB would be shared among python applets ? In my my first email, i reported that deskbar-applet takes 22MB RES : 10MB are writable and can't be shared. -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le mercredi 26 octobre 2005 à 18:50 +0200, Benoît Dejean a écrit : Of course i'm overreacting. I'm quotting Davyd : Inclusion into Desktop should not be a sign of any particular standard or quality, but simply that it is a critical piece of software that a desktop should not be without. Wow. I didn't see this before. The first part of the sentence is false: a proposed module should be of quality and there are some things it should be/do (be documented, translatable, accessible, etc.). There are requirements for the quality of the module. Exceptions can happen, of course. Also, we already included modules that are not critical pieces of software that a desktop should not be without. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le mercredi 26 octobre 2005 à 20:15 +0200, Vincent Untz a écrit : Le mercredi 26 octobre 2005 à 18:50 +0200, Benoît Dejean a écrit : Of course i'm overreacting. I'm quotting Davyd : Inclusion into Desktop should not be a sign of any particular standard or quality, but simply that it is a critical piece of software that a desktop should not be without. Wow. I didn't see this before. See http://bugzilla.gnome.org/show_bug.cgi?id=97664 last comment. This answer was more specific about applets. -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Wed, 2005-10-26 at 18:50 +0200, Benoît Dejean wrote: Le mercredi 26 octobre 2005 à 18:32 +0200, Thomas Vander Stichele a écrit : Of course i'm overreacting. I'm quotting Davyd : Inclusion into Desktop should not be a sign of any particular standard or quality, but simply that it is a critical piece of software that a desktop should not be without. I am very much being quoted out of context here. I like the direction in which Deskbar is headed. It combines lots of GNOME technology in such a way that it is indeed a powerful tool. It also serves to replace an existing, dying piece of technology: mini-commander. Deskbar offers features that give us a cut above other desktop environments that don't have a feature like this. It is innovative, and exciting. It happens to be a little bit slow, but I'm sure that will improve as more people use it. It just so happens that a lot of Apple's technological innovations as well as Microsoft's (yes, they do have them) are also a little slow. We are not instantly requiring everyone to have 22MB more RAM. We are requiring interested people to have 22MB more RAM (or 11MB if they were previously running mini-commander). In short, I am excited about Deskbar. It has more of a home in the desktop than mini-commander does. It serves my goal of making gnome-applets more clean (by allowing mini-commander to be deprecated) and incorporates technology exciting to the future of GNOME. -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Wed, 26 Oct 2005 18:28:46 +0200, Thomas Vander Stichele wrote: Why not ? It is not different for any other language you could be using except for C and C++. What sort of answer would be better (and still truthful) ? Something like Python eats your memory, now here's how we're going to solve it was what I was after. Anyway, Raphael and myself talked a bit about this on IRC and threw around some ideas that might help. We'll see how it goes. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Tue, 2005-10-25 at 00:35 +0200, Benoît Dejean wrote: I really don't see what's the point in getting python into desktop. Many people are spending their time optimizing startup time and memory usage. A single python applet would annihilate all that painful work. I'am a python hacker but i think it is unaffortable in desktop. We already have at least one python app in the desktop - gmenu-simple-editor. An applet is different, though, because its started at login and remains running for the entire session so any memory usage problems are more keenly felt. Cheers, Mark. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Tue, 25 Oct 2005 11:25:40 +0800, Davyd Madeley wrote: I don't think it is unacceptably high however. Has anyone profiled the usage of PyGTK applications. Can it be improved? http://evanjones.ca/memoryallocator/ I'm not sure if any work has been done on this since PyCon 2005, but if not then Python will always have problems. Summary of paper: its memory allocator optimises for CPU speed over memory usage by never freeing anything, instead it runs its own heaps which just grow and grow over time. The garbage collector also has serious problems, for instance it's not compacting so even if heap space could be returned to the OS often they would not be due to fragmentation. So assuming there has been no action on this front I guess there are three ways to fix this: * Fix the Python interpreter to use a real compacting GC * Rewrite the applet in something other than Python and which isn't going to cause massive flamewars (which basically means C or C++) * Somebody could implement a Python-like language which compiles to native code. But then you'd have pretty much cloned Boo, and might as well be using Mono anyway. thanks -mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Ter, 2005-10-25 às 14:39 +0100, Mike Hearn escreveu: On Tue, 25 Oct 2005 11:25:40 +0800, Davyd Madeley wrote: I don't think it is unacceptably high however. Has anyone profiled the usage of PyGTK applications. Can it be improved? http://evanjones.ca/memoryallocator/ I'm not sure if any work has been done on this since PyCon 2005, but if not then Python will always have problems. Summary of paper: its memory allocator optimises for CPU speed over memory usage by never freeing anything, instead it runs its own heaps which just grow and grow over time. The garbage collector also has serious problems, for instance it's not compacting so even if heap space could be returned to the OS often they would not be due to fragmentation. So assuming there has been no action on this front I guess there are three ways to fix this: * Fix the Python interpreter to use a real compacting GC - OK, but you'd lose some speed.. you can always compile python with configure --without-pymalloc... probably does something similar to what you want. * Rewrite the applet in something other than Python and which isn't going to cause massive flamewars (which basically means C or C++) Or: * Rewrite performance-sensitive parts of the deskbar applet in C, but keep the rest in python. * Somebody could implement a Python-like language which compiles to native code. But then you'd have pretty much cloned Boo, and might as well be using Mono anyway. Work is underway to generate C++ from python code: http://sourceforge.net/projects/shedskin/ Finally, I should mention that a future pygtk version should decrease memory usage, and improve startup time, by registering GObject wrappers on demand, and by using mmapped introspection information, instead of code generation of wrappers for everything upfront. We hope the new introspection-powered version will be available for gtk 2.10, if all goes well... Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On 10/25/05, Mike Hearn [EMAIL PROTECTED] wrote: On Tue, 25 Oct 2005 11:25:40 +0800, Davyd Madeley wrote: I don't think it is unacceptably high however. Has anyone profiled the usage of PyGTK applications. Can it be improved? http://evanjones.ca/memoryallocator/ I'm not sure if any work has been done on this since PyCon 2005, but if not then Python will always have problems. Summary of paper: its memory allocator optimises for CPU speed over memory usage by never freeing anything, instead it runs its own heaps which just grow and grow over time. You can call the garbage collector to cleanup unsused objects in memory as frequently as you wish. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le mardi 25 octobre 2005 à 15:57 +0100, Gustavo J. A. M. Carneiro a écrit : Ter, 2005-10-25 às 14:39 +0100, Mike Hearn escreveu: Finally, I should mention that a future pygtk version should decrease memory usage, and improve startup time, by registering GObject wrappers on demand, and by using mmapped introspection information, instead of code generation of wrappers for everything upfront. We hope the new introspection-powered version will be available for gtk 2.10, if all goes well... We (Christian Meyer, Martin Grimme and I) worked a lot on gdesklets to reduce its memory usage, and iirc, We never got significant results. May be we once managed to get 1MB back. Fixing memory leak in python gdk helped a lot, but that was not our code. IIRC most optimizations were about image drawing / desktop transparency. Which is irrelevant to deskbar-applet. So i can hardly imagine how you could shrink memory usage from 22MB to 15MB for example ... (which would still make deskbar applet the biggest applet memory wise). -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Mike Hearn wrote: So assuming there has been no action on this front I guess there are three ways to fix this: * Fix the Python interpreter to use a real compacting GC That could be worse! Compacting GC's require twice the memory of a non-compacting one. (you dont know how much garbage you have when you walk the heap to GC so you need another empty heap of the same size to copy everything into it) * Rewrite the applet in something other than Python and which isn't going to cause massive flamewars (which basically means C or C++) Could do but might not be economical time wise for the devloper(s) * Somebody could implement a Python-like language which compiles to native code. I would like to but GCC4 has absolutely no docs for implementing new languages. It should also be a community effort to create a new language if existing ones are unsuitable. But then you'd have pretty much cloned Boo, and might as well be using Mono anyway. Mono and most other GC languages (gcj/java et al) also suffer from memory leaks due to the boehm GC not being precise enough. This alone makes them unsuitable for long running apps or daemons else you risk having all your free memory being eaten up in the long run. The right solution is to not use a GC langugae for these kinds of apps (unless they offer manual freeing of objects in addition to GC which the boehm GC supports). -- Mr Jamie McCracken http://www.advogato.org/person/jamiemcc/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Hi ! I'll try to reply to some things that have been discussed on this thread recently So assuming there has been no action on this front I guess there are three ways to fix this: * Fix the Python interpreter to use a real compacting GC That could be worse! Compacting GC's require twice the memory of a non-compacting one. (you dont know how much garbage you have when you walk the heap to GC so you need another empty heap of the same size to copy everything into it) As i understand the paper that was linked to, on python memory management, the peak memory used by a program will be the maximum memory it will ever use, i don't think deskbar has large bursts of memory requirements, and as such won't have an ever expanding memory consumption which could lead to problems. So Yes, it will eat your memory, but not increasingly with time (hopefully). * Rewrite the applet in something other than Python and which isn't going to cause massive flamewars (which basically means C or C++) Could do but might not be economical time wise for the devloper(s) I love how gnome-launch-box works (more then an applet for this type of things), but it lacks many of the functionality deskbar backend has got... Guess why ? Let's be clear here, developing with python is fun, and quick, it's a prototyping language. Writing the same program in C would require much more time, bug fixing, memleak-fixing, and other things few want to do. Python has easy way to add independnt modules, with C it's a pain in the Ass. We won't switch to C or C++ anytime soon. It can be considered once the codebase is stable and the features well settled down, but certainly not in the 2.14 timeframe. We (Christian Meyer, Martin Grimme and I) worked a lot on gdesklets to reduce its memory usage, and iirc, We never got significant results. May be we once managed to get 1MB back. Fixing memory leak in python gdk helped a lot, but that was not our code. I think the point is clear, python eats your memory, live with it. Or: * Rewrite performance-sensitive parts of the deskbar applet in C, but keep the rest in python. That technique works well for CPU-speed limited code, but would probably make little difference for memory usage unless nearly all was written in C. Bear in mind the interpreter itself carries quite a large fixed overhead. But I guess you'd need to do some memory profiling (assuming there are tools that can profile the python heaps). There are no CPU-intensive parts in deskbar except startup because we crate an index, so there is no point in implementing some parts in C and others no, it's either all or nothing. If start-up of deskbar blocks the panel, then it is an issue :-) Else, it might not be an issue for the user. Deskbar does not block the panel while loading, it just does a lot of IO to index the files it needs, the only blocking thing is deskbar itself (and it's greyed out during that time). Start-up time may not be that big an issue if it's a one-off and doesn't stop you otherwise using your desktop. This may be a bigger concern for those who want to replace the Alt-F2 Run dialog. In the current state of things, having it as quick-start standalone alt-f2 dialog is not possible, since it takes relatively long to start. Now if we don't take startup time, it is easy to have it quickly start if there is an instance running somewhere before. i meant 6s startup with CPU 100% Yes that's a problem and we will be fixing it, but if you install the applet you are accepting it's drawbacks. I really don't see what's the point in getting python into desktop. Many people are spending their time optimizing startup time and memory usage. A single python applet would annihilate all that painful work. I'am a python hacker but i think it is unaffortable in desktop. Having the desktop or email program (*hint* /me looks at evolution *hint*) start fast is crucial. Having an applet start slow is just a problem for those who care about performance. That excludes lots of users, me being the first. That and the fact that an applet is something you choose to use, whereas you *have* to use evolution on a stock gnome desktop. So to summarize the discussion: * Yes, deskbar is written in python and that won't be changing soon, and not in 2.14 timeframe. * The startup time and CPU usage is problematic but there is not much to be done (more below) * We propose deskbar to become an applet, nothing more, nothing less, applets are optionally used by users, and by using them users are accepting the consequences. If we see the functions provided by it are useful to replace mini-commander/alt-f2 let's discuss how to do it properly, instead of bashing python, if doing it without python is not an option, let's not consider that use-case. * Most users don't care about an applet taking a bit more memory than others, most will not even see it. * Deskbar doesn't block the gnome
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Tue, 2005-10-25 at 22:26 +0200, Raphael Slinckx wrote: There are no CPU-intensive parts in deskbar except startup because we crate an index, so there is no point in implementing some parts in C and others no, it's either all or nothing. Could you cache this generation as a picked dictionary? Then simply test if your dictionary is still valid when you load up next time. That would surely save some startup time. In the current state of things, having it as quick-start standalone alt-f2 dialog is not possible, since it takes relatively long to start. Now if we don't take startup time, it is easy to have it quickly start if there is an instance running somewhere before. This is why I would suggest having all of the hard stuff in a Bonobo factory. You already have one to power the applet. It would be a relatively simple matter of implementing a different type of instance that was a launch dialog. Since the factory already did all of the indexing when it started, you needn't worry about that when an instance is created. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Vincent Untz wrote: I would love to see this not only go in, but also replace mini-commander (ie. have everyone's mini-commander get automagically upgraded to deskbar, unless they choose to specifically build mini-commander). I'd like it to replace the current run dialog as well. Raphael: is this on your roadmap? :-) For the moment we only have the applet/entry form working, but we also have a new presentation widget [1] in the work. The plan is to make that one drop down instead of the current flat list, if it fits well. Now the widget could be reused as an alt-f2 dialog replacement easily, i guess just stick it in a standalone window, and you're set... Raf. [1] http://www.daimi.au.dk/~kamstrup/cuemiac-live.png ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Raphael Slinckx wrote: Vincent Untz wrote: I would love to see this not only go in, but also replace mini-commander (ie. have everyone's mini-commander get automagically upgraded to deskbar, unless they choose to specifically build mini-commander). I'd like it to replace the current run dialog as well. Raphael: is this on your roadmap? :-) For the moment we only have the applet/entry form working, but we also have a new presentation widget [1] in the work. The plan is to make that one drop down instead of the current flat list, if it fits well. Now the widget could be reused as an alt-f2 dialog replacement easily, i guess just stick it in a standalone window, and you're set... Raf. [1] http://www.daimi.au.dk/~kamstrup/cuemiac-live.png Any plans for a gnome-launch-box like interface? I love how gnome-launch-box works (more then an applet for this type of things), but it lacks many of the functionality deskbar backend has got... Ciao Michele ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le dimanche 23 octobre 2005 à 19:19 +0200, Raphael Slinckx a écrit : == Requirements == Required dependencies: * Python 2.3 or above :/ - deskbar-applet startup is as long as full gnome startup: 6s for loading the applet on my ppc 1GHz. - Memory usage on startup : 22MB RES this is the highest memory usage after X on startup. (for the record, the second biggest applet is wnck-applet with 8MB RES) let's have a look : python -c import operator, gtop; print reduce(operator.add, [(m.end - m.start) for m in gtop.proc_map(`pgrep python`) if m.perm gtop.MAP_PERM_WRITE]) 10412032 ~10 MB of writable/unshared memory. I really don't see what's the point in getting python into desktop. Many people are spending their time optimizing startup time and memory usage. A single python applet would annihilate all that painful work. I'am a python hacker but i think it is unaffortable in desktop. Thanks. NB: this is off-topic. For the same reasons, i don't like ubuntu update applet. It is the biggest app on startup, even Xorg takes less memory. -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Tue, 2005-10-25 at 00:35 +0200, Benoît Dejean wrote: - deskbar-applet startup is as long as full gnome startup: 6s for loading the applet on my ppc 1GHz. - Memory usage on startup : 22MB RES Performance is a concern, but also one I do not want to attack prematurely. For example, python per se may not be the culprit, but rather the fact that we have to parse and index browser bookmarks and history files. Perhaps a better solution would have such database queries provided by an epiphany-data-server appended to the current evolution-d-s. Start-up time may not be that big an issue if it's a one-off and doesn't stop you otherwise using your desktop. This may be a bigger concern for those who want to replace the Alt-F2 Run dialog. Also, my understanding is that there is a difference between getting deskbar into GNOME, and getting deskbar into (onto?) the default GNOME desktop. We've shipped mini-commander for a number of years now as a power-user feature. Regardless, starting quicker and taking less memory are almost always worthy goals. Nigel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le mardi 25 octobre 2005 à 13:13 +1000, Nigel Tao a écrit : On Tue, 2005-10-25 at 00:35 +0200, Benoît Dejean wrote: Start-up time may not be that big an issue if it's a one-off and doesn't stop you otherwise using your desktop. This may be a bigger concern for those who want to replace the Alt-F2 Run dialog. i meant 6s startup with CPU 100% -- Je cherche un emploi de développeur / admin sysréseau sous GNU/Linux http://fr.lolix.org/search/cv/cv.php3?id=7101 http://dejean.benoit.free.fr/CV.pdf %% JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Mon, 2005-10-24 at 22:55 +0200, Michele Cella wrote: Any plans for a gnome-launch-box like interface? I love how gnome-launch-box works (more then an applet for this type of things), but it lacks many of the functionality deskbar backend has got... When I was designing Auric (which is basically what deskbar is, but in Python and without eplugin) I had always imagined a global keyshortcut that would simply focus the input entry box. If the run dialog too were be replaced, the keystroke could either focus the applet or run the dialog, based on whether or not the applet was present. The correct way to do this would be to have both the applet and the run dialog launched out of the same Bonobo factory with slightly different OAFIID strings. When the keystroke was received, it would decide what to do. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
Le mardi 25 octobre 2005 à 13:13 +1000, Nigel Tao a écrit : Start-up time may not be that big an issue if it's a one-off and doesn't stop you otherwise using your desktop. This may be a bigger concern for those who want to replace the Alt-F2 Run dialog. If start-up of deskbar blocks the panel, then it is an issue :-) Else, it might not be an issue for the user. I didn't try, so I don't know if it blocks the panel or not. I just don't want to receive lots of slow startup of the panel bugs ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
On Sun, Oct 23, 2005 at 07:19:15PM +0200, Raphael Slinckx wrote: This mail introduces the deskbar-applet, and officially propose its inclusion in the gnome 2.14 desktop release ! Of these requirements, only gnome-python-extras is problematic from what i understand, maybe it's a good time to push gnomeapplet into gnome-python proper ? I would love to see this not only go in, but also replace mini-commander (ie. have everyone's mini-commander get automagically upgraded to deskbar, unless they choose to specifically build mini-commander). I would also love to see the ability to write GNOME Applets in Python be an officially supported part of 'Desktop'. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
I'm in favour of python based applets as well. Python is an ubquitious language that making a requirement for it would have pretty light impact. sri On Mon, 2005-10-24 at 02:30 +0800, Davyd Madeley wrote: On Sun, Oct 23, 2005 at 07:19:15PM +0200, Raphael Slinckx wrote: This mail introduces the deskbar-applet, and officially propose its inclusion in the gnome 2.14 desktop release ! Of these requirements, only gnome-python-extras is problematic from what i understand, maybe it's a good time to push gnomeapplet into gnome-python proper ? I would love to see this not only go in, but also replace mini-commander (ie. have everyone's mini-commander get automagically upgraded to deskbar, unless they choose to specifically build mini-commander). I would also love to see the ability to write GNOME Applets in Python be an officially supported part of 'Desktop'. --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.14 Module Proposal: Deskbar Applet
That takes long enough to start as is yet, and with optional beagle dependency (which of course distributions are going to compile it with) I really doubt that this would be a good idea. kr, Jan On Sun, 23 Oct 2005, Luis Villa wrote: On 10/23/05, Davyd Madeley [EMAIL PROTECTED] wrote: On Sun, Oct 23, 2005 at 07:19:15PM +0200, Raphael Slinckx wrote: This mail introduces the deskbar-applet, and officially propose its inclusion in the gnome 2.14 desktop release ! Of these requirements, only gnome-python-extras is problematic from what i understand, maybe it's a good time to push gnomeapplet into gnome-python proper ? I would love to see this not only go in, but also replace mini-commander (ie. have everyone's mini-commander get automagically upgraded to deskbar, unless they choose to specifically build mini-commander). I'd like it to replace the current run dialog as well. Luis Chipzz AKA Jan Van Buggenhout -- UNIX isn't dead - It just smells funny [EMAIL PROTECTED] Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
