xffm package separation
Starting with xffm-4.3.4, individual packages which are currently part of xffm will split into individual packages (fgr, xfdiff, xfsamba, xffm-libs, etc.). SVN for these packages will still be nexted in the xffm tree. Today the first of these packages, called libtubo, is released. Libtubo is a small library that only depends on glib>=2.0. Libtubo is the engineblock behind xffm. With the library xffm communicates with other applications to do stuff like samba browsing, finding files, mounting volumes, copying and scp, and just about everything. As from today, this library can be used by any other package and does not require xffm to be installed. Source tarball is available at http://xffm.sf.net/libtubo.html where you will find complete API Reference Manual. The source is also available from svn tree under xffm/libtubo.
Xfce News – From Then Till About Now
Let’s pretend the last several months haven’t happened, and I’ll pretend that more than three of you read this.
That said, it seems like the best thing to do is to lay out where we are going, where we are, and what’s happening to get us there. If you care what’s been going on in Xfce, but haven’t been following the various blogs and lists, this is your chance to get caught up.
Mousepad! Finally!
Okay.
So, I finally just crawled through my email till I found the right URL to do a checkout from the Xfce repository.
I felt very very stupid.
Having done so, I pulled a fresh checkout of Mousepad (since the one I had was corrupted), and made a branch for 0.3. Since I was without internet for so long, I was working on Mousepad a few minutes a day in a local repo. I commited those files to the new branch with surprisingly little difficulty.
It’s amazing how easy that was, once I remembered to not be a douche.
You can pull it from the anonymouse repository this way
svn co http://svn.foo-projects.org/svn/xfce/mousepad/branches/mousepad-0.3.x mousepad
And you can build it with a simple ‘make’
Currently, it does very little that’s interesting, just a window with a GtkTextView in it. The Makefile is even handwritten. The goals of this rewrite are:
- Eliminate deprecated stuff where possible
- Organize the code into a maintainable structure
- Take advantage of the Xfce platform more fully
- Make it faster
- Make it smaller
- Add some small features
- More fully learn C, Gtk+, and autotools
We’ll see how much of this I manage to acheive. However, so far, all looks good.
If you see a bug in Mousepad, please let me know. It is highly likely that there are memory management bugs inside. It’s also likely that I do things in ways which are not cross platform, or reinvent the wheel.
As an anecdote, the reason to fork leafpad was I needed printing support. Since I could read C poorly, and write it hardly at all, a good chunk of the printing code was copy and paste from the inside of the “Save” routine. Turns out the old save routine reimplemented a GtkTextView method, and poorly, so the printing code did the same.
Had I realized I didn’t need to fight with it to add printing support, I might not have bothered with the fork, really.
Tales From The Xfweiner
So, everything that has possibly gone wrong has gone wrong. Basically, life sucks.
But I’m not going to go into that. Things will get sorted out. Until then, however, my Xfce participation is a mess.
However, I’m hoping to pick up a few hours a week on Mousepad, and get the damn thing finished.
In other news, Robert Moog, the father of electronic music (Leonard Theremin being the grandfather), died from a brain tumor. I got the chance to meet Bob several years ago, he settled down in the smallish town in the mountains where I live. He was one of my heros, and I will miss him.
Also: This is what God intended. I’m tired of apps like Abiword having no Gnome dependecies mean “Just libgnomeprintui”. And Totem depending on gnome-vfs. But that’s really another story, since gnome-vfs isn’t going to go into GTK+. But the principle remains.
Patch for Compaq R3000 laptop
Off topic, but since I’ve been working on this mostly for the past few weeks… I’ve prepared a workarround to an incredibly crappy harware bug that cause the timer to run 3 times too fast on some of the Compaq R3000/HP zv5000 laptops.
The page is here : http://www.xfce.org/~olivier/r3000
Thoughts
I may have mentioned this to a few of you already, but I’m currently undergoing a bounty of family concerns. My grandma (technically my great grandmother) slipped into a coma last weekend, and that’s added to the stack.
I feel like I haven’t been doing my part around here, with Thunar still being written primarily by Benny, and 4.4 looming, and Mousepad still in pieces on my harddrive. I hope things get sorted out soon, and I can be a useful community member again.
As a comment on the recent KDE posts: the thing I noticed most is where KDE wants to become more like Xfce. Namely, the respect that both of those posts had for simple, small applications that did their job and nobody elses. I have some more deep thoughts about that, but it’ll have to wait till later.
deskview background
To keep things simple, xffm-deskview does not set the root Pixmap, but rather takes whatever Pixmap any other application sets for the root background. Unfortunately, many programs are screwy with the root Pixmap on exit. Most will not set the persist-on-exit, but will neither destroy the property. Since the atom will persist until X exits, this leaves a bogus root Pixmap. To deal with this problem, on startup xffm-deskview will automatically assume the Pixmap is bogus (even though the Pixmap set by fvwm-root —for example— is not bogus) and fall back to a solid background. Thus, to set the background image, the root Pixmap must be set by the background setting utility after xffm-deskview is up and running. I’m thinking about wrapping fvwm-root in a gtk GUI to provide this application, if I have the time. This won’t be for 4.3.3 because the release is already on the horizon.
KDE articles
Usually I follow developments in GNOME more closely than those in KDE, mainly because Xfce is more closely related to them using the same toolkit and all.
But I just saw two blog entries about KDE4 that were quite interesting to read for anyone interested in desktop development. The level of integration they are talking about is not something that Xfce offers, or probably should even want to offer, but they make some good points about general desktop and application design.
Oh, the articles I am talking about are by Mathias Ettrich and Ben Meyer.
SVN accounts for translators
The opportunity of SVN accounts for translators was discussed just after the switch to subversion around March (IIRC) and at that point it needed some experimentation and testing. Now, it’s ready, translators can get their SVN account (i sent a personal mail to those who can have one, if you feel forgotten drop me a note), now the translation efforts won’t suffer delay due to committing anymore.
If you want to help for the translations, you’re welcome to join the team, just subscribe to the xfce-i18n ML and and let you know; you can watch the status of translations here; i also created some basic scripts to help subversion newbies to checkout and update their working copy, you’ll find them there.
Once again, thanks go to Auke, our (over)skilled server admin, for his work.
Happy translations…