New and improved Metacity

The constraints_experiments stuff is now done and merged to head, and Metacity 2.13.2 has been released with the changes. The full ChangeLog can be viewed or the super-summarized version that basically just lists the bugs fixed (though bug 86644 should have also been on that list), the new enhancement, and major structural code changes.

It’s probably worth noting that I expect many will dislike the screen timeout resistance at first. This is because everyone has been trained that if they want to move their window to the screen edge then they have to move slowly or they’ll overshoot. Therefore they won’t take advantage of the new feature and the only time the new ability will kick in is the times when someone really is trying to move their window offscreen, in which cases it’s a hindrance. But see bug 106740 comment 39, which really applies to all edges and not just the top. Slamming windows to the screen edge should be a more common use case then moving windows off the screen, and so we should enable users being able to do that and do so at *maximum velocity* (i.e. users should be able to “throw” their windows to the screen edge). I might tweak the screen timeout later, but for a while at least it will be left where it is (the other numbers, however, will likely be tweaked much sooner). Sorry if you hate it at first, but I expect that once people have retrained themselves and start making use of it they’ll start loving the ability to throw their windows to screen corners. I need to give everyone enough time so that the retraining has taken place or the feedback won’t really be fair to the tradeoffs involved.

Some words worth repeating

[At http://gnomedesktop.org/node/2468#comment-39184 I posted the following, and I thought it might be worth repeating here. Note that words in italics are quotes from the person to whom I responded.]

It’s difficult to claim that GNOME is community project because all the important decisions are made by employees of corporations at the behest of their paymasters. This isn’t always a bad thing, since a variety of opinions is needed… but the viewpoint of average user/developer isn’t represented in GNOME, and is in fact ignored.

Wow, somehow I missed that. I didn’t know that my opinions as a volunteer didn’t count. Yet somehow I managed to become a bugmaster, have heavily influenced the direction of metacity, became a co-maintainer for libwnck, and am a member of the release team (and, in fact, recently became the release team manager though that’s a role that I’m actively trying to make not mean much; especially since I’m in the odd situation where everyone else on the team is more qualified to be on it than I am).

I’m by no means a lone exception either; I can point you to other influential volunteers. Yes, there are a large number of developers who get paid by various companies to work on Gnome, but that’s a reflection of the fact that the community is growing to the point that businesses are interested in it and thus tend to hire many of the individuals in the community (and/or individuals in the community start up a company themselves). But that’s no different than how the linux kernel operates.

Anyone who has followed GNOME over the last few years cannot have failed to notice this. From corporate GNOME developers ignoring bugzilla patches, roundly ignoring any comments

You try to make the lack of patch review and response on many bugs sound like a conspiracy. It’s not. It’s a failure of the community at large and it’s not limited to Gnome either. Take a look at http://mail.gnome.org/archives/desktop-devel-list/2005-March/msg00136.html for example. That email (and others) explain how there just isn’t enough hours in the day for the current developers to handle everything. I’ll let you in on a little secret: you can help.

I used to sit around waiting for all the patches to get reviewed too, and would often have to politely ping developers in other forums (irc, email, via coworker, etc.). One day, I started trying to assisting other people who had submitted patches by pointing out parts of it that wouldn’t pass review by the maintainer (and always pointed out I wasn’t the maintainer whenever I did so). After a while, the maintainer started asking me to review various patches or would say in some cases that if I’ve looked at a patch and tested it out, then it was okay to commit.

Maintainers would love to do the same thing and get lots more people reviewing patches. But they need to have someone that they know understands the code and design goals of the project in order to do so. The only way they find out if someone is capable is if people start doing “pseduo-reviews”.

Also, I’ll point out that you try to point out this lack of patch review and bug review as a corporate oriented thing. That’s not true. Volunteers also drop stuff from sheer lack of time. There are many outstanding libwnck and metacity patches out there that I personally should be looking at. It’s not from a conflict of interest from an employer (I’m a student so no such conflict of interest could exist), it’s just a lack of time. Yes, it is totally embarrassing to have some patches get through the cracks and take over a year (the maximize-to-fill bug in particular that I’m thinking of–I totally suck for not responding yet). I do try to respond to most quickly but I don’t get them all. Please help.

to the absolutely refusal to setup a Metacity mailing list on the grounds that (and I kid you not), people might comment on the software.

That’s a very misleading way to represent the reasons. Further, it doesn’t back up your claim that it was corporations are in some kind of conspiracy or tight control. Rob Adams, a volunteer who has done an awful lot of work on Metacity, represented the strongest opinion against the creation of such a mailing list. Yes, Havoc was also opposed, but he was not the only one. I, as another volunteer, agreed for a while as there are several good reasons (bugzilla can be used to track bugs and carry on discussion–what does a mailing list add?, further it can be used to mark duplicates which mailing lists suck at, etc.) Besides, Metacity is kind of the favorite punching bag of everyone (admittedly because it still sucks pretty bad) and the sad fact of the matter is that as a developer trying to fix its problems you often spend more time responding to peoples’ constant criticisms or queries or hard-to-understand duplicate reports instead of actually fixing the stupid bugs. The signal-to-noise ratio is often terrible. You may not think it’s a big deal as one individual, but when you multiply by hundreds of people it becomes a real problem. The only way to try to fix it is to try to increase the signal to noise ratio by e.g. avoiding those that will try to get into long arguments or that constantly whine (no, this is not true of everyone in the community, but there are far too many noisy individuals that suck time these ways).

Anyway, I don’t know if I’ve really explained the reasoning behind this very well, but let me point out that metacity-devel-list was created later. Interestingly enough, not very many people have posted.

Yes, I’d say the days of GNOME as a community project are long past. It’s now a collection of prima donnas in the pay of various corporations.

Couldn’t be further from the truth.

Edge Resistance and extending deadlines

I guess I don’t blog about anything but the constraints_experiments stuff these days. Oh, well. After I missed the deadline last week, Olav was interested enough in getting edge resistance that he encouraged me to take another week and put off the bugzilla stuff. I did so, and made a lot of progress, but missed that deadline too. So he gave me another week. Hopefully I should finish this time. The basics are in place and part of the edge resistance stuff is working already, so it looks encouraging.

So I really need to finish it this week. Somehow, sometime, I also need to get some usability feedback on certain decisions on the branch, fix up some regressions and other small bugs, and document how the stuff on the branch is structured. Then we can open up testing, get some expert reviews and tests, and then hopefully merge it all to HEAD.

Missed the deadline…

Well, I missed my self-imposed deadline on the constraints experiments work I’ve been doing on Metacity. I really need to help Olav out with bugzilla, though, so it’ll have to kind of be on the backburner for a little while. It’s kind of painful to do it that way since I like the branch version so much better (since the couple major regressions don’t affect my usage scenarios). Anyway, for the curious, I thought I’d list the bugs that got fixed on the branch in the process of trying to rewrite constraints.c to make it human readable and ensure that it was flexible enough to handle everything we needed.

FIXED:

  • unfiled – constraints.c is overly complicated[1]
  • unfiled – constraints.c is not robust when all constraints cannot simultaneously be met (constraints need to be prioritized)
  • unfiled – keep-titlebar-onscreen constraint is decoration unaware (since get_outermost_onscreen_positions() forgets to include decorations)
  • 109553 – gravity w/ simultaneous move & resize doesn’t work
  • 113601 – maximize vertical and horizontal should toggle and be constrained
  • 122196 – windows show up under vertical panels
  • 122670 – jerky/random resizing of window via keyboard[2]
  • 124582 – keyboard and mouse snap-resizing and snap-moving erroneously moves the window multidimensionally[3]
  • 136307 – don’t allow apps to resize themselves off the screen (*cough* filechooser *cough*)
  • 142016, 143784 – windows should not span multiple xineramas unless placed there by the user
  • 143145 – clamp new windows to screensize and force them onscreen, if they’ll fit
  • 144126 – Handle pathological strut lists sanely[4]
  • 149867 – fixed aspect ratio windows are difficult to resize[5]
  • 154706 – bouncing weirdness at screen edge with keyboard moving or resizing
  • 156699 – avoid struts when placing windows, if possible (nasty a11y blocker)
  • 302456 – dragging offscreen too restrictive[6]
  • 308521 – make uni-directional resizing easier with alt-middle-drag and prevent the occasional super annoying resize-the-wrong-side(s) behavior
  • 312007 – snap-resize moves windows with a minimum size constraint
  • 312104 – resizing the top of a window can cause the bottom to grow

So what’s left?

  • The “force new windows onscreen” and “don’t allow apps to become partially offscreen due to a resize unless already partially offscreen” behaviors make edges seem special and make it weird to not have edge resistance at screen edges when the user moves windows around. So, the long requested edge-resistance feature request needs to be written[7]. This has been started.
  • Fix the regressions (shouldn’t be hard, but I’m waiting off on this due to the infrastructure that needs to be added for the edge resistance stuff)
  • I need to write up some documentation about the structure of the framework and changes made; I started that over a month ago but it’s actually misleading now as I’ve had to modify the framework a fair amount. Should be relatively easy; just need a couple hours to write everything up and carefully check that it’s easy to understand.
  • (Optional) Fix the extra issues related to fixed bugs (or almost fixed ones) pointed out in the notes below

NOTES:

[1] Well, at least I hope so. constraints.c is much easier for me to read, though largely due to the fact that much of the complexity has been moved to boxes.c. However, there is an extremely thorough set of testcases for boxes.c in testboxes.c, and those testcases are automatically compiled into a simple test program named testboxes. I think this separation helps a lot for managing the complexity and for ensuring that things work correctly.

[2] Actually, not totally fixed (just annoying instead of almost completely unusable). Matthias had a suggestion that may fix the remainder of the problems.

[3] There are two closely related bugs remaining though. Trying to mouse snap uni-directionally is still difficult because we only provide a threshold of 1 pixel movement before snapping. Also, there’s a related issue in that if the user stops pressing shift before letting go of the mouse button, then the ButtonRelease triggers a non-snapped movement causing the window to “un-snap” from where it was to somewhere potentially far away. Neither of these should be too difficult to fix, I’ve just run out of time for now.

[4] This bug was originally about not-quite-so-pathological cases but was left open for the worse cases. The code on the branch handles the remainder of the cases mentioned in this bug.

[5] There’s still some bugs with it, namely (A) a slight drift that’s only noticeable after lots of resizing, and (B) nasty interaction with onscreen constraints. Neither of those are quite so common, though, so I’ve punted handling those, and in any event things are *way* nicer on the branch.

[6] Though I’ve done virtually no testing so I’m not sure if my new simple formula is too lenient or still too strict. However, any further adjustment to get it in the right range should be trivial.

[7] The patches in bug 81704 are nice and helpful for testing and perhaps for getting started (though it appears they only apply to moving windows and not resizing them), but much more needs to be done:

  • We should not have edge resistance at the edge of the “workarea”; with panels that only extend part of the length of the screen, we don’t want to snap to the “missing” part of the panel–we want to have edge resistance on the actual screen edges. Therefore, the correct patch can not make use of the meta_window_find_(next|nearest)_(horizontal|vertical)_edge functions.
  • Edges of the screen (including between monitors for xinerama setups) and edges of windows should be treated differently by edge resistance because we should facilitate users “throwing” their window against the screen edge. Using pixel-distance for resistance is not sufficient for this. We need to include timeouts too.
  • Magnetism sucks (haha, I’m so punny), resistance is good (Commander Riker proved The Borg were wrong). We do want to allow windows to kind of “stick” when they are already next to each other, and I’m of the opinion that magnetism was just a simple attempt to implement that (it’s probably much easier to implement windows getting sucked to each other when within a certain distance than to implement only allowing adjacent windows to move apart with a sufficiently strong move). I really hate having windows getting “pulled away from me”. I guess, in effect, I’m advocating something that could be called 0-distance magnetism to go along with resistance.
  • We should not have edge resistance/magnetism due to unseen edges. If you have some small window buried under a bunch of large firefox/gedit/openoffice/emacs windows, the current patches blindly snap to them. Again, that’s a shortcoming of the the meta_window_find_(next|nearest)_(horizontal|vertical)_edge functions in place.c and is another reason to not use them.
  • We shouldn’t be searching for edges more than we need to, we ought to just cache them when they aren’t going to change (i.e. create and cache them at the beginning of the move/resize op instead of recomputing them every time the window moves or resizes slightly during the move/resize operation. Also the screen edges can be found and cached when determining the workarea in workspace.c so that they don’t need to be recomputed with every move/resize-grab-op).
  • The keyboard snap moving/resizing needs to be fixed according to the relevant parts of the above criteria as well (including the fact that resistance should be strong enough to require several keypresses to move past the screen edge instead of just one). And instead of having the code duplicated in the keyboard resize function, the keyboard move function, and both the resize and move mouse functions once this gets implemented, we should factor this all out into one common place.