As of tomorrow's rawhide [1], gnome-session will no longer treat llvmpipe as an unsupported driver. This means gnome-shell will run even on hardware without a native 3D driver, including virt guests.
There are probably bugs! I've done some quick tests on the hardware I have handy and in kvm, and things do appear to work. You, lucky contestant, might have a different experience. If you do, bugzilla is standing by and ready to take your call; please file against the 'mesa' component and set me as the assignee. In the meantime you can still get to fallback mode through the Graphics section of the System Info control panel.
Very little performance work has been done on this yet - like, literally, none - though there are some things you can do [2]. Outside of virt you will probably want to tell your driver to use ShadowFB in xorg.conf. This will disable hardware acceleration, but in exchange you won't be doing very slow GetImages all the time to get textures loaded into the compositor. In virt, however, the double-buffering done by ShadowFB just slows you down, so you're probably best off switching your driver to NoAccel instead.
The vesa driver should get this right for you already, as should cirrus under virt.
Beyond that, most of the performance work is going to require new kernel and Mesa features. For details, please see:
https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering
If you're interested in contributing to this effort, please follow up on dri-devel@lists.freedesktop.org.
[1] - In particular, you'll need these packages or newer for things to work:
mesa-*-7.11-9.fc17 cogl-1.8.2-4.fc17 gnome-session-3.3.1-2.fc17
[2] - It's something of a policy decision to get some of these things "right" by default, because you're deciding to throw away hardware accel on old chips, and some people who aren't using gnome-shell might think that's worth keeping. We'll figure something out, I'm sure, but contributions are most welcome.
- ajax
On Thu, 2011-11-03 at 17:57 -0400, Adam Jackson wrote:
As of tomorrow's rawhide [1], gnome-session will no longer treat llvmpipe as an unsupported driver. This means gnome-shell will run even on hardware without a native 3D driver, including virt guests.
I said on IRC, but just to reiterate, this is completely awesome work, major congratulations! I alerted Phoronix already ;)
Adam Jackson <ajax <at> redhat.com> writes:
As of tomorrow's rawhide [1], gnome-session will no longer treat llvmpipe as an unsupported driver. This means gnome-shell will run even on hardware without a native 3D driver, including virt guests.
For all of us gnome-shell sceptics that prefer the fallback mode, does that mean that mutter will then be default WM for everything? Or does it mean that we'll be evicted from the Gnome user space completely?
-- Bojan
On Fri, 2011-11-04 at 03:42 +0000, Bojan Smojver wrote:
Adam Jackson <ajax <at> redhat.com> writes:
As of tomorrow's rawhide [1], gnome-session will no longer treat llvmpipe as an unsupported driver. This means gnome-shell will run even on hardware without a native 3D driver, including virt guests.
For all of us gnome-shell sceptics that prefer the fallback mode, does that mean that mutter will then be default WM for everything? Or does it mean that we'll be evicted from the Gnome user space completely?
That's really a policy decision for the GNOME / Fedora desktop teams, not for ajax.
But based on what they've said in the past, I expect that once most hardware that previously needed the fallback mode is covered, fallback mode will die. AIUI, fallback mode isn't meant to be a GNOME 2-by-stealth for Shell refuseniks, it's purely an attempt to accommodate hardware which doesn't support Shell.
Adam Williamson <awilliam <at> redhat.com> writes:
That's really a policy decision for the GNOME / Fedora desktop teams, not for ajax.
Yeah, I got that bit. But I'm sure all you folks are in the know, so I asked.
But based on what they've said in the past, I expect that once most hardware that previously needed the fallback mode is covered, fallback mode will die. AIUI, fallback mode isn't meant to be a GNOME 2-by-stealth for Shell refuseniks, it's purely an attempt to accommodate hardware which doesn't support Shell.
Right. OK, fair enough. Thanks for the info.
I guess for me, it's going to be either "find-enough-extensions-to-never-see-overview-in-shell" or another desktop. Ah, well...
-- Bojan
On Fri, 2011-11-04 at 06:23 +0000, Bojan Smojver wrote:
Adam Williamson <awilliam <at> redhat.com> writes:
That's really a policy decision for the GNOME / Fedora desktop teams, not for ajax.
Yeah, I got that bit. But I'm sure all you folks are in the know, so I asked.
No more than anyone - there really is no cabal ;) All I know is what the GNOME / desktop team have said in public, but what they've said seems to point in a Shell-y direction, to me.
Adam Williamson <awilliam <at> redhat.com> writes:
Yeah, I got that bit. But I'm sure all you folks are in the know, so I asked.
No more than anyone - there really is no cabal ;) All I know is what the GNOME / desktop team have said in public, but what they've said seems to point in a Shell-y direction, to me.
I meant, on average, a guy working for Red Hat would know a whole lot more about Gnome than myself, who's got zero knowledge.
Anyhow, it's not the shell per se that's the problem. It's the overview mode - so bloody annoying with its constant expose in/out animations, lack of desktop visibility etc. I know - it looks great on YouTube. Not so great when you have use it for work all day.
Ah, never mind - just whinging...
-- Bojan
On Fri, 4 Nov 2011 10:25:54 +0000 (UTC) Bojan Smojver bojan@rexursive.com wrote:
Adam Williamson <awilliam <at> redhat.com> writes:
Yeah, I got that bit. But I'm sure all you folks are in the know, so I asked.
No more than anyone - there really is no cabal ;) All I know is what the GNOME / desktop team have said in public, but what they've said seems to point in a Shell-y direction, to me.
I meant, on average, a guy working for Red Hat would know a whole lot more about Gnome than myself, who's got zero knowledge.
Anyhow, it's not the shell per se that's the problem. It's the overview mode - so bloody annoying with its constant expose in/out animations, lack of desktop visibility etc. I know - it looks great on YouTube. Not so great when you have use it for work all day.
Ah, never mind - just whinging...
Bojan, Install xfce. You'll be happy w/that.
-sv
On 4 November 2011 13:21, seth vidal skvidal@fedoraproject.org wrote:
On Fri, 4 Nov 2011 10:25:54 +0000 (UTC) Bojan Smojver bojan@rexursive.com wrote:
Adam Williamson <awilliam <at> redhat.com> writes:
Yeah, I got that bit. But I'm sure all you folks are in the know, so I asked.
No more than anyone - there really is no cabal ;) All I know is what the GNOME / desktop team have said in public, but what they've said seems to point in a Shell-y direction, to me.
I meant, on average, a guy working for Red Hat would know a whole lot more about Gnome than myself, who's got zero knowledge.
Anyhow, it's not the shell per se that's the problem. It's the overview mode - so bloody annoying with its constant expose in/out animations, lack of desktop visibility etc. I know - it looks great on YouTube. Not so great when you have use it for work all day.
Ah, never mind - just whinging...
Install xfce. You'll be happy w/that.
This is essentially giving up. It's frustrating to be stuck on overview mode on a four core machine while gnome-shell is doing /something/ but you don't know what. If it worked fluidly it would be okay. Actually, the responsiveness issue isn't limited just to overview, but that's where it's most annoying because it completely cuts you off. (And ten seconds to get the applications list, really?)
On Fri, 4 Nov 2011 14:10:57 +0000 Ian Malone ibmalone@gmail.com wrote:
On 4 November 2011 13:21, seth vidal skvidal@fedoraproject.org wrote:
On Fri, 4 Nov 2011 10:25:54 +0000 (UTC) Bojan Smojver bojan@rexursive.com wrote:
Adam Williamson <awilliam <at> redhat.com> writes:
Yeah, I got that bit. But I'm sure all you folks are in the know, so I asked.
No more than anyone - there really is no cabal ;) All I know is what the GNOME / desktop team have said in public, but what they've said seems to point in a Shell-y direction, to me.
I meant, on average, a guy working for Red Hat would know a whole lot more about Gnome than myself, who's got zero knowledge.
Anyhow, it's not the shell per se that's the problem. It's the overview mode - so bloody annoying with its constant expose in/out animations, lack of desktop visibility etc. I know - it looks great on YouTube. Not so great when you have use it for work all day.
Ah, never mind - just whinging...
Install xfce. You'll be happy w/that.
This is essentially giving up. It's frustrating to be stuck on overview mode on a four core machine while gnome-shell is doing /something/ but you don't know what. If it worked fluidly it would be okay. Actually, the responsiveness issue isn't limited just to overview, but that's where it's most annoying because it completely cuts you off. (And ten seconds to get the applications list, really?)
It's not giving up. It's moving on to something which does what you want.
There's no malice here - just sense.
-sv
On Fri, 2011-11-04 at 14:10 +0000, Ian Malone wrote:
It's frustrating to be stuck on overview mode on a four core machine while gnome-shell is doing /something/ but you don't know what. If it worked fluidly it would be okay. Actually, the responsiveness issue isn't limited just to overview, but that's where it's most annoying because it completely cuts you off. (And ten seconds to get the applications list, really?)
I hate that, too -- the shell deserves some tuning to not always show up with about 5%-10% CPU consumed, in the top 3 of top (ha!) -- but to be fair, opening the GNOME 2 panel application menu for the first time wasn't quicker (at least for me).
Nils
On Fri, Nov 4, 2011 at 3:10 PM, Ian Malone ibmalone@gmail.com wrote:
On 4 November 2011 13:21, seth vidal skvidal@fedoraproject.org wrote:
On Fri, 4 Nov 2011 10:25:54 +0000 (UTC) Bojan Smojver bojan@rexursive.com wrote:
Adam Williamson <awilliam <at> redhat.com> writes:
Yeah, I got that bit. But I'm sure all you folks are in the know, so I asked.
No more than anyone - there really is no cabal ;) All I know is what the GNOME / desktop team have said in public, but what they've said seems to point in a Shell-y direction, to me.
I meant, on average, a guy working for Red Hat would know a whole lot more about Gnome than myself, who's got zero knowledge.
Anyhow, it's not the shell per se that's the problem. It's the overview mode - so bloody annoying with its constant expose in/out animations, lack of desktop visibility etc. I know - it looks great on YouTube. Not so great when you have use it for work all day.
Ah, never mind - just whinging...
Install xfce. You'll be happy w/that.
This is essentially giving up. It's frustrating to be stuck on overview mode on a four core machine while gnome-shell is doing /something/ but you don't know what. If it worked fluidly it would be okay. Actually, the responsiveness issue isn't limited just to overview, but that's where it's most annoying because it completely cuts you off. (And ten seconds to get the applications list, really?)
That's what people call "bugs" please file them (upstream) so that we can fix them.
Tell us again where to find that "gnome shell for dummies" doc?
I tried to give it a fair trial, but I found it so non-intuitive/counter-intuitive that I gave up after an hour and switched to Forced Fallback Mode.
On Fri, Nov 4, 2011 at 2:53 PM, Kaleb S. KEITHLEY kkeithle@redhat.com wrote:
Tell us again where to find that "gnome shell for dummies" doc?
The cheat sheet? http://live.gnome.org/GnomeShell/CheatSheet
I tried to give it a fair trial, but I found it so non-intuitive/counter-intuitive that I gave up after an hour and switched to Forced Fallback Mode. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 4 November 2011 14:36, drago01 drago01@gmail.com wrote:
On Fri, Nov 4, 2011 at 3:10 PM, Ian Malone ibmalone@gmail.com wrote:
This is essentially giving up. It's frustrating to be stuck on overview mode on a four core machine while gnome-shell is doing /something/ but you don't know what. If it worked fluidly it would be okay. Actually, the responsiveness issue isn't limited just to overview, but that's where it's most annoying because it completely cuts you off. (And ten seconds to get the applications list, really?)
That's what people call "bugs" please file them (upstream) so that we can fix them.
Somewhere like bugzilla perhaps? https://bugzilla.redhat.com/show_bug.cgi?id=743250
If I filed every bug in the distro in upstream I'd have a dozen different bugzilla accounts by now.
On Fri, Nov 04, 2011 at 06:23:02PM +0100, Kevin Kofler wrote:
Ian Malone wrote:
If I filed every bug in the distro in upstream I'd have a dozen different bugzilla accounts by now.
So what? Maintainers are not messengers, they have other work to do than forwarding the bugs you're too lazy to file directly at the right place.
Shipping bug-free software is the job of maintainers. It's reasonable to ask a reporter to take an issue upstream if you feel that that'll result in the bug being fixed faster, but there's no reason to mandate that and it certainly doesn't match the common use of bugzilla.
On Fri, Nov 4, 2011 at 6:35 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Fri, Nov 04, 2011 at 06:23:02PM +0100, Kevin Kofler wrote:
Ian Malone wrote:
If I filed every bug in the distro in upstream I'd have a dozen different bugzilla accounts by now.
So what? Maintainers are not messengers, they have other work to do than forwarding the bugs you're too lazy to file directly at the right place.
Shipping bug-free software is the job of maintainers. It's reasonable to ask a reporter to take an issue upstream if you feel that that'll result in the bug being fixed faster, but there's no reason to mandate that and it certainly doesn't match the common use of bugzilla.
Argh I didn't intend to start this kind of discussion by "(upstream)" I just meant "I prefer upstream" ... I didn't mandate anything.
On Fri, Nov 4, 2011 at 9:35 AM, Matthew Garrett mjg59@srcf.ucam.org wrote:
Shipping bug-free software is the job of maintainers. It's reasonable to ask a reporter to take an issue upstream if you feel that that'll result in the bug being fixed faster, but there's no reason to mandate that and it certainly doesn't match the common use of bugzilla.
My personal policy.
1) If I can reproduce it, and I agree that its a bug, I'll try to drive it forward and tell the reporter to poke me in the eye on some reminder timescale..because you know..life happens..and reminders are good.
2) if either of those two pre-conditions aren't satisfied, I encourage them to file it upstream and hand be back a reference so I can track it and respond if there's additional information needed that the impacted user doesn't know how to provide. But at the end of the day, I feel its most important to have upstream talking directly with the person who can reproduce the problem. If I can't, I'm just a lossy communication medium.
-jef
On Fri, 2011-11-04 at 10:17 -0800, Jef Spaleta wrote:
On Fri, Nov 4, 2011 at 9:35 AM, Matthew Garrett mjg59@srcf.ucam.org wrote:
Shipping bug-free software is the job of maintainers. It's reasonable to ask a reporter to take an issue upstream if you feel that that'll result in the bug being fixed faster, but there's no reason to mandate that and it certainly doesn't match the common use of bugzilla.
My personal policy.
- If I can reproduce it, and I agree that its a bug, I'll try to
drive it forward and tell the reporter to poke me in the eye on some reminder timescale..because you know..life happens..and reminders are good.
- if either of those two pre-conditions aren't satisfied, I encourage
them to file it upstream and hand be back a reference so I can track it and respond if there's additional information needed that the impacted user doesn't know how to provide. But at the end of the day, I feel its most important to have upstream talking directly with the person who can reproduce the problem. If I can't, I'm just a lossy communication medium.
That's exactly the same policy I apply as well.
...snip...
Just another datapoint, my personal policy here is:
a) ask the reporter if they could report it upstream, as they will be able to answer questions and advocate for their bug much better that I can in some cases.
b) If they say no, and I agree it's a bug/issue that should be addressed, then I report it upstream and try to bridge between fedora reporter and upstream. If something breaks down, too bad.
kevin
On Fri, Nov 4, 2011 at 12:23 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Ian Malone wrote:
If I filed every bug in the distro in upstream I'd have a dozen different bugzilla accounts by now.
So what? Maintainers are not messengers, they have other work to do than forwarding the bugs you're too lazy to file directly at the right place.
While I agree it can be a pain, don't you want to know if a user is having problems with a package you're responsible for? If they file it upstream there's a chance you will not find out about it, nor would you know when it's fixed and a new package should be built.
Richard
On 4 November 2011 17:23, Kevin Kofler kevin.kofler@chello.at wrote:
Ian Malone wrote:
If I filed every bug in the distro in upstream I'd have a dozen different bugzilla accounts by now.
So what? Maintainers are not messengers, they have other work to do than forwarding the bugs you're too lazy to file directly at the right place.
Is there any point in me reporting any bug in Fedora bugzilla ever then?
On 11/04/2011 05:39 PM, Ian Malone wrote:
On 4 November 2011 17:23, Kevin Koflerkevin.kofler@chello.at wrote:
Ian Malone wrote:
If I filed every bug in the distro in upstream I'd have a dozen different bugzilla accounts by now.
So what? Maintainers are not messengers, they have other work to do than forwarding the bugs you're too lazy to file directly at the right place.
Is there any point in me reporting any bug in Fedora bugzilla ever then?
Sure, but understand that it may not be as effective as reporting upstream. I think it is useful for tracking purposes and for other Fedora users to find (and why I hate the closed->upstream approach). Sometimes it really is a bug in the Fedora package or in interaction with Fedora libraries.
But many (most) Fedora packagers are over worked or do this in their very limited free time and are almost certainly not as experienced with the code as the upstream maintainers.
As an example, I recently filed a bug against ghostscript. Now, Tim Waugh is a great guy and often very responsive, but this time nothing happened for a bit (I'm guessing he was busy :-). So I filed upstream and it was fixed in a day. I notified Tim of the fix in the Fedora bug and an update was shortly on its way (courtesy of that nice Tim guy).
Yes, I have dozens of accounts in upstream issue trackers. No big deal. I want the issues I'm running up against fixed as soon as possible and filing upstream I've found is the most effective means. Filing in both is even better. But I won't call you lazy if you don't :)
Am 05.11.2011 01:50, schrieb Orion Poplawski:
On 11/04/2011 05:39 PM, Ian Malone wrote:
On 4 November 2011 17:23, Kevin Koflerkevin.kofler@chello.at wrote:
Ian Malone wrote:
If I filed every bug in the distro in upstream I'd have a dozen different bugzilla accounts by now.
So what? Maintainers are not messengers, they have other work to do than forwarding the bugs you're too lazy to file directly at the right place.
Is there any point in me reporting any bug in Fedora bugzilla ever then?
yes - because most maintainers are having bugzilla-accounts upstream and reading the uptream-mailing-lists and are much more cooperative as the KDE SIG, especially Kevin Kofler
if you than report a bundle of new introduced bugs upstream you are told in the case of KDE yous hould file for every piece a seperate bugreport
guys this is not the way you can act with users treat them report exactly where and how you like it, a few peopole will do, most will never again report any bug and stop testing packages and later if there are too few testers maintainers are whining "why?"
Reindl Harald wrote:
yes - because most maintainers are having bugzilla-accounts upstream and reading the uptream-mailing-lists and are much more cooperative as the KDE SIG, especially Kevin Kofler
Yes, we have Bugzilla accounts upstream. But as I explained, upstream wants to talk to the actual person experiencing the bug, not to a middleman. Plus, we get many bug reports, it'd be very time-consuming for us to forward them all upstream, whereas you as a user (hopefully) have much fewer bug reports to deal with. It's not our job to play "stille Post" for you (a game which necessarily loses information with every middleman you introduce).
if you than report a bundle of new introduced bugs upstream you are told in the case of KDE yous hould file for every piece a seperate bugreport
Of course! It is just plain impossible to work with a "bug report" which conflates several, totally different issues, which need to be tracked and fixed separately. Upstream will also require one bug report per issue. It's part of the absolute basics of bug reporting. We just cannot track what's fixed and what's still open if we have multiple issues in one report, because a report can only be either open or closed.
guys this is not the way you can act with users treat them report exactly where and how you like it, a few peopole will do, most will never again report any bug and stop testing packages and later if there are too few testers maintainers are whining "why?"
Thankfully, not all users are as lazy and arrogant as you.
Kevin Kofler
Am 05.11.2011 20:18, schrieb Kevin Kofler:
Reindl Harald wrote:
yes - because most maintainers are having bugzilla-accounts upstream and reading the uptream-mailing-lists and are much more cooperative as the KDE SIG, especially Kevin Kofler
Yes, we have Bugzilla accounts upstream. But as I explained, upstream wants to talk to the actual person experiencing the bug, not to a middleman. Plus, we get many bug reports, it'd be very time-consuming for us to forward them all upstream, whereas you as a user (hopefully) have much fewer bug reports to deal with. It's not our job to play "stille Post" for you (a game which necessarily loses information with every middleman you introduce).
most maintainers see this different and only the fact that fedora-packages are mostly patched makes it not useful throw all upstream first
the sense of a distribution for users is have a centralized source for packages and problems, if your standard-answer is "report upstream" you are damaging the benefits of a distribution for users
i have filled MANY bugreports in the last years and really often some hours later there was a new version on koji, maintainer aksed to try this, confirmed as "works now" and the maintainer submitted his patch upstream and included it as long iht was not fixed upstream in the fedora-packages - this way users start to love fedora, the maintainers and all peopole from users, maintainers to upstream developers are happy - your way of handling bugreports is the exactly oppiste of this
if you than report a bundle of new introduced bugs upstream you are told in the case of KDE yous hould file for every piece a seperate bugreport
https://bugs.kde.org/show_bug.cgi?id=236025 is the best example that this is not useful - in this case some random guy decided to replace a whole io-subsytem from scratch without any knowledge what he is doing for POSSIBLE get better performance sometimes later which is not true in exactly this case because the limit is the network and not the kio-slave
after such a useless, not needed replacement force users open a bunch of bugreports instead revert the whole changes and release them if they are finished and useable is the wrong way
anyways: fact is that if you punsih users how to report bugs in such ways the result will be for MANY of them stop reporting bugs
On Sat, 05 Nov 2011 09:49:16 +0100, RH (Reindl) wrote:
guys this is not the way you can act with users treat them report exactly where and how you like it, a few peopole will do, most will never again report any bug and stop testing packages and later if there are too few testers maintainers are whining "why?"
If it's many users who are affected by the same bug, surely one of them can contribute a little bit and report the bug directly to the software developers. This is especially true for bugs the package maintainer cannot reproduce.
Refusal to help with testing and bug-reporting will backfire eventually. It will be one of the users who will start whining about a pet peeve bug.
Still, a user reporting a bug in Fedora bugzilla should get _some_ response rather sooner than later, even if it were a canned response or a fully automated one.
Btw, with ABRT, many users just dump their report into bugzilla with only a few added words (if at all) and without out paying attention to NEEDINFO or questions asked by the package maintainer(s).
On 5 November 2011 00:50, Orion Poplawski orion@cora.nwra.com wrote:
On 11/04/2011 05:39 PM, Ian Malone wrote:
On 4 November 2011 17:23, Kevin Koflerkevin.kofler@chello.at wrote:
Ian Malone wrote:
If I filed every bug in the distro in upstream I'd have a dozen different bugzilla accounts by now.
So what? Maintainers are not messengers, they have other work to do than forwarding the bugs you're too lazy to file directly at the right place.
Is there any point in me reporting any bug in Fedora bugzilla ever then?
Sure, but understand that it may not be as effective as reporting upstream. I think it is useful for tracking purposes and for other Fedora users to find (and why I hate the closed->upstream approach). Sometimes it really is a bug in the Fedora package or in interaction with Fedora libraries.
Absolutely agree, which is why my first response is to file in Fedora. Additionally Fedora will have a particular version of a given package, the maintainer hopefully knows more than me about differences and the current development of their packages, part of the role must be to facilitate communication with upstream. If there's one person reporting a bug they know nothing about then telling them to go upstream is fine, if five people have reported bugs in Fedora then it's probably necessary to take a larger role in coordinating with upstream.
Unless Fedora believes that the maintainer's responsibility stops at getting the package built successfully there is a communication element to the role. This includes things they can do without ever looking at code, like knowing about how the upstream for their package does things or knowing particular people to contact.
But many (most) Fedora packagers are over worked or do this in their very limited free time and are almost certainly not as experienced with the code as the upstream maintainers.
I don't expect a maintainer to fix a bug, I don't really expect them to post it upstream either if it's just me reporting it, but there did used to be at least a triage process.
Yes, I have dozens of accounts in upstream issue trackers. No big deal. I want the issues I'm running up against fixed as soon as possible and filing upstream I've found is the most effective means. Filing in both is even better. But I won't call you lazy if you don't :)
Thank you, I did object to being called lazy on the basis I don't first file every bug I see in the upstream. Package maintainers don't have a monopoly on being busy or having other commitments, but they have volunteered to take on some responsibility.
What would be nice would be the ability to forward bugs upstream from within bugzilla. Having dozens of accounts you hardly ever use becomes a maintenance issue: details like the last few times I reported gnome bugs directly I had to reset my password because I kept getting caught out by its length limits being different from most others or trying to sign up for a bugzilla account and finding your email is already registered, things like this are unnecessary overhead for everyone.
Ian Malone wrote:
What would be nice would be the ability to forward bugs upstream from within bugzilla.
Yes, definitely! But the problem is that getting it right is hard, and requires closer cooperation with upstream infrastructure than we currently have. (In particular, we'd like the bug to show up as reported by the original reporter in Fedora and/or with that original reporter CCed, without them having to register for an upstream account first.)
Kevin Kofler
Dne 5.11.2011 21:40, Kevin Kofler napsal(a):
Ian Malone wrote:
What would be nice would be the ability to forward bugs upstream from within bugzilla.
Yes, definitely! But the problem is that getting it right is hard, and requires closer cooperation with upstream infrastructure than we currently have. (In particular, we'd like the bug to show up as reported by the original reporter in Fedora and/or with that original reporter CCed, without them having to register for an upstream account first.)
Just to add "I told you so" http://article.gmane.org/gmane.linux.redhat.fedora.devel/79936
Unfortunately, bugzilla still doesn't support inter-site communication. List of the upstream (yes ;)) bugs concerning this could be provided upon the request. Also, I am quite sure, that a Perl hacker willing to help with their fixing would be warmly welcomed.
Best,
Matěj
Dne 5.11.2011 00:39, Ian Malone napsal(a):
Is there any point in me reporting any bug in Fedora bugzilla ever then?
Of course, there are plenty of bugs caused by our packaging or moments when one programs stomps on the other one's toes.
See https://bugzilla.redhat.com/page.cgi?id=fields.html#upstream: “We only keep bug open on redhat.com to track our immediate short-term TODO items, or issues with our patches/packaging, or because the upstream package in question has poor bug tracking.”
Matěj
On Fri, 04 Nov 2011 18:23:02 +0100 Kevin Kofler kevin.kofler@chello.at wrote:
If I filed every bug in the distro in upstream I'd have a dozen different bugzilla accounts by now.
So what? Maintainers are not messengers, they have other work to do than forwarding the bugs you're too lazy to file directly at the right place.
IMHO you are very, very wrong about this. A maintainer is fully responsible for the product he is delivering into the hands of users. Sending them to file bugs upstream means not doing maintainer's job.
Aside from the abdication of responsibility, there are a few technical problems with the idea as well. The need for a given user to allocate accounts and the resulting chilling effect is one downside, as already mentioned. The bug is not going anywhere if you make it harder for the user to file! Also, upstream often refuses to deal with distro bugs, and may ask to rebuild from the source or to use upstream-built releases.
-- Pete
Ian Malone <ibmalone <at> gmail.com> writes:
This is essentially giving up. It's frustrating to be stuck on overview mode on a four core machine while gnome-shell is doing /something/ but you don't know what. If it worked fluidly it would be okay.
For me, it goes further than that. I do not want overview mode - ever. Fast, slow - in any shape or form. It reduces visibility of my desktop in normal use, introduces kitchen sink approach to "doing something else", attacks me with unnecessary animations when I never asked for them etc. It's just silliness that should be dropped.
Just look at all the extensions that sprung up:
- extension to have apps menu on the top bar - extension to switch workspaces from the top bar - extension to have constant dash
Essentially, extensions to have Gnome 2.
PS. Yes, overview _still_ looks great on YouTube. :-)
-- Bojan
On 05.11.2011 01:09, Bojan Smojver wrote:
Ian Malone <ibmalone <at> gmail.com> writes:
This is essentially giving up. It's frustrating to be stuck on overview mode on a four core machine while gnome-shell is doing /something/ but you don't know what. If it worked fluidly it would be okay.
For me, it goes further than that. I do not want overview mode - ever. Fast, slow - in any shape or form. It reduces visibility of my desktop in normal use, introduces kitchen sink approach to "doing something else", attacks me with unnecessary animations when I never asked for them etc. It's just silliness that should be dropped.
Just look at all the extensions that sprung up:
- extension to have apps menu on the top bar
- extension to switch workspaces from the top bar
- extension to have constant dash
Essentially, extensions to have Gnome 2.
PS. Yes, overview _still_ looks great on YouTube. :-)
Yet look at all the happy users of default Gnome 3! I am one of them and I went directly from the tilling-WM Xmonad to gnome 3! So you can't say it's only for absolute noobs :). I installed it and it took about a week to get used to it so that I stopped thinking "why the heck did they do it" but instead started to understand the new Concepts. Today after about a Year of usage I have to say that its the best user interface that I ever used so far! The only negative points that I still don't get is the removal of the power of button (without config to change it). But yes there is an extension to add it again! So just because the rants are much more visible don't think it is the majority! ;)
enaut
w <at> googlemail.com> writes:
Yet look at all the happy users of
default Gnome 3!
I am one of them and I went directly
from the tilling-WM Xmonad to gnome
3! So you can't say it's only for
absolute noobs :). I installed it and
it took about a week to get used to it
so that I stopped thinking "why
the heck did they do it" but instead
started to understand the new
Concepts. Today after about a Year of
usage I have to say that its the
best user interface that I ever used so
far!
The only negative points that I still
don't get is the removal of the
power of button (without config to
change it). But yes there is an
extension to add it again! So just because the rants are much
more visible don't think it is the
majority! ;)
Please. What would you think of the system that when you click on FF starts FF, Evo and Gimp? I think you would say the system is broken.
Right now, if I want to start an app, the shell gives me zoom out, search, expose, workspaces, dash and apps, followed by zoom in. WTF? Seriously?
I am glad that you can take a lot of pain, but when things don't make sense, they don't make sense. No rant - just facts.
-- Bojan
On Sat, 2011-11-05 at 13:40 +0000, Bojan Smojver wrote:
w <at> googlemail.com> writes:
Yet look at all the happy users of
default Gnome 3!
I am one of them
[... snip ...]
Please. What would you think of the system that when you click on FF starts FF, Evo and Gimp? I think you would say the system is broken.
Right now, if I want to start an app, the shell gives me zoom out, search, expose, workspaces, dash and apps, followed by zoom in. WTF? Seriously?
Right now, if I want to start an app, I just hit alt+f2, type the first few letters, hit tab and then enter.
No zoom, no search, no expose, no workspaces, no dash.
Just see it that way: you have one powerful interface to do advanced stuff (reorganizing windows, editing your favorites, searching,...) and a few simple keyboard shortcuts to do those same actions faster: - alt+f2 to run an app - ctrl+alt+arrow up/down to change workspace
Etc...
Nothing broken here. Just convenience, efficiency and adaptation to my workflows, whether I'm trying to be productive or just relaxing.
I am glad that you can take a lot of pain,
He wrote he was happy with Gnome 3, which doesn't tell me he is capable of taking a lot of pain, rather that he is enjoying this environment.
And so am I.
In fact, I'm taking a lot of pain when I have to go back to Gnome 2, which I used to love before I moved to Gnome 3.
It's obvious that Gnome 3 doesn't work for you. Just use something else then, no one is forcing you to « take that pain ». At least two alternatives have been suggested already in this thread, so pick the one that works for you, and be happy with it, while others are happy with something else.
Mathieu Bridon <bochecha <at> fedoraproject.org> writes:
Right now, if I want to start an app, I just hit alt+f2, type the first few letters, hit tab and then enter.
No zoom, no search, no expose, no workspaces, no dash.
Just see it that way: you have one powerful interface to do advanced stuff (reorganizing windows, editing your favorites, searching,...) and a few simple keyboard shortcuts to do those same actions faster:
- alt+f2 to run an app
- ctrl+alt+arrow up/down to change workspace
Etc...
Tried and true advice for the broken _graphical_ UI - just use keyboard shortcuts, type etc. Straight back to the 80s.
Nothing broken here.
If _nothing_ was broken, you wouldn't have to resort to shortcuts (which can, of course, be added to most UIs - this is not in question).
It's obvious that Gnome 3 doesn't work for you.
It does - in fallback mode. It's very nice, actually. I would like to continue using Gnome, otherwise I wouldn't discuss any of it here.
-- Bojan
On Sat, 2011-11-05 at 13:40 +0000, Bojan Smojver wrote:
w <at> googlemail.com> writes:
Yet look at all the happy users of
default Gnome 3!
I am one of them and I went directly
from the tilling-WM Xmonad to gnome
3! So you can't say it's only for
absolute noobs :). I installed it and
it took about a week to get used to it
so that I stopped thinking "why
the heck did they do it" but instead
started to understand the new
Concepts. Today after about a Year of
usage I have to say that its the
best user interface that I ever used so
far!
The only negative points that I still
don't get is the removal of the
power of button (without config to
change it). But yes there is an
extension to add it again! So just because the rants are much
more visible don't think it is the
majority! ;)
Please. What would you think of the system that when you click on FF starts FF, Evo and Gimp? I think you would say the system is broken.
Right now, if I want to start an app, the shell gives me zoom out, search, expose, workspaces, dash and apps, followed by zoom in. WTF? Seriously?
I am glad that you can take a lot of pain, but when things don't make sense, they don't make sense. No rant - just facts.
You won't be able to convince Gnome3 zealots. Believe me, a lot of people tried.
Vote with your legs. Switch to a different desktop. A lot of people switched to xfce.
On Mon, 2011-11-07 at 14:33 +0100, Denys Vlasenko wrote:
You won't be able to convince Gnome3 zealots.
That's a bit harsh, I think. They are just very impressionable folk. :-)
Believe me, a lot of people tried.
I would like to believe that a rational argument eventually prevails.
Vote with your legs. Switch to a different desktop. A lot of people switched to xfce.
Yeah, it seems so.
I have a lot years invested in Gnome, helped fix many bugs by diligently reporting problems, chasing traces etc. Don't want to throw all that away just because one aspect of one program is not done right.
I also do not dislike gnome-shell per se. Many things are done right and make sense. Overview, on the other hand, looks like an implementation of RFC1925(6).
I think what will most likely happen is that someone out there will come up with an extension to nuke the Activities button and replace it with Applications button. And that will be the end of that discussion.
On Tue, 2011-11-08 at 09:31 +1100, Bojan Smojver wrote:
I think what will most likely happen is that someone out there will come up with an extension to nuke the Activities button and replace it with Applications button. And that will be the end of that discussion.
There's been one for months, and yet 'the end of that discussion' does not appear to have come, and not all Shell users use it.
http://intgat.tigress.co.uk/rmy/extensions/index.html
Adam Williamson <awilliam <at> redhat.com> writes:
There's been one for months, and yet 'the end of that discussion' does not appear to have come, and not all Shell users use it.
Yeah, guilty as charged on the discussion bit.
-- Bojan
On 11/08/2011 12:45 AM, Adam Williamson wrote:
On Tue, 2011-11-08 at 09:31 +1100, Bojan Smojver wrote:
I think what will most likely happen is that someone out there will come up with an extension to nuke the Activities button and replace it with Applications button. And that will be the end of that discussion.
There's been one for months, and yet 'the end of that discussion' does not appear to have come, and not all Shell users use it.
I also found the recent Linux Mint approach sensible. http://blog.linuxmint.com/?p=1851 They're getting lots of unity defectors. To me it seems like low hanging fruit to install some of these extensions + gnome-tweak-tool on Fedora and integrate these options into the settings panel (even as an "extra-settings" item that starts gnome-tweak-tool).
I realize that options are often a sign of incomplete software, but with direct user interaction, options can be a necessary evil to deal with people's tastes and expectations.
cheers, Pádraig.
On Tue, 2011-11-08 at 09:31 +1100, Bojan Smojver wrote:
On Mon, 2011-11-07 at 14:33 +0100, Denys Vlasenko wrote:
You won't be able to convince Gnome3 zealots.
That's a bit harsh, I think. They are just very impressionable folk. :-)
That's also a bit harsh I think, and I'd appreciate it if you could simply assume that we made the conscious choice to use the environment that works best for us.
Believe me, a lot of people tried.
I would like to believe that a rational argument eventually prevails.
So would I, but you seem to be just as much camped in your boots as you accuse us of being, and refuse the rational arguments we proposed.
So the only thing I can suggest now is that you simply agree to disagree and stop wasting everybody's bandwidth.
Vote with your legs. Switch to a different desktop. A lot of people switched to xfce.
Yeah, it seems so.
[... snip ...]
I think what will most likely happen is that someone out there will come up with an extension to nuke the Activities button and replace it with Applications button. And that will be the end of that discussion.
You probably want to switch to Linux Mint 12 when it comes out with their GSME enabled.
On Tue, 2011-11-08 at 09:31 +1100, Bojan Smojver wrote:
On Mon, 2011-11-07 at 14:33 +0100, Denys Vlasenko wrote:
You won't be able to convince Gnome3 zealots.
That's a bit harsh, I think. They are just very impressionable folk. :-)
Believe me, a lot of people tried.
I would like to believe that a rational argument eventually prevails.
This assumes that the choice of desktop is a purely rational one. It is not. People are different. Gnome 3 crowd implemented Gnome 3 Shell to *their* own liking. It makes sense to *them*.
Apparently they did not consider that a large group of users was quite happy with Gnome 2 desktop and did not need any revolutionary reshuffling in that area.
They don't listen to our arguments. It's like talking to a wall. I only hear endless "try it for a week, you'll like it" and "its the progress, stupid". I think such attitude towards your user base is arrogant and ultimately self-harming: users *will* change to alternatives with less arrogant developer team. And I will not hesitate to recommend that route to anyone who is pissed off by Gnome 3 Shell disaster of the UI design.
I have a lot years invested in Gnome, helped fix many bugs by diligently reporting problems, chasing traces etc. Don't want to throw all that away just because one aspect of one program is not done right.
Good luck then.
enaut wrote:
I am one of them and I went directly from the tilling-WM Xmonad to gnome 3! So you can't say it's only for absolute noobs :).
The fact that you were using a tiling WM first shows that you are much more willing to adapt to unconventional designs than most other users. I, for one, want my computer to work the way I learned and interiorized a computer works, any "innovative" interface destroys my automatisms and confuses me.
I'm using Plasma Desktop with the Classic menu (not the default fancy Kickoff), only 1 virtual desktop and only the default activity.
Kevin Kofler
Kevin Kofler <kevin.kofler <at> chello.at> writes:
I, for one, want my computer to work the way I learned and interiorized a computer works, any "innovative" interface destroys my automatisms and confuses me.
I'm using Plasma Desktop with the Classic menu (not the default fancy Kickoff), only 1 virtual desktop and only the default activity.
I'm not actually arguing against certain features of gnome-shell based on what I'm used to. For instance, I am not disputing that having an apps menu that can be searched and is both flat and nested is useful. I'm not disputing that having one panel is better than two, because it takes less precious desktop space. I'm not disputing that having search in general is useful etc.
What I'm disputing is usefulness of the overview. It brings nothing to the table - for anyone. Rationalisations for it as as funny as rationalisations against the taskbar. Usually we are told that users would be too confused by seeing workspaces/taskbar on the panel or some such. Who are these poor souls that get confused by having more visibility that also gives them the ability to directly navigate to where they want to go, while taking no more space from the desktop? With the taskbar, we've been told that it's not a true representation of running apps. The next piece of advice is usually that dash can also be used to switch tasks. I guess the dash is then a true representation of running apps. Probably because it's vertical. ;-)
With overview, shell introduces unnecessary view switches (at least two for each "other" task), UI elements user never asked for etc. Just makes things less visible, more cumbersome and slower to use. Not to mention annoying.
Just think of doing a cut and paste from one workspace to the next using shell and overview using nothing but GUI. I reckon you'd get a vertigo. :-)
-- Bojan
On Sun, Nov 6, 2011 at 3:04 AM, Bojan Smojver bojan@rexursive.com wrote:
Kevin Kofler <kevin.kofler <at> chello.at> writes:
I, for one, want my computer to work the way I learned and interiorized a computer works, any "innovative" interface destroys my automatisms and confuses me.
I'm using Plasma Desktop with the Classic menu (not the default fancy Kickoff), only 1 virtual desktop and only the default activity.
I'm not actually arguing against certain features of gnome-shell based on what I'm used to. For instance, I am not disputing that having an apps menu that can be searched and is both flat and nested is useful. I'm not disputing that having one panel is better than two, because it takes less precious desktop space. I'm not disputing that having search in general is useful etc.
What I'm disputing is usefulness of the overview. It brings nothing to the table
- for anyone. Rationalisations for it as as funny as rationalisations against
the taskbar. Usually we are told that users would be too confused by seeing workspaces/taskbar on the panel or some such.
Not true ... I recommend reading https://live.gnome.org/GnomeShell/Design/#Activities_Overview
drago01 <drago01 <at> gmail.com> writes:
Not true ... I recommend reading https://live.gnome.org/GnomeShell/Design/#Activities_Overview
I read that a long, long time ago, of course. In fact, I have written a constructive critique of Gnome 3 many months ago, based to a large degree on the very document you pointed to. Critique still holds, unfortunately. You can google it.
The existence of all those extensions that bring back sanity (apps menu in normal view, workspaces in normal view, persistent dash for switching tasks in normal view etc.) is the proof of the ultimate irony - the (supposedly) biggest innovation of gnome-shell (the overview mode) is unfortunately a mistake.
-- Bojan
On dom, 2011-11-06 at 22:42 +0000, Bojan Smojver wrote:
The existence of all those extensions that bring back sanity (apps menu in normal view, workspaces in normal view, persistent dash for switching tasks in normal view etc.) is the proof of the ultimate irony - the (supposedly) biggest innovation of gnome-shell (the overview mode) is unfortunately a mistake.
Does that mean that the existence of terminal emulators for X11 is proof of graphical user interfaces being a mistake?
Really, all those extensions proof is that *some* people prefer (parts of) the old interface, and cared enough to implement it as extensions. Good for them! But implying that users who don't use any of those extensions are either insane or don't exist is a stretch at best, if not plain rude.
Florian
Florian Müllner <fmuellner <at> gnome.org> writes:
Rebuttal only here. No new material.
Does that mean that the existence of terminal emulators for X11 is proof of graphical user interfaces being a mistake?
Terminal and (I guess other) GUI apps do entirely _different_ things. Apps menu in overview and apps menu in normal view do the _same_ thing.
Really, all those extensions proof is that *some* people prefer (parts of) the old interface, and cared enough to implement it as extensions. Good for them!
It actually proves that some people were willing to put an effort into _duplicating_ the functionality already present in overview, because they found that going into overview involves _unnecessary_ steps.
But implying that users who don't use any of those extensions are either insane or don't exist is a stretch at best, if not plain rude.
I did not imply that users that use gnome-shell as is are insane. What I said was that GUI behaviour that introduces many _unnecessary_ steps for _no_ _benefit_ is insane.
-- Bojan
On Sun, 2011-11-06 at 23:25 +0000, Bojan Smojver wrote:
I did not imply that users that use gnome-shell as is are insane. What I said was that GUI behaviour that introduces many _unnecessary_ steps for _no_ _benefit_ is insane.
Did you even read my answer to you earlier where I said that I was much more productive with Gnome 3 than I used to be with Gnome 2?
Gnome 3 didn't introduce many unnecessary steps for no benefit. It brought a lot of sanity to my desktop. It offered me a way to use my computer in a much more natural and efficient way.
Is it now possible that you simply agree that Gnome 3 is not for you and that you move to something else, instead of complaining and being insulting?
On Sun, 2011-11-06 at 22:42 +0000, Bojan Smojver wrote:
drago01 <drago01 <at> gmail.com> writes:
Not true ... I recommend reading https://live.gnome.org/GnomeShell/Design/#Activities_Overview
I read that a long, long time ago, of course. In fact, I have written a constructive critique of Gnome 3 many months ago, based to a large degree on the very document you pointed to. Critique still holds, unfortunately. You can google it.
Reading all sorts of stuff or trying to but havcen't found yours yet (don't like it neither, so wanted to see your thoughts on it too)
On Mon, Nov 7, 2011 at 11:35 PM, Bojan Smojver bojan@rexursive.com wrote:
Mike Chambers <mike <at> miketc.net> writes:
Reading all sorts of stuff or trying to but havcen't found yours yet (don't like it neither, so wanted to see your thoughts on it too)
If you google '"on gnome 3" bojan', it should come up in top 10.
Just point people to the link directly if you want them to read it (should be easier for both sides).
drago01 <drago01 <at> gmail.com> writes:
Just point people to the link directly if you want them to read it (should be easier for both sides).
Spamming the list with links to my own site is not something I want to do. If someone really wants to read that, they'll find it.
-- Bojan
drago01 <drago01 <at> gmail.com> writes:
Not true ... I recommend reading https://live.gnome.org/GnomeShell/Design/#Activities_Overview
Just one link, so you wouldn't say I'm plucking things out of thin air:
https://live.gnome.org/GnomeShell/Design/FAQ#Why_no_window_list_or_dock.3F
This explains... <sorry, was just chewing my gum there>... how users are being told that "constant temptation to switch focus" is evil. Ergo, the wonderful kitchen sink overview that does all that and more for them.
You know, I go around my place and my daughters and my wife do nothing all day but click on those darn taskbar/dock buttons in Windows/OSX, switching tasks aimlessly. Sometimes I have to give them a jolt, just to get them out of the daze of task switching. If _only_ they had overview... :-)
Seriously for a second, I can also write anything I want in some design document that rationalises whatever design choice I want to make. Doesn't make it good, useful or sane in real life.
Anyhow, I think I've made my points known. Don't want to wake the list police, so last post on this topic.
-- Bojan
On Mon, Nov 7, 2011 at 12:09 AM, Bojan Smojver bojan@rexursive.com wrote:
drago01 <drago01 <at> gmail.com> writes:
Not true ... I recommend reading https://live.gnome.org/GnomeShell/Design/#Activities_Overview
Just one link, so you wouldn't say I'm plucking things out of thin air:
https://live.gnome.org/GnomeShell/Design/FAQ#Why_no_window_list_or_dock.3F
This explains... <sorry, was just chewing my gum there>... how users are being told that "constant temptation to switch focus" is evil. Ergo, the wonderful kitchen sink overview that does all that and more for them.
You know, I go around my place and my daughters and my wife do nothing all day but click on those darn taskbar/dock buttons in Windows/OSX, switching tasks aimlessly. Sometimes I have to give them a jolt, just to get them out of the daze of task switching. If _only_ they had overview... :-)
Seriously for a second, I can also write anything I want in some design document that rationalises whatever design choice I want to make. Doesn't make it good, useful or sane in real life.
Anyhow, I think I've made my points known. Don't want to wake the list police, so last post on this topic.
I didn't comment on whether your arguments are valid or not I simply said that "confused users" was *not* the reason for the lack of taskbar. distraction != confusion.
drago01 <drago01 <at> gmail.com> writes:
Again, rebuttal only.
I didn't comment on whether your arguments are valid or not I simply said that "confused users" was *not* the reason for the lack of taskbar. distraction != confusion.
Now we're splitting hairs, eh? A distracted user is not a confused user, that seems to be your point.
Please, just give me the name of _one_ user that got _distracted_ by the taskbar in Gnome (or any other OS, for that matter). The name of one user that was tempted to switch tasks just because the taskbar/workspace switcher was there. One.
Of course, this is a rhetorical question - no such user exists.
-- Bojan
On Sun, 2011-11-06 at 23:33 +0000, Bojan Smojver wrote:
Please, just give me the name of _one_ user that got _distracted_ by the taskbar in Gnome (or any other OS, for that matter).
Look at the value of the « From: » header of this email for a name of such a user.
The name of one user that was tempted to switch tasks just because the taskbar/workspace switcher was there. One.
I wasn't tempted to switch task just because the switcher was there.
But certainly, I got very distracted every time something would happen in another window and that button was blinking blue on the taskbar.
It surprised me every time, and I had to spend a short time (perhaps less than a second?) wondering if I should go and see what it was, and thanks to my incredibly poor focus, I needed a few seconds to get back into whatever I was doing previously. To make my point clear: each notification was costing me much more to get back into what I was doing than to notice it.
Gnome 3 doesn't have those distractions and I'm incredibly grateful to the developers. In fact, most of the time I turn off notifications in the shell altogether so that I'm not distracted by uncontrollable sources. And I can focus on my work, or relax without being interrupted, and go see the message tray when I actually want to.
Oh, and I don't think I am a "Joe Average" or an "Aunt Tillie": I'm a Fedora package maintainer, Python developer, a release engineer for an in-house Linux distribution at $dayjob, and I spend most of my time in a terminal.
Hopefully that will clear the myth that Gnome 3 is not for power users / developers.
Mathieu Bridon <bochecha <at> fedoraproject.org> writes:
[..snip..] and thanks to my incredibly poor focus [..snip..]
Oh, and I don't think I am a "Joe Average" or an "Aunt Tillie": I'm a Fedora package maintainer, Python developer, a release engineer for an in-house Linux distribution at $dayjob, and I spend most of my time in a terminal.
Hopefully that will clear the myth that Gnome 3 is not for power users / developers.
If you have so incredibly poor focus, how do you do all these things? ;-)
I think you're being overly modest - you sound more like a very capable guy than a person with poor focus to me. Gnome 2/3 notwithstanding.
In terms of various notifications, obviously, I have no idea what kind of things you're logged into daily and what kind of apps you have open. In any event, I do not see how this is in any way related to usefulness/uselessness of overview. You should be able turn notification off with or without overview - that is not in question. Ditto any kind of taskbar (although I do not see why you'd want that - it is usually an app you've opened yourself that's asking for input). The fact that some apps nudge the taskbar when they have a new message instead of using notifications is just a bug.
Not one person that is happy with Gnome 3 has been able to explain to me why overview is _required_ for any of these things to work. In the absence of that and believe me, with all due respect, I do not see why I have to go through two view switches and expose animation just to start an app.
-- Bojan
On Mon, 2011-11-07 at 03:24 +0000, Bojan Smojver wrote:
Mathieu Bridon <bochecha <at> fedoraproject.org> writes:
[..snip..] and thanks to my incredibly poor focus [..snip..]
Oh, and I don't think I am a "Joe Average" or an "Aunt Tillie": I'm a Fedora package maintainer, Python developer, a release engineer for an in-house Linux distribution at $dayjob, and I spend most of my time in a terminal.
Hopefully that will clear the myth that Gnome 3 is not for power users / developers.
If you have so incredibly poor focus, how do you do all these things? ;-)
Simple: I try very hard to do one at a time.
Of course I have windows opened all over the place between all of them, but Gnome 3 allows me to avoid switching context as much as possible, which is what costs me the most in terms of productivity.
Sure, I could avoid switching contexts in Gnome 2 as well, but that would have required more discipline on my part. With Gnome 3, I don't need more discipline, the OS does (mostly) the right thing. (it could be perfected of course ;)
Not one person that is happy with Gnome 3 has been able to explain to me why overview is _required_ for any of these things to work.
It's not required, nothing ever is.
It's just an incredibly convenient thing to have: - when I'm focused on doing something, I have the current window (usually maximized, sometimes a couple of windows tiled together to occupy the whole screen) and nothing else. Nothing will blink, move or require my attention in any way - when I **decide** to switch contexts (to run a new app, to search for a contact, to manage my windows,...) I just go to the overview and everything is there, providing me with an efficient access to all those functions.
In other words, the overview allows me to have 2 isolated modes of interacting with my computer, which adapts very well how my brain works.
Or as another example, when I want to start working on a new task, I can just go to the overview, and start dragging and dropping icons everywhere to run all the applications I'm going to need. And I can do that on a new desktop, dynamically created just for this purpose, which will be discarded once I have finished working on this task and close all the associated windows.
In the absence of that and believe me, with all due respect, I do not see why I have to go through two view switches and expose animation just to start an app.
You don't have to: you can always use another DE.
There is no way one DE^wproduct of any kind will ever be adapted to everyone. Why would you choose to impose yourself the pain of using a product not adapted to you is beyond me.
"Doctor, when I do that, it hurts..." "Well, then don't do that"
Unless you actually take pleasure in putting yourself through that pain? :)
And if you really loved Gnome 2 so much, I'm sure the MATE developers would love your help: https://github.com/Perberos/Mate-Desktop-Environment#readme
Mathieu Bridon <bochecha <at> fedoraproject.org> writes:
And if you really loved Gnome 2 so much
If this is what think, then you really completely missed what I'm trying to say. The main reason I'm using the fallback mode is the insanity of overview in gnome-shell.
Don't worry - I'm sure someone will write an extension that will nuke the stupid Activities button sooner or later.
-- Bojan
Bojan Smojver <bojan <at> rexursive.com> writes:
Don't worry - I'm sure someone will write an extension that will nuke the stupid Activities button sooner or later.
I'm behind times:
http://intgat.tigress.co.uk/rmy/extensions/index.html
Open source - it's a wonderful thing.
-- Bojan
On Sat, Nov 05, 2011 at 09:46:41PM +0100, Kevin Kofler wrote:
enaut wrote:
I am one of them and I went directly from the tilling-WM Xmonad to gnome 3! So you can't say it's only for absolute noobs :).
The fact that you were using a tiling WM first shows that you are much more willing to adapt to unconventional designs than most other users. I, for one, want my computer to work the way I learned and interiorized a computer works, any "innovative" interface destroys my automatisms and confuses me.
http://zs1.smbc-comics.com/comics/20110814after.gif
--CJD
------- Original message -------
From: seth vidal
Install xfce. You'll be happy w/that.
Thanks for the tip.
Or maybe I'll just have to find time to (learn how to) hack the shell, remove overview from it, bring back the taskbar and workspaces to normal view and call it gnome-non-shell-shell. Or even non-gnome-shell-for-gnome. :-)
-- Bojan
On Thu, 2011-11-03 at 23:09 -0700, Adam Williamson wrote:
But based on what they've said in the past, I expect that once most hardware that previously needed the fallback mode is covered, fallback mode will die. AIUI, fallback mode isn't meant to be a GNOME 2-by-stealth for Shell refuseniks, it's purely an attempt to accommodate hardware which doesn't support Shell.
That's pretty accurate, yes.
On Fri, Nov 4, 2011 at 2:40 PM, Matthias Clasen mclasen@redhat.com wrote:
On Thu, 2011-11-03 at 23:09 -0700, Adam Williamson wrote:
But based on what they've said in the past, I expect that once most hardware that previously needed the fallback mode is covered, fallback mode will die. AIUI, fallback mode isn't meant to be a GNOME 2-by-stealth for Shell refuseniks, it's purely an attempt to accommodate hardware which doesn't support Shell.
That's pretty accurate, yes.
One nice outcome is that we could end up with an optimized reference s/w renderer (and kernel/user land stack) for all platforms. Which is cool! :)
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, Nov 04, 2011 at 14:58:47 +0100, Ilyes Gouta ilyes.gouta@gmail.com wrote:
One nice outcome is that we could end up with an optimized reference s/w renderer (and kernel/user land stack) for all platforms. Which is cool! :)
The other graphics related improvement looking possible for F17 is complete OpenGL 3.0 support (including GLSL 1.3) for mesa.
On Thu, Nov 03, 2011 at 23:09:12 -0700, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2011-11-04 at 03:42 +0000, Bojan Smojver wrote:
But based on what they've said in the past, I expect that once most hardware that previously needed the fallback mode is covered, fallback mode will die. AIUI, fallback mode isn't meant to be a GNOME 2-by-stealth for Shell refuseniks, it's purely an attempt to accommodate hardware which doesn't support Shell.
It does a pretty good job at providing a Gnome 2 look and feel. If it is low cost to keep it working, it might be worth doing just for that.
On Thu, Nov 3, 2011 at 5:57 PM, Adam Jackson ajax@redhat.com wrote:
As of tomorrow's rawhide [1], gnome-session will no longer treat llvmpipe as an unsupported driver. This means gnome-shell will run even on hardware without a native 3D driver, including virt guests.
There are probably bugs! I've done some quick tests on the hardware I have handy and in kvm, and things do appear to work.
Hi Ajax!
What's the plan for rather old, limited hardware? Have you personally got XO-1, XO-1.5 units to test? We'll be testing it (with some trepidation) at OLPC, but it's always better if you can see it in all its glory on your own.
We also have some hw in the pipeline that can handle OpenGLES; and that's likely to be increasingly the case for ARM laptops and tablets. AFAIK, the current stack can't use OpenGLES, correct?
cheers,
m
On Mon, 2011-11-07 at 09:37 -0500, Martin Langhoff wrote:
What's the plan for rather old, limited hardware? Have you personally got XO-1, XO-1.5 units to test? We'll be testing it (with some trepidation) at OLPC, but it's always better if you can see it in all its glory on your own.
I have one or two around. I haven't successfully run anything on them in ages, but I guess I can always try again.
We also have some hw in the pipeline that can handle OpenGLES; and that's likely to be increasingly the case for ARM laptops and tablets. AFAIK, the current stack can't use OpenGLES, correct?
For now let's say yes, but that's more like implementation detail than fundamental property. Clutter'd be perfectly happy atop a GLES renderer, we just don't have that wired up.
- ajax
On Mon, Nov 7, 2011 at 2:45 PM, Adam Jackson ajax@redhat.com wrote:
On Mon, 2011-11-07 at 09:37 -0500, Martin Langhoff wrote:
What's the plan for rather old, limited hardware? Have you personally got XO-1, XO-1.5 units to test? We'll be testing it (with some trepidation) at OLPC, but it's always better if you can see it in all its glory on your own.
I have one or two around. I haven't successfully run anything on them in ages, but I guess I can always try again.
Details of rawhide builds for them here[1], the XO-1 build isn't tested but the XO 1.5 one works fine, I'll be testing further and likely the next build I do I'll add all the components to test the llvmpipe feature on them.
[1] http://lists.fedoraproject.org/pipermail/olpc/2011-November/003005.html
Peter
We also have some hw in the pipeline that can handle OpenGLES; and that's likely to be increasingly the case for ARM laptops and tablets. AFAIK, the current stack can't use OpenGLES, correct?
For now let's say yes, but that's more like implementation detail than fundamental property. Clutter'd be perfectly happy atop a GLES renderer, we just don't have that wired up.
- ajax
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Nov 7, 2011 at 9:55 AM, Peter Robinson pbrobinson@gmail.com wrote:
Details of rawhide builds for them here[1], the XO-1 build isn't tested but the XO 1.5 one works fine, I'll be testing further and likely the next build I do I'll add all the components to test the llvmpipe feature on them.
[1] http://lists.fedoraproject.org/pipermail/olpc/2011-November/003005.html
Yep -- Peter put together a rawhide build last night. If you need a hand to run through the installation steps,
In case you're a bit rusty on the installation steps
- XO-1.5: you need the .zd or .zd4 file. Put it on a FAT formatted USB and from OFW's "ok" prompt run "fs-update u:\osNN.zd4"
- XO-1: you need the .onu and .uim files, and the OFW command to flash is: update-nand u:\osNN.onu
Once you're on that image, you can probably yum update on rawhide.
For now let's say yes, but that's more like implementation detail than fundamental property. Clutter'd be perfectly happy atop a GLES renderer, we just don't have that wired up.
Ok -- that doesn't sound so terrible. Are there concrete plans to wire it up?
m
On Mon, 2011-11-07 at 10:11 -0500, Martin Langhoff wrote:
For now let's say yes, but that's more like implementation detail than fundamental property. Clutter'd be perfectly happy atop a GLES renderer, we just don't have that wired up.
Ok -- that doesn't sound so terrible. Are there concrete plans to wire it up?
I guess? It sort of depends what the support story for those chips looks like: who provides the GLES and EGL libraries, what their ABI looks like, whether it's feasible to compile against Mesa's implementation but use another at runtime...
None of which has a real answer just yet, I don't think.
- ajax
On Mon, 2011-11-07 at 14:55 +0000, Peter Robinson wrote:
Details of rawhide builds for them here[1], the XO-1 build isn't tested but the XO 1.5 one works fine, I'll be testing further and likely the next build I do I'll add all the components to test the llvmpipe feature on them.
Don't freak out if it doesn't seem like it works. Somehow between F16 and rawhide we're managing to change LLVM's behaviour for allocating memory in the JIT, such that selinux puts the smack down.
I'm working on it, but in the meantime, enforcing=0 if you want to try it.
- ajax
On Mon, Nov 7, 2011 at 9:05 PM, Adam Jackson ajax@redhat.com wrote:
On Mon, 2011-11-07 at 14:55 +0000, Peter Robinson wrote:
Details of rawhide builds for them here[1], the XO-1 build isn't tested but the XO 1.5 one works fine, I'll be testing further and likely the next build I do I'll add all the components to test the llvmpipe feature on them.
Don't freak out if it doesn't seem like it works. Somehow between F16 and rawhide we're managing to change LLVM's behaviour for allocating memory in the JIT, such that selinux puts the smack down.
I'm working on it, but in the meantime, enforcing=0 if you want to try it.
We don't have selinux enabled on the XO builds but it still doesn't work on the Via based XO-1.5. I have logs and I'm going to post a bug report for it when I get a sec.
Peter
On Mon, 2011-11-07 at 16:05 -0500, Adam Jackson wrote:
On Mon, 2011-11-07 at 14:55 +0000, Peter Robinson wrote:
Details of rawhide builds for them here[1], the XO-1 build isn't tested but the XO 1.5 one works fine, I'll be testing further and likely the next build I do I'll add all the components to test the llvmpipe feature on them.
Don't freak out if it doesn't seem like it works. Somehow between F16 and rawhide we're managing to change LLVM's behaviour for allocating memory in the JIT, such that selinux puts the smack down.
I'm working on it, but in the meantime, enforcing=0 if you want to try it.
It seems like a similar bug has come up before in clamav:
https://bugzilla.redhat.com/show_bug.cgi?id=573191
if that's any help to you. Just saw this in my VM test. With selinux, no worky (aww...) but with selinux disabled, worky (yayyy!). Bit jerky but definitely usable, with qxl/SPICE on a fairly powerful F16 host. very nice stuff!
Adam Williamson wrote:
It seems like a similar bug has come up before in clamav:
This issue affects many JITs. The WebKit JIT is affected too. Actually, the execmem boolean has been enabled by default for a while, did it get disabled again in F17? We had been disabling the QtWebKit JIT, but we reenabled it when we found out execmem got enabled by default. More and more things in Fedora use JITs (see also Orc etc.), and those JITs all tend to require execmem, with upstreams showing little to no interest in changing them not to. (There is a way, but 1. it's complicated and 2. it hurts performance.)
Kevin Kofler
On Tue, 2011-11-08 at 04:48 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
It seems like a similar bug has come up before in clamav:
This issue affects many JITs. The WebKit JIT is affected too. Actually, the execmem boolean has been enabled by default for a while, did it get disabled again in F17?
I believe the bugs come and go in cycles because what happens is the SELinux team disables the boolean up till Beta or so, to try and encourage people to fix their code, then disable it so the releases aren't too broken.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/08/2011 01:11 AM, Adam Williamson wrote:
On Tue, 2011-11-08 at 04:48 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
It seems like a similar bug has come up before in clamav:
This issue affects many JITs. The WebKit JIT is affected too. Actually, the execmem boolean has been enabled by default for a while, did it get disabled again in F17?
I believe the bugs come and go in cycles because what happens is the SELinux team disables the boolean up till Beta or so, to try and encourage people to fix their code, then disable it so the releases aren't too broken.
Yes that is the goal...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/07/2011 10:48 PM, Kevin Kofler wrote:
Adam Williamson wrote:
It seems like a similar bug has come up before in clamav:
This issue affects many JITs. The WebKit JIT is affected too. Actually, the execmem boolean has been enabled by default for a while, did it get disabled again in F17? We had been disabling the QtWebKit JIT, but we reenabled it when we found out execmem got enabled by default. More and more things in Fedora use JITs (see also Orc etc.), and those JITs all tend to require execmem, with upstreams showing little to no interest in changing them not to. (There is a way, but 1. it's complicated and 2. it hurts performance.)
Kevin Kofler
Any time I go into a rawhide I enable the tightest controls. Then relax them as we get closer to Beta. I am thinking of dropping execmem protection from user apps altogether as I see almost all applications that a user relies on needing execmem. The attached regular expressions match all of the executables that we are currently marking as needing execmem protection.
/usr/(.*/)?bin/java.* /opt/(.*/)?bin/java[^/]* /usr/lib(.*/)?bin/java[^/]* /opt/ibm(/.*)?/eclipse/plugins(/.*)? /opt/real/(.*/)?realplay.bin /opt/Adobe.*AIR/.*/Resources/Adobe.AIR.Updater /opt/Adobe.*AIR/.*/Resources/Adobe.AIR.Application /opt/matlab.*/bin.*/MATLAB.* /opt/MATLAB.*/bin.*/MATLAB.* /usr/matlab.*/bin.*/MATLAB.* /usr/Aptana[^/]*/AptanaStudio /usr/bin/mono.* /usr/lib/ghc-[^/]+/ghc.* /opt/ibm/java.*/(bin|javaws)(/.*)? /usr/sbin/VBox.* /usr/lib/opera(/.*)?/opera /usr/lib/opera(/.*)?/works /usr/lib/gimp/[^/]+/plug-ins/help-browser /usr/bin/haddock.* /usr/bin/octave-[^/]* /usr/libexec/gcc(/.*)?/gnat1 /usr/libexec/ghc-[^/]+/.*bin /usr/libexec/ghc-[^/]+/ghc.* /usr/java/eclipse[^/]*/eclipse /usr/lib/jvm/java(.*/)bin(/.*)? /opt/local/matlab.*/bin.*/MATLAB.* /opt/local/MATLAB.*/bin.*/MATLAB.* /usr/local/matlab.*/bin.*/MATLAB.* /usr/lib/wingide-[^/]+/bin/PyCore/python /usr/lib/erlang/erts-[^/]+/bin/beam.smp /usr/lib/thunderbird-[^/]+/thunderbird-bin /usr/local/Wolfram/Mathematica(/.*)?MathKernel /opt/ibm/lotus/Symphony/framework/rcp/eclipse/plugins(/.*)? /usr/bin/gij /usr/bin/sbcl /usr/bin/darcs /usr/bin/skype /usr/bin/frysk /usr/bin/grmic /usr/bin/dosbox /usr/bin/runghc /usr/bin/gnatls /usr/bin/fastjar /usr/bin/hasktags /usr/bin/valgrind /usr/bin/gkeytool /usr/bin/gnatbind /usr/bin/gnatmake /usr/bin/aticonfig /usr/bin/runhaskell /usr/bin/gcj-dbtool /usr/bin/gjarsigner /usr/bin/jv-convert /usr/lib/R/bin/exec/R /usr/bin/grmiregistry /usr/bin/gappletviewer /usr/bin/plasma-desktop /usr/lib/eclipse/eclipse /usr/sbin/vboxadd-service /opt/google/chrome/chrome /usr/lib/ia32el/ia32x_loader /usr/lib/virtualbox/VirtualBox /opt/likewise/bin/domainjoin-cli /opt/google/chrome/google-chrome /opt/real/RealPlayer/realplay.bin /usr/local/RealPlayer/realplay.bin /opt/secondlife-install/bin/SLPlugin /opt/Komodo-Edit-5/lib/mozilla/komodo-bin /usr/lib/chromium-browser/chromium-browser /opt/Adobe/Reader9/Reader/intellinux/bin/acroread
Daniel J Walsh wrote:
Any time I go into a rawhide I enable the tightest controls. Then relax them as we get closer to Beta. I am thinking of dropping execmem protection from user apps altogether as I see almost all applications that a user relies on needing execmem. The attached regular expressions match all of the executables that we are currently marking as needing execmem protection.
Anything that directly or indirectly uses QtWebKit or QtScript also requires execmem, unless we disable the JavaScript JIT, which we used to do, but got users complaining about the slowness.
See also: https://bugs.webkit.org/show_bug.cgi?id=35154 which is being ignored entirely by upstream.
Kevin Kofler
On Wed, Nov 9, 2011 at 15:27, Kevin Kofler kevin.kofler@chello.at wrote:
Anything that directly or indirectly uses QtWebKit or QtScript also requires execmem, unless we disable the JavaScript JIT, which we used to do, but got users complaining about the slowness.
See also: https://bugs.webkit.org/show_bug.cgi?id=35154 which is being ignored entirely by upstream.
I don't know if you noticed but that bug shows it isn't and never has been assigned to anybody so it is not entirely impossible nobody has actually seen it...
John5342 wrote:
I don't know if you noticed but that bug shows it isn't and never has been assigned to anybody so it is not entirely impossible nobody has actually seen it...
Well, that's a failure of upstream's process then. Somebody has to look at incoming bug reports, you cannot treat your bug tracker as /dev/null.
Kevin Kofler