Given that test1 is around the corner, I thought it might be a good idea to give a little status update on the features that the desktop team has been working on for F8:
NoMoreXFS - Done. Bigboard - In test1, run god-mode 1 to turn it on and play with it. Bluetooth - bluetooth printer support is in test1. Remaining Bluetooth features are still being worked on upstream and will appear in rawhide over time. LaptopImprovements - the bulk of the keyboard and suspend/resume work is in hal-info-20070725 and hal-0.5.10rc1 which narrowly missed test1 and will appear in rawhide soon. PolicyKit - missed test1 by a few days, will appear in rawhide soon. PulseAudio - not in test1, the changes to make PulseAudio play nicely with fast user switching are done upstream. CodecBuddy - not in test1. NetworkManager - not on by default in test1. The necessary changes are being worked on upstream, and the feature page says 70% done. I heard that a 0.7 release might happen around test3 time, I hope we can get a usable snapshot earlier than that. BetterStartup - not targetting F8, since it depends on kernel features that will not land in time.
Matthias Clasen (mclasen@redhat.com) said:
NoMoreXFS - Done.
Well, it's still pulled in and enabled becuase the font packages still require chkfontpath. Probably should file some bugs and get this done.
LaptopImprovements - the bulk of the keyboard and suspend/resume work is in hal-info-20070725 and hal-0.5.10rc1 which narrowly missed test1 and will appear in rawhide soon.
For thinkpads, at least, there are some HAL and kernel interaction issues remaining.
Bill
On 7/27/07, Bill Nottingham notting@redhat.com wrote:
Matthias Clasen (mclasen@redhat.com) said:
NoMoreXFS - Done.
Well, it's still pulled in and enabled becuase the font packages still require chkfontpath. Probably should file some bugs and get this done.
I fixed most of them, and filed a bug for urw-fonts, for which I'm not in the acl. Are there other font packages pulling in chkfontpath?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245784
Kristian
Kristian Høgsberg (krh@bitplanet.net) said:
I fixed most of them, and filed a bug for urw-fonts, for which I'm not in the acl. Are there other font packages pulling in chkfontpath?
According to repoquery, the following require chkfontpath:
fonts-KOI8-R-75dpi-0:1.0-9.1.1.noarch efont-unicode-bdf-0:0.4.2-6.1.fc6.noarch fonts-KOI8-R-100dpi-0:1.0-9.1.1.noarch fonts-ISO8859-2-0:1.0-17.1.noarch fonts-japanese-0:0.20061016-6.fc7.noarch fonts-korean-0:1.0.11-9.1.1.noarch fonts-x11-apl-0:4.20.2-19.fc8.x86_64 wqy-bitmap-fonts-0:0.8.1-6.fc8.noarch fonts-truetype-apl-0:4.20.2-19.fc8.x86_64 x3270-x11-0:3.3.4p7-5.fc6.x86_64 libdockapp-fonts-0:0.6.1-3.fc8.x86_64 fonts-ISO8859-2-100dpi-0:1.0-17.1.noarch grace-0:5.1.21-1.fc7.x86_64 urw-fonts-0:2.3-6.1.1.noarch fonts-chinese-0:3.03-4.fc7.noarch fonts-ISO8859-2-75dpi-0:1.0-17.1.noarch fonts-KOI8-R-0:1.0-9.1.1.noarch terminus-font-x11-0:4.20-5.fc6.noarch zvbi-fonts-0:0.2.25-1.fc8.x86_64
Bill
On 7/27/07, Bill Nottingham notting@redhat.com wrote:
Kristian Høgsberg (krh@bitplanet.net) said:
I fixed most of them, and filed a bug for urw-fonts, for which I'm not in the acl. Are there other font packages pulling in chkfontpath?
According to repoquery, the following require chkfontpath:
I put the list on the wiki page along with extended information about how to update the packages:
http://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS
Kristian
On 7/27/07, Matthias Clasen mclasen@redhat.com wrote:
Given that test1 is around the corner, I thought it might be a good idea to give a little status update on the features that the desktop team has been working on for F8:
what happend to compiz-fusion?
On Fri, 2007-07-27 at 18:50 +0200, dragoran wrote:
On 7/27/07, Matthias Clasen mclasen@redhat.com wrote: Given that test1 is around the corner, I thought it might be a good idea to give a little status update on the features that the desktop team has been working on for F8:
what happend to compiz-fusion?
Nothing. Kristian said he was going to look at updating compiz. It is not a new "feature", just a package update, really.
On Fri, 27 Jul 2007 13:02:55 -0400 Matthias Clasen mclasen@redhat.com wrote:
Nothing. Kristian said he was going to look at updating compiz. It is not a new "feature", just a package update, really.
Yet something that will immediately be visible to end users who poke at it. We have got to stop thinking about the work we do as just 'a package update'. If we're updating a package to a new upstream version that offers new stuff, YELL about it. Get some excitement going. Get some people interested in trying it out. We're far far too modest about the things we're doing or the things we're including. We've seen that others aren't, and they get all the glory.
On Fri, 2007-07-27 at 13:10 -0400, Jesse Keating wrote:
On Fri, 27 Jul 2007 13:02:55 -0400 Matthias Clasen mclasen@redhat.com wrote:
Nothing. Kristian said he was going to look at updating compiz. It is not a new "feature", just a package update, really.
Yet something that will immediately be visible to end users who poke at it. We have got to stop thinking about the work we do as just 'a package update'. If we're updating a package to a new upstream version that offers new stuff, YELL about it. Get some excitement going. Get some people interested in trying it out. We're far far too modest about the things we're doing or the things we're including. We've seen that others aren't, and they get all the glory.
Well, it is really just the version checklist you see when the release goes out: comes with the latest Gnome, X, KDE, ... I assume that list is assembled anyway, without tracking every single new version as a feature, with all the added overhead that it entails.
And I really don't think FESCO need to vote on compiz-fusion as an F8 feature.
On Fri, 27 Jul 2007 13:12:40 -0400 Matthias Clasen mclasen@redhat.com wrote:
Well, it is really just the version checklist you see when the release goes out: comes with the latest Gnome, X, KDE, ... I assume that list is assembled anyway, without tracking every single new version as a feature, with all the added overhead that it entails.
Again I think you underestimate how "cool" this will seem to people, they get their beryl like stuff with compiz. This is not insignificant. This is not just a version tick unless that's all you say about it. Ho hum, we have version 3 of blah. Big whoop. But if version 3 brings out Cool New Thing bar and baz and bang, that's FAR more exciting to talk about.
And I really don't think FESCO need to vote on compiz-fusion as an F8 feature.
Are we doing anything at all to our 'enable desktop effects' menu because of this? Do we have to coordinate with say the removal of beryl? Are there any config changes people will have to make (they want to keep their working beryl config but use it with -fusion?) Will the end user notice something? These are the types of things we want to list Features for, and yes, being a Feature comes with the small price tag of needing a FESCo rubber stamp, but that's really really not hard to do at all, and not really a big deal for FESCo to do this.
On Fri, 2007-07-27 at 13:19 -0400, Jesse Keating wrote:
These are the types of things we want to list Features for, and yes, being a Feature comes with the small price tag of needing a FESCo rubber stamp, but that's really really not hard to do at all, and not really a big deal for FESCo to do this.
It also comes with the not-quite-so-small price tag of filling out a feature approvat template in the wiki, and being bugged about updating it every 2 weeks...
On Fri, 27 Jul 2007 13:28:20 -0400 Matthias Clasen mclasen@redhat.com wrote:
It also comes with the not-quite-so-small price tag of filling out a feature approvat template in the wiki, and being bugged about updating it every 2 weeks...
Yes, being verbose about the work you're doing for Fedora is a terrible thing.
On Fri, 27 Jul 2007 13:55:31 -0400 Matthias Clasen mclasen@redhat.com wrote:
Being verbose not so much, more that fact that it feels like applying for a Fedora Mortgage - you have been pre-approved !
So what we're really arguing about is our tools right? And you're using our tools as an excuse not to do the work? That's cool, I can take that, sure our tools suck. But you know what, it's what we've got right now. Maybe if enough people are using them we'll get enough mindshare to improve the tools, because really, that's the argument I see most often. "I don't want to do $foo because the tools suck." Not that $foo is a bad idea (although it has been disguised as a bad idea like "$Foo is a terrible idea, it takes to long to do it with our tools.")
So really, if we're going to argue about the tools lets argue about them instead.
On 7/27/07, Matthias Clasen mclasen@redhat.com wrote:
Being verbose not so much, more that fact that it feels like applying for a Fedora Mortgage - you have been pre-approved !
I appreciate the status update to this list, but I'd have to concur with Jesse. We really need to find ways for the active developers to communicate their excitement about 'cool' things which are being worked on as widely as possible. Long term this will help with existing morale and it will help us attract potential new contributors, especially if we communicate interesting areas that could benefit from new involvement. Getting feature ideas into the feature road-mapping process early, increasing the chances of finding a new contributors who wants to help with the work. If we wait and talk about things until their are nearly completed, not only do we set ourselves up to be scooped by other people, but we miss an opportunity to use that feature to grow new community developer talent. If you have suggestions to streamline the feature road-mapping process to make it more worthwhile to use, I'd love to hear them.
-jef"For every feature status update to the wiki you post... you get a coupon for one free KK doughnut redeemable next time I am in your town of residence. Offer expires three months from the date of status posting. Offer not valid in Alaska."spaleta
On Fri, 2007-07-27 at 15:52 -0800, Jeff Spaleta wrote:
On 7/27/07, Matthias Clasen mclasen@redhat.com wrote:
Being verbose not so much, more that fact that it feels like applying for a Fedora Mortgage - you have been pre-approved !
I appreciate the status update to this list, but I'd have to concur with Jesse. We really need to find ways for the active developers to communicate their excitement about 'cool' things which are being worked on as widely as possible.
Blogs?
On 7/27/07, Colin Walters walters@redhat.com wrote:
Blogs?
I love the planet. I'd love the planet more if I could convince developers to do video entries where they were literally foaming at the mouth while attempting to describe the cool crap they were doing. Incoherent, frenetic ramblings which convey passion and excitement about whatever it is they are working on that they are actually passionate or excited about. But I also enjoy live sock puppet theater as a form of high cultural expression worthy of wearing a full tuxedo while in attendance. So take my opinion with a grain of salt.
The problem with the planet is.... it also includes post by idiots like me. The feature dashboard in the wiki gives a compelling view that... holy crap Fedora developers are doing a metric buttload of interesting things. The totality of the features, even wacky proposed no where near working features aimed for two releases away, generates a sense of momentum, instead of a sense of inertia. And its a sense of forward looking momentum that is we need to keep refueled.
-jef
Jeff Spaleta wrote:
On 7/27/07, Matthias Clasen mclasen@redhat.com wrote:
Being verbose not so much, more that fact that it feels like applying for a Fedora Mortgage - you have been pre-approved !
I appreciate the status update to this list, but I'd have to concur with Jesse. We really need to find ways for the active developers to communicate their excitement about 'cool' things which are being worked on as widely as possible.
So, there are two things here.
1. The Board/FESCo needs this information. I'll agree using those hats.
2. The current way of getting the information is causing headache. "If you want to be allowed to work, you need to plead your case to the Don, and then every two weeks you need to pay up with status reports else your feature gets sent to sleep with the fishes." Using my maintainer hat, I'll agree with Matthias this policy is not ideal.
The answer is to continue getting the information but to fix the means of doing so. We're effectively adding hassle rather than inviting people and facilitating communication, which is just wrong wrong WRONG.
Possible solutions:
* Go to a "point man". Appoint someone from e.g. the KDE Sig, Desktop team, Rel-Eng, etc to provide updates for all relevant features. This lets the engineers do the work, and lets others contribute esp if they aren't necessarily engineers and facilitates intra-team communication. * Ask for updates via IRC, casually. Maintainers tend to be quite responsive when asked casually vs in a formal capacity. It's just geek nature. Fedora needs to mold around they work, not the other way around. A "Feature Manager" would be suited to do this. * Monitor checkins/IRC chat. Slightly more agressive version of the previous. Probably not feasible. * ??? Other ideas here.
Christopher Aillon wrote:
The Board/FESCo needs this information. I'll agree using those hats.
The current way of getting the information is causing headache. "If
you want to be allowed to work, you need to plead your case to the Don, and then every two weeks you need to pay up with status reports else your feature gets sent to sleep with the fishes." Using my maintainer hat, I'll agree with Matthias this policy is not ideal.
I am not sure who anybody needs to plead to. FESCo approval is a simple check so that people don't end up putting things non-free software helpers in the roadmap or anything else like that. If we are tracking some features, they would need status reports. The need for that should be obvious.
Possible solutions:
- Go to a "point man". Appoint someone from e.g. the KDE Sig, Desktop
team, Rel-Eng, etc to provide updates for all relevant features. This lets the engineers do the work, and lets others contribute esp if they aren't necessarily engineers and facilitates intra-team communication.
Desktop doesn't have a SIG, a list of members, lead, regular irc meetings or a contact point documented unlike the other examples pointed out here but if they do the specs could easily have desktop SIG as the contact point instead of a specific person. That is in fact already the case for example, the spec for the KDE 4 plan where KDE SIG is the owner. Point man is Rex Dieter.
- Ask for updates via IRC, casually. Maintainers tend to be quite
responsive when asked casually vs in a formal capacity. It's just geek nature. Fedora needs to mold around they work, not the other way around. A "Feature Manager" would be suited to do this.
- Monitor checkins/IRC chat. Slightly more agressive version of the
previous. Probably not feasible.
Formal capacity vs informal chat seems to a matter of sending mails vs asking on IRC. IRC has several problems as a means of tracking features. Spec owners are distributed all over the world. Many of them don't do IRC. Finding which server or channels they hang out in can be difficult. You have to be in the same time zone etc. Sounds tedious to me.
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
I am not sure who anybody needs to plead to. FESCo approval is a simple check
... If it involves creating a 10-entry wiki page, waiting 1-2 weeks to get on the FESCo schedule, attending a meeting, waiting another week for status to get updated... I wouldn't call it 'simple'.
Bill
Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
I am not sure who anybody needs to plead to. FESCo approval is a simple check
... If it involves creating a 10-entry wiki page, waiting 1-2 weeks to get on the FESCo schedule, attending a meeting, waiting another week for status to get updated... I wouldn't call it 'simple'.
Copy template, edit it quickly to add some information. I did it for XULRunner. Hardly took 10 mins. It will get on the FESCO schedule automatically. Attending a meeting is optional. When you create the spec, subscribe to it to know the status. Let people know the progress now and then or update the wiki directly.
Looks simple to me.
Rahul
Rahul Sundaram wrote:
Christopher Aillon wrote:
The Board/FESCo needs this information. I'll agree using those hats.
The current way of getting the information is causing headache.
"If you want to be allowed to work, you need to plead your case to the Don, and then every two weeks you need to pay up with status reports else your feature gets sent to sleep with the fishes." Using my maintainer hat, I'll agree with Matthias this policy is not ideal.
I am not sure who anybody needs to plead to. FESCo approval is a simple check so that people don't end up putting things non-free software helpers in the roadmap or anything else like that. If we are tracking some features, they would need status reports. The need for that should be obvious.
As was pointed out on other lists, that doesn't stop anyone from putting in non-free software. They simply have to not write a feature page on the wiki and just do it. We can take recourse, but the FESCo approval process does not stop it if someone wants to do it. So, one could make the argument that FESCo approval should be needed only if someone is unsure about whether it is a good idea; not for everything, which would be more of a "steering" role IMO.
Possible solutions:
- Go to a "point man". Appoint someone from e.g. the KDE Sig, Desktop
team, Rel-Eng, etc to provide updates for all relevant features. This lets the engineers do the work, and lets others contribute esp if they aren't necessarily engineers and facilitates intra-team communication.
Desktop doesn't have a SIG, a list of members, lead, regular irc meetings or a contact point documented
Yeah. Now if only there was a member of desktop that was on the board/fesco that had stated they wanted to facilitate communication between the desktop team and both the board and fesco as part of their mission statement prior to successfully being elected....
- Ask for updates via IRC, casually. Maintainers tend to be quite
responsive when asked casually vs in a formal capacity. It's just geek nature. Fedora needs to mold around they work, not the other way around. A "Feature Manager" would be suited to do this.
- Monitor checkins/IRC chat. Slightly more agressive version of the
previous. Probably not feasible.
Formal capacity vs informal chat seems to a matter of sending mails vs asking on IRC. IRC has several problems as a means of tracking features. Spec owners are distributed all over the world. Many of them don't do IRC. Finding which server or channels they hang out in can be difficult. You have to be in the same time zone etc. Sounds tedious to me.
Or we could make you do it since you seem to never sleep and thus are in everyone's timezone. ;-)
Christopher Aillon wrote:
As was pointed out on other lists, that doesn't stop anyone from putting in non-free software. They simply have to not write a feature page on the wiki and just do it. We can take recourse, but the FESCo approval process does not stop it if someone wants to do it. So, one could make the argument that FESCo approval should be needed only if someone is unsure about whether it is a good idea; not for everything, which would be more of a "steering" role IMO.
... which is fine by me. I don't think a FESCo approval is really necessary for each and every feature. FESCo can generally have a "keep an eye on the feature list" item in their schedule all the time and ask questions if needed.
Yeah. Now if only there was a member of desktop that was on the board/fesco that had stated they wanted to facilitate communication between the desktop team and both the board and fesco as part of their mission statement prior to successfully being elected....
In that case you should list yourself as the feature own for all the desktop related specs. If desktop team is a SIG it should act more like all the other SIG's in Fedora and list the lead, members, tasks to do etc.
What the desktop team does was pretty opaque to me and that has improved quite a lot these days since I can read the feature list and this mailing list isn't dead either.
KDE SIG is a very good example to follow since they do open weekly irc meetings too which is pretty good to keep track of what that team is doing.
Or we could make you do it since you seem to never sleep and thus are in everyone's timezone. ;-)
That would work too, seriously. If you want me as a gateway for some of the specs, let me know.
Rahul
Matthias Clasen wrote:
Well, it is really just the version checklist you see when the release goes out: comes with the latest Gnome, X, KDE, ... I assume that list is assembled anyway, without tracking every single new version as a feature, with all the added overhead that it entails.
And I really don't think FESCO need to vote on compiz-fusion as an F8 feature.
It boils down to this. Please tell us all what you are working on. People have been asking and we need to communicate information to them. Compiz fusion might just be a version bump to maintainers but for end users it brings in major new functionality. So tell them what you are planning to do with it.
Writing a spec that follows the template and throwing in the information that is already in the thread is 10 minutes week. Sending a bi weekly status note in probably another 5. Not a big deal at all. Please do it.
Rahul
Matthias Clasen wrote:
Well, it is really just the version checklist you see when the release goes out: comes with the latest Gnome, X, KDE, ... I assume that list is assembled anyway, without tracking every single new version as a feature, with all the added overhead that it entails.
And I really don't think FESCO need to vote on compiz-fusion as an F8 feature.
It boils down to this. Please tell us all what you are working on. People have been asking and we need to communicate information to them. Compiz fusion might just be a version bump to maintainers but for end users it brings in major new functionality. So tell them what you are planning to do with it.
Writing a spec that follows the template and throwing in the information that is already in the thread is 10 minutes week. Sending a bi weekly status note in probably another 5. Not a big deal at all. Please do it.
Rahul
On 7/27/07, dragoran drago01@gmail.com wrote:
On 7/27/07, Matthias Clasen mclasen@redhat.com wrote:
Given that test1 is around the corner, I thought it might be a good idea to give a little status update on the features that the desktop team has been working on for F8:
what happend to compiz-fusion?
I've been punting this issue for a while; sorry about that, I should have been more involed in the debate there. I have two concerns about the proposed updates:
1) I'd rather not ship a git snap shot for fedora 8. If we know that there's a stable release on the horizon, that is, coming out withing the next 1 or 2 months, we can do an update, but if there's no expectation that a stable release is coming out in time for fedora 8, I'd rather wait. The concern here is mainly that we're starting to ship externally packaged plugins for compiz and we need an upstream maintenence branch (0.6) that maintains a stable plugin API. I don't know what the compiz schedule is for the current development branch but it still sees plugin API breaking changes at this time. As far as I know, there's hasn't been a stable release since the merge, but if most of the API changes to allow beryl plugins to run have been merged, maybe it would be a good idea to wind down and release 0.6?
2) I don't know what the current status is on config plugins. I know there is interest in getting ccp configured as the default backend, but I don't know what the benefits of that is over gconf. I understand that gconf is GNOME specific, but I was thinking that the better approach was to move gconf and gtk-window-decorator to a new compiz-gnome subpackage. What is the compiz upstream position? My position is that we need to use the native configuration system of the desktop environment (that is, gconf when running under GNOME) and reinventing new config file formats is almost never the right approach (no matter how fun it is).
Kristian
On 7/27/07, Kristian Høgsberg krh@bitplanet.net wrote:
On 7/27/07, dragoran drago01@gmail.com wrote:
On 7/27/07, Matthias Clasen mclasen@redhat.com wrote:
Given that test1 is around the corner, I thought it might be a good
idea
to give a little status update on the features that the desktop team
has
been working on for F8:
what happend to compiz-fusion?
I've been punting this issue for a while; sorry about that, I should have been more involed in the debate there. I have two concerns about the proposed updates:
- I'd rather not ship a git snap shot for fedora 8. If we know that
there's a stable release on the horizon, that is, coming out withing the next 1 or 2 months, we can do an update, but if there's no expectation that a stable release is coming out in time for fedora 8, I'd rather wait. The concern here is mainly that we're starting to ship externally packaged plugins for compiz and we need an upstream maintenence branch (0.6) that maintains a stable plugin API. I don't know what the compiz schedule is for the current development branch but it still sees plugin API breaking changes at this time. As far as I know, there's hasn't been a stable release since the merge, but if most of the API changes to allow beryl plugins to run have been merged, maybe it would be a good idea to wind down and release 0.6?
I asked about this a while ago and David wanted to release a 0.5.2 and a 0.6.0 a bit later... what happend to this? David?
2) I don't know what the current status is on config plugins. I know
there is interest in getting ccp configured as the default backend, but I don't know what the benefits of that is over gconf. I understand that gconf is GNOME specific, but I was thinking that the better approach was to move gconf and gtk-window-decorator to a new compiz-gnome subpackage. What is the compiz upstream position? My position is that we need to use the native configuration system of the desktop environment (that is, gconf when running under GNOME) and reinventing new config file formats is almost never the right approach (no matter how fun it is).
ccp has a gconf and a konf backend so we can just use this. the benefit over gconf are the configuration tools that already exist for it. there was a thread on fedora-devel-list about this...
Matthias Clasen wrote:
Given that test1 is around the corner, I thought it might be a good idea to give a little status update on the features that the desktop team has been working on for F8:
NoMoreXFS - Done.
There are dozens of font packages that would need to changed still. Might be useful if you drop in a announcement to fedora-devel-announce letting the maintainers know what they need to do.
Bigboard - In test1, run god-mode 1 to turn it on and play with it.
god-mode is a awful name.
Rahul
On Sat, 28 Jul 2007 16:40:13 +0530 Rahul Sundaram sundaram@fedoraproject.org wrote:
god-mode is a awful name.
It's a throwback to many ID games such as Doom and Quake, where 'god-mode' meant that you could not be killed.
On Sat, 2007-07-28 at 07:11 -0400, Jesse Keating wrote:
On Sat, 28 Jul 2007 16:40:13 +0530 Rahul Sundaram sundaram@fedoraproject.org wrote:
god-mode is a awful name.
It's a throwback to many ID games such as Doom and Quake, where 'god-mode' meant that you could not be killed.
Bah, but in this case, using god-mode kills(*) my classic panel setup, so it's at least a little bit misleading, don't you think?
(*): It did that the last time I tried it out and I probably won't try it out again unless somebody vouchsafes for it not treading over my carefully crafted configuration again. If you want me to try something out, I want to be sure that I can easily go back to what I had before if I don't like it(**).
(**): The benefit of the Bigboard menu learning what applications I like to use is much outweighed by its eating a good share of my screen real estate _permanently_. My well trained panels hide themselves like the good servants they should emulate -- invisible when not needed. Panels that don't hide themselves are okay, but the Bigboard menu wastes too much space considering that I need it say < 5% of the time (I'm making that number up), the other > 95% of the time it's just in the way.
I'd be happy if I could combine the (auto-hiding, self-learning) Bigboard menu with the classical panels I have today.
Be my heroes and tell me that my concerns will be addressed in the final version ;-).
Nils
On Sat, 2007-07-28 at 19:15 +0200, Nils Philippsen wrote:
On Sat, 2007-07-28 at 07:11 -0400, Jesse Keating wrote:
On Sat, 28 Jul 2007 16:40:13 +0530 Rahul Sundaram sundaram@fedoraproject.org wrote:
god-mode is a awful name.
It's a throwback to many ID games such as Doom and Quake, where 'god-mode' meant that you could not be killed.
Yeah...it is silly though; just changed it in svn.
Bah, but in this case, using god-mode kills(*) my classic panel setup, so it's at least a little bit misleading, don't you think?
It shouldn't overwrite the existing config; the code just adds new panel configuration to GConf, then changes the default, effectively.
(*): It did that the last time I tried it out and I probably won't try it out again unless somebody vouchsafes for it not treading over my carefully crafted configuration again. If you want me to try something out, I want to be sure that I can easily go back to what I had before if I don't like it(**).
"god-mode 0" should have reverted to the old config; however bonobo-activation-server sometimes locks up during panel changes, and so you may have to restart the session (and killall bonobo-activation-server).
(**): The benefit of the Bigboard menu learning what applications I like to use is much outweighed by its eating a good share of my screen real estate _permanently_.
Well, we have the "Minimize to panel" option, but it's not a very good solution yet. We'd talked about a design where it would minimize very small, then slide out on top of apps, then go back when you launch an app or something else.
Be my heroes and tell me that my concerns will be addressed in the final version ;-).
I think so, yep.
desktop@lists.stg.fedoraproject.org
-
Bill Nottingham -
Christopher Aillon -
Colin Walters -
drago01 -
Jef Spaleta -
Jesse Keating -
Kristian Høgsberg -
Matthias Clasen -
Nils Philippsen -
Rahul Sundaram