Re: bug-buddy integration
Luis Villa wrote: On Wed, Mar 11, 2009 at 6:46 PM, Andre Klapper ak...@gmx.net wrote: Am Mittwoch, den 11.03.2009, 23:28 +0100 schrieb Juan Jesús Ojeda Croissier: Apport[1] is a system which is able to send a very complete crash log to a bug tracker system (not necessary the Ubuntu's one). This is working with the one from Ubuntu, but also Fedora and OpenSuse. Can be used agoinst email based interface and more. Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki I always wonder if this isn't all about duplicating efforts. No need to wonder; it definitely is duplicated and wasted effort. Not intentional, of course[1], but painful no matter how you slice it. Luis [1] Despite the slight tinge of NIH in many of the efforts. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Do we have a list of features missing from bug buddy so maybe we could direct some of this energy towards making it (or some standard community crash logger) meet community need and distro specific needs so we don't have every distro reinventing this wheel? My own ideas are: - capture more complete distro and component revision information. - optionally passes bug first to a distribution maintained bug database. (to filter distro specific bug pollution) - callable by user from application (window manager?) menu, captures user comments as well as application context info. - plug-ins for distro specific capture tools (strace, ktrace, truss, dtrace, mdb, pstack, gdb, dbx,...) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Luis Villa wrote: On Wed, Mar 11, 2009 at 7:28 PM, Brian Nitz brian.n...@sun.com wrote: Luis Villa wrote: On Wed, Mar 11, 2009 at 6:46 PM, Andre Klapper ak...@gmx.net wrote: Am Mittwoch, den 11.03.2009, 23:28 +0100 schrieb Juan Jesús Ojeda Croissier: Apport[1] is a system which is able to send a very complete crash log to a bug tracker system (not necessary the Ubuntu's one). This is working with the one from Ubuntu, but also Fedora and OpenSuse. Can be used agoinst email based interface and more. Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki I always wonder if this isn't all about duplicating efforts. No need to wonder; it definitely is duplicated and wasted effort. Not intentional, of course[1], but painful no matter how you slice it. Do we have a list of features missing from bug buddy so maybe we could direct some of this energy towards making it (or some standard community crash logger) meet community need and distro specific needs so we don't have every distro reinventing this wheel? My own ideas are: - has to work with non-GNOME apps. I don't think this precludes having a user-invoked option, though it does make it a bit more of a challenge. - capture more complete distro and component revision information. This is pretty complete in modern versions of bug-buddy, I believe. - optionally passes bug first to a distribution maintained bug database. (to filter distro specific bug pollution) This is the default behavior distros tend to want... which makes it hard for upstream to do anything useful, since the distros are historically pretty bad at getting this data upstream. (By 'pretty bad' I don't think any distro which does this has ever systematically/programatically moved that data upstream, though I'm certainly out of touch and may have missed something.) Mind you, it isn't clear to me that upstream has been doing much useful with the data we do have of late, but like the uncoordinated re-inventions of bug-buddy, that is a symptom of the general underinvestment in QA by GNOME partners. Too true. - callable by user from application (window manager?) menu, captures user comments as well as application context info. - plug-ins for distro specific capture tools (strace, ktrace, truss, dtrace, mdb, pstack, gdb, dbx,...) I'd note that this data is actually overrated. Useful, yes, but even the primitive information we used to get was very useful when we got it in volume and we had eyes poring over it for clues. I have a sense that the current emphasis on all these various tools (with their attendant complexities) makes perfect data collection the enemy of good data collection. I agree that too much information in the capture can be at least as much of a problem as too little. Still, it would be nice to capture enough to have a unique 'bug/crash fingerprint'. Everyone tells me this is impossible, but I'm an optimist. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Low memory hacks
Behdad Esfahbod wrote: On Mon, 2008-03-03 at 09:05 +, Brian Nitz wrote: Third, there's no such thing as locale-specific fonts. If a font happens to cover Chinese only, so be it. Finally, if you don't need those fonts, simply don't install them (or uninstall them). I know it doesn't make sense from a developer's point of view, but it has been a request for end users, We don't ever use (X language) fonts in our Hospital/Bank/University/Government Office, why are we installing these fonts? It may be a distribution specific issue, but it's probably an issue with nearly every distribution. A logical conclusion is that if of a gazillion different Linux distros, none fixed it, chances are high that it's not a problem to begin with. Even if Pat Sulwalski's estimate that GNOME deployments where resource consumption matters only amounts to about 5% of the market, I don't think we can ignore that market because it represents: - Newcomers (a.k.a. our growth). Those who are just getting their feet wet with *nix/GNOME aren't going to install it on their primary computer. They're probably running it on an old laptop with 128Mb which someone gave to them. - Large commercial deployments. Whether it is on a thick or thin client, a deployment of several thousand GNOME desktops (which I've done) is probably going to want to strip out as much as possible to reduce resource consumption, reduce potential security exploits, reduce administration costs... - Small footprint devices (our future): Devices such as OLPC laptops and Nokia phones seem to have the CPU power and memory capacity of a 10 year old desktop PC. Just because something feels suboptimal doesn't mean it should be fixed. It's not really a distro issue. It's an integrator issue. And BTW being able to render Chinese just fine if a friend of mine happens to want to check a Chinese web site on my laptop sounds like a useful issue to me, even if I'm sacrificing 10MB of my harddisk for it. We were talking about physical memory, not hard disk space. Sorry I've caused the topic to drift a little bit, Nickolay began this thread addressing the real need for some GNOME user's to reduce memory usage with a little reduction in functionality. I don't think any of us would advocate removing evolution calendar or stripping L10N messages or fonts or removing anything else from all GNOME desktops. But if a feature isn't used 99.999% of the time and it consumes resources, it should have an off switch. I hope Nickolay's thread can become a brainstorming session regarding which GNOME components should have an off switch? (and don't) Your comments and a couple of experiments with dtrace and various other tools, convinced me that it probably isn't worthwhile to restrict the opening of these font cache files by locale even in cases where they are remotely mounted via NFS. (Does anyone remember when Apple system performance was proportional to the number of installed fonts?) If a font is installed, it HAS to be noted in the cache somewhere to be discoverable by apps. O.K. but opening and mapping these files on every application launch even when the associated fonts may _never_ be read for a particular user doesn't seem to be the most efficient thing to do. A very common rule for optimizing code is, don't optimize it if it's not a bottleneck. Say, you get rid of those 20 extra system calls out of the 7000 system calls during a typical application startup. You've gained what, a 0.3% improvement in the number of syscalls. Go translate that to wall clock time... True, but we're talking about memory consumption. A 1 byte malloc which pushes your page or process off to disk can cause an order of magnitude (or two) degradation in performance of whatever it forces out. Except for a few applications which we know are heavy resource consumers because of their nature (web browsers, email clients and file indexers), GNOME has become balanced enough that we can't necessarily count on the low hanging fruit of optimizing by removing severe bottlenecks. It's death by 1000 cuts, but I agree that the opening (and mmapping?) of all font-cache files at every application launch doesn't appear to be a very deep cut. Yes, of the 5GB worth of data installed on my laptop by Fedora, I probably don't need and never use 3GB of it. But I have better things to do than going over the list of all five hundred thousand files on my root partition and remove the ones I don't need. That holds true for most people. If you don't like it, use LSB, or gentoo, or some other productivity-optimized system. Again, I'm not talking about hard drive space. On that very same laptop I would bet that you max out physical RAM from time to time. If you don't, try hanging a few hundred GNOME users off the same box. Someone will put you over the edge. CPU
Re: Low memory hacks
Behdad Esfahbod wrote: On Fri, 2008-02-29 at 13:32 +, Brian Nitz wrote: For example, launching eog in the C locale (Solaris Nevada build 82, GNOME 2.20.2) opens font files for many other locales. These may be mapped into physical memory at times, regardless of your locale. : 4302 eog 18 /usr/openwin/lib/locale/zh/X11/fonts/TrueType//fonts.cache-1 4302 eog -1 /usr/openwin/lib/locale/zh_CN.GB18030/X11/fonts/75dpi//fonts.cache-1 [...] This might make sense for a browser or email client, but if there is a performance and memory impact, it would be nice to have the option to disable loading of fonts from other locales. Some GNOME users are running on thin client kiosks on isolated networks (banks...) where they are unlikely to need all of these fonts. This makes zero sense. First, those are caches, not actual fonts. Second, they are mapped into the address space readonly, not read, so they don't consume per-process memory. Good point. The opens of so many (often unnecessary) font cache files during every application launch may impact performance if not memory but that's another topic. Third, there's no such thing as locale-specific fonts. If a font happens to cover Chinese only, so be it. Finally, if you don't need those fonts, simply don't install them (or uninstall them). I know it doesn't make sense from a developer's point of view, but it has been a request for end users, We don't ever use (X language) fonts in our Hospital/Bank/University/Government Office, why are we installing these fonts? It may be a distribution specific issue, but it's probably an issue with nearly every distribution. If a font is installed, it HAS to be noted in the cache somewhere to be discoverable by apps. O.K. but opening and mapping these files on every application launch even when the associated fonts may _never_ be read for a particular user doesn't seem to be the most efficient thing to do. Ok, now looking at your list again, you are running an old version of fontconfig that does in fact read those caches into memory for each process. Use a newer fontconfig, and that would save you some 100k per process, or more. Thanks for this information. This will be useful. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Low memory hacks
Kalle Vahlman wrote: 2008/2/29, Nickolay V. Shmyrev [EMAIL PROTECTED]: Heh, I also would like to delete all .po files if only I knew how to keep translations :) Deleting .po:s would be futile as those are just the sources from which the actual (binary) files loaded are compiled ;) I agree that deleting the .po files probably won't impact your physical memory footpring. Even so, you only have the translations of your current locale loaded into RAM so by deleting all the others you only save disk space. AFAIK that should be safe to do though. This might not be entirely true. Gconf does now separate locale specific strings into separate backend files. But fonts for all locales tend to be loaded regardless of your base locale. For example, launching eog in the C locale (Solaris Nevada build 82, GNOME 2.20.2) opens font files for many other locales. These may be mapped into physical memory at times, regardless of your locale. : 4302 eog 18 /usr/openwin/lib/locale/zh/X11/fonts/TrueType//fonts.cache-1 4302 eog -1 /usr/openwin/lib/locale/zh_CN.GB18030/X11/fonts/75dpi//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/zh_CN.GB18030/X11/fonts/TrueType//fonts.cache-1 4302 eog -1 /usr/openwin/lib/locale/zh_HK.BIG5HK/X11/fonts/75dpi//fonts.cache-1 4302 eog -1 /usr/openwin/lib/locale/zh_HK.BIG5HK/X11/fonts/TT//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/zh_TW.BIG5/X11/fonts/75dpi//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/zh_TW.BIG5/X11/fonts/TT//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/KOI8-R/X11/fonts/TrueType//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/ar/X11/fonts/TrueType//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/en_US.UTF-8/X11/fonts/misc//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/hi_IN.UTF-8/X11/fonts/TrueType//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/ja/X11/fonts/75dpi//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/ja/X11/fonts/TT//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/ja/X11/fonts/TTbitmaps//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/ko.UTF-8/X11/fonts/75dpi//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/ko.UTF-8/X11/fonts/TrueType//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/ko/X11/fonts/75dpi//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/ko/X11/fonts/TrueType//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/ru.ansi-1251/X11/fonts/TrueType//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/th_TH/X11/fonts/75dpi//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/th_TH/X11/fonts/TrueType//fonts.cache-1 4302 eog -1 /usr/openwin/lib/locale/zh.GBK/X11/fonts/75dpi//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/zh.GBK/X11/fonts/TrueType//fonts.cache-1 4302 eog 18 /usr/openwin/lib/locale/zh/X11/fonts/75dpi//fonts.cache-1 This might make sense for a browser or email client, but if there is a performance and memory impact, it would be nice to have the option to disable loading of fonts from other locales. Some GNOME users are running on thin client kiosks on isolated networks (banks...) where they are unlikely to need all of these fonts. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Extreme memory usage for gnome-panel related apps
I typically leave gnome-panel (gnome 2.20.1 on Solaris Nevada) running for weeks in a Sun Ray session. The heap does appear to be growing over time: pmap -x of gnome-panel process BEFORE restart of gnome-panel: 22817: gnome-panel --sm-client-id 11819cdc2800011951517610052150048 --scr Address Kbytes RSSAnon Locked Mode Mapped File 0001 496 488 - - r-x-- gnome-panel 0009A000 24 24 16 - rwx-- gnome-panel 000A345634561432 - rwx--[ heap ] 0040 12288 12288 12288 - rwx--[ heap ] F92813121024 - - r-x-- libcrypto.so.0.9.8 F93D8000 104 96 - - rwx-- libcrypto.so.0.9.8 F93F2000 8 - - - rwx-- libcrypto.so.0.9.8 F94053441640 - - r icon-theme.cache ... pmap -x of gnome-panel process AFTER restart of gnome-panel: 3024:gnome-panel --sm-client-id 11819cdc2800011951517610052150048 --scr Address Kbytes RSSAnon Locked Mode Mapped File 0001 496 488 - - r-x-- gnome-panel 0009A000 24 24 24 - rwx-- gnome-panel 000A196019601960 - rwx--[ heap ] F94053441640 - - r icon-theme.cache F9C070565904 - - r icon-theme.cache FA35 16 16 - - r-x-- libmoniker_std_2.so FA362000 8 8 8 - rwx-- libmoniker_std_2.so FA37 32 32 - - r-x-- libstartup-notification-1.so.0.0.0 FA386000 8 8 8 - rwx-- libstartup-notification-1.so.0.0.0 FA39 8 8 8 - rwx--[ anon ] FA3A 88 80 - - r-x-- libgnome-desktop-2.so.2.3.14 FA3C4000 8 8 8 - rwx-- libgnome-desktop-2.so.2.3.14 FA3D 16 16 - - r-x-- libpixbufloader-png.so FA3E2000 8 8 8 - rwx-- libpixbufloader-png.so FA3F 64 16 16 - rwx--[ anon ] FA41 384 192 - - rwxs-[ shmid=null ] FA4835201496 - - r icon-theme.cache FA81 32 32 - - r-x-- libesd.so.0.2.38 ... I'll spare the details of the Anonymous memory used by all libraries in gnome-panel's address space, but notice that restarting gnome-panel reduced the heap from over 15M to about 2M when I restarted gnome-panel. Occasionally I see halting behaviour in gnome-panel menus which may be caused by paging activity. Did anything recently change in gnome-panel's memory management?When was gslice introduced? How can I disable it? Gslice might not be necessary on Solaris since running with a slab allocator is as simple as setting LD_PRELOAD to libumem.so. Ross Burton wrote: On Fri, 2007-11-30 at 10:51 +0100, Mark wrote: It's only leaked 2000 bytes, you'll need to do more research on the 422000 bytes which are still reachable. how do i do that? (gonna read the MemoryReduction docs soon) Read the valgrind help page. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Timelapsed backgrounds
It sounds like an interesting idea. One thing I wonder about with anything that changes the screen synchronized to a clock is if it can be randomized somewhat so that it wouldn't cause a network storm in cases where all thin client screens attached to a single server are set to goatse at precisely 12:00a.m. I wouldn't want the screens to change frequently in a thin client environment and I would want to be able to disable this feature as well as any fade-out effects. Thomas H.P. Andersen wrote: Desktop backgrounds are boring. Even though it's damn easy to change I would like the capability of having different virtual desktops have different backgrounds. People have been asking for that feature since GNOME 1.4. the background few people I know do it regularly. (Mine usually only change when some jerk comes by and decides my new background should be goatse :-) ) Having the background change subtly over time sounds like a very nice feature to me. Here is a slightly extreme idea. How about a dbus interface for changing the background? I guess all it should take is a path to an image and fade the background to it. I think background image setting belongs in gconf (or whatever configuration manager you're using) That way system administration tools which are designed to set user desktop parameters don't require a special case for desktop background. For example, in low-bandwidth thin client environments, it's sometimes useful to force all user desktop backgrounds to something low bandwidth. Also in a secure or medical environment you might want to set the screens of all employees of a certain level (DR, top secret gurumeister...) to a particular background. I actually thought about this the other day as I wanted to have my IM application change the background to the person I'm talking to. I like pictures of family and friends as my background but I just never get around to changing it. There is also an application to fetch interesting flickr pictures and put them as background as well. Having an easy interface to change it might spark even more innovative ideas too. On 26 Sep 2007 17:35:21 +0200, Soeren Sandmann [EMAIL PROTECTED] wrote: Sanford Armstrong [EMAIL PROTECTED] writes: This sounds really cool! Is there any support for for changing the background at a specific time of day? That way you could show morning images in the morning, evening images in the evening, etc. Yes, this is exactly the intention. I don't see how you could guarantee that with durations (as in the sample XML file), unless you always logged in at the same time every day. ;-) The slides.xml file has: starttime year2007/year month8/month day28/day hour12/hour minute21/minute second23/second /starttime which means the first slide would be shown at that time. If the sum of durations is 24 hours, then the cycle would start over at the same time every day. Soren ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop sounds in Gnome
Thomas Wood wrote: On 23 Mar 2007, at 19:26, Glenn J. Mason wrote: things super simple from a user perspective. Do we really need, and do users really care about, different sounds for questions, information, battery low, etc. my personal opinion is no, we don't need all that. So, the question is, are there users that use and like this functionality? Personally: yes, I like the functionality very much! I have cordless headphones and often walk away from the compy whilst it is doing something which might take a while (CD burning, downloading, updating). I really like being notified audibly, and the different urgency I can assign to it -- a question? I'll wander back. Battery low? Find transformer and run! Laptops often make their own noise when running low on power anyway. Anyway, I guess there's a possible argument for two sounds to represent critical and non critical alerts. The point here is would anyone want to change all these different noises if they were really good quality to start with? iTunes makes a noise when it finishes ripping a cd (which is only mildly useful to me at best), and I don't see an option to change it if I wanted. Not that I ever would probably... And that's before even considering accessibility, etc. I was wondering when someone would bring this up. It doesn't make much sense to me, as you're probably going to be using a screen reader anyway, so you don't need to learn half a dozen different sounds because you already know the spoken word. However, I'm not experienced in this field so it'd be interesting to hear from someone who is. Regarding sound alerts and themed alerts, first do no harm. That is, the themed alert sound shouldn't clobber the screenreader. (e.g. on Ubuntu Edgy, the screen reader doesn't work unless sound events are disabled.) While it's true that OSX has only one system wide alert sound, it has been possible to configure speakable alerts since MacOS 9.0 or earlier. This made per event alert sounds less necessary. Speakable alerts don't have the functionality of a screen reader, but they are useful when your display isn't working or when you aren't looking at the display. Would it be useful to review previous GNOME sound architecture? What deficiencies in esd, gstreamer... prevent us from wanting to move forward with these? We've learned a few things by finding and fixing bugs with previous GNOME sound daemons. For example, I hope any new sound architecture takes the following into consideration: 1) Work with screenreaders, VOIP and streaming audio/video players, not against them. 2) Don't assume that the user is at the console. (e.g. on a thin client or remote X display, the sound should come out of the client, not the server.) 3) Don't assume that you have sole access to an audio device and don't assume that there is only one audio device on a machine. 4) Don't lock the sound API to a specific architecture (e.g. X86), specific kernel (e.g. Linux) or specific sound hardware (e.g. soundblaster...) 5) Try to avoid sucking resources when idle and be reasonably efficient when in use. Can the ekiga and gaim developers let us know what would help them? I find that relating sound events to IRC events (e.g. my name mentioned on a channel) is extremely useful. Unfortunately this isn't yet reliable. And wouldn't it be cool to have this somehow fit in with sound themes. Each sound themable application (ekiga, gaim, evolution, nautiulus/panel/metacity) would expose a list of events which could be associated with sounds. Sounds could be dropped from a sound pallet or pulled in together from a sound theme. Hmm, it's starting to remind me of my mobile phone: HomeSun GAIM: my name is mentionedpfftping some leaves the room Evolution: Email received blurp pfft System Alerts: speak %s speak %s ... I know this can be done per application, but wouldn't it be fun to unify, remove some redundant code and allow for a common user interface? -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop Session Presence Manager
Galaga does seem to have what it takes, but if it doesn't quite meet Alex's needs, I'd suggest extending Galaga rather than reinventing the wheel. I looked at Galaga a few months ago when I was considering how to notify IM applications and other desktop applications that I'm not here so that, for example on thin clients: When I pull my smart card out, I'd like GAIM to mark me as Away When I pull my smart card out, I'd like GNOME stock ticker and other screen update applications to slow their refresh rate or otherwise reduce their resource and network bandwidth usage. For this I think there needs to be an interface to indicate local presence which doesn't rely on any instant messaging client running. Could Galaga be made to read a /desktop/gnome/presence gconf key if no IM client is running? Or would it be better to makd the /desktop/gnome/presence gconf key the focal point for presence and have Galaga write to that? Ross Burton wrote: On Tue, 2007-01-23 at 12:38 +, Alex Jones wrote: But that presence is backed by Gaim, right? So that leaves it up to Gaim to dictate session user presence, based on some IM account. This isn't a good idea IMO - Gaim isn't what I'd consider to be a desktop service! This idea sits underneath Gaim, or whatever app you wish to choose that might be interested in *real* session user presence, as in the actual presence of a user at the computer seat. No, there is a gaim feed, but there is also a telepathy feed, and a gossip feed. The point of Galago was to abstract the presence and rosters, not to be a front-end to gaim. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: The future of session management in GNOME
Tommi Komulainen wrote: On 9/13/06, Brian Nitz [EMAIL PROTECTED] wrote: Why do we ever log out? 4) Free up resources. ??? Reason 4 is especially interesting for multiuser systems, especially thin clients. It might be interesting for embedded uses of GNOME (laptop/child, maemo...) to reduce resources when user isn't looking. For single user embedded case I can't suddenly think of anything logging out would provide that idle/screensaver mode and offline mode wouldn't. When the user isn't watching you should've already stopped all timers and screen updates. Except for possible music playing and network transfers, when the screen is blanked nothing should be happening. I agree, what I'm proposing is a unified method of using I'm not present information to stop timers and screen updates instead of logging out. For embedded you have control over timers and screen updates, but my guess is that maemo has their own solution and OLPC has another one and multiuser yet another. For desktop and laptop PCs you can invoke the kernel's power management to save the state of the entire machine (rather than the session), but this doesn't work for multiuser. Also doing more work (saving state, shutting down applications) just to do more work later (restarting the apps, restoring state) might not be the brightest idea unless you know the extra memory would be better spent elsewhere (but where? nothing should be happening when the user isn't looking.) Yes. That's why I was considering a way of avoiding logout and yet avoid consuming resources when the user isn't present. But now that I look at it, when the screen is blank and I have terminal, evolution and a few other apps running, only at-spi-registryd and mixer_applet2 appear hot enough to be worth bothering about. Memory usage while idle is a more significant issue. In multiuser its obvious where the extra memory would be used. In embedded its more a matter of reducing power consumption by avoiding cache misses to flash or disk. But if the kernel is doing it's job, memory from idle user processes should be paged out, so I think we're better off attacking that problem by reducing general bloat rather than introducing page/swap complexity into the session manager. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: The future of session management in GNOME
Ray Strode wrote: * XSMP does a number of useful session-managey things (logout notification, logout cancellation, specifying apps that should be restarted right away if they crash, specifying commands to run at logout, etc) which we currently have no other way of doing, so we'd be forced to reinvent half of XSMP if we ditched it. So at this point I'm sort of of the opinion that logout cancellation isn't really useful. Then you'd need to decide whether application state and overwrite all open documents, or throw everything away or somehow allow the user to individually decide (by cancelling logout!) An alternative would be to save a snapshot of current state and current open documents into a versioning filesystem and offer the user a choice of which state to restore upon login. Until versioning filesystems become more common, this would be complicated and I'm not sure there is a clear way to present the snapshot restore options on login. Maybe something like OSX's time machine. I've been thinking about a few other things which may fit into the future of session management. Why do we ever log out? 1) For security (A good screensaver will give you this.) 2) To switch users (Sun Ray does this, but couldn't gdm also eventually provide fast user switching without logout?) 3) Reset application environment states (Improvements to the session management GUI could reduce the need for logout here) 4) Free up resources. ??? Reason 4 is especially interesting for multiuser systems, especially thin clients. It might be interesting for embedded uses of GNOME (laptop/child, maemo...) to reduce resources when user isn't looking. Currently, when I pull my card out, it appears that I'm logged out, but the GNOME applications, applets, anything with dynamic content is refreshing, polling, consuming CPU, memory and network bandwidth even though the session is no longer attached to a keyboard and monitor. Would it be possible to: Have session manager tell (galago?) I'm not here when user selects logout/switch user or a session card is removed. Have embedded and other devs detect I'm not here from keyboard timeout, suspend switch, closed lid... Use this presence information to tell applications/applets with dynamic content and UI polling to hibernate for a while. Make sure screen saver and session manager (and a user selectable set of applications) are immune to this hibernate signal. It's just an idea. Just let me know if it's cracked or if it sparks off a better idea. I like the fact that I never have to log out and it takes 0.5 seconds to get back to work in the morning. And I love the fact that I can take my session home with me and continue work there in 0.5 seconds. Is the eternal portable gnome session paradigm workable? So I'm volunteering to do all of this: * Write up a more detailed proposal than the above * Propose extensions to fdo autostart spec, and a spec covering the XSMP extensions and clarifications. (Hopefully the XSMP stuff could also go into the autostart spec.) * Finish/rewrite msm, add a migration path from gnome-session, propose for 2.18 (or maybe 2.20) * Reimplement GnomeClient as GtkClient, propose for gtk 2.something. awesome. Does this make sense or does someone want to put forth a stronger argument for killing XSMP? I don't have a strong argument against it, but I don't see what it really buys us. Apps either don't support it, or support it very minimally. I wouldn't say it's that well understood, either. It's pretty ambiguous in places. Having said that, I would love to see some improvements on this front, and I'm sure you'll come up with something reasonable. What (I think) XSMP does buy us is some session restore compatibility with applications from KDE, CDE and other desktops. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: downstream bugs [was Re: GnomeClient replacement?]
Luis Villa wrote: On 7/19/06, Dan Winship [EMAIL PROTECTED] wrote: Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So now that we've got XML-RPC support in bugzilla, it would be insanely cool if someone could write interfaces and code to let you do cross-bugzilla refiling / mark as duplicate / mark as depending on or blocking. (Including cross-bugzilla notifications of relevant changes.) So like, someone files a bug against the panel on SLED, we figure out that it's an upstream bug, but we still want to track it, because it's still a bug against our product too, and it's affecting a customer. So we click a little refile this upstream and mark the local bug as depending on the upstream one button, which does just that. Then if we investigate further, we can add comments upstream, or if someone else fixes it and closes the bug upstream, we'd get a notification of that, and can apply the fix and close our bug. I strongly believe developing and maintaining such tools would be a very worthwhile investment for the various distros- it would reduce the duplication of QA by all parties (which is pretty brutal overhead right now), increase the speed that fixes get to users (again, a win for all parties), so on, so forth. I'd even be willing to argue that this is something a paid bugmaster should do, or at least help the distros' QA teams with. Obviously not going to be me at this point, but something I think the board and advisory board should keep in mind. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list I really like this idea. We (Sun) had a process for upstreaming bugs but when GNOME head moved away from the center of gravity of our user base we didn't find it very useful. Now that we're developing closer to head again, we're encouraging non-distro specific bugs to be manually upstreamed. This isn't an easy sell because most QA and customer support people are familiar with one tool and one process. If GNOME was the only component in our distribution I'd push to drop our internal bug tools entirely and use b.g.o but it isn't. So I'd like to push internally for improving our process for mapping QA bug content to and from bugzilla, tools and a good process for managing bugs generated by users of legacy GNOME releases would certainly help make the case. What, besides bugzilla's XML-RPC support, do we need in order to make this work well? Off the top of my head: A cross-platform automated crash logger: - gathers corefile and symbols when possible - modular so that lsof, dtrace and stacktrace fingerprinting can be enabled. (Would it be useful if, when an infrequent bug happened in a component the logger could automatically load some more detailed tracing modules so that if it happens again we get a better trace?) A crash/bug/rfe GUI which allows opt-in/opt-out to avoid privacy law violations. An I hate this/I love this key which brings up the GUI and passes it information about the currently focused widget (or just a screenshot?) A crash/bug/rfe fingerprinter. - Gathers gnome release version, component versions, distribution and whatever else makes this crash/bug/rfe unique. - When passed a crash/bug/rfe object attempts to match the stack trace or bug description with known b.g.o bugs. A patch-bug mapper - O.K. maybe this is blue-sky stuff, but one of my pet peeves is when bugs are marked as fixed without any indication in the bug as to where the patch is, what version the patch applies to... I'd like to see a two way mapping between every fixed bug and the source patch that fixed it. I understand that this is often impossible when one patch fixes many bugs or several patches fix one bug and some of the patches only apply to patched distribution specific code... but wouldn't it be cool to always tag the bits of code responsible for fixing each bug/rfe with something that can be linked to and viewed from within the bug report? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
Shaun McCance wrote: On Thu, 2006-07-20 at 13:52 -0500, Shaun McCance wrote: Yikes, all right. We should definitely keep the exec_ats key for legacy. I suppose the Assistive Technology Preferences dialog should continue to set the old values, if possible, to keep older machines functioning the same. I'm not sure what keys are used by the Preferred Applications dialog. The keys under /desktop/gnome/applications seem to be obsolete. We could just make six keys: a boolean to enable each technology, and an exec string for each technology. Then there's the question of the interface. Would we want to shunt stuff off to the Preferred Applications dialog? I think it will be more obvious if it's right in the Assistive Technology Preferences dialog. So something like I meant to say something else here, but forgot about it. What happens if I set my preferred screen reader to Orca on a fancy new machine, and then try to log into an older Gnome using the same home directory. We don't have any sort of fallback mechanism in place. This problem isn't unique to us, by the way, and it goes as far back as networked Unix itself. Changing your shell, for example, can be a real headache on a heterogeneous network with centrally-managed login information. You won't even be able to log into a machine without your selected shell. I don't necessarily have a good solution to this problem. I can think of some strategies, but none that I think are much more than a hack. I know there's been blue-sky talk of a next-generation configuration system. A general-purpose solution to problems like these would be a definite selling point for such a system. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list This is one of my biggest headaches in supporting enterprise GNOME users. Consider these use cases: 1.An ISV creates creates a custom application and wisely chooses to base this application on GNOME components which won't change between releases. He creates a launcher for this application in the main menu. The launcher stops working when GNOME is upgraded. Not a huge problem for a developer on his laptop, a major headache for a sysadmin of 5,000 desktops. 2.Someone logs into a server running GNOME 2.1X, logs out and logs into a server running GNOME 2.1.X+2 using the same NFS home directory. 3.Someone logs into a server running GNOME 2.1.X, _doesn't_ log out and logs into a server running GNOME 2.1.X+2 using the same NFS home directory. (This can be common on Sun Ray and possibly other thin client GNOMEs) Should we say that cases 1-3 won't be supported by GNOME? or... A simple but incomplete and probably slow solution (hack?) might be to put the entire home directory under CVS control or on top of a versioning filesystem and give gdm and gnome session the smarts to checkout the right branch during login. Would something like this work instead?: Move everything off the filesystem into the filesystem independent configuration database. (this includes .gaim, .evolution, .gimp,.mozilla, font stuff, desktop files... which means the configuration database shouldn't be slower than the filesystem.) The configuration system manages configuration objects which expose read/write methods based on release, key and migration rules. E.G. Key :Range:Rule default_screenreader:2.10-2.14:RW default_screenreader:2.06-2.14:R default_screenreader:2.16-2.20:M The M rule means the migrate methods would be called for releases where Read or Write are not already defined in the rules. These methods would take key, version_key and version_now. In this case, the migrate read method would decide that if default_screenreader GNOME 2.12 key value is gnopernicus, and the client is version 2.16, it returns orca. Yeah, I know this idea is only 25% baked, but could it be refined into something which would improve the user experience? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus!
Do we know what level of accessibility is possible within the current mono framework? Do we know what level of accessibility is likely (e.g. with C# apps ported from other platforms?) Bill Haneman wrote: Federico said: Big tangent: the GNOME Certification plan will help in defining what is a good GNOME application and what isn't. That certification will include things like consistent lookfeel [insert a lot of handwaving about how to quantify this...] /me points to Gnome Accessibility Guide For Developers, http://developer.gnome.org/projects/gap/guide/gad , and Testing Gnome Applications for Accessibility: http://developer.gnome.org/projects/gap/testing/index.html Bill Federico -- Message: 5 Date: Wed, 19 Jul 2006 01:07:57 +0200 From: Philip Van Hoof [EMAIL PROTECTED] Subject: Re: [Evolution-hackers] Memory consumption and virtual machines To: desktop-devel-list@gnome.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On Tue, 2006-07-18 at 16:05 -0500, Federico Mena Quintero wrote: On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote: I've been talking to Philip on IRC, and gave him these requirements for his patch: 1. Don't change the external ABI of Camel, so that Evo needs no changes, *OR* also submit a patch to update Evo for the changed API. Achieved 2. Make sure the summary format on disk works with older Evos without making *them* rewrite the summaries. This is for deployments which have machines with old and new versions of GNOME, but NFS homedirs accessible from any machine. Achieved my renaming all the summary filenames 3. Keep the coding style, variable naming convention, indentation, etc. Done For you, attached and on a plate: o. The patch for evolution-data-server o. The patch for evolution-exchange Trying to get this upstream is, for me, saying thank you. Looking at the patch technically AND testing it (and if it doesn't perform, giving me numbers that compare it with the original implement- ation) is all I'm asking for. If Novell wants me to implement unit tests (or other tests) for this, I will ask for payment. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be -- next part -- A non-text attachment was scrubbed... Name: evolution_data_server__mmap_summary.diff.gz Type: application/x-gzip Size: 14012 bytes Desc: not available Url : /archives/desktop-devel-list/attachments/20060719/9407295b/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: evolution_exchange__mmap_summary.diff.gz Type: application/x-gzip Size: 871 bytes Desc: not available Url : /archives/desktop-devel-list/attachments/20060719/9407295b/attachment-0001.bin -- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list End of desktop-devel-list Digest, Vol 27, Issue 65 ** ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
