Bugzilla – Bug 326158
YaST constantly steals focus
Last modified: 2008-09-01 19:24:11 UTC
I'm not sure whether this should just be filed under gnome (metacity), but anyway: We all have 2-3 repos enabled, and refreshing these brings up a million progress dialogs (which is the real problem, as well) when it refreshes and parses the cache, so we normally let it do its thing and load while we're working on other stuff. This isn't really possible with the GTK-YaST because it will always steal the focus. Even if you have it minimised (and this is the issue) it will still pop the window up and take focus. You can't really keep typing, because it may pop up and you'll hit "abort" by accident. So, expected behaviour: when you minimise YaST, for it to not keep popping up every time it wants to show a new progress dialog.
See also bug #246934. It's similar, but not a duplicate since the specific UI (Gtk vs. Qt) still proactively grabs the keyboard focus. Yes, it's very annoying. But we have to be carful to make sure we don't break the installation because of this; it had happened that pop-up dialog had disappeared behind another (larger) dialog with no obvious way for the user to find out what's going on and how to fix it. This is why when user input is expected, YaST2 dialogs tend to bully their way to the front.
We are doing our job telling the window manager the popups are transient to the window. Feel free to test on another window manager than Metacity. I rather we don't do a work-around for yast-gtk. Let's get rid of the popup dialogs (put a progress bar on the main window), or at least use just one popup. YCP coders?
Created attachment 176483 [details] Test case «This isn't really possible with the GTK-YaST because it will always steal the focus. Even if you have it minimised (and this is the issue) it will still pop the window up and take focus.» No, yast-gtk won't steal the focus. Metacity will. Checkout the appended program (try to minimize it before the timeout and see it popup back up because of a transient window).
I was just thinking of writing a bug-report on this one. Very annoying bug. I would like to see a progress bar in the window instead. That would be better.
*** Bug 330060 has been marked as a duplicate of this bug. ***
It should be said that #330060 is complaining about the dialog in the end of the package manager process next to the system update scripts. We probably also want to get rid of the "Install more packages? [Yes] [No]" dialog. Is the point of that dialog to be just a message alerting the user the job is done? Because it makes no sense otherwise to annoy him with such a dialog; just default to yes, and let him close the window or press quit. What we probably need here is a UI::NotifyUser() API, so that the task bar gets highlighted when a job is completed, and the interface is ready for some more. Let's not use dialog for that. And, to make it clear, this isn't yast-gtk specific. Try yast-qt in Gnome. It is just a coincidence that yast-gtk was included when yast guys added more popups than ever to sw_single module (before there were just 2 on loading, and the quit-stay at the end). Even if less of a problem, this is also an annoyance for KDE that, at the very best, have the taskbar highlighted. Some window managers ask the user to position the window before showing it, so this popup madness can be a problem there as well. The Metacity report: https://bugzilla.novell.com/show_bug.cgi?id=331835
This could likely be marked as a duplicate of bug #330649.
*** Bug 330649 has been marked as a duplicate of this bug. ***
Here is some info about focus stealing and window managers: http://osdir.com/ml/gnome.gaim.devel/2004-12/msg00077.html It suggests to do popup_window.set_focus_on_map (False) Unfortunately there is a bug in emerald (compiz) that dows not show the new window above (files as Bug #337652). When using metacity it works.
Thanks for pointing out the method, haven't noticed it... It works by changing some timespan property through Xlib that window managers are supposed to understand, so we could use the fix for yast-qt too. It isn't honored on my system though (Metacity), it still steals focus. And the fact that it works badly on a popular window manager kills it. :(
Btw. in most of the cases the problem could be fix by not opening a window in yast too. E.g. when starting install or online update, it would be better to have a secondary progress indicator inside the main window. is this worth an enhancement request?
Its comming \o/ http://blogs.warwick.ac.uk/bweber/entry/nicer_yast_progress/
*** Bug 339735 has been marked as a duplicate of this bug. ***
Hi Ben, I see the work you've been doing in YaST to eliminate this problem (with actually a whole new package management verbose mode) but what is the likely hood that it will be seen in 10.3 to fulfill this bug? Or will we just see it incorperated into openSUSE 11.0? Would love the package management to be less verbos. e in 10.3.. but we'll see.. Love the work btw.. Looking great.
*** Bug 340992 has been marked as a duplicate of this bug. ***
See also bug 331835 for metacity test packages.
*** Bug 342574 has been marked as a duplicate of this bug. ***
I was going to submit a bug on this as well - not only is it an annoying bug, but if I'm working on something and I happen to hit enter just as one of these windows pops up, I end up canceling something I didn't intend to cancel. I was going to suggest as a possible solution a progress bar instead as per Jonas Björk's suggestion on 2007-10-06 09:09:02 MST. To me that seems a much better solution than constantly creating and destroying windows to tell me it's doing something - especially since those popups tend to disappear before I have a chance to read them anyways. Pop something up if there's an error, but not to give me a status as to what's going on.
(In reply to comment #18 from Jim Henderson) > I was going to submit a bug on this as well - not only is it an annoying bug, > but if I'm working on something and I happen to hit enter just as one of these > windows pops up, I end up canceling something I didn't intend to cancel. > > I was going to suggest as a possible solution a progress bar instead as per > Jonas Björk's suggestion on 2007-10-06 09:09:02 MST. To me that seems a much > better solution than constantly creating and destroying windows to tell me it's > doing something - especially since those popups tend to disappear before I have > a chance to read them anyways. Pop something up if there's an error, but not > to give me a status as to what's going on. > Check this out: http://blogs.warwick.ac.uk/bweber/entry/nicer_yast_progress/ Which was originally posted https://bugzilla.novell.com/show_bug.cgi?id=326158#c12 Hopefully it'll be fully implemented into 11.0. I would love to see it changed / updated for 10.3, but doubtfully.
The popup window could show up when there are errors, however, I don't know about you but, I get lots of errors all the time, saying YaST can't connect to the remote repository. Then I have to click "Retry" and after clicking it several time, it succeeds. It's clearly not a connection problem, as I have a fast DSL connection, it's not a repository problem either, as this happens with several repositories. I don't know if I'm the only one with this problem but in this case, when the YaST window pops up, I can click "Cancel" not knowing while I'm typing.
Ben, the video looks more like the QT interface than the GTK+ interface (or GNOME interface, I assume it's GTK+, but maybe I'm wrong). But the idea behind it is kinda what I imagined. Charles, I don't see the problems you do - but I would think that if that's considered "normal" behaviour, then that issue needs to be addressed separately. Personally, I want to see an alert of some sort when there's an error. Perhaps the default selection shouldn't be "Cancel" but "Retry" instead so an accidental response would just throw it into a loop. I know that would get my attention. I also have a relatively fast DSL connection and subscribe to 10 different repos, but I don't think I've ever had a connect issue such as the one you describe on either of my 10.3 systems. If that hasn't been submitted as a bug, perhaps it needs to be.
I'm not sure where the problem comes from, but I think I'll report it. If it's not an openSUSE bug, it'll be easy enough to close the bug report.
Sounds like a plan, Charles - I know I wouldn't accept constant error messages as "normal" behaviour, I'd want to see that fixed myself. :-)
I still think the problem could be fixed quite easily (So far only Windows/XP here had the annoying feature that some "background tasks" popped up a window for a fragment of a second, and then the previously active window was inactive. That raises my blood pressure regularly, triggers loud shouts, and the search for an axe...). I hope the Windows disease didn't spread so far. I believe that one can create a new window in X11 that is not automatically going into foreground. Windows/XP and PuTTY (to give a positive example) are able to draw the users attention on a window that is in background and needs attention (icon in the task bar blinks orange/blue). I see no reason why Linux should or must be worse.
*** Bug 345491 has been marked as a duplicate of this bug. ***
besides the ultimately slow package management in yast. this bug is also a major annoyance for me. please fix it for 10.3 if you want users to stay, i`m really a fan of (open)suse, but since i`m using 10.3 as a desktop OS on my older notebook, i`m more and more getting annoyed.... It`s working fine for surfing the net or doing office stuff, but this tons of popups on each updates and those "need to wait half an hour for a single package to be installed" is something which really makes me think if i should try another distro, to see how that performs....
I agree 100% with Roland. Having to wait almost half an hour to update your system is ridiculous. You'll notice that the simple task of adjusting the time and date of your system takes also almost half an hour. And these constant popups are just too annoying also. I have stopped updating my system for now, I'm just keeping my fingers crossed. This kind of bug is so obvious that it should have been found and fixed during beta testing. I don't know how it reached the stable release with no one noticing it.
It seems this bug has been fixed. The time it takes for Zypp to initialize is an entirely different problem. They use XML files for the packages metadata, which is not the most appropriate format, as they end up having close the same structural data in size as the actual information, resulting in long download and parsing time. I'm sure they will come up with some hacks in the near future to alleviate the problem. Fortunately, PackageKit is a distro-independent framework, that is better engineered, and will start replacing the Zypp API for 11.0, so possibly, it could end up replacing Zypp in its entirely in the future. They are looking for volunteers for this.
>I don't know how it reached the stable release with no one noticing it. because everbody is using a fast machine nowadays and if it`s slow, then it must be the machine not being tuned optimally. software mostly gets optimized to that degree, that its usable on a fast machine. it`s seldom being optimized further. guess what a java programmer tells me if i tell him that his trivial little tool needs a little bit too much ressources for doing such simple task? i get some "so what? buy another gig of ram or use a faster pc". >It seems this bug has been fixed. so, how can i fix it on my system? ;)
My computer isn't a high-end computer but it's not slow either: ASUS P4C-800 Deluxe 1GB RAM CPU Intel Pentium IV 3.2Ghz HT Western Digital Raptor 36GB 10,000rpm SATA I shouldn't have slowness issues, I suppose. One of the drawbacks with Vista is resource requirements. Linux should stand out with low resource requirements. BTW, I don't use any single Java application, I always stay away from this resource hog :)
Back to the original bug. I don't think it should be discussed even. This is a major issue of 10.3. Given that fact that there is a fix and there is online_update, it should be released. If the suse-developers give us explanation here how to update needed components manually, I volunteer to test it and for others that might be enough. Dear opensuse developers, please explain whats the plan with this.
(In reply to comment #31 from Stefan Kost) > Back to the original bug. I don't think it should be discussed even. This is a > major issue of 10.3. Given that fact that there is a fix and there is > online_update, it should be released. > If the suse-developers give us explanation here how to update needed components > manually, I volunteer to test it and for others that might be enough. > > Dear opensuse developers, please explain whats the plan with this. > I totally agree with this. Why we have to wait for 11.0. If there is a fix, it should be released. Is not the slowness issue what it really bothers me, but the pop ups. This is very, very annoying.
Please see if the metacity package in https://bugzilla.novell.com/show_bug.cgi?id=331835#c10 helps with this.
*** Bug 351900 has been marked as a duplicate of this bug. ***
The GUI focus is not stolen by the YaST notification popups if I am using the KDE window manager "kwin" on my system. Does the Compiz software change the focus handling in this use case?
I'm curious: This has been reported in beta 4 months ago and not been fixed yet? And is at NEEDINFO? Do none of the developers experience this? Please fix this ASAP for 10.3: It really makes installing software through Yast on KDE nearly useless; I find myself using the console mode instead. :-(
We do have a fix, we've been figuring out how risky it is to ship however. Its in NEEDINFO because no external users ever confirmed the metacity package fixed the problem. We didn't have a report for compiz before now.
I am using compiz too. The major issue are the many popups and that non warning messages open windows that grab the focus. So even mitigating the problem, by reusing the message box would help.
(In reply to comment #37 from JP Rosevear) > We do have a fix, we've been figuring out how risky it is to ship however. How many people complained about the previous behaviour? I'm really curious if you are using your own programs, because IMHO this bug makes installing or updating software with Yast unusuable. And I do understand that you probably see the current behaviour as a feature.
To comment #37: This thoughtless use of Popup Boxes, where a progress log would be appropriate, makes the use of yast2 a painfull experience. Because yast takes ages (over 15 min) for the initialization for 'install' and 'install_update' you have to start working on something else. So you change to a different kde desktop, but yast manages to send it boxes to that screen, too. This is a very annoying behaviour. And it is upsetting people.
Not sure whether all of you are talking about the same configuration. I am one of the "annoyed" people who didn't report. I am using GNOME and YaST2 QT and for me it seems to work much better now. Especially yast2 sw_single has only one window which reports and stays in the background ( it's running while I am writing this undisturbedly ). Notebook: Fujitsu Siemens Amilo Si 1520 Graphics: Fujitsu Siemens Mobile 945GM/GMS/GME, 943/940GML Express Monitor: QUANTADISPLAY LCD Monitor 1280x800@60Hz Wireless: Intel PRO/Wireless 3945ABG Network Connection Sound: 82801G (ICH7 Family) High Definition Audio Controller Desktop: gnome2-SuSE-10.3-148 YaST GUI: yast2-qt-2.16.20-4 OS: openSUSE 11.0 (i586) Alpha2 VERSION = 11.0 Kernel: 2.6.24-6-default rpm -qa | grep gnome | sort bluez-gnome-0.15-3 bluez-gnome-lang-0.15-3 bundle-lang-gnome-11.0-62 bundle-lang-gnome-de-11.0-62 bundle-lang-gnome-en-11.0-62 bundle-lang-gnome-ru-11.0-62 compiz-gnome-0.5.4-78 gnome2-SuSE-10.3-148 gnome2-user-docs-2.20.1-3 gnome-applets-2.21.4-3 gnome-applets-lang-2.21.4-3 gnome-audio-2.0.0-215 gnome-backgrounds-2.20.0-56 gnome-bluetooth-0.11.0-3 gnome-bluetooth-lang-0.11.0-3 gnome-certauth-devel-0.3-3 gnome-commander-1.2.4-76 gnome-common-2.20.0-4 gnome-cups-manager-0.32-40 gnome-cups-manager-devel-0.32-40 gnome-desktop-2.21.90-4 gnome-desktop-devel-2.21.90-4 gnome-desktop-lang-2.21.90-4 gnome-doc-utils-0.10.3-97 gnome-doc-utils-devel-0.10.3-97 gnome-games-2.20.0.1-84 gnome-games-lang-2.20.0.1-84 gnome-icon-theme-2.21.4-4 gnome-keyring-2.21.90-3 gnome-keyring-devel-2.21.90-3 gnome-keyring-lang-2.21.90-3 gnome-keyring-manager-2.20.0-53 gnome-keyring-pam-2.21.90-3 gnome-mag-0.15.0-3 gnome-main-menu-0.9.8-152 gnome-main-menu-devel-0.9.8-152 gnome-media-2.20.1-84 gnome-media-devel-2.20.1-84 gnome-menus-2.21.90-6 gnome-menus-devel-2.21.90-6 gnome-mime-data-2.18.0-54 gnome-mount-0.7-41 gnome-netspeed-applet-0.14-43 gnome-netstatus-2.12.1-125 gnome-netstatus-lang-2.12.1-125 gnome-nettool-2.20.0-53 gnome-panel-2.21.90-2 gnome-panel-devel-2.21.90-2 gnome-panel-doc-2.21.90-2 gnome-pilot-2.0.15-80 gnome-pilot-devel-2.0.15-80 gnome-pilot-lang-2.0.15-80 gnome-power-manager-2.21.1-4 gnome-printer-add-1.0.1-190 gnome-python-desktop-2.21.2-2 gnome-reset-0.1.1-181 gnome-screensaver-2.20.0-59 gnome-session-2.21.90-4 gnome-settings-daemon-2.21.90.2-3 gnome-settings-daemon-lang-2.21.90.2-3 gnome-sharp2-2.16.0-89 gnome-speech-0.4.18-3 gnome-speech-devel-0.4.18-3 gnome-spell2-1.0.8-4 gnome-system-monitor-2.21.5-4 gnome-system-monitor-lang-2.21.5-4 gnome-terminal-2.21.90-4 gnome-terminal-lang-2.21.90-4 gnome-themes-2.21.5-5 gnome-utils-2.20.0.1-56 gnome-vfs2-2.21.90-3 gnome-vfs2-devel-2.21.90-3 gnome-vfs2-doc-2.21.90-3 gnome-vfs2-lang-2.21.90-3 gnome-vfs-obexftp-0.4-35 gnome-vfs-sharp2-2.16.0-89 gnome-volume-manager-2.17.0-156 gnome-web-photo-0.2-167 libgail-gnome-1.20.0-53 libgail-gnome-devel-1.20.0-53 libgnome-2.21.90-3 libgnomebt0-0.11.0-3 libgnomebt-devel-0.11.0-3 libgnomecanvas-2.20.1.1-3 libgnomecanvas-devel-2.20.1.1-3 libgnomecanvas-doc-2.20.1.1-3 libgnomecanvas-lang-2.20.1.1-3 libgnome-certauth0-0.3-3 libgnomecups-0.2.3-27 libgnomecups-devel-0.2.3-27 libgnomecups-lang-0.2.3-27 libgnomedb-3.1.1-43 libgnomedb-devel-3.1.1-43 libgnomedb-lang-3.1.1-43 libgnome-desktop-2-2-2.21.90-4 libgnome-devel-2.21.90-3 libgnome-doc-2.21.90-3 libgnomekbd-2.21.4.1-5 libgnomekbd-devel-2.21.4.1-5 libgnomekbd-lang-2.21.4.1-5 libgnome-lang-2.21.90-3 libgnome-menu2-2.21.90-6 libgnomeprint-2.18.3-4 libgnomeprint-devel-2.18.3-4 libgnomeprint-doc-2.18.3-4 libgnomeprint-lang-2.18.3-4 libgnomeprintui-2.18.1-39 libgnomeprintui-devel-2.18.1-39 libgnomeprintui-doc-2.18.1-39 libgnomeprintui-lang-2.18.1-39 libgnomesu0-1.0.0-204 libgnomesu-1.0.0-204 libgnomesu-devel-1.0.0-204 libgnomesu-lang-1.0.0-204 libgnomeui-2.21.90-3 libgnomeui-devel-2.21.90-3 libgnomeui-doc-2.21.90-3 libgnomeui-lang-2.21.90-3 libgsf-gnome-1.14.5-73 nautilus-gnome-main-menu-0.9.8-152 NetworkManager-gnome-0.7.0-15 OpenOffice_org-gnome-2.3.99.2-2 openssh-askpass-gnome-4.7p1-22 PolicyKit-gnome-libs-0.7-16 python-gnome-2.20.0-52 python-gnome-bluetooth-0.11.0-3 python-gnome-devel-2.20.0-52 python-gnome-extras-2.19.1-47 yast2-control-center-gnome-2.13.2-144 rpm -qa | grep yast | sort autoyast2-2.16.6-9 autoyast2-installation-2.16.6-9 yast2-2.16.25-3 yast2-add-on-2.16.1-4 yast2-add-on-creator-2.16.3-19 yast2-apparmor-2.1-68 yast2-autofs-2.15.3-15 yast2-backup-2.16.1-20 yast2-bluetooth-2.15.4-46 yast2-bootloader-2.16.5-4 yast2-ca-management-2.16.4-19 yast2-control-center-2.16.0-19 yast2-control-center-gnome-2.13.2-144 yast2-control-center-qt-2.16.0-19 yast2-core-2.16.25-3 yast2-core-devel-2.16.25-3 yast2-country-2.16.7-7 yast2-country-data-2.16.7-7 yast2-devel-doc-2.16.25-3 yast2-devtools-2.16.4-3 yast2-dirinstall-2.16.0-29 yast2-dns-server-2.16.1-19 yast2-fingerprint-reader-2.16.2-19 yast2-firewall-2.15.8-51 yast2-firstboot-2.16.3-5 yast2-ftp-server-2.15.9-71 yast2-gtk-2.16.2-3 yast2-hardware-detection-2.16.0-24 yast2-http-server-2.16.2-5 yast2-inetd-2.15.1-88 yast2-installation-2.16.15-4 yast2-instserver-2.15.4-85 yast2-irda-2.15.1-138 yast2-iscsi-client-2.16.2-25 yast2-iscsi-server-2.14.4-12 yast2-kdump-2.16.9-12 yast2-kerberos-client-2.16.1-19 yast2-kerberos-server-2.16.0-27 yast2-ldap-2.15.1-124 yast2-ldap-client-2.16.6-7 yast2-ldap-server-2.15.5-120 yast2-mail-2.16.0-5 yast2-mail-plugins-2.16.0-5 yast2-mcs-plugin-0.1.0-77 yast2-metapackage-handler-0.7.3-29 yast2-mouse-2.16.0-29 yast2-multipath-2.13.0-129 yast2-ncurses-2.16.13-3 yast2-network-2.16.21-10 yast2-network-devel-doc-2.16.21-10 yast2-nfs-client-2.15.0-68 yast2-nfs-server-2.15.5-14 yast2-nis-client-2.16.0-39 yast2-nis-server-2.16.2-5 yast2-nis-server-devel-doc-2.16.2-5 yast2-ntp-client-2.16.3-6 yast2-online-update-2.16.6-20 yast2-online-update-frontend-2.16.6-20 yast2-packager-2.16.19-4 yast2-pam-2.16.0-40 yast2-perl-bindings-2.16.0-44 yast2-pkg-bindings-2.16.12-6 yast2-pkg-bindings-devel-doc-2.16.12-6 yast2-printer-2.16.7-5 yast2-printer-devel-doc-2.16.7-5 yast2-product-creator-2.16.7-6 yast2-profile-manager-2.16.0-30 yast2-python-bindings-2.16.3-7 yast2-qt-2.16.20-4 yast2-registration-2.16.0-31 yast2-repair-2.16.4-7 yast2-restore-2.16.0-31 yast2-ruby-bindings-0.2.0-43 yast2-runlevel-2.16.0-31 yast2-samba-client-2.16.2-7 yast2-samba-server-2.16.0-43 yast2-scanner-2.15.5-86 yast2-schema-2.15.0-163 yast2-security-2.15.1-68 yast2-slide-show-SuSELinux-2.15.16-2 yast2-slp-2.15.0-75 yast2-slp-server-2.15.0-86 yast2-sound-2.16.2-12 yast2-squid-2.16.1-9 yast2-sshd-2.16.0-25 yast2-storage-2.16.9-5 yast2-storage-devel-2.16.9-5 yast2-storage-evms-2.16.9-5 yast2-storage-lib-2.16.9-5 yast2-sudo-2.16.0-5 yast2-support-2.15.3-58 yast2-sysconfig-2.15.3-101 yast2-tftp-server-2.14.0-148 yast2-theme-openSUSE-2.16.7-2 yast2-trans-de-2.16.1-10 yast2-trans-en_US-2.15.5-29 yast2-transfer-2.16.1-13 yast2-trans-ru-2.16.1-10 yast2-trans-stats-2.15.0-56 yast2-tune-2.15.7-68 yast2-tv-2.16.3-12 yast2-update-2.16.4-9 yast2-users-2.16.8-4 yast2-x11-2.15.11-74 yast2-xml-2.16.0-22 antonyarendt@workstation6l:~> rpm -qa | grep compiz compiz-gnome-0.5.4-78 compiz-0.5.4-78
I have had this problem with YaST Qt and Gnome on a PC running openSUSE 10.3 ever since I installed it. Whenever I start YaST Online Update or Software Installation, whether from the YaST Control Center or (the former) from the opensuse-updater-gnome-applet, my X session becomes unusable for minutes on end, because a seemingly endless series of pop-up windows about reading caches and RPM databases, downloading, updating repositories, cleaning caches and checking dependencies keeps popping up, each one grabbing the focus no matter what I'm doing. This is not a question of machine or network performance: I'm running this on a dual-core Pentium D 3.2 GHz with 2 GB RAM behind a 2 MBit/s DSL line. If that isn't sufficient I don't know what is. All updates offered by YOU as per today are installed (painful as it was) but none of them made any difference. I have the line WANTED_GUI="qt" in /etc/sysconfig/yast2 to force the Qt GUI, after serious (other) problems with the GTK version. I do hope that this provides the information you need in order to proceed towards a solution of this problem. If not, accept my apologies and tell me what the needed information is; I will do my best to provide it.
cc michael meeks, who is internal maintainer of yast2-gtk.
This doesn't have to do with yast2-gtk. Comment 42, for instance, says he uses the Qt interface. The culprits are both the YCP code that flashes those dialogs (which no longer happens on the 11.0 Alphas), and Metacity as in bug 331835 (which the bug report says was fixed as an Update). So, lets close the report.
Well, can we at least have the fix backported to the gtk interface in 10.3? If there's been a fix in the update channels, it's not applied to either of my 10.3 systems, so that tells me that there hasn't been an update published to fix this for 10.3. Not everyone is running 11.0 alpha/beta code.
Again, it has nothing to do with the GTK interface of Yast. With regard to fixing it, one way to go is by distributing a Metacity patch through YOU. Federico Quintero seems to say in bug 331835, comment 17 that he did so. I guess I misread that. Federico?
And its not just metacity, as I am using compiz as a window manager.
Stefan, is it really a big deal there as it is with Metacity? Because there were reports from KDE users too, but it is more annoying than nefarious there. In any case, I just know that Metacity was fixed to better workaround flashing popups. You have to open a bug report for Compiz too. Please reference it from here, so other users can get to it.
Ricardo, this bug is not about metacity. Its about 'Yast stealing focus'. For compiz the issue simillar, whenever a new popus comes up (and there are many) it becomes active. The only workaround with compiz is to switch to a different desktop (means different viewport), where for some reason the focus is not stolen. The popup stay a the other desktop (at least those he scan the different repositories).
Ricardo, that's fine - but the bottom line for me is that the fix hasn't been distributed through the update channel (whatever the fix is), so the issue is still here for me. I don't see how it can be called "fixed" if the fix isn't in the channel. While I am capable of building/compiling/installing software from sources, it seems to me that this shouldn't be necessary, and if a fix is available, the fix should be distributed before the bug is closed. IMHO, of course. :-)
I agree with you, Stefan. In comment 44, I mentioned the two components of the bug: * Yast tools: shouldn't flash popups like crazy. This is fixed on 11.0 Alphas, and I am not sure how easy it is to backport. I also don't know what module is responsible for this. Anyone? * Window managers: shouldn't steal focus for popups while the user is typing. Both are to blame, and both should fix, but we just need to backport one. So, with regard to which should be back ported, I would say the easiest to backport. Until I realized this was a problem with Compiz, I'd say to backport the Metacity patch. However, since we don't have a Compiz patch to go with it, I guess we should try to get the responsible for the Yast/YCP module to arrange for a patch. Either way, we probably also want to fix Compiz in the future, since obviously no window should interrupt the user while he is interacting with another one. I'm re-opening it then, and will drop a mail in the yast-devel mailing list.
Btw, I think this is a duplicate of bug 246934. The reporter there is just a more conforming guy, and would be already satisfied to be able to not have the popups when the window is minimized, but it comes down to the same. Anyway, lets keep working on this one...
I think ultimately the problem is the use of popups to convey *status* information - to me that doesn't make sense at all. If I've got 5 repos in my list, I don't need a popup notification that it's moved on from the update repo to the Packman repo - if there's a problem, I would want a notification of that, but I think popups are being overused in the update module (as well as the software installation module). A progress bar with a status area that shows what's being displayed in the popup (ie, "Refreshing Packman", etc) would make a lot more sense to me. Then if there's an error, pop something up - but don't have the default be "Abort" - either select no default button or select "Retry" as the default button - more often than not, if I'm typing in another application and I hit "enter" just as the dialog pops up, I end up aborting something I wanted to retry or examine - retry would be the safest option, because if I see a dialog flash past as I hit enter (when it takes focus), I'm going to wait for the dialog to come back. If it aborts, I have to start over again. I don't believe popups should be used at all to convey status - they should only be used when it's necessary to take focus to communicate something important to the user, and preferably only when there's an action the user has to take as a result of the information presented.
(In reply to comment #46 from Ricardo Cruz) > With regard to fixing it, one way to go is by distributing a Metacity patch > through YOU. Federico Quintero seems to say in bug 331835, comment 17 that he > did so. I guess I misread that. Federico? Argh - my bad, sorry. I submitted the Metacity package with the fix to the build system, but forgot to go through the process of requesting an online update. This should be done tomorrow.
Alright, so this is what the yast team has to say: Stephan Kulow: The progress handling was redone pretty heavily for Factory and I see no way of backporting this. If there is no easy fix for compiz, then I would indeed suggest to close it FIXED (for 11.0) I know some people would love us to fix 10.3 till it's perfect, but this just does not work out. Ladislav Slezak: I completely reimplemented the callbacks, now the progress is displayed in the main window instead of popups. This is a large change so it won't be backported to 10.3. With the Metacity fix applied, this isn't much of an issue. For those that use Compiz, I guess you guys will have to hang on. Sorry. :-/ It seems that XFCE users (window manager: xfwm4) has a "focus stealing prevention" option that you can enable.
Reopening. Confirming, that standard installation is fixed. But installation using YMP files still uses pop-up based interface (one popup per package and repository) in 11.0 Alpha3.
Still same in GM?
Nope, now fixed.
*** Bug 421994 has been marked as a duplicate of this bug. ***