Author: Elijah

Anyone know how to put more hours in the day?

Sorry to everyone that’s had to pick up some slack from me or got responses much slower (or not at all in some cases) over the past few weeks. I know this was a really bad time for me to not be very available, but it wasn’t really avoidable. It hasn’t been quite as bad as I expected, though, and I’ve at least been able to respond randomly and intermittently to some things. Hopefully I should be able to continue to help with some of the release stuff until things start clearing up in another week or so and I can start attacking a long backlog for other stuff…

On a similar note[1], I was supposed to go through my CV a long time ago and make a resume-ified version for free software positions since I want to keep that on the table. Anyone have some good tips on handling that? Maybe I should ping Luis; I remember him posting a similar dilemma a while ago… *sigh* I’ve really sucked at this whole job search thing. I’ve made a couple early contacts but should have done more and started actual applications. But trying to do that and finish my dissertation at the same time my wife is doing her student teaching has been nightmarish and just hasn’t left enough time; it has pushed things so that I decided to shoot for graduation in the Fall instead to give me a little more time. But, such is life I guess. And being too busy is always better than the alternative.

Man, it’s so cool when new people show up and just start exterminating bugs left and right. It doesn’t happen very often, but Thomas Thurman showed up recently, tried fixing a couple Metacity bugs, emailed asking about what else he could do, and then took the large list of possibilities I responded with and appears to have decided that his answer to ‘which of these things should he pursue’ is ‘all of them’! Very cool. He’s already fixed a number of them and the patches just keep coming.

Hopefully, I won’t suck as much at patch review this time around. I’m afraid Björn Lindqvist, who had similiarly been fixing lots of stuff for us, probably decided to get interested in other projects when I went through a big unresponsive period last year. Sorry about that Björn, and much thanks for the many bugs you did fix.

Unfortunately, though, the next 2-3 weeks are going to be insane and will be *very* hard for me to be responsive to much of anything. But I’ll do my best.

John, those are great goals, but in general making official focuses on a subset of the range of possible improvements for Gnome would do more harm than good. And I say that as someone who spends almost all of his development time on Gnome by fixing bugs. I think Manuel Amador probably said it best when something like this came up previously:

For some odd reason, when people get told, say, “gnome 2.8 will
focus on performance”, only the hackers which like performance
hacking will be stimulated to work. IT’s almost as if you told
everyone “gnome 2.8 will ONLY do performance work”. Focusing
generally stymies those who think they don’t share the focus.

That’s not to say that we can’t try to increase the focus on bug fixing. Luis had a good comment in that same thread as well:

FWIW, it is my experience in previous gnome development cycles that
these things happen when one person takes responsibility for them
and nags widely and actively, ideally sowing code along the way.
Saying ‘everyone please set your own goals’ or ‘audit your own
stuff’ leads to sitting around at the end of the cycle and
wondering why the goal wasn’t achieved.

Obviously, fixing bugs yourself is one way of contributing. But there are lots of things non-developers can do to help increase work and attention in this area:

• Join the bugsquad and triage bugs
• Search for bugs that have been fixed recently or are being worked on. Blog on them. Providing a spotlight on some cool work going on motivates others to do similar work
• Try to find steps to duplicate common but hard to reproduce bugs. Add the information to the relevant bug report. (Here’s an example of one I did back before I became a Gnome developer)
• Volunteer to create showstopper review lists. These can help a lot, but this has been heavily neglected the last couple of cycles and we need more help.
• Try to find other volunteers to help with creating those showstopper review lists. This could include things like making a wiki page with general guidelines on making good showstopper review lists (some basic steps and examples already provided in that email, it just needs to be put together and then sent around to others for review and comments). Or blogging about it when someone else makes one. Or blogging about trying to get someone else to do it (man, am I lazy or what?) 😉

I’ve been stuck using pine for several months because Evolution has been totally nonfunctional. I’ll try to be level headed here instead of stating what a ‘pleasure’ this time has been and how much I have grown to ‘love’ Evolution for this. Somehow I stuck through it all and even spent time searching for Evolution bugs and comments on occasion, learning more diagnostics and even reading over the Evolution code.

Today, I found where someone who is apparently much smarter than I was provided a dirt simple workaround to my problem. In bug 317518 comment 9, John pointed out that one could symlink to the Inbox from the overridden namespace location in order to finally be able to access one’s Inbox again when using IMAP. Indeed, after ssh’ing to the relevant machine and running the simple
cd mail && ln -s /home/mail/newren INBOX
my INBOX now appears in the midst of all my other saved folders. Not the perfect UI, but hey, at least it works.

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.

[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.

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.

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.

So, Havoc has for a long time made comments about constraints.c and mentioned how it was busted, broken, wrong and complicated…among many
other
similar comments. It’s even to the point that he has said he may have too much inertia to review patches against it (not that I can blame him…), and that he wants it to be rewritten (again).

I was naive enough to try to tackle this. I had been eyeing it for quite some time, slowly trying to understand how everything worked. Then I started working pretty hard on this task. Then I thought I had everything finally figured out, had a fair amount of code written that I could use, and a good roadmap with the necessary ideas to get it all done pretty quickly. So much for quickly…

Anyway, things are finally starting to come together and the code has at long last reached a stage where it can be used as a demo (in other words, it really sucks to try to use it for normal work but if you avoid the known nasty regressions and brokenness, you can show off some of the smooth bugfixes). But I believe things are in pretty good shape and this new framework is easier to understand and update (though I’ll need others to chime in to measure whether that’s really true or not).

Anyway, it should be exciting. I’m hoping to get it good enough to merge onto HEAD in the next couple weeks so that I can help out Olav with bugzilla as I’ve been promising to do. Stay tuned…

A while ago Havoc pointed out that I needed to put my copyright name/date at the top of files to which I’ve made “nontrivial” additions or modifications. Sounded like a bit of a pain; he suggested that it wasn’t urgent and it might be something I could do as I made future changes as that would probably eventually get it all covered. I thought that sounded good–but now that it has been a while I now realize that this course of action just means I continue to forget. So, I made a little script to search for files potentially missing my copyright information.

The script gets some false positives (e.g. trivial changes, plus sometimes I may have just been moving a function someone else wrote to a different file, and I’ve committed many patches for other people), and it may also miss some changes (if someone else committed a patch I wrote), but overall I found it pretty helpful in narrowing down which files to look at. It was as simple as running:

$ ./find-cvsuser-modifications.sh --missing-copyright "Elijah Newren" newren

I could also add –print-changes to get a couple of the log entries (well, truncated versions), which helps rule some of the changes out.

Now, if only it could check the actual changes and determine whether they are “non-trivial” and whether the changes were actually made by me instead of just committed by me…