Apparently, someone decided to go shopping instead. But really guys…really?
So I took a bit of free time to fix up some things in my semi-toy project hotssh. If you like it, you should upgrade since this release fixes some major bugs with the connection tracking, and some more minor things.
The project’s at the point where though if I wanted to do anything noticeably more compelling, I’d have to either take the leap of using a real SSH library (maybe libssh?) rather than invoking OpenSSH as a subprocess. The problem is that gets into a lot of complexity in trying to stay in sync with whatever OpenSSH does (key management, known_hosts etc.). Probably someday though.
In the category of less user visible but probably more important, a new stable DBus is available. There are fixes larger and smaller (the real changelog is from 1.2.18 which was a paper bag release). I think one of the most important for mobile Linux users is the patch to switch to the monotonic clock; basically DBus will be more reliable if you suspend the system or reset the system clock. Besides other reliability fixes, there are some other small nice things like a better dbus-monitor. Thanks to Tom Hughes of Palm for the former, and Lennart Poettering of Red Hat and Will Thompson of Collabora for the latter!
And now back to some more user-visible GNOME Shell work; as Jon mentioned it looks like some new contributors are outpacing me, while I’ve been working on some of the underlying St toolkit infrastructure. Time to catch up!
Now that I’m on the Fedora Project Board, you may be wondering what my plans are. The first answer is – ideally – not much! Ideally, no one posts semi-nude material on the planet, we all cooperate nicely on the mailing lists, and in general the construction of a Free Software operating system and applications basically runs itself, and I can spend most of my time working on code too. However, we aren’t quite in an ideal state, so let me give you a sense of my thoughts and goals.
First, at a high level, I’d like Fedora to be more like Mozilla, which is arguably the most successful Free Software project ever. They do a lot of things extremely well, and we would do well to learn from them. I’ll elaborate a bit more on this later. But I think a lot of us inside the project should ask ourselves “How does Mozilla do it”?
Second, I’ll do all I can to prevent or work through intrapersonal conflicts inside the project. These have been a very serious problem for us, and we have to remember that we share the same goals. Being on the Board doesn’t give me any more actual powers here at the moment, possibly just a slightly higher platform from which to say, pretty please. (I have personally been part of the problem in the past, and that’s something I’ve been trying very hard to fix).
Third, be a part of the vision/what-is-Fedora/target audience discussions. I have a fairly strong opinion on these in general, which let me give a one sentence description here:
Fedora – A project to produce a Free Software general purpose operating system and applications through the process of rough consensus and working code.
Target Audience – Ok, this one is hard to fit in a single sentence, but I think the current proposal is a good start.
Finally, as mentioned earlier, spend most of my time on the code!
Andre Klapper did a neat summary of GNOME Bugzilla activity and I ended up with an average of exactly one patch submitted to GNOME a day for 2009. Cool! A fair chunk of that is probably tweaks of existing patches re-submitted, since git bz makes it so easy.
Looking forward to 2010!
As always, sysprof is an a great tool, and revealed we had some relatively low-hanging fruit. (Side note – in Fedora 12, sysprof no longer requires an external kernel module, which is awesome). Said fruit was partly in Gjs, partly in the GObject Introspection layer. We could clearly be doing more caching in the latter, but Gjs was also using the basically toy/demo invocation function g_function_info_invoke.
Now, in the the farther future, I could imagine teaching SpiderMonkey‘s JIT compiler about how to invoke directly from JS to C (and the reverse); the amount of generic work we still do to take say a single double across is fairly high, but the JIT could know about the platform ABI, and be able to trace right up until a native method, which would be a large speedup.
And for now, I’ll leave you with a picture of a tasty waffle from this morning:
|From FUDCon Toronto 2009|
For a long time my primary workstation was a (now 3 year old) Dell Inspiron E1705, or “bricktop” as ajax liked to call it. However the hinge broke a while ago when I closed my car door while the bag was too close, and when the laptop started to fall apart I decided to get a new machine. Actually, I got two. The first thing I did was get a serious desktop computer, a Dell XPS 630. It’s quite a beast, especially since I got 8GB of RAM with it. I pretty typically have over 2GB of memory used purely for page cache, which is probably my entire working set of files. It’s hooked up to a nice 24″ Dell 1920×1200 monitor. This computer is named megatron.
Needless to say, the machine is fast and nice to use. However, it’s rather unrepresentative of the general personal computing space. So I wanted another machine that was mobile, and also closer to what “most” people use. So I picked up a MSI Wind U123, known as pocket. It has just 1GB of RAM, which is probably the realistic minimum we want to support going forward (ideally we’d be workable with 512MB, and we probably are if you’re just running one application or one or two websites, but…). The machine also has an Intel 945 video, which is also near the lowest end graphics card we’ll be supporting for GNOME Shell.
The difference between the two computers is rather extreme, but I use the netbook very often, and working on it has forced me to optimize some things in the shell. It serves a similar role for performance issues that canaries used to do in coal mines (hence the title of this post). Specifically, I’ve been working on search performance, with fairly good results. We had a few sillies in the old search system like creating lots and lots of ClutterActors we’d never display, not caching lowercased strings, etc. (the other goal by the way of my search work is to move us closer to the current search mockup, which should be cool).
But the biggest performance problem I’ve been running into so far is synchronous I/O. A lot of GNOME libraries like gnome-menus were designed for gnome-panel, which typically you don’t interact with often, and so it’s not a big deal if the process is blocked. However if the shell is blocked, because we’re acting as a compositor, we won’t repaint the desktop or process input, which is a serious user experience problem. An example of this was that we would synchronously stat (check for existence) of recent documents; this could easily take several hundred milliseconds if the data isn’t currently in the kernel cache.
I’ve been reworking our docs handling specifically to be smarter; we use async I/O now, and only stat ones we’re actually going to show in the UI. We could be smarter still, but this has helped a lot. GIO has really nice APIs for this kind of thing.
I mention this for two reasons; first, just because you might be interested in a status update on Shell work. The second is because I’m hoping to Real Soon Now land my extension system patch, so if you create an extension using it, for a good user experience, you’ll need to be very careful about I/O too =)
GNOME Summit went really well, and I had a great time. One thing that I was really heartened to see is that we’ve agreed on a GLib/dbus plan, and this will enable a number of cool things. First, dbus-glib is just not very good, and we’ve needed a better story. I hadn’t realized before just how much nicer GVariant can make doing DBus calls. But beyond that, having DBus underneath the GTK+ stack will better unlock things like GApplication which will in turn let us do nifty things like exporting GtkAction over the bus. If that’s still a bit abstract, look at say Stuart Langridge’s post on Linglish.
A major change we’re trying in the GNOME 3 Shell is to be application-based instead of window-based. In this we’ll be in good company with newer releases of other operating systems, but it’s still a major change. What I want to explain in this blog entry is what that means from a user perspective. For the developer perspective, see this wiki page.
Let’s first look at one of the most venerable (and yet apparently still obligatory) applications, the Calculator. In GNOME 2, launching the calculator looks like this:
|From GNOME Shell|
When we click on that menu entry, the application is started (for more details about under the hood, see the linked wiki page above). The visual result is this:
|From GNOME Shell|
Calculator and the window list entry
There’s a window for the application, and a task list entry. Now in GNOME 2, if we go to the menu and choose Calculator again, we get this:
|From GNOME Shell|
Technical people will know that under the covers, there are two gcalctool processes, each of which is creating one window. What this example emphasizes is that in GNOME 2, the bottom panel has a list of windows (or tasks), not applications.
Moving on to GNOME Shell, the “window list” and “menus” part are merged into the overview. Let’s take a look at the application well when Calculator is not launched:
|From GNOME Shell|
GNOME Shell overview application well
Here I’ve added Calculator to my favorites, so it always shows up. It’s not running yet. When I click on it, the active application at the top immediately changes to show that (GNOME techies: this replaces startup notification), and then the widow appears:
|From GNOME Shell|
Running Calculator in GNOME Shell
So now that Calculator is running, let’s go back to the overview and see what changed there.
|From GNOME Shell|
Application well, with Calculator running
You can see that the Calculator gained a glowing status indication, like the other applications I had running already. When I click on that icon again, I am switched to the running calculator window:
|From GNOME Shell|
Looks exactly the same!
In other words, it looks exactly the same, it just shows you the window again. (Under the hood, the program is not re-executed, there won’t be multiple gcalctool processes, etc.)
Ok you say, but Calculator is a pretty boring application and you don’t use it anyways. How am I making your life better? Well, there are two major things.
One of them is that many programs fail in some obvious and other times less than obvious ways if you click the menu entry twice in GNOME 2 (technically, by default this will start two processes). They’ll overwrite each other’s data, etc. For very few instances does it make sense to have multiple if the app is not explicitly designed for it, and this will avoid you accidentally launching two. Personally I get annoyed when I accidentally launch two xchat-gnome instances and appear on IRC twice.
The second improvement here will come when we get a bit better application integration; the mockup we’d like to implement for say Firefox and multiple windows looks like this:
|From GNOME Shell|
This needs application-specific work though.
As a brief unrelated aside, I think recent Chromium builds with the tabs-in-window borders (technically, client side decorations) looks cool fullscreen in GNOME Shell with the application menu:
|From GNOME Shell|
Chromium in GNOME Shell
Next post I’ll talk about how GNOME Shell will save you time and get you back into your applications faster.
This work is licensed under a Creative Commons Attribution 3.0 United States License.
…it turns out someone on the Interwebs already did it. Curse you interwebs for how easily you crush one’s brief pretensions to originality. Anyways, in GNOME Shell we finally got bug 589652 in which means we’re ready for translations! We don’t have a lot of strings, but it’d be good to get the ones we have translated for 2.28. Ready, set, go! I’ve given French a leg up with a translation for Activites as a test case.
Along the way it took a bit of gjs hacking to make it easier to create native modules; if you found yourself embedding Spidermonkey but yearning for PyArg_ParseTuple, gjs_parse_args is your friend.
Speaking of programmer stuff, the built-in console mentioned in my previous post gained a parent-list inspector and property inspector which bring it very slightly closer to Firebug-like real, ultimate power. True story, I originally called it lookingGlass.js completely forgetting about Sun’s project ironically also about 3D-based desktops. Anyways, since that doesn’t seem to be actively developed anymore, and it’s a really great name, I think I’ll just…if you don’t mind….(yoink!) claim that name.
There have been a lot of other user-visible changes recently, in visual terms I really like the result of both Sander’s excellent work in bug 584609 in combination with the progress recently on moving visually to the mockup Jon referenced here. Another promising change is our start on the application menu area.
Which gets me to the subject of the next blog post; one the major changes in GNOME 3 from both a user experience point of view and application developer view is that we’re application based, not task based. Work continues in this area – in the next post I’ll talk about how this affects the experience.
It’s hot and humid in Boston, and I’ve been finding it a bit hard to sleep sometimes. I keep telling myself I’m going to get an air conditioner, but, well, laziness and money. Anyways tonight around 3am I just gave up, and from then till now-ish I was working on this cool little hack for Gnome Shell.
So here’s the problem. I have almost no visual skills personally, and in a freeform environment like Clutter or HTML I have a really tough time making things I code look good without basically being handed the pixels directly by a visual designer. But one thing I have noticed though is we have some people in the GNOME community with awesome visual skills. So I wanted to lower the barrier to entry a bit for them.
My inspiration was Firebug (which again if you have to do HTML and haven’t tried, do so immediately); I wanted to make something where you could interactively edit and debug the visual layout. So the result of the hacking landed in bug 590515. But since you’re unlikely to do a git pull and git bz apply, I used Owen’s cool builtin facility for making .ogg recordings of the shell.
Note however that at least parts of the shell aren’t redrawing correctly in the beginning, and I gave up debugging that for now. The top chrome will appear in the middle of the video.
Ok, you don’t have the video tag, try the direct link.
To actually make this useful for artists there’s a lot more to do; a Firebug style properties display/layout debugger probably wouldn’t be too hard, and would help you get past the problem of even knowing what properties there are. But besides this tool, in the big picture we really need to switch to CSS, but that’s coming.
One question you may have is why when I moused over the window area, we didn’t see different boxes for the windows? Well, that comes down to the fact that there’s a transparent input-only box over the windows. A nice future enhancement for this tool would be to be able to skip layers; then you could type in a bit of code and animate/color etc. your windows.
There’s more going on in the shell land, among other things we’re taskbar-less now. Yay for less visual chrome, though we have to work through the details. More on this later.