Yesterday I reviewed all of our launchpad-gm-scripts scripts in light of Launchpad's recent UI changes. I was a bit surprised to see half the scripts work fine, but disappointed that half show some breakage.
I fixed my buttontags script, which was not able to apply tags, and filed bugs 245042 and 245048 for the other two bugs caused by the Launchpad update.
As well, since I expect we are likely to experience future sudden Launchpad interface changes, I've written up a TESTING file to hopefully help folks doublecheck the scripts still work in such situations. Wish there was some way these tests could be done prior to new Launchpad UI updates, but lacking that we'll just have to beg forgiveness for the inevitable breakages.
If you're not yet using the Launchpad greasemonkey scripts, here's a quick plug for them, and list of what they do:
lp_buttontags.user.js - Shortcut for applying several standard tags on bugs
lp_highlight_me.user.js - Highlights your items on the +milestones page
lp_karma_suffix.user.js - Displays user's karma next to their username. Handy to spot new users vs. experienced ones.
lp_patches.user.js - Stars attachments which are patches
lp_stockreplies.user.js - Mechanism for storing and applying a set of stock replies (which you can define) to bugs, updating status dropdowns, etc. as well.
lp_workflowreports.user.js - Identifies workflow reports.
A number of people have contacted me with comments on my post yesterday about Document vs. Stream UI approaches.
Of particular note is a wiki Rudd-O has set up on Streams vs. Documents. If you find the concept interesting, you might find that a useful place to collaborate with others.
JL Dugger also shared some thoughts with me on Dataflow Languages. I wasn't familiar with the term, but the concept is one I've seen and used previously. I don't think it's necessary to write apps in one of these data flow languages - you can probably model that style of data flow processing in *any* language - but looking at how those languages are designed could probably give a ton of good implementation strategies. Another commenter echoed this with a quite informative discussion about 'functional reactive programming'.
Indeed, I think a lot of the ideas here are covering ground many others have thoroughly tread before. A few people pointed out various technologies and tools that already exist for doing stream oriented stuff; again though, my point is not that we *can't* handle streams, but rather that we already are doing lots of stream stuff, but the OS is not giving the support it should. Someone mentioned a not-yet-released Microsoft project called LiveMesh. (Personally, I long, long ago got worn out by MS products that take a great concept and implement only about half of it - with no way for me to get in and hook up the remaining bits myself, but to each their own.)
kyb outlined some thoughts about task streams with workflow aspects - something I totally agree with and have thought quite a bin on myself. I like the idea of prioritizing streams by work style type ("casual"/"concentrated"/"in the zone"). I myself find when working on bug triaging, that I deliberately break down my work in this fashion - in the mornings when I'm fresh I'll work on a handful of bugs that require a lot of thought, but in the evenings when I'm tired I prefer doing simpler triaging (typically going through and requesting bug reporters attach their Xorg.0.log's *grin*).
Both kyb and enobrev emphasized the need to be able to collate different kinds of streams (email, web urls, SMS, etc.) which may require indexing them into some neutral form, and then assigning various metadata properties to aid in organizing them, prioritizing them, determining if they must be seen or can age and expire, etc. Totally agreed.
Another user inquired about tracking changes on a collaborative SVG document in Inkscape. Glad you asked! :-) For a few years now we've been maintaining an experimental thing Ted Gould thought up called 'inkboard', an online whiteboard which allows multiple inkscape instances to interface to each other by communicating document changes through the jabber protocol. We don't ship it turned on by default, but if you rebuild inkscape from source, you can just pass configure the --enable-inkboard to flip it on. (We learned a lot of hard lessons in this; working effectively with streams is a lot more complex in practice than you realize.)
One comment pointed out that Google Apps, etc. provide these services on the server. I knew someone would inevitably bring up Google Apps. ;-) Web services obviously play a HUGE role in streams. Ignoring the open/closed issue here for now, my point is really that rather than consign my kick ass powerful desktop machine to being essentially just a dumb terminal, the underlying OS ought to get more involved in all these streams going around. Browsing lists, viewing bug reports, etc. etc. through firefox is operating at sluggish Comcast network speeds; we deserve the ability to do all this stuff at CPU speeds!
Also, a point I hope to get into in a future blog post is that an issue we have is that there are too many different UI's, and unfortunately with web services, the situation isn't much better. For instance, I love the Netflix UI approach, but it's completely different from GMail or Flickr (which also have great UI's optimized for their own purposes). Anyway, I'll leave that whole discussion for later.
This would be a good spot to mention an extremely interesting Desktop session at UDS2008 I enjoyed sitting through about UI integration of single-sign-on for web services. Ted Gould is maintaining a set of blueprints on the topic. The Ubuntu desktop team has some very intriguing plans under way.
Posted in Ubuntu Submitted by bryce on Wed, 2008-06-25 18:26.
bryce's blog | 3 comments
The other day I was trying to figure out what was making my desktop computer run so slow. This was pretty unusual on Linux. Way back when I used to use Windows, I'd encounter such things due to running too many programs, so of course I looked at what was running.
But these days I don't really run that many intensive applications. I hardly ever use spreadsheets, presentation tools, word processors, or so on like I used to. Really the only things visible in my task bar were Firefox and Terminal. Killing off Firefox made no difference. And even more oddly, rebooting had no effect - within minutes my load average was up in the 20-30's.
Of course, the culprit was that I had a bunch of automatic cron jobs scheduled to occur at the same time. Reordering the timings got the system back on track.
But this led to an epiphany moment.
This was my *desktop* machine. The last time I'd seen this cron job I/O blocking madness was on servers. What was I doing with so many cron jobs on a *desktop*??
I looked at the individual cron jobs, and found that each and every one of them had something to do with my job. Disabling any one of them would reduce my work productivity. I could no longer do without one of these silly cron jobs than I could have done without Microsoft Excel a decade ago.
And then, as I looked around my desktop at the other things running on it - internet radio, IRC chat, mutt - that I noticed that I hardly ever use traditional "document-centric" applications. Everything running had something to do with dealing with _streams_ of information.
The realization sank in at that point, that our computer UI paradigm really stinks for what we actually use our computers for.
The prevailing UI paradigm today is built around the notion of document authoring. It expects that the main thing you do is create spreadsheets, word documents, presentations, and so on. There is a task bar to remind you of what documents you're editing, there is cross-application cut and paste so you can put pieces of one document into another. You can place documents on your desktop surface itself, so you can organize your work. You can define which applications to use for which types of docs. You can set up a default printer to put your documents to hard copy. You can set up system-wide fonts to use in documents. You can put icons to apps and even documents onto your panel. And on and on.
Occasionally, some of that is actually useful to me. But most of the time, for most of the work I do, it's all irrelevant. To pick one example, I used absolutely none of that in order to write this blog post.
Really, what I mostly do today is stream management. And I suspect this is true for the vast majority of people. I don't deal with writing documents, but with changes to documents. I put comments onto things. I slap patches onto things. I tweak the states of things. Once in a rare while I may author a completely new thingee, but even there I usually end up working with it as a stream of changes that I build up over time (and usually in collaboration with a few other people who stream changes to me).
Thinking about user interfaces this way, it occurs to me that there are a LOT of different kinds of streams. Streams of emails. Streams of spam to take *out* of my email stream. Streaming radio broadcasts. Streams of bug reports. Streams of software updates to apply. Streams of chatter on IRC. Streams of youtube video URL's from friends and family to check out. Streams of updates to my weather applet. Even my todo list is more like a stream of things coming in and going out, than like a static document I can print and save and be done with.
Each one of those silly cron jobs bogging down my computer were critically important for me, because THEY were the tools I used for helping me stay atop all these streams. They summarized my bug streams in various ways. They filtered my email streams into more organized sub-streams. They flagged tasks (and took care of certain tasks for me). They took care of updating the tools I used day to day.
It's weird that for all the document tools at my fingertips, it's a stodgy old *server* tool that is helps my productivity the most. I wonder how non-technical people not knowledgeable about crontab and scripting deal with such things?
This all got me to a key question... Since the purpose of our desktop UI is to make our work easier and more efficient, then if today's knowledge workers are, like me, more stream-oriented than document-oriented, then doesn't it stand to reason that we ought to re-think our UI design to optimize it for making stream management easier and more efficient? How would such optimization be done? How would such a UI look and feel? What kinds of toolkits would be needed?
Cairofication of Inkscape took a big step forward today, with Bulia's announcement that several canvas items (bpaths, ctrllines, and ctrlquadrs) now being drawn using Cairo. Regular objects are still rendered as before, so there's still further work to be done.
There were some great comments to my previous blog entry, Pay bounties in time, not money, including this one:
I would love to pay in time and not in money. But I don't have any programming skills whatsoever. I'm an office manager by trade. I'm skilled in interactions between people and (basically) herding cats... and I'm good at it, if I can say so myself :)
How can I use this experience to help Inkscape or Ubuntu? I don't really know if I can.
For Inkscape, I've already written up an answer in depth in Inkscape's FAQ entry: Are there non-coding ways to help? There has been a huge number of non-coder Inkscapers who have gotten involved with the project in these ways and helped to make it a roaring success. So for that half of the question let me just point there, and focus on the Ubuntu side of things.
A lot of people don't realize they CAN contribute. A widespread assumption is that software is technically hard and that you need advanced coding skills to do anything to contribute. It simply isn't true. And in fact if people think that way, it holds FOSS back from its true potential. Have a look-see at the above Inkscape link to see the big breadth of non-coding things that an average piece of software needs done to make it succeed: Tutorials, clipart, teaching other users, mocking up dialog changes, translating, testing, marketing, and (especially!) helping with the bug queue. Working on any of these (especially bugs!) can have the add-on effect of freeing up those who DO have coding skills to focus them on coding instead of all the other non-technical tasks that need to be done in order to make the software successful.
Let me focus specifically on management ("cat herding") since that was the question, and try to slant it towards Ubuntu.
I suspect one of the things developers enjoy about working on open source is that they don't have a boss! I'd bet that hardly any FOSS project would say they "need a manager". However, there is more to "management" than "being a boss", and indeed I think these aspects are among the highest areas of need with most open source projects.
For these reasons, let's also distinguish between "project owner" management where you are the primary lead of the project, and "contributor" management where you're a regular team member, and narrow our focus to the latter.
With Open Source management, I like to think it involves three kinds of work beyond regular development: a) Cheerleading, b) Taking out the trash, and c) Operating the switchboard.
"Cheerleading" is essentially just encouraging good behavior and motivating and inspiring people to do more work. If you've ever worked in a demoralized environment you can know how big of a productivity difference it can make when people are happy vs. not. With volunteer projects - as most FOSS projects are - morale is HUGELY important, and unfortunately there are a LOT of demoralized open source communities out there. Getting morale back is very hard, but imagine what a difference it makes for FOSS overall to take a dispirited, nearly defunct community, turn things around, and get developers excited again about pushing their software project forward.
With Ubuntu, this could involve simply cheering folks on at e.g. bug hug days, issuing thank-you's to people who fix bugs you care about, etc. or to identifying ineffective communities around particular areas of Ubuntu you think could be better, and stimulate them to be better organized and better focused towards progress.
"Taking out the trash" is the idea of handling the chores that other people don't wish to do, yet that have begun blocking up the project. This could be helping get the indefinitely-delayed release finally out the door, cleaning up an out-of-control bug tracking system, organizing a marketing effort, researching into the background of a serious blocker bug, fixing the website, or resolving some differences of opinion that have split the project. In other words, find the things that EVERYONE complains about, but no one actually does, and to devote yourself to doing THAT. Often, once you demonstrate leadership charging right into the problem, others will follow your example and assist - sometimes even taking care of the technical hard parts you are apprehensive about doing yourself!
In Ubuntu, certainly the biggest "chore" right now is the mass of bug reports in the bug tracker. Organizing testing activities is another area where contributions could make a huge difference.
"Operating the switchboard" is probably one of the most rewarding (and unrecognized) management contributions you can make in FOSS. Everyone knows that lots of issues end up just being failures of communication. So if you turn this around, you realize that many problems can be solved just by stimulating the right channels of discussion. Thus, without really needing to deeply understand a technical issue, you can solve problems just by finding the right two people, and linking them together. For example, this might be by linking a well motivated but inexperienced coder banging their head on a bug, with an experienced coder who can give advice; or it could be putting an upstream developer in touch with an engineer at a hardware manufacturing company with the data sheets about the HW you care about; or it could be getting developers of two different applications together to discuss issues like a consistent protocol format. You know when you've made the right introduction, because you see the two instantly go off into technical depths way over your head. Be sure to check back in a day or two to see how the discussions went, so you can help see that follow up actions get taken, or results communicated to third parties appropriately.
For Ubuntu, there are probably infinite areas where locating the right upstream person and hooking them to the right MOTU or core-dev person can advance a bug a LONG way.
I can't count the number of times people have offered $100 bounties for implementing some feature or other in Inkscape.
From what I've seen - and I've seen MANY features come into Inkscape from folks who aren't developers - $100 is the wrong way to do it.
Not that people are anti-money or anything like that. Certainly we've gotten rabid success out of our Google Summer of Code projects, but these pay out $4500. So maybe $100 just isn't the right price point to stir interest (even a simple feature is going to require 10-20 hrs work, at which point you might make more flipping burgers!)
In any case, aside from GSoC, I've not really seen that many successful cash-for-code projects in Inkscape.
But I *have* seen a number of similar situations that ended up *quite* successful, but didn't involve money at all.
The Mac port of Inkscape is my favorite example. Inkscape started as a Linux-only product but quickly gained a Windows port. A lot users were also very interested in seeing a Mac port, but few of the active developers were all that interested. I think maybe someone even offered a $100 bounty for it, although I'm not certain; in any case none of the existing developers took interest in doing the port.
But there was one user that was really interested in getting it, and he sat down and hacked away on it. After a few weeks he talked to me and said it was just too frustrating to get something that worked properly and he was giving up on porting it. (IIRC, he was able to get it to build but not cleanly, and when it ran it didn't work properly.)
I sympathized but encouraged him to write up his notes into the Inkscape Wiki, to explain how far he got and the problems he ran into. "Maybe someone else will know how to sort those issues out some day."
Meanwhile, people continued to clamor for a Mac port. Eventually, another person took interest in just doing it himself, and when he asked me about it, I pointed him at the wiki page the prior person had written. This was useful in getting a leg up, and he was able to sort out the build problems the first person had run into, but he eventually also gave up frustrated with the limited results he saw. I encouraged him to update the wiki page with his findings.
This cycle went on for some time, but eventually enough knowledge had accumulated that someone (JiHo I think) was able to clean it all up into a proper procedure, and to start getting successful builds that more people could use. This enabled people to focus on the next layer up - fixing the Mac-specific bugs.
Now there were also complaints that while it ran on Mac, it looked out of place and was hard to install due to its dependence on libx11. People started clamoring for a "Native Mac Inkscape Port". And so the cycle began again...
In Inkscape I've seen this pattern repeated again and again. And not just in Inkscape. This seems to be a universal mechanism for how open source works. I'm sure there's an aphorism or law or something that describes it.
In any case, the lesson that can be taken from this is that if you want to get some feature or fix into an open source project, rather than offering money, have a go at it yourself. Even if it is well beyond your technical ability or time availability, your efforts may be enough to simulate someone else to eventually have a go at it too. This could be a detailed procedure you followed that got close to working but had a fatal problem. Or a messy patch you made that *should* work but doesn't. Or it might be a list of possible solutions you've ruled out and why.
If you think, "I want a way to just throw money at the problem and make it just work," then remind yourself, "Time is money" and throw time at the problem instead of cash. Spend $100 worth of your time banging your head on the issue, trying out ideas and hacking on code if possible, and posting the results even if they turned up negative. They may give someone enough of a clue to stand on your shoulders and reach the goal.
For Ubuntu, a *lot* of time and effort goes into triaging X bugs. Mostly, this work consists of helping bug reporters get enough data to actually begin troubleshooting the problem. Sadly, a lot of bugs go uninvestigated due to lack of enough info.
I have noticed lately though, that a number of reporters are starting to include the info needed, which is great! Developers can then focus their time in actually solving their problem rather than requesting files and trying to think about what to ask for that might give clues.
If nothing else, the #1 most important thing to always include when reporting an X bug is your /var/log/Xorg.0.log. This file is chock full of useful data... versions of modules, configs, resolutions identified, warnings, error messages, and sometimes even partial backtraces. If you remember nothing else, please remember this one thing: "When reporting an X bug, ALWAYS include your Xorg.0.log".
Sometimes Xorg.0.log isn't necessary, but it seems like 80-90% of the time I need some bit of data which is there, so unless you're *certain* it's not needed, make every attempt to include it. If you can include it directly with your report at the time you submit it, you can save triagers time and decrease the time before someone takes a stab at troubleshooting your problem.
The #2 most important thing to include depends a bit on what type of X bug you've encountered. I'd group X bugs like this:
Screen Corruption. A photograph of the screen helps a lot, since it's often hard to describe in words, but can be obvious when you see it.
X Crashes/Lockups/Freezes. Many people report these kinds of X breakages; certainly they are troubling, and unfortunately not as rare as we'd like to make them. The important thing to include is a full backtrace with debug symbols installed (see the directions). Indeed, there really is *nothing* anyone can do to troubleshoot this class of bug without a backtrace, and we'll usually close these bug reports if no backtrace is posted in a reasonable amount of time.
If you're not familiar with what a backtrace is, it's basically a list of the function calls that were made immediately leading up to the crash. A 'full' backtrace also includes the values of the function's parameters and local variables, which is useful for spotting NULL pointers, invalid strings or indexes, etc.
I can't emphasize the importance of full backtraces enough. I've noticed that somewhere around 20-30% of the time where a full backtrace is posted, we're able to identify the bug and propose a patch directly. Often the bugs are simple null pointer dereferences or other obvious coding issues, we can patch immediately and post upstream. Without a backtrace there would be no way to identify these fixes.
"But it worked in Gutsy...?". X changes a lot. New functionality is continually being added and we want to make the new stuff available as we put out new Ubuntu's. Unfortunately, sometimes new code means new bugs. I see a lot of irritation when people find that something that worked fine in the previous stable release suddenly stops working in the development release.
These kind of bugs have a surprisingly effective brute force way to isolate the problem: Just start checking some of the intermediary versions between the stable and development releases. (Usually this involves building from upstream's git repository, perhaps using 'git bisect'. Stay tuned, I have ideas on how to make this easier for folks.)
Everything Else. Of course, there are many other kinds of failures... configuration errors, wrong DPI's, performance problems, and on and on. Use your judgment in what to include in addition to Xorg.0.log. Sometimes experimenting with alternate xorg.conf Options is worth doing. Sometimes checking with a different monitor, or with Compiz turned on or off can produce useful info. More tips are on the Reporting X Bugs page.
Posted in Ubuntu Submitted by bryce on Mon, 2008-04-21 22:30.
bryce's blog | 1 comment
Thought I'd take a break from the Xrandr GUI blogging to make mention of a few new (and old) tools I put together for the Xorg bug swat team.
First up is a new high level Ubuntu-X Status Page, updated several times an hour. This was directly inspired by Leann Ogasawara's Ubuntu Development Weather Report tool, but is focused one level down on just Xorg stuff.
This has been a handy tool for reviewing and accessing various "targets of opportunity" lists that others maintain, like Daniel's sponsoring and 'really-fix-it' pages, and Brian's handy 'bugs with more than 5 subscribers' pages, along with the usual milestone and release targeted bug lists in launchpad.
One thing this highlights is that our -ati driver needs a lot more bug triager attention, as there are quite a few serious bugs plaguing users (note the large number of subscribers).
Anyway, the tool is still a bit crude, but it's been useful to me. I'm hoping to develop it a bit further in Intrepid.
Next up is an older tool I've mentioned, the Launchpad Bug Graphs. I don't know if anyone else uses it, but I use it daily.
The 6-month view of the -intel X driver Open Bugs shows the great progress we've made with the Intel bug stats. I'd set as a goal for Hardy to reduce it to below 100, and after quite a bit of work, this was achieved! Of course, 100 bugs in -intel is still concerning, and I hope with Ubuntu community member's help we can continue pushing this down.
I think -ati could benefit from a similar intense focus; while the total raw number of bugs has not grown significantly since last release, the numbers are higher than they've been for as long as we've been graphing them, which is troublesome given that we're about to finalize an LTS. We could really use some serious help here, so if you're an ATI user looking for a way to really help Ubuntu, this could be it.
The next tool to show off is extremely new, and in fact is really just a static prototype, but has already been proven useful. I'm calling it the Historical Ubuntu Xorg Intel Drivers page, but that doesn't really roll off the tongue. Anyway, it's essentially a series of git snapshots of Xorg's upstream Intel driver, pre-built for hardy-i386.
There is a certain class of bugs I've noticed, where the user reports that the issue worked in Gutsy or an earlier Alpha, but currently is broken, and this tool is designed to assist in narrowing this down. The user identifies a "known good" and a "known bad" entry in the table and then "bisects", picking a deb halfway between them, and tests that. Then, depending on whether that failed or not, they pick one halfway between it and one of the original two, and so on until they identify the two adjacent versions between which it fails.
I didn't build every single git commit, since that would be a bit overwhelming. I skipped every several commits, figuring that once it's down to about 4-8 patches then a developer ought to be able to pick out the most likely candidate. I hope this will help enable non-technical Ubuntu folk to do much of the legwork in isolating regressions, without needing to break out a compiler or spend a lot of time on it. (As a side benefit, this gives them a way to upgrade or downgrade to a working driver if worse comes to worse.)
When I get more time I plan on enhancing this tool with debs for more releases, for amd64, and for the -ati and -nv drivers, and maybe -radeon if there's sufficient interest. We'll see how it works.
Okay, last tool. Well, documentation actually... This is the Ubuntu X page on the Ubuntu wiki. I've linked in tons of other useful stuff here, and in particular would like to highlight the X Debugging Handbook, which I've recently broken up into separate pages for easier reading. Through the Hardy bug fixing period I've added a good bit to the Troubleshooting page, to document steps one can take for figuring out various classes of problems. It's not quite to the paint-by-numbers level that I hope to get it to, but getting close.
Posted in Ubuntu Submitted by bryce on Fri, 2008-04-11 00:37.
bryce's blog | 1 comment
Like kees mentioned, Kees and I tested his laptops on the Hitachi projector that Elmo lent me from work.
The background here is pretty simple: We want Linux to work with projectors, or at *least* for Ubuntu to work with Canonical's specific projectors. It's embarrassing enough as a presenter to walk into a Linux conference providing some random projector and not be able to connect; imagine how frustrating it is to go to a Ubuntu conference with an up to date Ubuntu laptop, and plug into Canonical's own projector and not be able to get it to work!
Historically, getting a laptop to work with a projector has been a Dark Art, requiring major xorg.conf tweakage. Things have gotten better with the introduction of Xrandr, though.
Intel graphics was the first to get good Xrandr support. Both my (working) laptops are Intel based, and sadly I could find no bugs with the projector. Hotplugging, resolution switching, rotation... it all just worked.
Kees had described some rather nasty issues he'd found with his ATI graphics laptop, so I knew there were resolution issues, I just had to find them!
So a couple weeks ago I ordered several popular (but cheap) nVidia 7000-series and ATI cards, and tested 9 different hardware configurations.
I did find some bugs - rotation on -ati is **horribly** busted, for example - but was surprised to see that by and large, resolution changing worked amazingly well. Hotplugging not so much. But I never had to fiddle with xorg.conf. Most of the issues I did find were oddball corner cases, or were easily fixed by doing a vt switch, or switching to another resolution and back, or etc.
So today I had Kees bring his laptops over, including the aforementioned broken ATI one, which he also upgraded to Hardy today. The other projector is a Dell with a recent 8000-series nVidia graphics chipset.
Amazingly, he was able to boot the projector on both laptops to just about every resolution supported. There were a handful of various little glitches and issues, but mostly known bug - I mentioned to him that I felt like he was demoing everything currently in Launchpad for Xorg. Even rotation sort of worked for him on -ati: We could invert the screen without problems, but Left/Right didn't work and required restarting X.
Of course, we did nearly all of this testing with the new Xrandr GUI, which aside from a couple issues fulfilled its role admirably. I was particularly gratified seeing the Revert Dialog (which I'd only just uploaded last night) came up and worked exactly as expected.
Unfortunately, while we were pleased with X and the Xrandr GUI at letting us experiment with all these resolutions on the fly, it's clear that things beyond X need work. GNOME's panels were quite easy to get confused. The desktop background can get strangely stretched in some configs. Full screen apps (games and movie players) also seem to get easily confused; they tend to want to display on the laptop, when of course you want them to go up on the projector!
I guess my hope is that providing an easier way for people to experiment with their Xrandr settings, it will better expose these WM-level and app-level issues and make it simpler to test them, and maybe we'll start seeing improvements in Intrepid and later. I'll look forward to seeing games and movies display properly on the expected output.
I'm sure everyone must be sick of hearing about this xrandr gui work, but by popular demand I've added a Revert Dialog, like in the old Screen Resolution tool. Needs a bit more testing.
Posted in Ubuntu Submitted by bryce on Wed, 2008-04-02 04:57.
bryce's blog | 2 comments
