GNOME Bugzilla – Bug 327335
Problems with new explicit-apply behaviour
Last modified: 2006-02-11 08:04:21 UTC
2.13.7 changed the background properties capplet from being instant-apply to explicit okay/cancel. I usually change my background every now and then, by looking at a couple and deciding which one I feel like. With the only behaviour I could click on a image and see how it looked on the desktop, and find a different one if I didn't like it. With the new behavior I have to click okay, and then re-open the capplet if I decide against that particular background. I don't think that looking at a few background before deciding is that uncommon, since it is hard to tell exactly how a image will look on the desktop from just the thumbnails. I would suggest either reverting to the old behaviour; or if instant-apply causes problems, then an "Apply" button (which doesn't close the window) and it being dismissed by the close box.
*** Bug 328752 has been marked as a duplicate of this bug. ***
This is fixed in CVS. There is now an Apply button which applies the current settings. Cancel will revert the selection and close the dialog. And OK will apply the selection, and close the dialog.
Huh? Why can't we just keep the old instant-apply behaviour. That was really nice. When did we start getting apply/ok/cancel buttons in capplets???
*** Bug 328811 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Huh? Why can't we just keep the old instant-apply behaviour. That was really > nice. When did we start getting apply/ok/cancel buttons in capplets??? I for one also don't like the apply/ok/cancel situation. A best of both worlds solution would be a two button setup: basically do instant-apply, but provide a cancel/revert option.
JRB: I switched it to the explicit apply behavior, for several reasons. Users in testing found the "Close" button confusing. Applying a background is also very slow, and the design of the capplet is to apply all the settings at once. According to the HIG section on apply behavior[1], this means that the capplet should be explicit apply. [1] http://developer.gnome.org/projects/gup/hig/2.0/windows-utility.html
"It's slow" is not a good excuse. Let's make it fast. It's only a screen-sized image, and Quake could push out 50 of those, every second, on my 300 MHz Pentium. Did we do user testing with the apply/ok/cancel version? What problems did they encounter with just Close?
bad comparison; in quake you basically repeat the same image with minor gemetry transformations. We load completley different compressed images, which eventually have to be resampled and cropped first - thats what quake doing when you load the level. Now imagine we will get 3D Wallpapers with several texture layers(like in suns looking galss or e17). these will take up even more time to load, so the current behaviour is better
(In reply to comment #6) > Users > in testing found the "Close" button confusing. Could you just note which videos you especially noticed this problem. I'd be really interested in watching those, I've only seen one of them and there are a number. > Applying a background is also > very slow, and the design of the capplet is to apply all the settings at once. I'd agree with comment 7 that there's probably some way to improve the speed. For me it takes less than a second to change the background, perhaps that's not average time. > According to the HIG section on apply behavior[1], this means that the capplet > should be explicit apply. Well if we could fix the slowness then I think we can keep the capplet as instant apply. I wonder if the problem isn't so much the close button as it is the effect or knowing that you've changed the background successfully. My gut tells me that it probably isn't the button itself, but the lack of feedback. I'll try to watch those videos sometime.
The new (okay/cancel/apply) behaviour is odd, and I find a couple of things confusing: * The capplet's close box acts as Cancel - so pressing Apply then closing the window reverts the change. I wouldn't expect the background to change in response to closing the window * Rather than having Apply, Cancel, and Okay, I think it would be better to have Apply and Revert - which makes it more obvious what they do. However I still think instant-apply is the way to go. I know my main system isn't that old (however it's not new either, 2 1/2 years) but it only takes ~1/2 s to change wallpapers.
Agreed with the others here; this need for explicitly applying (Why else would I have selected the image?!?) seem exceptionally odd and out of place.
*** Bug 329149 has been marked as a duplicate of this bug. ***
Background applying used to be fast. I recall the scaling and drawing got significantly slower during the switch to cairo in the last release cycle. Now, I keep the X hash pattern until several seconds after my panels show up. I'm certain the drawing could be optimized. Away with the Apply buttons.
As covered, this is an unacceptable break from our Instant-Apply metaphor, confusing for users and just plain ugly. We can do better. Things used to be fast enough for instant apply (even on my 3200x1200 desktop) and now they are god-aweful slow. Uncorroborated finger pointing suggests new gtk-engines/cairo (Cairo is known to have some issues here). It may be worth considering to ship gtk-engines 2.6 for the GNOME 2.14 release if these issues cannot be resolved. Longer rant: http://davyd.livejournal.com/164811.html
(In reply to comment #6) > the design of the capplet is to apply all the settings at once. > According to the HIG section on apply behavior[1], this means that the capplet > should be explicit apply. I haven't seen videos of user testing but, while the settings do get applied all at once, I think that people won't usually be changing them at the same time. From my experience, people are either a) chaning the image, or b) fixing the settings (scale, tile, etc). The few times I've seen people change both at once, it was because they put the image on their desktop, and then realised that it needed to be tiled/scaled, which won't happen until after they see it there.
Further, looking at the screenshots in "someone's" blog, why were the icons in all of the buttons removed? Is this just a fluke? I can't think of many places where the icons are more useful. People catch "stretch", "tile", "add", and "remove" much more easily with the icons. If this was, indeed, intentional, please stop castrating this interface.
Created attachment 58444 [details] [review] Removes apply button from background wallpaper dialog Sorry, this is the patch that we're applying to JDS - have attached it in case other distributions feel the same way.
*** Bug 329302 has been marked as a duplicate of this bug. ***
Created attachment 58446 [details] [review] Updated patch which builds [mistakingly missed one chunk]
Created attachment 58447 [details] [review] Blah, only removed the apply button, now remove ok/cancel.
Glad to see, that there is a patch dropping this *stupid* Ok/Cancel/Apply crap. Instant apply is essential for GNOME, ripping this from it's control center is pushing a knife into GNOME's heart! Unbelievable that someone wasted time in removing instant reply from this dialog. As Davyd points out: If something becomes slow, let's remove the cause for that slowdown, but keep instant apply!
And I would like to point out that icons from buttons are gone, what is not very nice. I know that someone has problems with buttons, claiming it is just wasted space, slows speed, etc. but it gives good visual clues even for me, computer geek. I think it is VERY essental for common user and should be reverted like it was so before that. If there was such decission in project level to remove icons from dialogs, please provide me with link where it has been said so I can rise a opposition to that. And yes, instant apply should stay, because it is quite stupid to open "Change Background" dialog fifty times while I try different backdrops for my screen. And it is somehow "stupid" to try solve gtk/cairo slowness (interesting that is not slow for me, so it is again isolated case which should be investigated, not to waste time on such hot-button solutions like this).
Damn, I come here from Davyd blog post, I always tought the Background dialog was one of the best from an HIG point. Please revert it to the old behavior, and give me back icons. They are quite useful for selecting the right style (center, fill scree, tiled...) and colors combination. Summary: please revert back to the *perfect* dialog that ships with gnome 2.12.
I think having the entire desktop doing instant apply and some dialogs with Apply/Ok/Cancel seems confusing. Like some said, they waited to the background to aplly, not noticing the apply button. And please people, don't get affected by blog entries, just because tigert or jimmac blogged about "i've created a monster" doesn't mean we should remove all button icons. I agree we don't need all buttons to have icons, but Add/Remove are surely the ones we need. We need because its faster to just see the + and the - and hit the button then having to read then to know what it does. Also, we need the desktop to be consistent, have icons on Add/Remove or not have them on any dialog. Please, revert the change.
Yup, the icons also should come back, especially since gtkrc knows this "gtk-button-images = 0" setting, which should please those, who dislike the icons.
Would need to know why the users were confused by Close, but it sounds like the wrong solution has been applied (ho-ho) here. If it was just because the change didn't happen instantly, some pointer feedback while the change was happening might well be sufficient.
I'd also like to have instant apply back. Instant apply on the wallpaper dialog was one of the first things I remember saying "Wow that's nice" about in GNOME. As mentioned, if users are confused by the "Close" button, maybe there's a different solution; perhaps an "OK" button instead? More details on what exactly confused the users would help... The icons are also important to me when I use dialogs quickly. Again, the icons on a lot of the buttons is one of the things that I like about GNOME. The drawing speed problems should probably disappear once Cairo has stabilised a bit more, but I never really experienced any problems on my system anyway.
I agree with Calum in comment #26. Setting a busy cursor while changing the desktop wallpaper is probably a nicer solution to this problem.
@dennis: Problem: gnome-background-properties just alters some GConf keys. Setting the background image is the job of someone other - Nautilus in most cases. Does Nautilus use D-Bus already? In that case Nautilus could implement some "BackgroundManager" interface and notify gnome-background-properties when it has finished it's job: interface BackgroundManager { signal background_changing; signal background_changed; } ---- GnomeBackgroundProperties::OnBackgroundChanging() { // switch to pointer with hourglass } GnomeBackgroundProperties::OnBackgroundChanged() { // revert to regular mouse pointer }
@ Mathias: While this is true, what we could do is have Nautilus set the busy cursor at the beginning of background change and change it back at the end of that operation. I have a notion that nautilus is the longest step here, so that could work fairly well, especially if it's just responding to a gconf key and most of the time is spent waiting for gnome-settings-daemon. This is just speculation.
This is a pretty big regression. In perspective of the rest of the desktop I thought the new behaviour was actually a bug that would be fixed soon enough. Only after reading about it on planet gnome did I realise that this change was intentional. (?!?) This calibre of crack is beaten in recent history only by Ubuntu Spatial. It's very badly broken and needs to be changed back.
Or some more low hanging fruit: Instead of playing with D-Bus, Nautilus could be patched to propagate some "background-is-changing" GConf key. When it starts changing the background the value is set to true, when it finishes the value is set back to false. Gnome-background-properties would monitor that key and whilest it is set to true, it would provide some progress indication. It's a few line patch...
We should never-ever pass state in GConf. That is all bad, mmkay?
Davyd: I know, that GConf hack I suggested is ugly. But somehow I have the feeling, that inventing full blown D-Bus interfaces is some kind of overkill. As GConf supports multiple backends: Can't we have some namespace in GConf backed by some non-persistent memory-only backend just for exchanging this kind of notifications? Somehow I have the feeling, that Gnome lacks some simple notification mechanism: D-Bus feels overdesigned for that purpose.
(In reply to comment #6) > JRB: I switched it to the explicit apply behavior, for several reasons. Users > in testing found the "Close" button confusing. It's interesting you found this in user testing. There was the pre-2.0 flamefest about having the Close button in preferences dialogs, and if I remember correctly some people suggested not having a close button, relying on the window manager-provided titlebar button to close the window. The main reason for against this idea was that a lot of window manager themes at the time didn't have a close button. Perhaps Novell could do some usability testing on this idea and this could be discussed again for GNOME 2.16. Until then it would probably be a good idea to have consistency in all capplets and preferences dialog with the current layout (Help and Close buttons only).
I gain want instant-apply back (btw: applying a new background is not slow for me - I'm not affected by that slowdown-bug, but I'm not using Xorg either..) I especially agree with comment #24 - don't get in a rush because some feature is misued/overused in some cases.
> Somehow I have the feeling, that Gnome lacks some simple > notification mechanism: D-Bus feels overdesigned for that purpose. How about, rather than using Gconf for something it's not intended to be used for, a simpler D-Bus notification API be created?
Milestoning to 2.14 since this has to be decided before the final release.
Looking a the release plan I guess it is too late for creating a simple D-Bus notification API, isn't it? Besides that I'd volunteer to take care about this issue, which also exists in applying Gtk widget themes for 2.16. Well, from a marketing POV shipping ok/cancel for 2.14 just to revert it again in 2.16 would make us look stupid, wouldn't it?
I don't know much, but from my simple user perspective, what _can_ be done in time for 2.14 is simply to make the wallpaper change fast again. then no need for hourglass cursor. I thought that there is code by Federico Mena Quintero for GTK (or maybe cairo?) and some code that is meant to go in X one day? if those changes are applied and released in a stable GTK/cairo, then GNOME could revert to behaviour of 2.12, saying it requires the new version of GTK and problem is solved. of course if there is no patch for GTK/cairo then there is no good solution.
sorry, here is more info on my comment #40: what i had in mind (gtk/cairo and X patches to make background changing faster): http://primates.ximian.com/~federico/news-2006-02.html#03 and also: http://bugzilla.gnome.org/show_bug.cgi?id=314616#c24 it appears i was maybe confused and maybe those are different issues (desktop repainting and wallpaper changing). though it's not 100% clear.
*** Bug 330587 has been marked as a duplicate of this bug. ***
Back to instant apply in CVS, with a dependency on gtk+ 2.8.12 which should be released very soon now, so that we can require Federico's patch for the small speed improvements. There's still work to do, but things are much better at the moment. And marking Glynn's patch as rejected, as it is a blind revert which removes other useful pieces of code, some of which fixes other bugs and issues.
Somewhat related, have the icons gone back in to the dialog? Many of these icons (especially one ones explaining the scaling/fill/tile etc.) are sorely missed also.