Re: RFC: hiding the new timezone feature in the clock applet for 2.20
Le lundi 20 août 2007, à 13:02 -0400, Ray Strode a écrit : > Hi, > > Since I didn't have time to fix a few things for the clock applet for > > 2.20, and I don't think anybody did it either, I think this feature is > > not ready to be used by all our users for 2.20: the UI is clearly far > > from being optimal, and it's also a bit slow for reasons I've not > > investigated. > > > > I'd like to remove the UI bits from the clock pref dialog that let the > > user enable this feature. People could still enable it via a gconf key, > > though. > > Seems reasonable enough. After that, maybe we can get Novell's > prettier map/clock graphics integrated into it? It might make sense, yes. I would have loved to know about Novell's version before I rewrote the entire patch that was sitting in bugzilla for quite some time to make it sane. This was a significant work. I learnt about Novell's version too late and I wouldn't say it was a nice surprise for me. May I request that such changes made for a distribution are at least made known to upstream? (and this is not just about Novell, really) Thanks, 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 Showstopper Review.
Le vendredi 24 août 2007, à 13:27 +0200, Andre Klapper a écrit : > > GNOME-PANEL > > http://bugzilla.gnome.org/show_bug.cgi?id=446183 > => crash in gtk_rc_reset_styles() > 170 dups total, 92 in the last 30 days. > (Perhaps Fedora specific.) If anybody can reproduce this, please provide > the relevant selinux log for vuntz, and the value of the > gconf /desktop/gnome/font_rendering. Help appreciated. FWIW, I've noticed similar stack traces on other distro than Fedora, so it might not be Fedora-specific in the end. There were some duplicates in 2.19, but not that much, and I didn't have time to look at the latest bug reports. Maybe it doesn't anymore (could have been a memory corruption that has been fixed in our stack). Anyway, it's really unfixable if no developer can reproduce it. 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: Requesting UI freeze break for Deskbar-Applet
Hi, Sorry for the late reply. Le vendredi 24 août 2007, à 17:50 +0200, Sebastian Pölsterl a écrit : > Hi! > > The attached patch adds a "Back to matches" button under the list of > actions (see attachment) and makes the '>' beneath matches that have > more than one action clickable to go the list of actions. This replaces > that you have to press ctrl while clicking on a match to display its > actions. > > Raphaël knows about this patch, too, and is all for it. > > This patch tackles bug #468455 and bug #468456. > > The patch is important, because it helps a lot to navigate. Without it, > navigating between the list of actions and the list of matches would > only be possible using the keyboard. Navigating using the keyboard is > somewhat a hidden feature and everything you could achieve with the > keyboard should be possible with the mouse, too. > If the patch won't be part of the final 2.20 release many users > obviously won't recognize the new feature of actions, because they won't > intuitionally find the way to the list actions. Actions are a core > feature of the new Deskbar-Applet. Therefore, I think this patch should > be applied. Approval one out of two from me. Deskbar has no complete documentation, so it should be okay from this point of view. And it seems really important to me. 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: Requesting UI freeze break for Deskbar-Applet
Le lundi 27 août 2007 à 13:33 +0200, Vincent Untz a écrit : > Hi, > > Sorry for the late reply. > > Le vendredi 24 août 2007, à 17:50 +0200, Sebastian Pölsterl a écrit : > > Hi! > > > > The attached patch adds a "Back to matches" button under the list of > > actions (see attachment) and makes the '>' beneath matches that have > > more than one action clickable to go the list of actions. This replaces > > that you have to press ctrl while clicking on a match to display its > > actions. > > > > Raphaël knows about this patch, too, and is all for it. > > > > This patch tackles bug #468455 and bug #468456. > > > > The patch is important, because it helps a lot to navigate. Without it, > > navigating between the list of actions and the list of matches would > > only be possible using the keyboard. Navigating using the keyboard is > > somewhat a hidden feature and everything you could achieve with the > > keyboard should be possible with the mouse, too. > > If the patch won't be part of the final 2.20 release many users > > obviously won't recognize the new feature of actions, because they won't > > intuitionally find the way to the list actions. Actions are a core > > feature of the new Deskbar-Applet. Therefore, I think this patch should > > be applied. > > Approval one out of two from me. Deskbar has no complete documentation, > so it should be okay from this point of view. And it seems really > important to me. Approval 2 of 2 from release team. -- Frederic Crozat <[EMAIL PROTECTED]> Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Full screen GtkDrawingArea performance sucking - help me!
Alex Jones wrote: > Hi list > > In my quest to write an awesome backdrop rendering app, I have this test > program that draws random colours to a GtkDrawingArea. For me, any size > over about 300x300 at 60fps just causes insane lag in Xorg -- the > renderings seem to queue up. If I run cairo clock maximised full screen, > it literally LAGS by about 5 seconds. Telling it to close takes ages, as > if the X connection is completely saturated. My own cairo clock which > draws the second hand smoothly between intervals shows that it seems to > run at less-than-real-time, but still smoothly. Eventually, the clock > skips ahead by 10 seconds or so. > > I have a 2.8 GHz Pentium 4 with 1 GB of RAM, nothing using my CPU and a > Radeon 9800 Pro with the r200 drivers. What's going on? This is a total > spanner-in-the-works for me. > Please open $YOUR_FAVORITE_PROFILER and provide some proof that your issues are related to GTK+. Regards, Sven ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Keyboard Indicator Applet... where are you?
Alex, > Ah. What kind of a name is that, anyway? Sounds like GJim'llFixIt! This is historical name (I maintained an independent project before joined gnome). And it is kept just because moving things into different directory would make browsing the history difficult. But other than source directory name, that gjimllfixit is not visible anywhere in UI (at least it should not, otherwise it is a UI bug). Also, there is project gswitchit_plugins which uses the same historical name. Cheers, Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Full screen GtkDrawingArea performance sucking - help me!
On Mon, 2007-08-27 at 14:47 +0200, Sven Herzberg wrote: > Alex Jones wrote: > > Hi list > > > > In my quest to write an awesome backdrop rendering app, I have this test > > program that draws random colours to a GtkDrawingArea. For me, any size > > over about 300x300 at 60fps just causes insane lag in Xorg -- the > > renderings seem to queue up. If I run cairo clock maximised full screen, > > it literally LAGS by about 5 seconds. Telling it to close takes ages, as > > if the X connection is completely saturated. My own cairo clock which > > draws the second hand smoothly between intervals shows that it seems to > > run at less-than-real-time, but still smoothly. Eventually, the clock > > skips ahead by 10 seconds or so. > > > > I have a 2.8 GHz Pentium 4 with 1 GB of RAM, nothing using my CPU and a > > Radeon 9800 Pro with the r200 drivers. What's going on? This is a total > > spanner-in-the-works for me. > > > > Please open $YOUR_FAVORITE_PROFILER and provide some proof that your > issues are related to GTK+. I don't have a favourite profiler. Suggest me one! (And show me how to use it :P) I believe it's something wrong with either GTK, Cairo or XRender because it's apparent that the expose event handler is running in good time, but the XRender operations are just queueing up like mad on the server until it spills over and discards a load of them. I don't think a clock should render like this. Finding the perfect framerate thus becomes a case of finding a magic number for a specific system in a specific condition, unless I'm missing something. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome_segv2 replacement in GNOME 2.20?
Hi, Apology for this wide spread email :) I have just found out that gnome_segv2 has been removed by 2007-07-27 Fernando Herrera <[EMAIL PROTECTED]> Reading bug http://bugzilla.gnome.org/show_bug.cgi?id=388441 indicating that there is a replacement coming in the form of libgnomeairbags.so loaded in gnome-session. I couldn't find libgnomeairbags in the gnome svn. Do we know that his feature is coming into GNOME 2.20? Thanks, -Ghee ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Full screen GtkDrawingArea performance sucking - help me!
On Seg, 2007-08-27 at 15:52 +0100, Alex Jones wrote: > I don't have a favourite profiler. Suggest me one! (And show me how to > use it :P) http://www.daimi.au.dk/~sandmann/sysprof/ Quite easy to use. Be sure to have all relevant packages' debug symbols installed and run it as root (at least on fedora you need to for it to read the X server binary). Rui 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_segv2 replacement in GNOME 2.20?
Le lundi 27 août 2007 à 16:47 +0100, Ghee Teo a écrit : > Hi, > > Apology for this wide spread email :) > I have just found out that gnome_segv2 has been removed by > 2007-07-27 Fernando Herrera <[EMAIL PROTECTED]> > > Reading bug http://bugzilla.gnome.org/show_bug.cgi?id=388441 > indicating that there is a replacement coming in the form of > libgnomeairbags.so loaded in gnome-session. I couldn't find > libgnomeairbags in the gnome svn. > > Do we know that his feature is coming into GNOME 2.20? It is already there with latest bug-buddy :) -- Frederic Crozat <[EMAIL PROTECTED]> Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Full screen GtkDrawingArea performance sucking - help me!
On Mon, 2007-08-27 at 15:52 +0100, Alex Jones wrote: > > Please open $YOUR_FAVORITE_PROFILER and provide some proof that your > > issues are related to GTK+. > > I don't have a favourite profiler. Suggest me one! (And show me how to > use it :P) oprofile (part of the stock kernel on most distros) and the GTK+ interface OProfileUI (http://projects.o-hand.com/oprofileui) work pretty damn well for me. You'll need -dbg packages unless you've built everything relevant from source. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF 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: Full screen GtkDrawingArea performance sucking - help me!
On Mon, 2007-08-27 at 03:49 +0100, Alex Jones wrote: > Hi list > > In my quest to write an awesome backdrop rendering app, I have this test > program that draws random colours to a GtkDrawingArea. For me, any size > over about 300x300 at 60fps just causes insane lag in Xorg -- the > renderings seem to queue up. If I run cairo clock maximised full screen, > it literally LAGS by about 5 seconds. Telling it to close takes ages, as > if the X connection is completely saturated. My own cairo clock which > draws the second hand smoothly between intervals shows that it seems to > run at less-than-real-time, but still smoothly. Eventually, the clock > skips ahead by 10 seconds or so. FWIW I experienced the same slowness in full-screen mode at our (Carl and I) GUADEC talk. Profiling showed most of the time spent in xorg, as expected. I imagine massive pixmap migration happening... Carl may know more. behdad > I have a 2.8 GHz Pentium 4 with 1 GB of RAM, nothing using my CPU and a > Radeon 9800 Pro with the r200 drivers. What's going on? This is a total > spanner-in-the-works for me. > > Cheers > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Full screen GtkDrawingArea performance sucking - help me!
The problem is that the expose handler gets called again before the XRender operations from the previous exposes have finished. Hence, XRender operations just queue up behind each other at a certain level of utilisation. It's the queueing that manifests itself as "lag". As a workaround, you can block the expose handler until the drawing is actually done, but that's not very nice if you have other things to service in the same thread like audio etc. I think a proper solution would be to have GTK/GDK queue up the drawing requests while X hasn't finished working on the drawable. Does anyone have any better suggestions? If not, how can we do this? On Mon, 2007-08-27 at 15:29 -0400, Behdad Esfahbod wrote: > On Mon, 2007-08-27 at 03:49 +0100, Alex Jones wrote: > > Hi list > > > > In my quest to write an awesome backdrop rendering app, I have this test > > program that draws random colours to a GtkDrawingArea. For me, any size > > over about 300x300 at 60fps just causes insane lag in Xorg -- the > > renderings seem to queue up. If I run cairo clock maximised full screen, > > it literally LAGS by about 5 seconds. Telling it to close takes ages, as > > if the X connection is completely saturated. My own cairo clock which > > draws the second hand smoothly between intervals shows that it seems to > > run at less-than-real-time, but still smoothly. Eventually, the clock > > skips ahead by 10 seconds or so. > > FWIW I experienced the same slowness in full-screen mode at our (Carl > and I) GUADEC talk. Profiling showed most of the time spent in xorg, as > expected. I imagine massive pixmap migration happening... Carl may know > more. > > > behdad > > > I have a 2.8 GHz Pentium 4 with 1 GB of RAM, nothing using my CPU and a > > Radeon 9800 Pro with the r200 drivers. What's going on? This is a total > > spanner-in-the-works for me. > > > > Cheers > > > > ___ > > 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: Full screen GtkDrawingArea performance sucking - help me!
On Mon, 2007-08-27 at 20:58 +0100, Alex Jones wrote: > The problem is that the expose handler gets called again before the > XRender operations from the previous exposes have finished. Hence, > XRender operations just queue up behind each other at a certain level > of utilisation. It's the queueing that manifests itself as "lag". As a > workaround, you can block the expose handler until the drawing is > actually done, but that's not very nice if you have other things to > service in the same thread like audio etc. Isn't that just an after-effect of the drawing being too slow? Sure you can gdk_display_sync() to not accumulate updates on the server. -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Requesting UI Freeze break for gnome-panel and gnome-utils
Hi, The gnome-searchtool icon got removed from gnome-icon-theme because it got replaced by the system-search icon. I've made patches for gnome-searchtool and gnome-panel to use the new icon. http://bugzilla.gnome.org/show_bug.cgi?id=470194 gnome-panel http://bugzilla.gnome.org/show_bug.cgi?id=470196 gnome-searchtool Can I apply the two patches? Thanks Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requesting UI Freeze break for gnome-panel and gnome-utils
On Mon, 2007-08-27 at 23:09 +0200, Jaap Haitsma wrote: > Hi, > > The gnome-searchtool icon got removed from gnome-icon-theme because it > got replaced by the system-search icon. > > I've made patches for gnome-searchtool and gnome-panel to use the new icon. > > http://bugzilla.gnome.org/show_bug.cgi?id=470194 gnome-panel > http://bugzilla.gnome.org/show_bug.cgi?id=470196 gnome-searchtool for gnome-searchtool, I don't have any problem applying the patch - but the maintainer is Dennis Cranston (Cc:-ed, in case he missed d-d-l). > Can I apply the two patches? on a related note: there is an existing patch[1] for replacing the icon of gnome-dictionary with the one provided by g-i-t - which would remove the abomination I concocted with inkscape. hence, I'm requesting a break for applying that patch as well. ciao, Emmanuele. +++ [1] http://bugzilla.gnome.org/show_bug.cgi?id=470287 -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requesting UI Freeze break for gnome-panel and gnome-utils
Le lundi 27 août 2007, à 23:09 +0200, Jaap Haitsma a écrit : > Hi, > > The gnome-searchtool icon got removed from gnome-icon-theme because it > got replaced by the system-search icon. > > I've made patches for gnome-searchtool and gnome-panel to use the new icon. > > http://bugzilla.gnome.org/show_bug.cgi?id=470194 gnome-panel > http://bugzilla.gnome.org/show_bug.cgi?id=470196 gnome-searchtool > > Can I apply the two patches? Adding gnome-doc-list and release-team to CC. You get one approval from me if documentation people are fine with this change. 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: Requesting UI Freeze break for gnome-panel and gnome-utils
Le lundi 27 août 2007, à 22:27 +0100, Emmanuele Bassi a écrit : > on a related note: there is an existing patch[1] for replacing the icon > of gnome-dictionary with the one provided by g-i-t - which would remove > the abomination I concocted with inkscape. hence, I'm requesting a break > for applying that patch as well. cc'ing gnome-doc-list :-) 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: Requesting UI Freeze break for gnome-panel and gnome-utils
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jaap Haitsma schrieb: > Hi, > > The gnome-searchtool icon got removed from gnome-icon-theme because it > got replaced by the system-search icon. > Good to know. Deskbar-Applet uses the icon as well. So the icon should get replaced there, too. - -- Greetings, Sebastian Pölsterl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG01Le1ygZeJ3lLIcRAi+aAJ44o5VH5GptyvLOCgz6WFBLASKp3QCfRune Z+BMr5w6vKTrcSTEaKF0BaQ= =hfcS -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requesting UI Freeze break for gnome-panel and gnome-utils
NOTE: I am not on the release team. My approval does not count towards the necessary two release team approvals. But it does count towards any release team approval which is contingent on documentation team approval. On Mon, 2007-08-27 at 23:39 +0200, Vincent Untz wrote: > Le lundi 27 août 2007, à 23:09 +0200, Jaap Haitsma a écrit : > > Hi, > > > > The gnome-searchtool icon got removed from gnome-icon-theme because it > > got replaced by the system-search icon. > > > > I've made patches for gnome-searchtool and gnome-panel to use the new icon. > > > > http://bugzilla.gnome.org/show_bug.cgi?id=470194 gnome-panel > > http://bugzilla.gnome.org/show_bug.cgi?id=470196 gnome-searchtool > > > > Can I apply the two patches? > > Adding gnome-doc-list and release-team to CC. > > You get one approval from me if documentation people are fine with this > change. Clearly, something has to be done. I suppose our options are: 1) Just make the icon change 2) Put the old icons back somewhere For the curious, here's the old and new icons: http://svn.gnome.org/svn/gnome-icon-theme/branches/gnome-2-18/48x48/apps/gnome-searchtool.png http://svn.gnome.org/svn/gnome-icon-theme/trunk/32x32/actions/system-search.png Let's just suck it up and make the change. On Mon, 2007-08-27 at 23:39 +0200, Vincent Untz wrote: > Le lundi 27 août 2007, à 22:27 +0100, Emmanuele Bassi a écrit : > > on a related note: there is an existing patch[1] for replacing the icon > > of gnome-dictionary with the one provided by g-i-t - which would remove > > the abomination I concocted with inkscape. hence, I'm requesting a break > > for applying that patch as well. > > cc'ing gnome-doc-list :-) Old and new again: http://svn.gnome.org/svn/gnome-utils/trunk/gnome-dictionary/data/gnome-dictionary.png http://svn.gnome.org/svn/gnome-icon-theme/trunk/32x32/apps/accessories-dictionary.png This change is less critical. The documentation hasn't been updated in 17 months. We wouldn't be wasting any new effort, although we would be further invalidating whatever documentation exists. The icon does appear in each of the figures, but always in a screenshot of the already-running application, either in the titlebar or next to the applet. I tend to worry more about icon changes where the user is being directed to look for something, and that something isn't there. Given: 1) The potential for user confusion is probably very low, and 2) It's not all that likely the documentation would have stood a better chance of being updated had the change been made earlier I say we make the change. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RFC: hiding the new timezone feature in the clock applet for 2.20
On 8/27/07, Vincent Untz <[EMAIL PROTECTED]> wrote: > > I would have loved to know about Novell's version before I rewrote > the entire patch that was sitting in bugzilla for quite some time to > make it sane. This was a significant work. I learnt about Novell's > version too late and I wouldn't say it was a nice surprise for me. > > May I request that such changes made for a distribution are at least > made known to upstream? > > (and this is not just about Novell, really) > To play with open cards here, we (Red Hat) are working on PolicyKit support for timezone changes to the Novell intlclock. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requesting UI Freeze break for gnome-panel and gnome-utils
On 8/27/07, Shaun McCance <[EMAIL PROTECTED]> wrote: > On Mon, 2007-08-27 at 23:39 +0200, Vincent Untz wrote: > > Le lundi 27 août 2007, à 23:09 +0200, Jaap Haitsma a écrit : > > > Hi, > > > > > > The gnome-searchtool icon got removed from gnome-icon-theme because it > > > got replaced by the system-search icon. > > > > > > I've made patches for gnome-searchtool and gnome-panel to use the new > > > icon. > > > > > > http://bugzilla.gnome.org/show_bug.cgi?id=470194 gnome-panel > > > http://bugzilla.gnome.org/show_bug.cgi?id=470196 gnome-searchtool > > > > > > Can I apply the two patches? > Clearly, something has to be done. I suppose our options are: > > 1) Just make the icon change > 2) Put the old icons back somewhere > I say we make the change. Due to Shaun being behind it and his reasoning, here's another approval to go with Vincent's to give you 2 of 2 approvals. Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
