From otaylor at redhat.com Fri Jun 1 01:15:01 2007 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 31 May 2007 21:15:01 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: References: <1180639616.9513.4.camel@localhost.localdomain> Message-ID: <1180660501.26450.49.camel@fresnel.dumbhippo.com> [ Cc: and Reply-To: fedora-desktop-list ] On Thu, 2007-05-31 at 19:57 +0000, Kevin Kofler wrote: > Matthias Clasen redhat.com> writes: > > So the two of you simply decided that it would be better for everybody > > if the menu item changed from the (somewhat cryptic, but informative) > > "IRC" to the totally meaningless "X-Chat" ? > > X-Chat has a meaning, it's the particular IRC client called X-Chat. There's > several IRC clients in Fedora, including one called xchat-gnome which several > people think should be the default (in fact, I'd LOVE for it to become the > default, not because I actually use it, in fact I hate it, but because that > could lead you to leave the regular X-Chat alone!), so "IRC" is very vague as a > menu entry. > > And KDE actually displays "X-Chat (IRC client)" if the user preferences are set > that way. Why does GNOME _still_ not support GenericName years after this > specification has been supposedly agreed on? IMHO, the real technical problem > lies there, mangling .desktop files like this is just papering over the > problem. I'm not sure how you think that the Fedora GNOME desktop should be using GenericName. The usage of a generic instead of a specific name in the Fedora menus is done for a small subset of applications: those considered to be "best of breed". Using a generic for everything would produce menus that looked like: IRC client IRC client Web Browser Web Browser Font editor Now, using a generic for *anything* is really a hold-over from a past era when our vision of the Fedora menus was that we'd select a small set of best-of-breed apps for our users, instead of making them deal with the chaos of the entire set of possible applications. This no longer fits with the Fedora philosophy, especially considering the merge of core and extras. The question is more "how to manage the chaos". Ideas that some of us have been working on for managing the chaos: - Collect statistics for the top applications in real use http://mugshot.org/applications - Concentrate on making it easy for the user to launch the applications they use most http://developer.mugshot.org/wiki/Image:Big_Board_and_Application_Browser.png - Bring together the installed applications and the available applications http://developer.mugshot.org/wiki/Image:Big_Board_Application_Browser_-_All_Internet.png Those mockups are a bit stale ... the real thing is better. (bigboard package in extras, but you might want to wait until tomorrow ... Colin has some neat stuff in the pipeline for setting everything up for online-desktop mode.) But you can see, sort of in the mockups, and more in the real thing, what we are using for applications is: X-Chat IRC Client With a tooltip of "Chat with your friends". (We get this from a merge of desktop files with the online Mugshot application database; neither GNOME nor KDE desktop files have all three of the above. GNOME desktop files miss the GenericName, KDE desktop files miss the tooltip.) OK, back to the present: My advise for the X-Chat is to make it match how we do a lot of other .desktop files now: do "X-Chat IRC Client" like "Firefox Web Browser" and so forth. Yes, that will screw over the KDE user who has chosen the Name (Generic Name) preference, but they already have Firefox Web Browser (Web Browser), so they can deal. Maybe we need X-Fedora-Name:, on the other hand, if we manage to make bigboard work, we don't need Fedora-customized menus at all, so we can (eventually, not right now, please), just use Name: X-Chat and get rid of having to munge desktop files as compared to upstream. - Owen From rdieter at math.unl.edu Fri Jun 1 04:35:07 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 31 May 2007 23:35:07 -0500 Subject: Meaningless name In-Reply-To: <1180660501.26450.49.camel@fresnel.dumbhippo.com> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> Message-ID: Owen Taylor wrote: > OK, back to the present: My advise for the X-Chat is to make it match how we > do a lot of other .desktop files now: do "X-Chat IRC Client" like "Firefox Web Browser" > and so forth. > > Yes, that will screw over the KDE user who has chosen the Name (Generic Name) > preference No screwing involved, if one chooses Name=X-Chat IRC Client then use (blank) GenericName= -- Rex From stuart at terminus.co.uk Fri Jun 1 10:02:11 2007 From: stuart at terminus.co.uk (Stuart Children) Date: Fri, 1 Jun 2007 11:02:11 +0100 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180660501.26450.49.camel@fresnel.dumbhippo.com> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> Message-ID: <20070601100211.GA9361@urchin.earth.li> For the benefit of those not subscribed, I previously emailed fedora-devel regarding this thread: https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00000.html On Thu, May 31, 2007 at 09:15:01PM -0400, Owen Taylor wrote: > Now, using a generic for *anything* is really a hold-over from a past era when > our vision of the Fedora menus was that we'd select a small set of best-of-breed apps > for our users, instead of making them deal with the chaos of the entire set of > possible applications. > > This no longer fits with the Fedora philosophy, especially considering the merge > of core and extras. The question is more "how to manage the chaos". I agree that only displaying generic names (regardless of what .desktop properties that string is derived from) isn't very helpful - certainly as you say given how Fedora now works. > Ideas that some of us have been working on for managing the chaos: > > - Collect statistics for the top applications in real use > http://mugshot.org/applications > > - Concentrate on making it easy for the user to launch the applications > they use most > http://developer.mugshot.org/wiki/Image:Big_Board_and_Application_Browser.png > > - Bring together the installed applications and the available applications > http://developer.mugshot.org/wiki/Image:Big_Board_Application_Browser_-_All_Internet.png > > Those mockups are a bit stale ... the real thing is better. (bigboard package in > extras, but you might want to wait until tomorrow ... Colin has some neat stuff > in the pipeline for setting everything up for online-desktop mode.) These look good. I'll definitely keep an eye on bigboard. > But you > can see, sort of in the mockups, and more in the real thing, what we are using for > applications is: > > X-Chat > IRC Client > > With a tooltip of "Chat with your friends". > > (We get this from a merge of desktop files with the online Mugshot application > database; neither GNOME nor KDE desktop files have all three of the above. > GNOME desktop files miss the GenericName, KDE desktop files miss the tooltip.) Yep, makes sense. So focusing purely on where we (GNOME and Fedora) want to go, rather than how to resolve the specifics of the X-Chat case right now... it would appear that we do intend to change desktop files to have Name and GenericName specific as in the fdo spec (values "X-Chat" and "IRC Client" in our example here). So the key question is, will bigboard replace the current gnome-panel's application menu? It would *seem* so, but it's not entirely clear. My reason for asking: is it worth my time going to hack on gnome-menus (though maybe the library changes there are required anyway - will have to see what bigboard's using to read desktop entries) and gnome-panel? The other consideration there would be the timeline for integration of bigboard into a GNOME/Fedora release. If there isn't currently one that's fine, I just want to differentiate that from me know being able to find it. :) The changes I was thinking of to gnome-panel could be done easily enough, would allow people to start "fixing" the desktop files right away, and prevent upsets about name display until bigboard is available. But maybe my efforts are better spent on bigboard? Many thanks -- Stuart Children http://terminus.co.uk/ From otaylor at redhat.com Fri Jun 1 10:58:38 2007 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 01 Jun 2007 06:58:38 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <20070601100211.GA9361@urchin.earth.li> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> Message-ID: <1180695518.13136.246.camel@huygens.home.fishsoup.net> On Fri, 2007-06-01 at 11:02 +0100, Stuart Children wrote: [...] > > But you > > can see, sort of in the mockups, and more in the real thing, what we are using for > > applications is: > > > > X-Chat > > IRC Client > > > > With a tooltip of "Chat with your friends". > > > > (We get this from a merge of desktop files with the online Mugshot application > > database; neither GNOME nor KDE desktop files have all three of the above. > > GNOME desktop files miss the GenericName, KDE desktop files miss the tooltip.) > > Yep, makes sense. So focusing purely on where we (GNOME and Fedora) want > to go, rather than how to resolve the specifics of the X-Chat case right > now... it would appear that we do intend to change desktop files to have > Name and GenericName specific as in the fdo spec (values "X-Chat" and > "IRC Client" in our example here). > > So the key question is, will bigboard replace the current gnome-panel's > application menu? It would *seem* so, but it's not entirely clear. My > reason for asking: is it worth my time going to hack on gnome-menus > (though maybe the library changes there are required anyway - will have > to see what bigboard's using to read desktop entries) and gnome-panel? In "online-desktop" mode. the applications section of bigboard replaces the menu. You have one or the other. > The other consideration there would be the timeline for integration of > bigboard into a GNOME/Fedora release. If there isn't currently one > that's fine, I just want to differentiate that from me know being able > to find it. :) The changes I was thinking of to gnome-panel could be > done easily enough, would allow people to start "fixing" the desktop > files right away, and prevent upsets about name display until bigboard > is available. But maybe my efforts are better spent on bigboard? The plan is definitely to have online-desktop mode there for Fedora 8. But will replace the current classic GNOME desktop as a main desktop configuration? I suspect that's more of a Fedora 9 thing than Fedora 8 thing. So for now, I think we need to maintain the menu system. Would GenericName support to gnome-menus help? I'm not quite sure I see how it that would work. While in many cases, we want the information of both name and generic name in the menus, doing a straight Name (GenericName) is going to be ugly because of all the parentheses. It also starts looking really duplicative once you get into things that are more "accessories". Thunderbird (Email) Abiword (Word Processor) GNOME Terminal (Terminal) Character Map (Character Map) Iagno (Board Game) Dropping the parentheses makes the accessories even worse "GNOME Terminal Terminal". What we'd presumably like is something like: Thunderbird Email Abiword Word Processor GNOME Terminal Character Map Iagno Maybe carefully omitting the GenericName field from the desktop files where it doesn't provide information we want in the menus would work. But is that an improvement from the current situation? - Owen From kevin.kofler at chello.at Fri Jun 1 11:32:39 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 1 Jun 2007 11:32:39 +0000 (UTC) Subject: Meaningless name (was: Re: rpms/xchat/devel ...) References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> <1180695518.13136.246.camel@huygens.home.fishsoup.net> Message-ID: Owen Taylor redhat.com> writes: > Maybe carefully omitting the GenericName field from the desktop files > where it doesn't provide information we want in the menus would work. It would. I'd argue about the Iagno case though, saying it's a board game does provide information. In KDE, there's a "board games" submenu, but 1. I don't believe GNOME has that and 2. Iagno isn't even currently in there AFAICS, that would need adding some X-KDE-* category to the list of categories (shall we start filing RFEs asking to add those categories to the desktop files where it makes sense? It wouldn't break anything for GNOME and it would make KDE look more organized). > But is that an improvement from the current situation? IMHO yes, because that would at least make 3 out of the 4 settings look right (Name only, Name and GenericName, GenericName and Name), only the "GenericName only" setting would look bad (it would use Name instead). Maybe the best solution would be to have a boolean which says whether the GenericName is useful in the presence of Name or only as a replacement for Name, but supporting that needs patching in both KDE and GNOME. Kevin Kofler From otaylor at redhat.com Fri Jun 1 12:19:27 2007 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 01 Jun 2007 08:19:27 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> <1180695518.13136.246.camel@huygens.home.fishsoup.net> Message-ID: <1180700367.13136.275.camel@huygens.home.fishsoup.net> On Fri, 2007-06-01 at 11:32 +0000, Kevin Kofler wrote: > Owen Taylor redhat.com> writes: > > Maybe carefully omitting the GenericName field from the desktop files > > where it doesn't provide information we want in the menus would work. > > It would. > > I'd argue about the Iagno case though, saying it's a board game does provide > information. In KDE, there's a "board games" submenu, but 1. I don't believe > GNOME has that and 2. Iagno isn't even currently in there AFAICS, that would > need adding some X-KDE-* category to the list of categories My tendency is to think about application browsing in terms of tasks: - Find an application to fit some role - Find an application you've used before - Find an interesting application/game to waste time with I don't really think that "Board Game" adds a lot for Iagno for any of those categories. (Iagno is actually a bad example, since "Reversi" would be a pretty useful generic name, even if people are most familiar with Reversi by a different trademarked name... but most stuff in the games menu can't be usefully described in a couple of words, beyond "Game") Now, in a context where extra information can be added without breaking up the reading flow ... like the bigboard arrangement of: Iagno Board Game (With "Board Game" in a lighter color), then even minimal information is a win. But in the standard menu arrangement, I think you lose quite a bit if you make people parse "Iagno Board Game" when they are looking for "Iagno". > (shall we start > filing RFEs asking to add those categories to the desktop files where it makes > sense? It wouldn't break anything for GNOME and it would make KDE look more > organized). That's really probably best done upstream, rather than in every distribution. I suspect a RFE to add X-KDE categories to the upstream gnome-games desktop files would almost certainly be accepted. > > But is that an improvement from the current situation? > > IMHO yes, because that would at least make 3 out of the 4 settings look right > (Name only, Name and GenericName, GenericName and Name), only the "GenericName > only" setting would look bad (it would use Name instead). > > Maybe the best solution would be to have a boolean which says whether the > GenericName is useful in the presence of Name or only as a replacement for > Name, but supporting that needs patching in both KDE and GNOME. A consideration here is what best reduces the difference in translatable strings between Fedora and upstream GNOME and KDE. If we have to make changes in the Fedora desktop files of any sort, a boolean or similar certainly causes less translator problems than modifying existing fields. I don't actually have a good sense of what the upstream GNOME .desktop files look like these days. - Owen From mclasen at redhat.com Fri Jun 1 13:08:59 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 01 Jun 2007 09:08:59 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <20070601100211.GA9361@urchin.earth.li> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> Message-ID: <1180703339.3553.24.camel@dhcp83-186.boston.redhat.com> On Fri, 2007-06-01 at 11:02 +0100, Stuart Children wrote: > Yep, makes sense. So focusing purely on where we (GNOME and Fedora) want > to go, rather than how to resolve the specifics of the X-Chat case right > now... it would appear that we do intend to change desktop files to have > Name and GenericName specific as in the fdo spec (values "X-Chat" and > "IRC Client" in our example here). > > So the key question is, will bigboard replace the current gnome-panel's > application menu? It would *seem* so, but it's not entirely clear. My > reason for asking: is it worth my time going to hack on gnome-menus > (though maybe the library changes there are required anyway - will have > to see what bigboard's using to read desktop entries) and gnome-panel? > > The other consideration there would be the timeline for integration of > bigboard into a GNOME/Fedora release. If there isn't currently one > that's fine, I just want to differentiate that from me know being able > to find it. :) The changes I was thinking of to gnome-panel could be > done easily enough, would allow people to start "fixing" the desktop > files right away, and prevent upsets about name display until bigboard > is available. But maybe my efforts are better spent on bigboard? I think it is definitively worth improving gnome-menus handling of Name/GenericName. Bigboard is in rawhide right now. The way we envision this to work in the F8 timeframe is that there will be a way to switch between "classical" and "online" mode (the switching code is currently under review in the online-desktop package). I don't think that the "classical" mode is not going completely away anytime soon. From jon.nettleton at gmail.com Fri Jun 1 13:17:43 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 01 Jun 2007 09:17:43 -0400 Subject: install pam_keyring by default in the GNOME based live cd? In-Reply-To: <1180620275.2702.9.camel@zelda.fubar.dk> References: <45FDC5F7.6080808@fedoraproject.org> <1174259891.8053.6.camel@localhost.localdomain> <45FDF88B.30706@fedoraproject.org> <1174294887.2699.4.camel@averatec> <1180620275.2702.9.camel@zelda.fubar.dk> Message-ID: <1180703863.4917.17.camel@birkoff> On Thu, 2007-05-31 at 10:04 -0400, David Zeuthen wrote: > Hi Jon, > > I'm replying to an old thread; see below. Is there any chance we can get > pam-keyring in by default for Fedora 8? If yes, how about creating a > Wiki page for the feature much like the ones Matthias created for other > F8 bound features as mentioned here > > https://www.redhat.com/archives/fedora-desktop-list/2007-May/msg00167.html > > so we can track the progress and everyone can get an overview of what > work is required etc. Thanks! Top men are on it! Well, as soon as the wiki isn't deathly slow from all the downloads. I am also working on getting a Trac instance up for pam_keyring. I am hoping I will finally have the time this weekend to get everything up and ready for public consumption. Jon > > David > > On Mon, 2007-03-19 at 10:01 +0100, Jon Nettleton wrote: > > On Mon, 2007-03-19 at 08:12 +0530, Rahul Sundaram wrote: > > > Dan Williams wrote: > > > > On Mon, 2007-03-19 at 04:36 +0530, Rahul Sundaram wrote: > > > >> Hi > > > >> > > > >> "PAM_KEYRING is a pam module that launches the > > gnome-keyring-daemon and > > > >> then unlocks a keyring using your login password." > > > >> > > > >> > > http://www.hekanetworks.com/index.php/publisher/articleview/frmArticleID/25/staticId/31/ > > > > > > > > +1 > > > > > > We have two bugs open against pam_keyring now both of which are > > very > > > important to fix if we need to put this in by default. CC'ing the > > > current upstream and Fedora maintainer > > > > > > * Should have an automated way to enable - > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 > > > * Make it possible to change keyring password - > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212845 > > > > > > The first bug probably can fixed by adding rpm post installation > > > scripts. The second bug currently requiring patching gnome-keyring. > > > > Well you guys caught me at a good time. I am on vacation this week and > > one of the things I had planned was to finally push the next version of > > pam_keyring. This version will have password changing support in it and > > should close bug #212845. > > > > I also started working on mockups of system-config-authentication that > > include a tab that would detect if you had pam_keyring or pam_ssh was > > available and add check boxes to enable it at graphical login. Maybe I > > will spend and hour or two and finish that up. Does that sound like a > > good solution for bug #232857? > > > > Jon > > > From sundaram at fedoraproject.org Fri Jun 1 13:20:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 18:50:00 +0530 Subject: install pam_keyring by default in the GNOME based live cd? In-Reply-To: <1180703863.4917.17.camel@birkoff> References: <45FDC5F7.6080808@fedoraproject.org> <1174259891.8053.6.camel@localhost.localdomain> <45FDF88B.30706@fedoraproject.org> <1174294887.2699.4.camel@averatec> <1180620275.2702.9.camel@zelda.fubar.dk> <1180703863.4917.17.camel@birkoff> Message-ID: <46601D00.5070303@fedoraproject.org> Jon Nettleton wrote: > On Thu, 2007-05-31 at 10:04 -0400, David Zeuthen wrote: >> Hi Jon, >> >> I'm replying to an old thread; see below. Is there any chance we can get >> pam-keyring in by default for Fedora 8? If yes, how about creating a >> Wiki page for the feature much like the ones Matthias created for other >> F8 bound features as mentioned here >> >> https://www.redhat.com/archives/fedora-desktop-list/2007-May/msg00167.html >> >> so we can track the progress and everyone can get an overview of what >> work is required etc. Thanks! > > Top men are on it! Well, as soon as the wiki isn't deathly slow from all > the downloads. I am also working on getting a Trac instance up for > pam_keyring. I am hoping I will finally have the time this weekend to > get everything up and ready for public consumption. That's good news. http//hosted.fedoraproject.org has trac which you might be able to use. Rahul From jon.nettleton at gmail.com Fri Jun 1 13:52:04 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 01 Jun 2007 09:52:04 -0400 Subject: install pam_keyring by default in the GNOME based live cd? In-Reply-To: <46601D00.5070303@fedoraproject.org> References: <45FDC5F7.6080808@fedoraproject.org> <1174259891.8053.6.camel@localhost.localdomain> <45FDF88B.30706@fedoraproject.org> <1174294887.2699.4.camel@averatec> <1180620275.2702.9.camel@zelda.fubar.dk> <1180703863.4917.17.camel@birkoff> <46601D00.5070303@fedoraproject.org> Message-ID: <1180705924.4917.20.camel@birkoff> On Fri, 2007-06-01 at 18:50 +0530, Rahul Sundaram wrote: > Jon Nettleton wrote: > > On Thu, 2007-05-31 at 10:04 -0400, David Zeuthen wrote: > >> Hi Jon, > >> > >> I'm replying to an old thread; see below. Is there any chance we can get > >> pam-keyring in by default for Fedora 8? If yes, how about creating a > >> Wiki page for the feature much like the ones Matthias created for other > >> F8 bound features as mentioned here > >> > >> https://www.redhat.com/archives/fedora-desktop-list/2007-May/msg00167.html > >> > >> so we can track the progress and everyone can get an overview of what > >> work is required etc. Thanks! > > > > Top men are on it! Well, as soon as the wiki isn't deathly slow from all > > the downloads. I am also working on getting a Trac instance up for > > pam_keyring. I am hoping I will finally have the time this weekend to > > get everything up and ready for public consumption. > > That's good news. http//hosted.fedoraproject.org has trac which you > might be able to use. I didn't know that such a site existed. Who would I contact to possibly get pam-keyring setup there? Jon From sundaram at fedoraproject.org Fri Jun 1 13:56:52 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 19:26:52 +0530 Subject: install pam_keyring by default in the GNOME based live cd? In-Reply-To: <1180705924.4917.20.camel@birkoff> References: <45FDC5F7.6080808@fedoraproject.org> <1174259891.8053.6.camel@localhost.localdomain> <45FDF88B.30706@fedoraproject.org> <1174294887.2699.4.camel@averatec> <1180620275.2702.9.camel@zelda.fubar.dk> <1180703863.4917.17.camel@birkoff> <46601D00.5070303@fedoraproject.org> <1180705924.4917.20.camel@birkoff> Message-ID: <466025A4.8000601@fedoraproject.org> Jon Nettleton wrote: >>> Top men are on it! Well, as soon as the wiki isn't deathly slow from all >>> the downloads. I am also working on getting a Trac instance up for >>> pam_keyring. I am hoping I will finally have the time this weekend to >>> get everything up and ready for public consumption. >> That's good news. http//hosted.fedoraproject.org has trac which you >> might be able to use. > > I didn't know that such a site existed. Who would I contact to possibly > get pam-keyring setup there? Not sure they are opening up for more public projects yet but it would be infrastructure team. http://fedoraproject.org/wiki/Infrastructure #fedora-admin or fedora-infrastructure list. Rahul From bnocera at redhat.com Fri Jun 1 15:20:46 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 01 Jun 2007 16:20:46 +0100 Subject: Some early Bluetooth enhancements for Fedora 8 Message-ID: <1180711246.25009.53.camel@cookie.hadess.net> Heya, In the past week, I've been working on 2 packages/patches that are now built into the Fedora 8 repositories. See: http://hadessuk.blogspot.com/2007/05/bluetooth.html and: http://hadessuk.blogspot.com/2007/06/mo-bluetooth.html Only a step away: yum -y install gnome-vfs2-obexftp bluez-utils-cups To use the ObexFTP browsing, just type "obex:///" in nautilus. Hopefully, we'll have a better UI in upcoming versions of the Bluetooth applet. Cheers From walters at redhat.com Fri Jun 1 01:21:33 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 31 May 2007 21:21:33 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <20070601100211.GA9361@urchin.earth.li> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> Message-ID: <1180660894.28298.5.camel@neutron> On Fri, 2007-06-01 at 11:02 +0100, Stuart Children wrote: > The other consideration there would be the timeline for integration of > bigboard into a GNOME/Fedora release. The package review should hopefully finish by today; the packages should then be available for F7 within a few more days after that. There's more work to do of course but the basic functionality is there. > The changes I was thinking of to gnome-panel could be > done easily enough, would allow people to start "fixing" the desktop > files right away, and prevent upsets about name display until bigboard > is available. But maybe my efforts are better spent on bigboard? As others have said I think it is likely worth updating the panel too. From nicolas.mailhot at laposte.net Fri Jun 1 17:46:05 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 01 Jun 2007 19:46:05 +0200 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180695518.13136.246.camel@huygens.home.fishsoup.net> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> <1180695518.13136.246.camel@huygens.home.fishsoup.net> Message-ID: <1180719965.9688.3.camel@rousalka.dyndns.org> Le vendredi 01 juin 2007 ? 06:58 -0400, Owen Taylor a ?crit : > What we'd presumably like is something like: > > Thunderbird Email > Abiword Word Processor > GNOME Terminal > Character Map > Iagno English-centric concatenation rule that won't work for other languages -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From otaylor at redhat.com Fri Jun 1 18:19:28 2007 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 01 Jun 2007 14:19:28 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180719965.9688.3.camel@rousalka.dyndns.org> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> <1180695518.13136.246.camel@huygens.home.fishsoup.net> <1180719965.9688.3.camel@rousalka.dyndns.org> Message-ID: <1180721968.11647.7.camel@fresnel.dumbhippo.com> On Fri, 2007-06-01 at 19:46 +0200, Nicolas Mailhot wrote: > Le vendredi 01 juin 2007 ? 06:58 -0400, Owen Taylor a ?crit : > > What we'd presumably like is something like: > > > > Thunderbird Email > > Abiword Word Processor > > GNOME Terminal > > Character Map > > Iagno > > English-centric concatenation rule that won't work for other languages Perhaps using a bit of (inconspicuous) punctuation for those languages would fix: Epiphany - Navigateur Web Or we could have a single translatable item that is a format string for concatenating GenericName and Name, though I'd worry about issues of agreement, and I think there is value in keeping the Name in front for quick scanning. What doesn't make sense to me is that the Fedora French translation team would have to, for every single desktop file, individually concatenate the name and generic name in a linguistically sensitive manner :-) - Owen From nicolas.mailhot at laposte.net Fri Jun 1 19:03:22 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 01 Jun 2007 21:03:22 +0200 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180721968.11647.7.camel@fresnel.dumbhippo.com> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> <1180695518.13136.246.camel@huygens.home.fishsoup.net> <1180719965.9688.3.camel@rousalka.dyndns.org> <1180721968.11647.7.camel@fresnel.dumbhippo.com> Message-ID: <1180724602.11490.13.camel@rousalka.dyndns.org> Le vendredi 01 juin 2007 ? 14:19 -0400, Owen Taylor a ?crit : > What doesn't make sense to me is that the Fedora French translation > team would have to, for every single desktop file, individually > concatenate the name and generic name in a linguistically sensitive > manner :-) French concatenation rules are easy, they're the reverse from English :). I was thinking more of langages that do not rely on word ordering to construct natural langage sentences but rely on nasty stuff like declinations -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sundaram at fedoraproject.org Sat Jun 2 10:59:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 16:29:48 +0530 Subject: Playing with Big Board In-Reply-To: <64b14b300705310652x32cb7090gaac82ee72cfb9072@mail.gmail.com> References: <463F5AF2.80803@fedoraproject.org> <200705071308.29497.jkeating@redhat.com> <1178558045.9714.12.camel@dhcp83-33.boston.redhat.com> <200705071421.32486.jkeating@redhat.com> <64b14b300705310652x32cb7090gaac82ee72cfb9072@mail.gmail.com> Message-ID: <46614DA4.9020400@fedoraproject.org> Valent Turkovic wrote: > On 5/7/07, Jesse Keating wrote: >> On Monday 07 May 2007 13:14:05 Matthias Clasen wrote: >> > It is not in fedora yet because getting stuff into Fedora is reasonably >> > hard... Colins review request for the required hippo-canvas was stuff >> > without a reviewer for a month before I reviewed and approved it, I >> > guess Colin is now looking for a sponsor to get hippo-canvas in... >> >> Yes, sometimes finding a reviewer is not an easy task, especially if >> you don't >> persue it at all. There is a HUGE queue of unreviewed packages. It >> takes a >> little bit of effort to find a peer to review it for you. > > Can you explain to me how review process works or point me to some > blog post about it? http://fedoraproject.org/wiki/Packaging/ReviewGuidelines > Who reviews packages that are in queue? Fedora members? Red Hat > devels? Community? Anyone interested. > Is there anything the community can do to review these packages? And > what does it exactly mean. See the review guidelines. If you got questions about reviewing post to fedora-devel list. Rahul From mclasen at redhat.com Sun Jun 3 02:03:44 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 02 Jun 2007 22:03:44 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180721968.11647.7.camel@fresnel.dumbhippo.com> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> <1180695518.13136.246.camel@huygens.home.fishsoup.net> <1180719965.9688.3.camel@rousalka.dyndns.org> <1180721968.11647.7.camel@fresnel.dumbhippo.com> Message-ID: <1180836224.4120.4.camel@localhost.localdomain> On Fri, 2007-06-01 at 14:19 -0400, Owen Taylor wrote: > On Fri, 2007-06-01 at 19:46 +0200, Nicolas Mailhot wrote: > > Le vendredi 01 juin 2007 ? 06:58 -0400, Owen Taylor a ?crit : > > > What we'd presumably like is something like: > > > > > > Thunderbird Email > > > Abiword Word Processor > > > GNOME Terminal > > > Character Map > > > Iagno > > > > English-centric concatenation rule that won't work for other languages > > Perhaps using a bit of (inconspicuous) punctuation for those languages > would fix: > > Epiphany - Navigateur Web > > Or we could have a single translatable item that is a format string for > concatenating GenericName and Name, though I'd worry about issues of > agreement, and I think there is value in keeping the Name in front > for quick scanning. > > What doesn't make sense to me is that the Fedora French translation > team would have to, for every single desktop file, individually > concatenate the name and generic name in a linguistically sensitive > manner :-) > I agree that the only way to make this work with translations is to add a new field, e.g. FullName, and allow placeholders: FullName=%{Name} %{GenericName} FullName[fr_FR]=%{Name} - %{GenericName} From rstrode at redhat.com Mon Jun 4 01:35:42 2007 From: rstrode at redhat.com (Ray Strode) Date: Sun, 03 Jun 2007 21:35:42 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180836224.4120.4.camel@localhost.localdomain> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> <1180695518.13136.246.camel@huygens.home.fishsoup.net> <1180719965.9688.3.camel@rousalka.dyndns.org> <1180721968.11647.7.camel@fresnel.dumbhippo.com> <1180836224.4120.4.camel@localhost.localdomain> Message-ID: <1180920943.4674.27.camel@halflap.boston.devel.redhat.com> Hi, > I agree that the only way to make this work with translations is to add > a new field, e.g. FullName, and allow placeholders: > > FullName=%{Name} %{GenericName} > FullName[fr_FR]=%{Name} - %{GenericName} That doesn't really work either, we had Name=Foo GenericName=Text Editor Fullname=Foo Text Editor it's possible the language could be something like: Name[qx_QX]=Foo GenericName[qx_QX]=Modifierer doo Tekst FullName[qx_QX] = Modifiereth du Tekst sa Fooerd What I'm saying is suffixes can change depending on the surrounding words, so any strategy that involves placeholders won't work (because they'll expand with the wrong suffixes). We've had bugs about this kind of thing before, although I don't remember the details. (Was it with Irish Gaelic? I don't know.) --Ray From mclasen at redhat.com Mon Jun 4 01:54:39 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 03 Jun 2007 21:54:39 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180920943.4674.27.camel@halflap.boston.devel.redhat.com> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> <1180695518.13136.246.camel@huygens.home.fishsoup.net> <1180719965.9688.3.camel@rousalka.dyndns.org> <1180721968.11647.7.camel@fresnel.dumbhippo.com> <1180836224.4120.4.camel@localhost.localdomain> <1180920943.4674.27.camel@halflap.boston.devel.redhat.com> Message-ID: <1180922079.3795.6.camel@localhost.localdomain> On Sun, 2007-06-03 at 21:35 -0400, Ray Strode wrote: > Hi, > > > I agree that the only way to make this work with translations is to add > > a new field, e.g. FullName, and allow placeholders: > > > > FullName=%{Name} %{GenericName} > > FullName[fr_FR]=%{Name} - %{GenericName} > > That doesn't really work either, we had > > Name=Foo > GenericName=Text Editor > Fullname=Foo Text Editor > > it's possible the language could be something like: > Name[qx_QX]=Foo > GenericName[qx_QX]=Modifierer doo Tekst > FullName[qx_QX] = Modifiereth du Tekst sa Fooerd > > What I'm saying is suffixes can change depending on the surrounding > words, so any strategy that involves placeholders won't work (because > they'll expand with the wrong suffixes). > > We've had bugs about this kind of thing before, although I don't > remember the details. (Was it with Irish Gaelic? I don't know.) > When I said "allow placeholders", I didn't mean you _have_ to use placeholders. If your language requires declination to make this work, you can just do what you outlined in your qx_QX example. The placeholders are just an optimization. From rstrode at redhat.com Mon Jun 4 02:22:16 2007 From: rstrode at redhat.com (Ray Strode) Date: Sun, 03 Jun 2007 22:22:16 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180922079.3795.6.camel@localhost.localdomain> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> <20070601100211.GA9361@urchin.earth.li> <1180695518.13136.246.camel@huygens.home.fishsoup.net> <1180719965.9688.3.camel@rousalka.dyndns.org> <1180721968.11647.7.camel@fresnel.dumbhippo.com> <1180836224.4120.4.camel@localhost.localdomain> <1180920943.4674.27.camel@halflap.boston.devel.redhat.com> <1180922079.3795.6.camel@localhost.localdomain> Message-ID: <1180923736.5293.8.camel@halflap.boston.devel.redhat.com> Hi, > When I said "allow placeholders", I didn't mean you _have_ to use > placeholders. If your language requires declination to make this work, > you can just do what you outlined in your qx_QX example. The > placeholders are just an optimization. I guess that's fine as long as it's made clear to translators what the string is so they can ignore the msgid/placeholders if they don't apply. I do kind of wonder what gains we get from having the optimization, though. (avoiding typos from the redundant information?) It seems like it might just add confusion for translators. --Ray From valent.turkovic at gmail.com Mon Jun 4 10:32:42 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 4 Jun 2007 12:32:42 +0200 Subject: Please test if your Fedora 7 has this bug... Message-ID: <64b14b300706040332r450c016cj3382203451c653b8@mail.gmail.com> Hi I posted this bug to bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242175 you can see the video and the bug here: http://www.youtube.com/watch?v=-_ayaoEUHZ4 The issue is really easy to reproduce; shutdown firefox mv .mozilla .mozilla.bkp mv .macromedia .macromedia.bkp and then launch firefox and go to http://www.youtube.com - and try to install flash plugin. Close Firefox rm .mozilla rm .macromedia and then restore your firefox settings from backup: rm .mozilla rm .macromedia mv .mozilla.bkp .mozilla mv .macromedia.bkp .macromedia then report back to bugzilla (or here on the mailing list) how many installs of flash succeeded and how much of them failed. this is an easy task, and then we will see if this is a issue happened by some off chance only to me or this is a bug. I don't see how you don't see the problem here. I posted a bug also for fedora 7 test 4, it happened there also... and how it happened again... so you draw your own conclusions... -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From david at lovesunix.net Mon Jun 4 11:22:59 2007 From: david at lovesunix.net (David Nielsen) Date: Mon, 04 Jun 2007 13:22:59 +0200 Subject: Please test if your Fedora 7 has this bug... In-Reply-To: <64b14b300706040332r450c016cj3382203451c653b8@mail.gmail.com> References: <64b14b300706040332r450c016cj3382203451c653b8@mail.gmail.com> Message-ID: <1180956179.6050.2.camel@dawkins> man, 04 06 2007 kl. 12:32 +0200, skrev Valent Turkovic: > Hi I posted this bug to bugzilla: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242175 > > you can see the video and the bug here: > http://www.youtube.com/watch?v=-_ayaoEUHZ4 The proprietary flash plugin is not supported, could you see if you can reproduce it with the swfdec-mozilla package from livna (since 0.4.4 and above depends on gstreamer instead of ffmpeg for their media decoding I think we could put it in Fedora at some point). Currently Livna only has 0.4.3 and 0.4.4 is much more stable in my experience, infact youtube has not caused it to crash once yet. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From caillon at redhat.com Mon Jun 4 16:51:05 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 12:51:05 -0400 Subject: Please test if your Fedora 7 has this bug... In-Reply-To: <64b14b300706040332r450c016cj3382203451c653b8@mail.gmail.com> References: <64b14b300706040332r450c016cj3382203451c653b8@mail.gmail.com> Message-ID: <466442F9.2080509@redhat.com> Wrong list. You want fedora-test-list. But, um, you already filed a bug. That is reason enough for it to be investigated if you'd just provide the information I need in the bug. I need data about your problem, not a bunch of "me too" comments. From vnpenguin at vnoss.org Sat Jun 9 08:29:50 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Sat, 9 Jun 2007 10:29:50 +0200 Subject: GTK2 apps : enable IM menu ? Message-ID: Hi, In previous release of FC, in any GTK2 apps I could choose Input Method via right click menu. But in current Gnome desktop of F7 I can see this such menu. Anyone know howto eable this menu ? environment variable ? .gtkrc-2.0 ? How ? Thanks, -- http://vnoss.org From mclasen at redhat.com Sat Jun 9 20:34:25 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 09 Jun 2007 16:34:25 -0400 Subject: GTK2 apps : enable IM menu ? In-Reply-To: References: Message-ID: <1181421265.3504.6.camel@localhost.localdomain> On Sat, 2007-06-09 at 10:29 +0200, Vnpenguin wrote: > Hi, > In previous release of FC, in any GTK2 apps I could choose Input > Method via right click menu. But in current Gnome desktop of F7 I can > see this such menu. > > Anyone know howto eable this menu ? environment variable ? .gtkrc-2.0 ? How ? > gconftool-2 --type=bool --set /desktop/gnome/interface/show_input_method_menu 1 From vnpenguin at vnoss.org Sun Jun 10 11:13:31 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Sun, 10 Jun 2007 13:13:31 +0200 Subject: GTK2 apps : enable IM menu ? In-Reply-To: <1181421265.3504.6.camel@localhost.localdomain> References: <1181421265.3504.6.camel@localhost.localdomain> Message-ID: On 6/9/07, Matthias Clasen wrote: > On Sat, 2007-06-09 at 10:29 +0200, Vnpenguin wrote: > > Hi, > > In previous release of FC, in any GTK2 apps I could choose Input > > Method via right click menu. But in current Gnome desktop of F7 I can > > see this such menu. > > > > Anyone know howto eable this menu ? environment variable ? .gtkrc-2.0 ? How ? > > > > gconftool-2 --type=bool --set /desktop/gnome/interface/show_input_method_menu 1 > What's exactly I'm looking for. Thank you very much ! Regards, -- http://vnoss.org From david at lovesunix.net Mon Jun 11 10:05:53 2007 From: david at lovesunix.net (David Nielsen) Date: Mon, 11 Jun 2007 12:05:53 +0200 Subject: An obvious problem with BigBoards application selection Message-ID: <1181556353.22995.9.camel@dawkins> I've been playing with Bigboard for a while now and for this stage in development it's both fairly solid and useful, however one thing makes it work rather badly - the way it selects applications. My background is on the QA team which means I tend to favor crashing applications, reproducing crashes over and over. This leads to bug-buddy being launched quite a bit, in fact so much that's now the 6th most used application on my desktop, which means it's now listed in my application list. The thing is Bug-buddy is no use for me as a separately started application so it shouldn't be listed there in the first place. I do realise this is one of those corner cases which on a real desktop will (hopefully) never happen. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From walters at redhat.com Mon Jun 11 20:44:27 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 11 Jun 2007 16:44:27 -0400 Subject: An obvious problem with BigBoards application selection In-Reply-To: <1181556353.22995.9.camel@dawkins> References: <1181556353.22995.9.camel@dawkins> Message-ID: <1181594667.3840.22.camel@neutron.verbum.private> On Mon, 2007-06-11 at 12:05 +0200, David Nielsen wrote: > I've been playing with Bigboard for a while now and for this stage in > development it's both fairly solid and useful, however one thing makes > it work rather badly - the way it selects applications. > > My background is on the QA team which means I tend to favor crashing > applications, reproducing crashes over and over. This leads to bug-buddy > being launched quite a bit, in fact so much that's now the 6th most used > application on my desktop, which means it's now listed in my application > list. The thing is Bug-buddy is no use for me as a separately started > application so it shouldn't be listed there in the first place. Right - there are two issues here. The first is that bug buddy shouldn't be listed as an application. The second is we need to implement the design for updating your preferred apps list: http://bugzilla.mugshot.org/show_bug.cgi?id=1254 From mclasen at redhat.com Mon Jun 11 21:41:29 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 11 Jun 2007 17:41:29 -0400 Subject: An obvious problem with BigBoards application selection In-Reply-To: <1181594667.3840.22.camel@neutron.verbum.private> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> Message-ID: <1181598089.3456.1.camel@localhost.localdomain> On Mon, 2007-06-11 at 16:44 -0400, Colin Walters wrote: > On Mon, 2007-06-11 at 12:05 +0200, David Nielsen wrote: > > I've been playing with Bigboard for a while now and for this stage in > > development it's both fairly solid and useful, however one thing makes > > it work rather badly - the way it selects applications. > > > > My background is on the QA team which means I tend to favor crashing > > applications, reproducing crashes over and over. This leads to bug-buddy > > being launched quite a bit, in fact so much that's now the 6th most used > > application on my desktop, which means it's now listed in my application > > list. The thing is Bug-buddy is no use for me as a separately started > > application so it shouldn't be listed there in the first place. > > Right - there are two issues here. > > The first is that bug buddy shouldn't be listed as an application. Bug-buddy does not show up in the classic menus; even though it does have a desktop file. Maybe bigboard should pay attention to the NoDisplay field. From walters at redhat.com Mon Jun 11 22:32:25 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 11 Jun 2007 18:32:25 -0400 Subject: An obvious problem with BigBoards application selection In-Reply-To: <1181598089.3456.1.camel@localhost.localdomain> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> <1181598089.3456.1.camel@localhost.localdomain> Message-ID: <1181601145.3840.41.camel@neutron.verbum.private> On Mon, 2007-06-11 at 17:41 -0400, Matthias Clasen wrote: > Bug-buddy does not show up in the classic menus; even though it does > have a desktop file. Maybe bigboard should pay attention to the > NoDisplay field. We did originally honor NoDisplay; I think it got lost in some code shuffling, or maybe because we wanted to show Evince? I just committed a fix (r5830). From jspaleta at gmail.com Mon Jun 11 23:44:48 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 11 Jun 2007 15:44:48 -0800 Subject: An obvious problem with BigBoards application selection In-Reply-To: <1181601145.3840.41.camel@neutron.verbum.private> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> <1181598089.3456.1.camel@localhost.localdomain> <1181601145.3840.41.camel@neutron.verbum.private> Message-ID: <604aa7910706111644v627a85d3s79ba5876816ea258@mail.gmail.com> On 6/11/07, Colin Walters wrote: > We did originally honor NoDisplay; I think it got lost in some code > shuffling, or maybe because we wanted to show Evince? Hmm... to show evince? If you want to show evince in bigboard...why wouldn't you want to show it in the normal menus as well? I honestly can't think of a rationale where you'd want it to show up in one interface and not the other. Either evince should be treated like a normal callable end user application or its treated as a helper and is thus hidden from selection interfaces... pick a pov and stick with it. -jef From jrb at redhat.com Wed Jun 13 18:34:26 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Wed, 13 Jun 2007 14:34:26 -0400 Subject: An obvious problem with BigBoards application selection In-Reply-To: <604aa7910706111644v627a85d3s79ba5876816ea258@mail.gmail.com> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> <1181598089.3456.1.camel@localhost.localdomain> <1181601145.3840.41.camel@neutron.verbum.private> <604aa7910706111644v627a85d3s79ba5876816ea258@mail.gmail.com> Message-ID: <1181759666.3274.36.camel@localhost.localdomain> On Mon, 2007-06-11 at 15:44 -0800, Jeff Spaleta wrote: > Hmm... to show evince? If you want to show evince in bigboard...why > wouldn't you want to show it in the normal menus as well? I honestly > can't think of a rationale where you'd want it to show up in one > interface and not the other. Either evince should be treated like a > normal callable end user application or its treated as a helper and is > thus hidden from selection interfaces... pick a pov and stick with it. It was a conscious design decision for evince to not appear in the menus. There seems to be no advantage to starting evince on its own, as it is very much a viewer and not a creator. We can perhaps finesse the NoDisplay issue with a white list or black list. A better approach might be to categorize that kind of application by mime-type. While it has a terrible name, something like this might be an interesting add-on to mugshot: https://wiki.ubuntu.com/UbuntuCommonHooker The design is pretty bad, but the overall idea is good. The mugshot server would be a great basis to do this right. Thanks, -Jonathan From jspaleta at gmail.com Wed Jun 13 20:37:09 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 13 Jun 2007 12:37:09 -0800 Subject: An obvious problem with BigBoards application selection In-Reply-To: <1181759666.3274.36.camel@localhost.localdomain> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> <1181598089.3456.1.camel@localhost.localdomain> <1181601145.3840.41.camel@neutron.verbum.private> <604aa7910706111644v627a85d3s79ba5876816ea258@mail.gmail.com> <1181759666.3274.36.camel@localhost.localdomain> Message-ID: <604aa7910706131337j214a976ek3fdbda0068a08ba9@mail.gmail.com> On 6/13/07, Jonathan Blandford wrote: > It was a conscious design decision for evince to not appear in the > menus. I realize.... but my point is if its not going to appear in the menus... it shouldn't appear in bigboards dynamic 'popular' application list that the user sees either. Don't complicate this by wrapping another layer of catergorization over NoDisplay. NoDisplay as a tag in the desktop file does exact the job its suppose to do. BigBoard needs to honor the design choices the same way the static menus do. Either an app should be displayed to the user as a stand alone applicarion.. or it shouldn't... it doesn't matter if its bigboards dynamic interface or the menu's static listing. Bending over backwards to get evince displayed in bigboard as a special exception to the NoDisplay rule but not in the static menus makes no sense what-so-ever. If it was a design choice to hide it... hide it...and stand up behind that original design choice. -jef"This is only a hypothetical argument, since Colin only suggested that showing evince in bigboard's listing was a goal and there's been no affirmation that this was indeed a goal. If this were an actual argument, oxygen masks would drop from the ceiling in front of you and emergency lighting would lead you to the nearest bottle of tequila."spaleta From bnocera at redhat.com Thu Jun 14 00:11:23 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 14 Jun 2007 01:11:23 +0100 Subject: An obvious problem with BigBoards application selection In-Reply-To: <1181759666.3274.36.camel@localhost.localdomain> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> <1181598089.3456.1.camel@localhost.localdomain> <1181601145.3840.41.camel@neutron.verbum.private> <604aa7910706111644v627a85d3s79ba5876816ea258@mail.gmail.com> <1181759666.3274.36.camel@localhost.localdomain> Message-ID: <1181779883.31424.118.camel@cookie.hadess.net> On Wed, 2007-06-13 at 14:34 -0400, Jonathan Blandford wrote: > On Mon, 2007-06-11 at 15:44 -0800, Jeff Spaleta wrote: > > > Hmm... to show evince? If you want to show evince in bigboard...why > > wouldn't you want to show it in the normal menus as well? I honestly > > can't think of a rationale where you'd want it to show up in one > > interface and not the other. Either evince should be treated like a > > normal callable end user application or its treated as a helper and is > > thus hidden from selection interfaces... pick a pov and stick with it. > > It was a conscious design decision for evince to not appear in the > menus. There seems to be no advantage to starting evince on its own, as > it is very much a viewer and not a creator. We can perhaps finesse the > NoDisplay issue with a white list or black list. A better approach > might be to categorize that kind of application by mime-type. Huh. Should we put Totem NoDisplay as well then? > While it has a terrible name, something like this might be an > interesting add-on to mugshot: > > https://wiki.ubuntu.com/UbuntuCommonHooker > > The design is pretty bad, but the overall idea is good. The mugshot > server would be a great basis to do this right. I don't even think you would need mugshot to do that. We already have /usr/share/applications/defaults.list which contains the mime-type <-> application link. So for example, trying to open a RAR file: application/x-rar=gnome-file-roller.desktop Gives you: yum -y install /usr/share/applications/gnome-file-roller.desktop Voila! You just need integration into nautilus, and a nice front-end to yum. From bnocera at redhat.com Thu Jun 14 00:11:23 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 14 Jun 2007 01:11:23 +0100 Subject: An obvious problem with BigBoards application selection In-Reply-To: <1181759666.3274.36.camel@localhost.localdomain> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> <1181598089.3456.1.camel@localhost.localdomain> <1181601145.3840.41.camel@neutron.verbum.private> <604aa7910706111644v627a85d3s79ba5876816ea258@mail.gmail.com> <1181759666.3274.36.camel@localhost.localdomain> Message-ID: <1181779883.31424.118.camel@cookie.hadess.net> On Wed, 2007-06-13 at 14:34 -0400, Jonathan Blandford wrote: > On Mon, 2007-06-11 at 15:44 -0800, Jeff Spaleta wrote: > > > Hmm... to show evince? If you want to show evince in bigboard...why > > wouldn't you want to show it in the normal menus as well? I honestly > > can't think of a rationale where you'd want it to show up in one > > interface and not the other. Either evince should be treated like a > > normal callable end user application or its treated as a helper and is > > thus hidden from selection interfaces... pick a pov and stick with it. > > It was a conscious design decision for evince to not appear in the > menus. There seems to be no advantage to starting evince on its own, as > it is very much a viewer and not a creator. We can perhaps finesse the > NoDisplay issue with a white list or black list. A better approach > might be to categorize that kind of application by mime-type. Huh. Should we put Totem NoDisplay as well then? > While it has a terrible name, something like this might be an > interesting add-on to mugshot: > > https://wiki.ubuntu.com/UbuntuCommonHooker > > The design is pretty bad, but the overall idea is good. The mugshot > server would be a great basis to do this right. I don't even think you would need mugshot to do that. We already have /usr/share/applications/defaults.list which contains the mime-type <-> application link. So for example, trying to open a RAR file: application/x-rar=gnome-file-roller.desktop Gives you: yum -y install /usr/share/applications/gnome-file-roller.desktop Voila! You just need integration into nautilus, and a nice front-end to yum. From katzj at redhat.com Thu Jun 14 00:26:14 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Jun 2007 20:26:14 -0400 Subject: An obvious problem with BigBoards application selection In-Reply-To: <1181779883.31424.118.camel@cookie.hadess.net> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> <1181598089.3456.1.camel@localhost.localdomain> <1181601145.3840.41.camel@neutron.verbum.private> <604aa7910706111644v627a85d3s79ba5876816ea258@mail.gmail.com> <1181759666.3274.36.camel@localhost.localdomain> <1181779883.31424.118.camel@cookie.hadess.net> Message-ID: <1181780774.2669.12.camel@aglarond.local> On Thu, 2007-06-14 at 01:11 +0100, Bastien Nocera wrote: > So for example, trying to open a RAR file: > application/x-rar=gnome-file-roller.desktop > Gives you: > yum -y install /usr/share/applications/gnome-file-roller.desktop Should be pretty easy to have pirut's single package installer[1] do that if we want it to. Say the word and it'll be in the next build :) Jeremy [1] The thing that comes up when you double click on a package. And is also used with mugshot/bigboard for installing apps. So this would be consistent with everything else From stuart at terminus.co.uk Thu Jun 14 16:16:03 2007 From: stuart at terminus.co.uk (Stuart Children) Date: Thu, 14 Jun 2007 17:16:03 +0100 Subject: An obvious problem with BigBoards application selection In-Reply-To: <1181779883.31424.118.camel@cookie.hadess.net> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> <1181598089.3456.1.camel@localhost.localdomain> <1181601145.3840.41.camel@neutron.verbum.private> <604aa7910706111644v627a85d3s79ba5876816ea258@mail.gmail.com> <1181759666.3274.36.camel@localhost.localdomain> <1181779883.31424.118.camel@cookie.hadess.net> Message-ID: <20070614161603.GA26712@urchin.earth.li> On Thu, Jun 14, 2007 at 01:11:23AM +0100, Bastien Nocera wrote: > On Wed, 2007-06-13 at 14:34 -0400, Jonathan Blandford wrote: > > On Mon, 2007-06-11 at 15:44 -0800, Jeff Spaleta wrote: > > > > > Hmm... to show evince? If you want to show evince in bigboard...why > > > wouldn't you want to show it in the normal menus as well? I honestly > > > can't think of a rationale where you'd want it to show up in one > > > interface and not the other. Either evince should be treated like a > > > normal callable end user application or its treated as a helper and is > > > thus hidden from selection interfaces... pick a pov and stick with it. > > > > It was a conscious design decision for evince to not appear in the > > menus. There seems to be no advantage to starting evince on its own, as > > it is very much a viewer and not a creator. We can perhaps finesse the > > NoDisplay issue with a white list or black list. A better approach > > might be to categorize that kind of application by mime-type. > > Huh. Should we put Totem NoDisplay as well then? Indeed. I don't think making Evince (or Totem) NoDisplay makes sense. Here's why: There are basically two ways a user might choose to "view" (or play or whatever) a file. One is to find the file and then open it via a process that knows what application should be used. The other is to start the application first, and use that to locate and open the file. Now, users who don't know that Evince opens PDFs, or that Totem opens videos are certainly only going to do the former. However, once they've made the connection, there are actually good reasons to use the application to open the file. Here are three: 1) The application might maintain a recently-used documents list, and so I don't waste time navigating to the right folder to open it. Personally, I do this all the time in OpenOffice as I rarely create new documents, but frequently update a small number of existing ones. (Evince has such a feature.) 2) The application knows what type of file it can open and so can automatically filter the list of files in an open file dialog - so it's also easy to find the right thing to open. (Evince can also do this, though the default on this machine is "All documents" for some reason.) 3) I want to view the file in something which is not the default applicaiton. I certainly don't see why it hurts to have Evince in the menu. So let's not proscribe behaviour? -- Stuart From bclark at redhat.com Thu Jun 14 18:59:30 2007 From: bclark at redhat.com (Bryan Clark) Date: Thu, 14 Jun 2007 14:59:30 -0400 Subject: An obvious problem with BigBoards application selection In-Reply-To: <1181779883.31424.118.camel@cookie.hadess.net> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> <1181598089.3456.1.camel@localhost.localdomain> <1181601145.3840.41.camel@neutron.verbum.private> <604aa7910706111644v627a85d3s79ba5876816ea258@mail.gmail.com> <1181759666.3274.36.camel@localhost.localdomain> <1181779883.31424.118.camel@cookie.hadess.net> Message-ID: <46719012.5030405@redhat.com> Bastien Nocera wrote: > On Wed, 2007-06-13 at 14:34 -0400, Jonathan Blandford wrote: > >> On Mon, 2007-06-11 at 15:44 -0800, Jeff Spaleta wrote: >> >> >>> Hmm... to show evince? If you want to show evince in bigboard...why >>> wouldn't you want to show it in the normal menus as well? I honestly >>> can't think of a rationale where you'd want it to show up in one >>> interface and not the other. Either evince should be treated like a >>> normal callable end user application or its treated as a helper and is >>> thus hidden from selection interfaces... pick a pov and stick with it. >>> >> It was a conscious design decision for evince to not appear in the >> menus. There seems to be no advantage to starting evince on its own, as >> it is very much a viewer and not a creator. We can perhaps finesse the >> NoDisplay issue with a white list or black list. A better approach >> might be to categorize that kind of application by mime-type. >> > > Huh. Should we put Totem NoDisplay as well then? > I repent! We had good reasons at the time to do this, we wanted to experiment and see if it's really better this way. However I've realized now that the undiscovered issue was actually in the display of the application menu as much as it was showing or hiding them. Much of the issues in the XChat thread [0] are actually due to how we display and allow access to the desktop entries / applications as much as the information we hold in the file. And with Big Board we've been able to change things to create much more interesting system for users that avoids the previous problem. Big Board shows the application (project) name and it's generic name at the same time allowing people who don't recognize the Open Source names of applications to recognize the one that handles "Email". But it also supports searching both those names, meaning a search for "evolution" or "email" will return the same thing. Hopefully in the future we'll have support for things like tags and such that could also be searched or used for showing related applications. I digress. > >> While it has a terrible name, something like this might be an >> interesting add-on to mugshot: >> >> https://wiki.ubuntu.com/UbuntuCommonHooker >> >> The design is pretty bad, but the overall idea is good. The mugshot >> server would be a great basis to do this right. >> > > I don't even think you would need mugshot to do that. We already > have /usr/share/applications/defaults.list which contains the mime-type > <-> application link. > > So for example, trying to open a RAR file: > application/x-rar=gnome-file-roller.desktop > Gives you: > yum -y install /usr/share/applications/gnome-file-roller.desktop > > Voila! You just need integration into nautilus, and a nice front-end to > yum. What the Big Board applications system gives you is not just a list of applications, but the list of applications that are being used most. Let me just give an example of how it would improve the defaults.list. Right now the defaults is a static list of applications that map to mime types, the mugshot / big board improvement on that would be offering the user a list of many applications that handle that mime type, sorted by their popularity through actual desktop usage. Because in reality there are a million programs out there that might handle RAR files, how does one choose the best of bread app? You'd have to read an article written specifically on the topic [1] to figure out which one might work for you; where mugshot could provide the list of apps that everyone else is already using. Cheers, ~ Bryan [0] http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00714.html [1] http://www.linux.com/article.pl?sid=07/01/29/2031237 From jdennis at redhat.com Fri Jun 15 14:13:48 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Jun 2007 10:13:48 -0400 Subject: Restarting desktop session services on RPM upgrade? Message-ID: <1181916829.19325.278.camel@junko.usersys.redhat.com> We've long had a way to restart system services on an RPM upgrade via condrestart in the initscript. However, there is another kind of service which runs, services bound to desktop sessions. Rather that global, these are per user session. Is there a mechanism by which an RPM which installs a desktop service can perform the equivalent of a condrestart on the session service? I imagine such a mechanism would work by iterating over every DBus session bus, query for the existence of the service, if it exists send it a stop signal and then after the service leaves the bus perform a StartServiceByName within the session. Do we have anything like that? I suspect not. If not then how can a root process iterate over existing sessions? -- John Dennis From hp at redhat.com Fri Jun 15 15:44:55 2007 From: hp at redhat.com (Havoc Pennington) Date: Fri, 15 Jun 2007 11:44:55 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181916829.19325.278.camel@junko.usersys.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> Message-ID: <4672B3F7.4030502@redhat.com> The Mugshot client daemon does this itself by installing a file called "version" with the package version, and if said file changes it restarts itself. The version file doesn't have the RPM release in it, but presumably could. An advantage of this approach is that it doesn't require magic in the spec file, though presumably it has downsides too. One downside is that the restart can be a bit too early (before the upgrade is complete). Havoc From caillon at redhat.com Fri Jun 15 15:54:45 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 15 Jun 2007 11:54:45 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181916829.19325.278.camel@junko.usersys.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> Message-ID: <4672B645.3000003@redhat.com> John Dennis wrote: > We've long had a way to restart system services on an RPM upgrade via > condrestart in the initscript. However, there is another kind of service > which runs, services bound to desktop sessions. Rather that global, > these are per user session. > > Is there a mechanism by which an RPM which installs a desktop service > can perform the equivalent of a condrestart on the session service? > > I imagine such a mechanism would work by iterating over every DBus > session bus, query for the existence of the service, if it exists send > it a stop signal and then after the service leaves the bus perform a > StartServiceByName within the session. > > Do we have anything like that? I suspect not. If not then how can a root > process iterate over existing sessions? The SELinux avc monitoring tool, sealert does simply restarts the app and setroubleshoot service. Might want to see how it handles that. From jdennis at redhat.com Fri Jun 15 16:11:49 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Jun 2007 12:11:49 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <20070615155850.GA15466@devserv.devel.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <20070615155850.GA15466@devserv.devel.redhat.com> Message-ID: <1181923909.19325.326.camel@junko.usersys.redhat.com> On Fri, 2007-06-15 at 11:58 -0400, Alan Cox wrote: > On Fri, Jun 15, 2007 at 11:44:55AM -0400, Havoc Pennington wrote: > > The Mugshot client daemon does this itself by installing a file called > > "version" with the package version, and if said file changes it restarts > > itself. > > init stats its own binary and librarie (or used to) But that exposes you to a race condition as you don't know when all the files have been upgraded and it requires inefficient periodic polling. -- John Dennis From jdennis at redhat.com Fri Jun 15 16:12:36 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Jun 2007 12:12:36 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <4672B3F7.4030502@redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> Message-ID: <1181923956.19325.328.camel@junko.usersys.redhat.com> On Fri, 2007-06-15 at 11:44 -0400, Havoc Pennington wrote: > The Mugshot client daemon does this itself by installing a file called > "version" with the package version, and if said file changes it restarts > itself. > > The version file doesn't have the RPM release in it, but presumably could. > > An advantage of this approach is that it doesn't require magic in the > spec file, though presumably it has downsides too. One downside is that > the restart can be a bit too early (before the upgrade is complete). Ah yes, the incomplete upgrade race condition problem. This is precisely the problem I'm trying to solve. I had done something similar to what mugshot did except it noticed when a socket was closed and reopened (result of a restart and the newly opened connection reported a different version). The package is divided into independent client and server packages. Client in this case being a desktop session service. The session service notices the upgrade which yum or rpm just finished installing and restarted and then decides to restart itself. But opps! Yum or rpm is now in the middle of updating the code for the desktop session component and the restart generates errors. One has to know to restart the desktop session service only after its files have been upgraded fully, e.g. in %post. Any scheme based on watching other components will expose you to a race condition. >From this I conclude: * There must be some mechanism callable in %post to signal the desktop session service to restart. -OR- * One must let the old desktop session service run until the user logs out and back in again thus restarting it. That might be a very long time and is clearly counter intuitive to someone who just installed an upgrade. Perhaps I've not understood all the issues but it seems to me one is between a rock and a hard place if one wants to do the right thing robustly. -- John Dennis From jdennis at redhat.com Fri Jun 15 16:18:02 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Jun 2007 12:18:02 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <4672B645.3000003@redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B645.3000003@redhat.com> Message-ID: <1181924282.19325.333.camel@junko.usersys.redhat.com> On Fri, 2007-06-15 at 11:54 -0400, Christopher Aillon wrote: > The SELinux avc monitoring tool, sealert does simply restarts the app > and setroubleshoot service. Might want to see how it handles that. :-) :-) :-) Yup, that would be my code and what prompted the question. The mechanism seems to be susceptible to a race where sealert restarts itself before all of its files have been upgraded. -- John Dennis From caillon at redhat.com Fri Jun 15 16:15:12 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 15 Jun 2007 12:15:12 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181924282.19325.333.camel@junko.usersys.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B645.3000003@redhat.com> <1181924282.19325.333.camel@junko.usersys.redhat.com> Message-ID: <4672BB10.9040602@redhat.com> John Dennis wrote: > On Fri, 2007-06-15 at 11:54 -0400, Christopher Aillon wrote: >> The SELinux avc monitoring tool, sealert does simply restarts the app >> and setroubleshoot service. Might want to see how it handles that. > > :-) :-) :-) > > Yup, that would be my code and what prompted the question. The mechanism > seems to be susceptible to a race where sealert restarts itself before > all of its files have been upgraded. Ah :-) From walters at redhat.com Fri Jun 15 17:07:30 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 15 Jun 2007 13:07:30 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181923956.19325.328.camel@junko.usersys.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181923956.19325.328.camel@junko.usersys.redhat.com> Message-ID: <1181927250.3348.33.camel@neutron.verbum.private> On Fri, 2007-06-15 at 12:12 -0400, John Dennis wrote: > * There must be some mechanism callable in %post to signal the desktop > session service to restart. It sounds like the Fedora architecture is moving towards everything calling yum-updatesd to do work. In that case, it should be fairly trivial to have yum-updatesd send a D-BUS signal on the system bus when the entire package set installation is complete. This would have the advantage that it avoids problems with interdependent packages being restarted out of sync[1], and you don't have to mess with horror that is RPM spec files[2] and %post for every package. Doing it this way, you then need a nice way to figure out which applications need to be restarted. One possibility is to standardize watching on the mtime of the .desktop file the package installs - though this might interact badly with menu editing, not sure. An alternative would be that the post-installation system sends out signals with the Exec= line of every .desktop file it changed, and then apps have to be modified to catch that signal and restart. Too bad .desktop files don't have a GUID in them =/ Finally, anyone tackling this problem should also think about the issue right now with key library packages like gtk+ being updated for security issues. Say there is a flaw in a pixbuf loader - this potentially affects all applications and thus requires a logout/login. Have some way for the system to handle that (this could just be a different signal that something like puplet catches). [1] An example is the mugshot client and loudmouth libraries being upgraded at the same time - it is key that the client gets restarted using the new loudmouth library. [2] (unprintable) From nicolas.mailhot at laposte.net Fri Jun 15 17:19:28 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 15 Jun 2007 19:19:28 +0200 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181923956.19325.328.camel@junko.usersys.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181923956.19325.328.camel@junko.usersys.redhat.com> Message-ID: <1181927968.4388.8.camel@rousalka.dyndns.org> Le vendredi 15 juin 2007 ? 12:12 -0400, John Dennis a ?crit : > One has to know to restart the desktop session service only after its > files have been upgraded fully, e.g. in %post. Any scheme based on > watching other components will expose you to a race condition. user starts gnome-terminal user launches a yum update first gui package reaches the %post stage session is restarted gnome-term is killed yum is killed in the middle of an upgrade user system is broken user is angry -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jdennis at redhat.com Fri Jun 15 17:36:45 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Jun 2007 13:36:45 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181927968.4388.8.camel@rousalka.dyndns.org> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181923956.19325.328.camel@junko.usersys.redhat.com> <1181927968.4388.8.camel@rousalka.dyndns.org> Message-ID: <1181929005.19325.373.camel@junko.usersys.redhat.com> On Fri, 2007-06-15 at 19:19 +0200, Nicolas Mailhot wrote: > Le vendredi 15 juin 2007 ? 12:12 -0400, John Dennis a ?crit : > > > One has to know to restart the desktop session service only after its > > files have been upgraded fully, e.g. in %post. Any scheme based on > > watching other components will expose you to a race condition. > > user starts gnome-terminal > user launches a yum update > first gui package reaches the %post stage > session is restarted > gnome-term is killed > yum is killed in the middle of an upgrade > user system is broken > user is angry No, we are not discussing restarting the entire desktop session, that would be a huge problem. We are talking about restarting specific session *services*. -- John Dennis From otaylor at redhat.com Fri Jun 15 19:57:58 2007 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 15 Jun 2007 15:57:58 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <4672B3F7.4030502@redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> Message-ID: <1181937478.12039.31.camel@fresnel.dumbhippo.com> On Fri, 2007-06-15 at 11:44 -0400, Havoc Pennington wrote: > The Mugshot client daemon does this itself by installing a file called > "version" with the package version, and if said file changes it restarts > itself. > > The version file doesn't have the RPM release in it, but presumably could. > > An advantage of this approach is that it doesn't require magic in the > spec file, though presumably it has downsides too. One downside is that > the restart can be a bit too early (before the upgrade is complete). We changed a while ago so Mugshot no longer installs the version file as a normal file .. instead it's %ghost and the end of the %post does: echo %{version} > %{_datadir}/mugshot/version Now, there are still a downside: you have to wake up to check for an upgrade every so often. If you wake up too often, you drain power. If you wake up less often, it might be a while before you switch versions, so the desktop component needs to be robust against that. (Doesn't try to read a file that gets removed in the newer version, say) For Mugshot, we know when we've told the user to go get a new version, so we check more frequently for a while after that. - Owen From rstrode at redhat.com Fri Jun 15 20:57:20 2007 From: rstrode at redhat.com (Ray Strode) Date: Fri, 15 Jun 2007 16:57:20 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181937478.12039.31.camel@fresnel.dumbhippo.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181937478.12039.31.camel@fresnel.dumbhippo.com> Message-ID: <1181941040.2567.5.camel@halflap.boston.devel.redhat.com> Hi, > echo %{version} > %{_datadir}/mugshot/version > > Now, there are still a downside: you have to wake up to check for an > upgrade every so often. If you wake up too often, you drain power. > If you wake up less often, it might be a while before you switch > versions, so the desktop component needs to be robust against that. Why aren't you just watching the file with inotify or gamin or whatever? --Ray From caillon at redhat.com Fri Jun 15 21:23:02 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 15 Jun 2007 17:23:02 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181937478.12039.31.camel@fresnel.dumbhippo.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181937478.12039.31.camel@fresnel.dumbhippo.com> Message-ID: <46730336.40903@redhat.com> Owen Taylor wrote: > On Fri, 2007-06-15 at 11:44 -0400, Havoc Pennington wrote: >> The Mugshot client daemon does this itself by installing a file called >> "version" with the package version, and if said file changes it restarts >> itself. >> >> The version file doesn't have the RPM release in it, but presumably could. >> >> An advantage of this approach is that it doesn't require magic in the >> spec file, though presumably it has downsides too. One downside is that >> the restart can be a bit too early (before the upgrade is complete). > > We changed a while ago so Mugshot no longer installs the version file as > a normal file .. instead it's %ghost and the end of the %post does: > > echo %{version} > %{_datadir}/mugshot/version > > Now, there are still a downside: you have to wake up to check for an > upgrade every so often. If you wake up too often, you drain power. > If you wake up less often, it might be a while before you switch > versions, so the desktop component needs to be robust against that. > > (Doesn't try to read a file that gets removed in the newer version, say) > > For Mugshot, we know when we've told the user to go get a new version, > so we check more frequently for a while after that. I have actually been wanting to do this for Firefox, as the /usr/lib/firefox-x.y directory changes. I've pondered having the %postun script check to check $1 == 1 or something to see if it was an upgrade, and if so call dbus-send to firefox on the system bus (which firefox would listen to) to load a webpage telling the user they need to restart the browser. From r.butts2 at verizon.net Fri Jun 15 22:00:08 2007 From: r.butts2 at verizon.net (Rob Butts) Date: Fri, 15 Jun 2007 18:00:08 -0400 Subject: Monitor Not Optimum Mode/Screen Black/Can't Get Back Message-ID: <000001c7af98$8a2ec840$1301a8c0@HPA1630N> After just installing Fedora 7 on a new drive I was setting the screen resolution to 1600 x 1200. The screen went black with a gray box voting around that reads: Not Optimum Mode Recommended Mode: 1600 x 1200 I'm sure this is because I didn't install the driver for this monitor but I don't know how to get to a lower resolution. I tried searching the Fedora 7 installation forum archives but I don't have permission. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajackson at redhat.com Fri Jun 15 22:05:43 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 15 Jun 2007 18:05:43 -0400 Subject: Monitor Not Optimum Mode/Screen Black/Can't Get Back In-Reply-To: <000001c7af98$8a2ec840$1301a8c0@HPA1630N> References: <000001c7af98$8a2ec840$1301a8c0@HPA1630N> Message-ID: <1181945143.30663.152.camel@localhost.localdomain> On Fri, 2007-06-15 at 18:00 -0400, Rob Butts wrote: > After just installing Fedora 7 on a new drive I was setting the screen > resolution to 1600 x 1200. The screen went black with a gray box > voting around that reads: > > > > Not Optimum Mode > > Recommended Mode: 1600 x 1200 What mode did you get? /var/log/Xorg.0.log should tell you. - ajax From pemboa at gmail.com Fri Jun 15 22:07:28 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 15 Jun 2007 17:07:28 -0500 Subject: Monitor Not Optimum Mode/Screen Black/Can't Get Back In-Reply-To: <000001c7af98$8a2ec840$1301a8c0@HPA1630N> References: <000001c7af98$8a2ec840$1301a8c0@HPA1630N> Message-ID: <16de708d0706151507m109d72d6x89da3b2f1ee2cbb0@mail.gmail.com> On 6/15/07, Rob Butts wrote: > > > > > After just installing Fedora 7 on a new drive I was setting the screen > resolution to 1600 x 1200. The screen went black with a gray box voting > around that reads: > > > > Not Optimum Mode > > Recommended Mode: 1600 x 1200 > > > > I'm sure this is because I didn't install the driver for this monitor but I > don't know how to get to a lower resolution. I tried searching the Fedora 7 > installation forum archives but I don't have permission. Assuming the problem is the same as with FC6 Follow the following tutorial to get to runlevel 3: http://www.pembo13.com/linux/tutorials/runlevel3/ Then edit the /etc/X11/xorg.conf to put in the proper resolution. If you need further assistance, let us know. Arthur Pemberton -- Fedora Core 6 and proud From pemboa at gmail.com Sat Jun 16 00:34:00 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 15 Jun 2007 19:34:00 -0500 Subject: Monitor Not Optimum Mode/Screen Black/Can't Get Back In-Reply-To: <1181945143.30663.152.camel@localhost.localdomain> References: <000001c7af98$8a2ec840$1301a8c0@HPA1630N> <1181945143.30663.152.camel@localhost.localdomain> Message-ID: <16de708d0706151734m24a1317cg67c7825d360e8de2@mail.gmail.com> On 6/15/07, Adam Jackson wrote: > On Fri, 2007-06-15 at 18:00 -0400, Rob Butts wrote: > > After just installing Fedora 7 on a new drive I was setting the screen > > resolution to 1600 x 1200. The screen went black with a gray box > > voting around that reads: > > > > > > > > Not Optimum Mode > > > > Recommended Mode: 1600 x 1200 > > What mode did you get? /var/log/Xorg.0.log should tell you. > > - ajax No it wouldn't, not unless you hardcode it. -- Fedora Core 6 and proud From otaylor at redhat.com Sat Jun 16 11:56:26 2007 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 16 Jun 2007 07:56:26 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181941040.2567.5.camel@halflap.boston.devel.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181937478.12039.31.camel@fresnel.dumbhippo.com> <1181941040.2567.5.camel@halflap.boston.devel.redhat.com> Message-ID: <1181994986.30526.0.camel@huygens.home.fishsoup.net> On Fri, 2007-06-15 at 16:57 -0400, Ray Strode wrote: > Hi, > > echo %{version} > %{_datadir}/mugshot/version > > > > Now, there are still a downside: you have to wake up to check for an > > upgrade every so often. If you wake up too often, you drain power. > > If you wake up less often, it might be a while before you switch > > versions, so the desktop component needs to be robust against that. > > Why aren't you just watching the file with inotify or gamin or whatever? ^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think that sort of answers the question :-) - Owen From ajackson at redhat.com Mon Jun 18 14:53:02 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 18 Jun 2007 10:53:02 -0400 Subject: Monitor Not Optimum Mode/Screen Black/Can't Get Back In-Reply-To: <16de708d0706151734m24a1317cg67c7825d360e8de2@mail.gmail.com> References: <000001c7af98$8a2ec840$1301a8c0@HPA1630N> <1181945143.30663.152.camel@localhost.localdomain> <16de708d0706151734m24a1317cg67c7825d360e8de2@mail.gmail.com> Message-ID: <1182178382.30663.159.camel@localhost.localdomain> On Fri, 2007-06-15 at 19:34 -0500, Arthur Pemberton wrote: > On 6/15/07, Adam Jackson wrote: > > On Fri, 2007-06-15 at 18:00 -0400, Rob Butts wrote: > > > After just installing Fedora 7 on a new drive I was setting the screen > > > resolution to 1600 x 1200. The screen went black with a gray box > > > voting around that reads: > > > > > > > > > > > > Not Optimum Mode > > > > > > Recommended Mode: 1600 x 1200 > > > > What mode did you get? /var/log/Xorg.0.log should tell you. > > No it wouldn't, not unless you hardcode it. That looks a lot like English, but it makes no sense. The X log does tell you what mode it's attempting. When it prints the list of modes that survived validation, the first one is the default. - ajax From sundaram at fedoraproject.org Wed Jun 20 19:28:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 21 Jun 2007 00:58:47 +0530 Subject: An obvious problem with BigBoards application selection In-Reply-To: <1181780774.2669.12.camel@aglarond.local> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> <1181598089.3456.1.camel@localhost.localdomain> <1181601145.3840.41.camel@neutron.verbum.private> <604aa7910706111644v627a85d3s79ba5876816ea258@mail.gmail.com> <1181759666.3274.36.camel@localhost.localdomain> <1181779883.31424.118.camel@cookie.hadess.net> <1181780774.2669.12.camel@aglarond.local> Message-ID: <46797FEF.4090504@fedoraproject.org> Jeremy Katz wrote: > On Thu, 2007-06-14 at 01:11 +0100, Bastien Nocera wrote: >> So for example, trying to open a RAR file: >> application/x-rar=gnome-file-roller.desktop >> Gives you: >> yum -y install /usr/share/applications/gnome-file-roller.desktop > > Should be pretty easy to have pirut's single package installer[1] do > that if we want it to. Say the word and it'll be in the next build :) > Have you done this? I think it's a useful feature regardless of whether big board is going to use it. Rahul From katzj at redhat.com Wed Jun 20 21:10:04 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Jun 2007 17:10:04 -0400 Subject: An obvious problem with BigBoards application selection In-Reply-To: <46797FEF.4090504@fedoraproject.org> References: <1181556353.22995.9.camel@dawkins> <1181594667.3840.22.camel@neutron.verbum.private> <1181598089.3456.1.camel@localhost.localdomain> <1181601145.3840.41.camel@neutron.verbum.private> <604aa7910706111644v627a85d3s79ba5876816ea258@mail.gmail.com> <1181759666.3274.36.camel@localhost.localdomain> <1181779883.31424.118.camel@cookie.hadess.net> <1181780774.2669.12.camel@aglarond.local> <46797FEF.4090504@fedoraproject.org> Message-ID: <1182373804.3486.22.camel@erebor.boston.redhat.com> On Thu, 2007-06-21 at 00:58 +0530, Rahul Sundaram wrote: > Jeremy Katz wrote: > > On Thu, 2007-06-14 at 01:11 +0100, Bastien Nocera wrote: > >> So for example, trying to open a RAR file: > >> application/x-rar=gnome-file-roller.desktop > >> Gives you: > >> yum -y install /usr/share/applications/gnome-file-roller.desktop > > > > Should be pretty easy to have pirut's single package installer[1] do > > that if we want it to. Say the word and it'll be in the next build :) > > Have you done this? I think it's a useful feature regardless of whether > big board is going to use it. Nope -- file it in bugzilla (so it doesn't get lost) and I'll try to get to it tonight or tomorrow Jeremy From drago01 at gmail.com Fri Jun 29 11:35:09 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 29 Jun 2007 13:35:09 +0200 Subject: Compiz Fusion? In-Reply-To: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> Message-ID: On 6/29/07, Dr. Diesel wrote: > > Any plans to incorporate into rawhide? was about to ask the same? what are the compiz plans for f8? will compiz-fusion replace compiz and berly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Sat Jun 30 04:26:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 30 Jun 2007 09:56:23 +0530 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> Message-ID: <4685DB6F.4020701@fedoraproject.org> dragoran wrote: > > > On 6/29/07, *Dr. Diesel* > wrote: > > Any plans to incorporate into rawhide? > > > was about to ask the same? what are the compiz plans for f8? will > compiz-fusion replace compiz and berly? This has already been answered in fedora-devel list. Please don't cross post. Rahul From drago01 at gmail.com Sat Jun 30 07:07:57 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 30 Jun 2007 09:07:57 +0200 Subject: Compiz Fusion? In-Reply-To: <4685DB6F.4020701@fedoraproject.org> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <4685DB6F.4020701@fedoraproject.org> Message-ID: <4686014D.8070602@gmail.com> Rahul Sundaram wrote: > dragoran wrote: >> >> >> On 6/29/07, *Dr. Diesel* > > wrote: >> >> Any plans to incorporate into rawhide? >> >> >> was about to ask the same? what are the compiz plans for f8? will >> compiz-fusion replace compiz and berly? > > This has already been answered in fedora-devel list. Please don't > cross post. > I wanted to move the discussion to fedora-desktop because I think its a more appropriate list for compiz discussions.