I don’t understand exactly what it’s meant to achieve, or how it’s controlled, but MacSlow’s videos of his LowFat file-management thing, using gtkmm and OpenGL are certainly smooth. He says he plans to use cairo(mm) for it in the future. Give it a minute or so to get to the good stuff.
Category Archives: General
Eclipse for existing code
Does anyone know how I can use Eclipse to edit an existing checkout, for instance to use it with my jhbuild checkouts? The best I can do so far is use Eclipse’s File/Import…/”Checkout Projects From CVS…” feature, but that puts a new copy of the code in ~/workspaces/. Eclipse’s File/Import…/”Filesystem” also seems to copy the code into ~/workspaces/ instead of just letting me edit the code.
Anjuta and KDevelop can do this, but I’d really like to use something more sane. I’m a bit afraid of Eclipse’s apparent complexity and odd new jargon, but I’d like to give it a chance, if I can get started.
GNOME at LinuxTag 2006, Wiesbaden
I got back from Wiesbaden yesterday after helping to man the GNOME stand for the first day of LinuxTag. This year it’s in Wiesbaden instead of Karlsruhe. It seems to be significantly smaller, and felt deserted on that first day, but I’m sure it will pick up later, like it always did in Karlsruhe. There’s nothing as good as LinuxTag in Germany.
We only had a few of the items from the GNOME Events Box due to an(other) organizational snafu, and the Foot poster didn’t arrive yet, but we still made the most of our half a booth, using Thomas Keup’s projector to throw some eye-catching GNOME logos on the wall and enticing people with Novell’s XGL videos and GPE‘s selection of embedded devices. Our friends at Ubuntu have a large stand opposite us, so I suspect that this will become an epicentere of enthusiasm when the crowd gets here.
Joerg “Josh” Kress is again taking most of the weight for the booth’s organisation. I am often amazed by his patience and dependability. He’s great at calmly introducing people to a new world, showing them how to learn more, and how to get involved with the community that makes it happen. His new book, “Linux Lernen mit Ubuntu” does this in more detail. You should all go out and buy it, so he can take you on a tour of desktop Linux. If you take your copy to LinuxTag then he’ll even autograph it for you.
Here is a photo if someone would like to make him a hackergotchi head for Planet Ubuntu:
We probably only spoke to about 15 people, compared to the usual hundreds, but it was nice to be more relaxed and to give people more time. Most people were completely new to Linux, which is similar to the last few events I’ve attended. The XGL videos are a nice opportunity to talk about how we like to take the time to make stuff really work, and to use technology where it’s useful and tasteful by default, resisting the temptation to throw in a lot of techie gimmicks that are fun at first, but would quickly become annoying. We need to get this idea of lifestyle design across in our marketing when this stuff goes mainstream. But I told them that they can try the work in progress in SUSE/Novell Linux and, with some tweaking, in the other distros in the meantime.
GNOME’s User Profiles Editor (Sabayon) is also a great demonstration for system administrators and existing users. It does so much, without forcing a whole new UI on people, because the developers were interested in the users’ goals rather than just mimicking existing tools.
I’m getting a little tired of my regular mini spiels, though they remain effective:
- Show how much better [Save] is than [Yes] in a “Do you want to save changes?” dialog, with a “Really Discard Changes?” dialog as the punchline. This emphasizes our attention to detail, and to the user experience, so they don’t need to pay attention.
- Showing our simple preferences and comparing them to the useless obscure options in Windows/Office applications.
Someone should write up something fun on the marketing pages.
Munich’s LiMux to use KDE
I’m probably a bit late with this, but I just noticed that Munich council decided to use KDE for their desktop. I think they announced it quietly in January 2006.
As someone interested in showing how Linux can finally make life better for users, and thus make the world a better place, this is a bit depressing to me. If Munich’s employees get a standard KDE desktop then they will be overwhelmed with its complexity, technical orientation, and inconsistency.
I know I should be glad that it’s a Linux and Free Software project, but I’d like it to be a success, and I don’t want to spend the next ten years hearing from people here about how much they hate it, and having to explain that that’s not what I do, and that’s not how it has to be. However, the project’s managers have otherwise seemed to be very smart and pragmatic, so I guess there’s a chance that they will heavily customize it, and this might be a wake-up call to the KDE developers that not all users are geeks, or that not all people should be forced to think like geeks, and that confused users should not be dismissed as too stupid to use a computer. Maybe there will be more in their LinuxTag 2006 presentation about how they made the decision.
(This is my personal opinion and not the official opinion of the GNOME project.)
Short Commute
Last week I took the contract here in Munich that I mentioned, so other large projects will have to wait for at least six months. I’d rather be coding with GNOME, but I’m really pleased that for once I don’t have to go away from home to earn the rent. That also means that I’ll still be able to do some open source work in the evenings.
FC5 and Ubuntu 6.06 like my laptop.
In the last few days I’ve tried installing both Fedora Core 5 and Ubuntu Dapper Beta on my Acer Travelmate 4101WLMi (i915 graphics version). There’s a huge difference compared to earlier versions, such as Ubuntu Breezy. I didn’t need any extra boot options, and I get working networking and audio, though FC5 doesn’t ship the firmware, and it’s difficult to find the correct version of it and install it.
The Ubuntu Dapper Beta now uses the LiveCD installer. They seem to be moving to that, instead of the regular Debian installer. It’s a bit confusing still, and the partitioning bit is particularly flaky for me, but just having the ability for people to take screenshots of the installer (because you have the rest of the desktop to use too) must help them to improve it.
I notice that the Dapper Beta CD doesn’t use Network Manager anymore, so you now have to manually configure the wireless connection, but it did at least show my wireless network name without me having to type it in. I loved how network manager just did the right thing without me lifting a finger, but I guess it has some problems still.
I still don’t have widescreen resolution. Setting a mode to 1280×800 with 915resolution just gives me a scrolling desktop. Setting all the modes to 1280×800 gives me an Xorg crash with a “no screens found” message. This is becoming a bit annoying.
svn branches are directories?
I find svn branches a bit confusing, because they feel like directories. You specify branches as part of the path to the directory, rather than separately, and it seems that, if a branch doesn’t exist explicitly, some directories don’t show up in trunk (the svn equivalent of SVN’s HEAD). This doesn’t seem useful.
For instance, in maemo, here’s the trunk branch:
https://stage.maemo.org/svn/maemo/projects/haf/trunk/
But a new directory doesn’t appear there. It’s here instead:
https://stage.maemo.org/svn/maemo/projects/haf/jhbuild_modules/
And maemo’s non-trunk branches appear in some strange places, with the branch names in a different part of the path (e.g. haf/gtk+/somebranch/ instead of somebranch/haf/gtk+.):
https://stage.maemo.org/svn/maemo/projects/haf/branches/gtk+/async-filechooser/
https://stage.maemo.org/svn/maemo/projects/haf/maemo-branches/IT-2005/gtk+/
Is this normal, or is maemo doing something it shouldn’t? When GNOME switches to svn we’ll need a version of GNOME’s great cvs instructions for svn.
Glom Web UI
If nobody else gets around to it, I might have to implement the Web interface for Glom myself. But I haven’t done web programming recently and I’m very out of touch with the latest stuff. The last time I did any, JSP was the nobody-ever-got-fired-for choice.
It just has to read the Glom .XML file and from that allow people to navigate through tables and records, getting and setting the data from the database, laying the fields out appropriately as per the simple Glom layouts.
Feel free to add comments to tell me what the latest popular proven technologies are. Note that I’m not interested in using .Net or Mono, and I’d rather avoid relatively new programming languages like Ruby, or APIs that were invented last week. Python would be nicely middle of the road if there’s some suitable APIs for it. It might be nice to be able to call a C++ libglom library, to reuse some logic.
I’m not going to do this any time soon. (Unless someone pays me for it. As ever.)
Update: I’d like to have a nice AJAXy responsive UI, so I can, for instance, update a list of choices in one field based on what the user has just entered in another field. A small delay would be acceptable, but a page refresh would be annoying. But I don’t want to write any javascript myself. It would be nice if I could just have all that hidden inside some widget objects, like using GTK+ that renders itself to a browser.
Building modified debian packages
I recently had to create modified versions of some debian packages, to apply some custom patches and use some special compilation options for a scratchbox environment. It was time that I learnt something about actually making debian packages. These were packages that Daniel Holbach couldn’t do for me, but he did explain some stuff, which I’ll note here for my reference. He’s not to blame for my errors.
To get existing debian package stuff, make a directory and do this:
- “apt-get source gtkmm2.4”, replacing gtkmm2.4 with your package name.
- or download from the debian page. For instance, http://packages.debian.org/stable/source/gtkmm2.4
This gives you 3 files, of these types:
- .orig.tar.gz: The original source tarball, exactly as you would get it if you downloaded the source code directly.
- .dsc: The Debian Source Control file.
- .diff.gz: A patch to add the debian sub-directory.
You don’t need to uncompress and apply all that manually. There are tools to help:
- dpkg-source -x something.dsc, to expand the source tarball and apply the .diff.gz patch. You then have the source directory, with the debian sub-directory inside. If you did apt-get source then this has been done for you already.
- cd into the source directory.
- Do debuild (or debuild -us -uc to avoid the GPG signing). This builds the package, by reading information from the debian sub-directory, building the source, and putting it all in .debs in the parent directory.
(On scratchbox, where debuild does not work due to fakeroot problems, do dpkg-buildpackage -rfakeroot -sa)
That should confirm that you can actually build the packages. If you are missing some dependencies, try “apt-get build-dep yourpackagname”.
Now you might want to change some things before building the packages again. For instance:
- Using a newer source tarball release:
- Get the source tarball of the latest release.
- Rename it to match the debian convention. For instance:
mv gconfmm-2.14.1.tar.gz gconfmm2.6_2.14.1.orig.tar.gz - Unpack the new tarball.
- Copy the debian directory from the old source directory to the new one.
- cd to the new source directory.
- Do dch -i to edit debian/changelog with the editor. Export EDITOR=editoryoulike if you don’t like vi.
- Change the version number in the new changelog entry. debuild/dpkg-buildpackge actually uses the version number in the changelog for the version number of the debian packages.
- Changing dependencies:
- Edit debian/control and change the Depends line.
- Using special compiler options, or configure options:
- Edit debian/rules and edit the appropriate makefile rule. Try to use a makefile variable, to keep things simple. Some debian/rules files already use CFLAGS or CXXFLAGS variables.
- Apply patches:
- Some debian/rules files have makefile rules to automatically apply any .patch files. If yours does then just add the .patch file in appropriate place. Otherwise, just apply the patch manually and store it in a debian/patches_applied/ directory.
After you have changed the sources and the debian files appropriately, debuild (or dpkg-buildpackage – see above), should build the packages again, putting them in the parent directory. It will even create the .dsc and .diff.gz files, completing the circle.
www.glom.org editing possible again
I noticed on planet.gnome.org that MediaWiki 1.6 was released, finally with a captcha plugin to prevent spam. and I’ve just upgraded. So I have now unprotected most of the pages (tell me if I’ve forgotten any) and allowed account creation again. Now you can fix my errors.
