Re: RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 23:04 +, Zing wrote: > On Wed, 06 Jan 2010 15:59:14 -0500, Owen Taylor wrote: > > > On Wed, 2010-01-06 at 16:00 +0100, nodata wrote: > >> I'd like to suggest an enhancement for Fedora 13: nothing should ever > >> steal focus from the window I am typing in. If I am typing in a shell > >> window, or in a word processor, or an e-mail, nothing should ever take > >> keyboard focus away from that window. > >> > >> Clearly I'm missing something, otherwise we would have this, hence the > >> posting to the list :) > > > > I'm not sure what you are missing, but I know what I'm missing here - a > > description of when exactly focus was stolen from you that was a > > problem. > > > > In almost all cases, if you are typing into one application in Fedora, > > and a window pops up from another application and steals away your > > focus, and your typing goes to the wrong place, that's a bug that should > > be filed against one of: > > > > - The application that popped up a window - The application that you > > are typing into - The window manager > > > > With the most likely candidate being the first one. If you run into such > > problems and you are using GNOME with Metacity (or gnome-shell and > > Mutter), please feel free to file bugs against Metacity and I'll help > > you figure out where they should be reassigned. > > > > There are also a number of GConf options for Metacity that can be set to > > modify the exact behavior; these are mostly, however, intended as > > workarounds for people using closed source applications that can't be > > fixed properly. When all the applications are under our control, it > > should "just work". > > Would you (or someone) mind explaining why the following happens and how I > could get pre-F12 behaviour?: > > In Fedora 12, > 1. start seamonkey > 2. start gnome-terminal (be on top of seamonkey window) > 3. $ seamonkey -remote "openurl(http://lwn.net,new-tab)" > 4. seamonkey pops in front and steals focus. > > This used to just load the page in the background without stealing focus. > It seems like there are a myriad of confusing ways this can happen and a > several options to mitigate it... but I'm lost. (A caveat here is that I can't speak to Compiz or Kwin or XFCE behavior, I can only discuss the behavior of Metacity. That is, GNOME with Compiz not selected in the desktop-effects tool.) In regards to Metacity, there were no changes that I can think of in this area between Fedora 11 and Fedora 12, so if anything changed it probably was a change to Seamonkey. There are two things in the situation that you describe which are somewhat difficult to handle: First, when you run a program from a terminal, there's no way that a launch timestamp will be set on that program, because the launching isn't done by gnome-panel, or some other GUI program, it's done by bash, which is ignorant of desktop niceties. So at that point, it's basically back to a fixed policy of taking focus or not stealing focus. The default is to take the focus. Second, when activating an existing app rather than starting a new application, the focus timestamp, if it exists, has to be passed across whatever protocol is used (here it is the "Mozilla Remote" protocol via X messages.) If I had to guess, I'd guess that prior to Fedora 12, Seamonkey wasn't worrying about timestamps at all - it wasn't passing a timestamp - so the new window was created with an old timestamp of the last time you interacted with Seamonkey. But an updated version now tries to do something smarter. Since no focus timestamp exists when invoking the remote command from a terminal, it ends up grabbing the focus unconditionally. There's not really a fix for this - either grabbing the focus or not grabbing the focus will annoy some people. But since it annoys you, you may find: gconftool-2 -s -t string /apps/metacity/general/focus_new_windows strict To be useful - when that's set, new windows never take focus away from a window that looks like a terminal window. (This is assuming the above opens a new window. If it changes an existing window, then "focus_new_windows" won't affect the behavior.) - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 22:12 +0100, Till Maas wrote: > On Wed, Jan 06, 2010 at 03:32:26PM -0500, Peter Jones wrote: > > On 01/06/2010 03:21 PM, Till Maas wrote: > > > >> How about making the gnome-panel give away its focus to the newly > >> created window? Within the gnome-panel, it should be pretty obvious > >> which actions should give away the focus and which should not. I do not > >> know, how easy to implement it is, though. > > > > That's pretty difficult for a launcher - how does the panel know that > > the launcher is going to create a window vs which is not? And how does > > it know what window it is? If you click on the firefox launcher, it > > runs a shell script. That script (may) eventually run an X > > application, but it in itself isn't one. What's the launcher telling > > the wm in that case under your proposed model? > > It could tell the WM, if a new window opens within the next second, > focus it. I guess this should work in many cases. But in a better world, > the launcher could maybe tell the WM if this process or a child of it > creates a new window, then give the focus to it. > Btw. I do not like it in general if a newly started application does not > immediately open a new window and is ready to be used, but instead takes > several seconds to startup and then take away focus if I am already > doing something else then to wait for it. This is also why I propose a > timeout for the focus giveaway. We already have ways of distinguishing these cases, and don't need to invent new mechanisms. - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 12:35 -0600, Serge E. Hallyn wrote: > Quoting Adam Jackson (a...@redhat.com): > > On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote: > > > Quoting Adam Jackson (a...@redhat.com): > > > There is no case where I want a new window or popup to take focus. Makes > > > for an easy algorithm. (hitting r in mutt is not a problem :) > > > > There is no case where _you_ want this, sure. > > Yes, exactly. You're saying that > 1. there are cases where you want a window to pop up > 2. it's too complicated to figure out which windows should pop up > 3. so windows should always pop up, no point being configurable > > and ridiculing us over (2). I'm saying there are no cases where I want > a popup, so we can easily have 2 configurable options: always have windows > pop up and take focus, never have them do so. > > That's all. This discussion would make a whole lot more sense if the current behavior was actually that windows always pop up and steal focus. It isn't. We actually have a mechanism that works pretty well for knowing when focus should be stolen and when not. (Not a Fedora or GNOME method, but one encoded in the freedesktop.org standards.) In simple terms, it works by comparing timestamps: - What was the timestamp of the user action that triggered the window to pop up? - What was the timestamp of the last user action with the currently focused window? If the timestamp for the user action that triggered the popup is newer than the timestamp of the last user action with the currently focused window, then focus is transferred. This isn't 100% perfect ... it's no substitute for electrodes implanted in the user's brain. But it's a pretty darn good method when all the actors are playing by the rules. So, when things go wrong, our first step shouldn't be adding a configuration variable, but trying to figure out if there is a bug that needs to be fixed. - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 16:00 +0100, nodata wrote: > I'd like to suggest an enhancement for Fedora 13: nothing should ever > steal focus from the window I am typing in. If I am typing in a shell > window, or in a word processor, or an e-mail, nothing should ever take > keyboard focus away from that window. > > Clearly I'm missing something, otherwise we would have this, hence the > posting to the list :) I'm not sure what you are missing, but I know what I'm missing here - a description of when exactly focus was stolen from you that was a problem. In almost all cases, if you are typing into one application in Fedora, and a window pops up from another application and steals away your focus, and your typing goes to the wrong place, that's a bug that should be filed against one of: - The application that popped up a window - The application that you are typing into - The window manager With the most likely candidate being the first one. If you run into such problems and you are using GNOME with Metacity (or gnome-shell and Mutter), please feel free to file bugs against Metacity and I'll help you figure out where they should be reassigned. There are also a number of GConf options for Metacity that can be set to modify the exact behavior; these are mostly, however, intended as workarounds for people using closed source applications that can't be fixed properly. When all the applications are under our control, it should "just work". - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help wanted with dist-cvs to git conversion
On Fri, 2009-12-11 at 11:05 +0100, Thomas Janssen wrote: > 2009/12/11 Jesse Keating : > > For the initial testing, just giving every user a @feodraproject.org > > domain would be sufficient, however we should have a discussion about > > whether to use this email address or to use the user's real email > > address. > > Definitely @fedoraproject.org email addresses. A lot of us use them > even in Bugzilla, all my packages have the fp.o address in %changelog. > I dont want to fiddle around when i change my "real" email address. > Just pop in to FAS and change it there, done. Another consideration in favor of using @fedoraproject.org emails is if you use real emails, they will be used for old commits, even when that's not historically accurate. We went with @src.gnome.org addresses for the GNOME git conversion because we didn't want, say, 5 years of work someone did at company A show up as commits from u...@companyb.com because that's where they work now. - Owen (We actually did something a little fancier at that - if the log message for the CVS/SVN commit contained something that looked like a ChangeLog entry with an obvious email address, then we used that as the Author and the @src.gnome.org only as the Committer. If we couldn't determine a plausible Author, then we used the @src.gnome.org address for both.) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, 2009-11-20 at 11:50 -0430, Robert Marcano wrote: > On 11/20/2009 10:04 AM, Matthew Garrett wrote: > > I know basically nobody who, on a generally single user system, > > explicitly switches to a console to log in as root and perform package > > installs there. If you're not doing that then the issue is basically > > moot - a user-level compromise will become a root-level compromise the > > next time you run anything as root. > > I do that on critical workstations because a long time ago an old > (fixed) bug killed my X session when updating and messed my system, so I > do not trust too much updating base X components using a GUI. on my > personal systems, yes I use the GUI method This actually is one of the big advantages of PackageKit - because the installation is being done by a daemon rather than a process running in your session, if the X session dies during package installation, you won't be left with a half-completed transaction. Though that only helps from the command line if you use gpk-install-package-name rather than yum. Probably not too many people do that :-) - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
PackageKit policy: background and plans
I wanted to provide an update to the list on the current thinking about the PackageKit policy issue from the perspective of the people working on the core desktop packages and on the desktop user experience. There was informal meeting earlier today with Richard Hughes, and myself, and a couple of people who could provide help with big-picture Fedora issues like Bill Nottingham and Jesse Keating, to try and figure out if there were obvious steps to take in the short term. Obviously there are lots and lots of people who care deeply about this, and there are discussions that need to continue, but with the delay in getting packages built, tested, and pushed out, we thought there were advantages to jump-starting things. If there was something obvious, then it made sense for the package maintainer (Richard) to just do it. I'm writing this mail somewhat by default: the people who really matter are the maintainers of the relevant packages, but Richard has gone to bed, and David Zeuthen and Matthias Clasen are on vacation this week. I'll try to reflect what they would say; much of it is certainly my own personal take on things instead. - Owen Where the Fedora 12 policy came from In Fedora 9, 10, and 11, the first time a user tried to install a package from the Fedora repositories, they would be prompted for a root password, with a checkbox to remember that permission for the future. (Before Fedora 9, you had to enter the root password every time.) We weren't really fully happy with this; this was basically asking the user to construct their own security policy. And not only that, but do it dialog-by-dialog, permission-by-permission as they tried to set up their Fedora system and get on with their life. >From a more general perspective, the end effect of putting up a lot of dialogs: +---+ | | | < A complicated explanation > | | | | Root password [ ] | | | |[ OK ] | +---+ is that you are training users to blindly enter the root password and hit OK, *not* something that enhances the overall security of the system. There is an obvious better way to do this, which is to figure out what the appropriate roles are for the system: adminstrative users, non-adminstrative users, etc., and let the person maintaining system decide who gets what role. So, David Zeuthen did a major redesign of PolicyKit to move it from the old "remembered permissions" policy, to a model where users could be assigned different roles. See: https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html For some more details about how it works. The idea was that the change in PolicyKit would be accompanied by a default set of roles, and a nice user interface for assigning users to roles. Unfortunately, with the constraints of time, it became clear that this all (and especially the GUI) wasn't going to be there for Fedora 12. So, PackageKit needed a fixed policy for all users. For each action (install signed packages, install unsigned packages, remove packages, etc.), it needed to allow, deny, or ask for the root password. Among the decisions Richard made was allowing all users to install signed packages from the Fedora repositories. This was clearly the right behavior for the common case of a single-user system, where the only user is also the administrator. And it seemed pretty safe: Fedora isn't supposed to have packages in it that are dangerous to install. (For example, by policy, all network services must be off by default and not enabled by simply installing a package.) The reaction (why that probably wasn't the best choice) === There's obviously been a lot of feedback on this list and in other forums about this approach. And a lot of good points have brought up. Probably the most important one is a bit obvious in hindsight: Fedora is used on a wide variety of systems, and in some of those - like a shared home system with parents and young children, or like a computer lab system - there are some users who shouldn't be able to change what is installed on the system. Even if installing those packages isn't a security hole. The other thing that is clear from the discussion is that we didn't do nearly enough communication about the change. I think was partly because the changes *weren't* finished. A rewrite of PolicyKit wasn't a feature in itself; the feature would have been the accounts dialog, which we didn't do for Fedora 12. But clearly the changes we did do had some major impacts that needed to be advertised. And while there are great low-level docs with all the details about PolicyKit configuration (see polkit(8) for a starting point to the docs), we didn't have the simple instructions for changing basic system policy. Moving forward from
Re: Security policy oversight needed?
On Thu, 2009-11-19 at 13:36 +, Richard Hughes wrote: > 2009/11/19 Owen Taylor : > > By having that two part policy, and having the straightforward user > > configuration GUI that we've been wanting for years, I think we cover > > almost everything. And we don't have to ask the user at install time a > > question that they can't answer: "do you want your machine to be safe or > > to be convenient?" > > Would this be part of the existing system-config-users tool or a new > thing altogether? I think the assumption we've been making it would be working via PolicyKit rather than than consolehelper and wouldn't be called system-config-*, but that's really a detail. The bigger deviation is the user interface; system-config-users is basically /etc/passwd in a GtkTreeView. We'd want to introduce the idea of predefined roles. We'd want to include the head-shots shown in GDM, and otherwise make the user interface pretty and friendly. We might even want to add things like "parental control" type configuration of when certain users can use the computer. > Are there any prototypes or mockups yet? I think we may have gotten to the mockup stage a couple of times; I seem to remember some designs that Bryan Clark did a couple of years ago, and there was another bit of work on it about a year ago. You can ask around. The project has tended to suffer a bit from scope creep. It's pretty clear how to design a nice tool that manages local users. Personally I think that's what we should write. But once you start worrying about LDAP and frameworks for network login abstractions, then it gets much, much harder to create a pleasant experience for the simple case. - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Thu, 2009-11-19 at 08:29 -0500, Paul W. Frields wrote: > On Thu, Nov 19, 2009 at 12:32:50PM +, Richard Hughes wrote: > > 2009/11/19 Naheem Zaffar : > > > policykit-profile-server > > > policykit-profile-controlled-deployment > > > policykit-profile-personal-desktop > > > > Sure, that's not an insane idea at all. I would imagine most network > > admins worth their salt would be shipping custom PolicyKit overrides > > in F12 anyway. Aim for the desktop use cases on the "Desktop" spin, > > and let other spins change the defaults. > > It makes sense to me for the upstream defaults to be fairly > restrictive, with changes being made downstream in distros (and their > remixes/spins) to loosen those up as needed. In other words, our > desktop package group would include whatever was needed to induce the > desired behavior in the Desktop spin. A good bit of this issue would > need to be addressed upstream though. (Maybe I just repeated what you > said, not sure if I caught the nuance.) This idea comes up a lot - that we can make Fedora packages be uncontroversial raw material, and then make the hard decisions at the spin level. (I'm speaking more generally than this particular issue.) It doesn't work practically: configuration for packages needs to live with the package. Putting gigantic amounts of configuration into the %post of a kickstart file quickly becomes unmanageable. And the idea that we make configuration changes in the %post of the kickstart really falls part badly once people start upgrading their install to the next version of Fedora. It doesn't work statistically: people in general don't get upset about decisions made about the desktop because they aren't using a desktop. They get upset because they *are* using a desktop and have a different vision for that detail. It doesn't work out conceptually: you can't escape having to make decisions. If the only vision we have is how the Desktop spin works, then what policy goes into the package? Practically speaking it will be the configuration that was designed for the desktop spin, with various random changes and missing pieces where people yelled a lot on fedora-devel-list. That's not a coherent operating system. (And it's a bad basis for spins other than the Desktop spin.) - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Thu, 2009-11-19 at 11:15 +, Richard Hughes wrote: > 2009/11/18 Chris Adams : > > I would like to see this discussion separate from discussion about the > > current issue with PackageKit. > > That would be nice :) > > The problem is who to target. If you call Fedora a desktop distro, > then it makes perfect sense for local users to be able to shutdown the > computer, suspend, change the system clock and install clipart without > passwords, as long as it's done in a secure way. > > If you call Fedora a server OS, then it shouldn't be shipping > PackageKit at all, and should have most of the PolicyKit > authentication actions defaulting to no. > > So obviously we need some middle ground. I guess if the spins > "personalise" the package set then they should also personalize the > security defaults. e.g. a server spin would not include PackageKit at > all, and default to not letting users change the time. A desktop spin > would allow the desktop user to do most things without a administrator > password. The tricky part is deciding a default policy that is > suitable for all the people using Fedora, which honestly, I think is > impossible. It seems to me that the way to proceed here isn't to worry about different classes of Fedora installations, but rather to think about different classes of *users*. There may be a few machines where nobody is trusted to install signed packages without typing in the admin password again; luckily PolicyKit is a very configurable framework. But most cases, things separate pretty cleanly into: - People who are assumed to know what they are doing (parents, the departmental IT guy, etc.) - People who don't get to reconfigure the machine (children, students, etc.) By having that two part policy, and having the straightforward user configuration GUI that we've been wanting for years, I think we cover almost everything. And we don't have to ask the user at install time a question that they can't answer: "do you want your machine to be safe or to be convenient?" - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages
On Mon, 2009-07-27 at 16:59 -0300, Allisson Azevedo wrote: > I am orphaning this packages because i don't have time to maintain > them. > > clutter -- Open Source software library for creating rich graphical > user interfaces > clutter-cairo -- A basic Cairo clutter widget > clutter-gst -- ClutterMedia interface to GStreamer > clutter-gtk -- A basic GTK clutter widget > pyclutter -- Python modules that allow you to use the Clutter toolkit I can certainly pick up clutter (in fact, I may have already been a co-owner of it...) I don't really mind doing the rest, but I'd prefer to have a co-owner since I'm likely to miss upstream releases and otherwise be not be that attentive at times... I don't actually use them at all. - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
an update to automake-1.11?
I was rather surprised to see: https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 Where the automake was upgraded to 1.11 for F9, F10, and F11. In general automake hasn't had a very good track record of compatibility between 1.x and 1.y, though this has been getting better recently. I don't see any specific mentions of incompatible changes in a quick scan of: http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html But it is also a pretty long release announcement so it wouldn't surprise me if there were some subtle incompatibilities. The only breakage I'm actually aware of in the gnome-common package; gnome-common-2.26 and earlier doesn't know that automake-1.11 is a valid replacement when automake-1.10 is asked for. So, we definitely need to release an update for gnome-common, or people aren't going to be able to do GNOME development on F11. But is this the type of upgrade that makes sense in general? It seems to me that we should be very conservative in upgrading build tools, especially in "maintenance mode" distributions like F9 and F10. - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dropdown menu's
On Sun, 2006-03-05 at 00:37 +0100, Erwin Rol wrote: > Hey all, > > This is something that already bothers me a while, i think it never > really worked as expected, but i am not sure if it is a "my machine > only" kind of problem. > > Dropdown menu's that don't fit on the screen are not displayed > correctly. For example take the gimp file-open dialog. When you move the > dialog to the bottom border of the screen, and press the "All Files" > dropdown menu, the menu will open, and the bottom of the menu will be > aligned with the bottom of the screen, the top of the menu will be > somewhere mid screen. But the first entry will be at the location of the > position of the dropdown box, and so everything above that position is > empty. I tried to make a screenshot, but that didn't work with the > dropdown box open, i suggest to just try it. Since it happens with every > GTK application, it smells like an GTK issue. Discussion, links, etc.: http://bugzilla.gnome.org/show_bug.cgi?id=129463 Regards, Owen
