Assuming Maintainership of gtk3-rs
This news isn’t quite fresh, but last month I took over maintainership
of gtk3-rs, the official Rust binding for
GTK3. It had been unmaintained and archived for years, since it’s a
small team, and most development effort had been (quite reasonably)
focused on gtk4-rs and the gtk-rs-core crates.
I’ve been using gtk3-rs in xfwl4,
for drawing UI elements like the alt+tab window and window dropdown
menus. It was unfortunate to be using an unmaintained library,
especially one whose dependencies (on the core gtk-rs crates for glib,
gio, etc.) could not be updated to the latest maintained versions.
I realized I’d sent a couple PRs to the project in the past, and I also
maintain a Rust binding for Xfce
libraries, so I’m familiar
enough with the architecture and tooling around it. It seemed like it
would be reasonable and not-too-difficult to maintain.
I spent a few weeks updating its dependencies, modernizing the code base
a bit, and made the first 0.19
release last week.
My future plans are mostly simple maintenance: bug fixes, adding small
features (like better support for subclassing), and keeping pace with
development and releases of the gtk-rs-core crates. I expect breaking
API changes to be at a minimum (mainly as a result of breaking
gtk-rs-core updates).
If you have problems or contributions, head over to the issue
tracker or submit a pull
request.
Finally, I’d like to thank Sebastian Dröge and Bilal Elmoussaoui, who
were open to the idea of a new maintainer, and reviewed my PRs and added
me to the org.
Xfwl4’s Second Preview Release
I’m pleased to announce the second preview release of xfwl4, Xfce’s Wayland compositor, version 4.21.1.
Thank you to all who provided feedback and filed issue reports on the first preview. I’ve fixed a lot of issues and added quite a few missing features.
Here are the essentials:
Source tarball. Build and install instructions are in the README. Please pay careful attention to build and runtime prerequisites.
Issue tracker. Search the issue tracker first in case someone else has already filed a similar issue. If not, and you file a new one, be sure to fill out every part of the issue template.
Git repository. If you’ve
found an issue, it would be helpful if you could ensure it’s still
present on git main. You can also try any fixes and features I’ve added
since the release. Be sure to clone it with --recursive.
Again, please take a look at the README for runtime dependencies. xfwl4 will build and start without those runtime dependencies met, but some functionality may not work if you have older versions of some Xfce components and libraries. That list has been updated with newer versions since the first preview release.
You can check out the list of closed
issues in
this release. Note that there are more changes and fixes than are
reflected there, as not everything I’ve done has an associated issue
(and there are some issues filed and closed in other Xfce components
that enabled some of this work). The NEWS file has the full list of
commits and translation updates.
Anyhow, enjoy, and let me know how it goes.
LLMs and xfwl4
I was planning to write a little about my usage of LLMs while building xfwl4 as a small section of a larger blog post, but I decided I’d rather get it out of the way on its own.
While LLM usage can be polarizing in the context of open source, I don’t really see it that way. It’s a tool, like any other. It has good parts and bad parts. On the bad parts, there are three things that stick out for me:
Training Data and Copyright
Among other sources, LLMs were trained on publicly-available data, without the permission of any of the rightsholders of that data. That especially smarts since I have a lot of open source code out there, much of it licensed under the GPL. Is training an LLM on my code copyright infringement? If someone gets output from an LLM that looks substantially similar to my code, and they don’t know and don’t follow my license terms, is that copyright infringement?
And if it goes the other way, if output I get from an LLM looks very much like someone else’s code, did I infringe on their copyright?
I’m not sure! US law seems to suggest that training is fair game, as long as the entity doing the training has legal access to the data they’re training on. As for the rest of it, I’m not sure that’s legally settled yet.
On top of that, it sometimes feels icky that companies like OpenAI and Anthropic are making money off of all this when all that data out there – for which they mostly paid nothing – makes it possible.
I don’t, however, think the best response for myself is to just pretend none of it exists. It’s a tool, and a useful one.
Environmental and Social Impact
LLMs need a lot of space, electricity, and water. Communities where data centers are being built, along with the associated power plant upgrades, are often getting stuck with some of the bill for those improvements, which is disgusting.
The secret deals between datacenter companies and utility companies, often with municipalities complicit, are often leaving regular ratepayers out to dry. That’s a local problem, and I hope those local people vote in representatives who will take better care of them.
Supply Chain
I don’t need to remind anyone how expensive GPUs and RAM are right now. I was planning to upgrade the mainboard in my laptop this year, which would require new RAM (my current board has DDR4 in it), but the cost of 64GiB of LPCAMM2 DDR5 makes my eyes water.
The consumer RAM market has been hollowed out; several companies have either stopped making consumer-grade RAM entirely, or have severely restricted supply in order to make more money selling to datacenters and AI labs. That’s capitalism at work for you, at the expense of regular folks who need to buy computing hardware for personal use.
But here I am, with a Claude Max 5x subscription for the past year and a half. I’m not comfortable with it, but the utility is just too great for me to take a principled stance here. I like it, and I want it, so I’m using it. Maybe that’s morally questionable, or worse. But, as I said: here I am.
xfwl4 and LLMs
So yes, I use Claude quite a bit while developing xfwl4. I don’t vibe-code, ever, and I probably use the LLM to generate less code than most people do. After all, building things with code is my hobby and passion (and I’m lucky I got to do it professionally for a quarter century), and driving an LLM is kinda boring.
Research and Planning
Most of my time with Claude Code is research and planning. One great match for LLM use here is helping me understand the finer details of xfwm4, since xfwl4 needs to duplicate all of its behavior. One common prompt of mine:
1 2 3 |
look at the xfwm4 source in detail and determine everything there is to know about $FEATURE. write up a plan for how to implement it in xfwl4 to notes/$FEATURE.md. |
I go do something else for a while, and when it’s done, I read the doc, and then spend a while asking Claude questions about it, and telling it the things I don’t like and what I’d like to be done differently, and it updates the doc.
Implementation
Most of the time I’ll start working from the notes doc myself, writing the implementation by hand. My guidelines for plan-writing to Claude are to do things in phases, and so I’ll complete a phase at a time, and then ask Claude to validate what I’ve done. Often, while I’m working, I’ll decide to deviate from the plan, and I’ll have to tell Claude to do the validation based on the outcome I want, not based on adherence to the plan.
Once it’s done, I’ll use /code-review and let Claude spawn sub-agents
to do a full review of the new code. This usually finds some problems,
even problems that the “main” Claude instance didn’t find during its
validation. I usually keep running /code-review again and again after
finding and fixing issues, until there aren’t any left. I actually
haven’t been doing /code-review for very long, maybe 6-8 weeks, as I
didn’t know about it. I wish I’d done it from the start, as it’s very
useful.
Sometimes I will have Claude write some code for me. Usually it’s when there’s a lot of boilerplate, or if there’s work that feels repetitive and tedious. Claude is generally a great fit for that, and I can both manually review the output and have a subagent do an independent review. I’ll usually keep CC in manual mode and approve every edit after reading it, but for some more mechanical changes, I’ll let it sit on auto for a while, and review when it’s done.
Occasionally I’ll have it write more substantial code for me, usually for bug fixes, and occasionally for small features. I find it does a pretty decent job here, but I keep it on manual mode and often ask it to write the code in a different way, or take a different approach.
Bug Fixing
Whenever there’s a bug, I’ll start looking into the code myself (I want to keep my debugging skills from atrophying), but in parallel I’ll also ask Claude to look into it, either by describing the problem, or pointing it to a Gitlab issue, if there is one.
I’ll admit that it’s rare for me to find the issue faster than Claude does, and there were some issues where I was completely lost, and Claude figured out something in 10 minutes that probably would have taken me days.
Tests
xfwl4 doesn’t have many unit tests, but I’d like to improve that at some point. Of the unit tests that do exist, they were al written by Claude. I’ve always found testing to be tedious, and never did a very good job of it. Claude’s tests are generally much more comprehensive than tests I’d write myself.
I’ve heard stories of people saying that Claude will change or delete failing tests instead of actually fixing the problem that makes the test fail, but that hasn’t (yet) happened to me.
xfwl4 also has a test-clients sub-crate that has a bunch of Wayland
and X11 client apps for manual testing of various compositor features.
I wrote the first Wayland test, using smithay-client-toolkit, but for
the rest of them, I told Claude to write them for me, using my first
test as a template.
My LLM Strategy
I don’t really have one. I just run the best model available for everything (Opus 5, at the time of this writing1). I don’t write skills or other bits of automation. I expect some of that is indeed valuable, but I’m just not interested in it, so I don’t do it.
My usage isn’t high enough to ever hit my 5-hour or weekly limits on the Max 5x plan, so I just don’t worry about it. I started out with the Pro plan, but very quickly started hitting limits in the first 1-2 hours of the 5-hour windows, so I eventually upgraded after trying out extra usage for a bit and deciding I’d be spending more going down that route.
As I said above, I don’t vibe-code. I care about code quality and about understanding what I’ve built. I care about being able to maintain it in the future, manually, without needing an LLM to do everything for me.
And That’s It…
That’s it, I guess. I don’t think I would have made anywhere near as much progress with xfwl4 without an LLM. It’s easily saved me months of time, not in writing code (for non-trivial things, I can usually write it just as fast or faster), but in tracking down problems and helping me figure out solutions, whether that’s in Claude reading and reasoning about my code to find something that’s wrong, or in adding tons of targeted debugging prints to gather the information we need, and then sifting through the log file for me to do analysis.
I know this blog post is a tiny drop in an ocean of people writing about their LLM use, but I expect some folks might be curious about the development process behind xfwl4, so I figured a sort of disclosure was in order.
It’s been a little over a month since the first preview release of xfwl4, and I’ve fixed many issues and added new features since then. Hopefully I should have a new preview release in the next week or so, but you can clone the git repository to check out the current state of things for yourself, whenever you want.
-
Yes, I know Fable exists. I was hesitant to start using Fable as it felt like Anthropic could pull the rug out and require API pricing for it at any time. It seems now they might leave it available to Max plan users indefinitely, but the usage terms (only allowing 50% of usage to go toward it) make me feel like I’ll get limit anxiety. ↩
Xfwl4’s First Preview Release
I’m pleased to announce the first preview release of xfwl4, Xfce’s Wayland compositor.
After close to six months of work, I feel like it’s ready to get some wider use, even though of course there will be bugs and missing features. Think of this as an alpha release.
First off, I’d like to give a big thanks to the rest of the Xfce core team for offering to sponsor this work. I’ve been an on-again off-again Xfce developer since 2004 (more “off” than “on”, I suppose), and I consider it a great privilege to have this work sponsored, giving me the opportunity to focus solely on this project since the beginning of the year. This is also a huge thank-you to all the supporters who have generously donated to Xfce over the years.
Here are the essentials:
Source tarball. Build and install instructions are in the README. Please pay careful attention to build and runtime prerequisites.
Issue tracker. Search the issue tracker first in case someone else has already filed a similar issue. If not, and you file a new one, be sure to fill out every part of the issue template.
Git repository. If you’ve
found an issue, it would be helpful if you could ensure it’s still
present on git main. You can also try any fixes and features I’ve added
since the release. Be sure to clone it with --recursive.
The end goal of xfwl4 is to behave as closely as possible to an Xfce desktop running on an X server. Ideally a user could switch between the two without even knowing there’s a difference. In reality, of course, it won’t be quite that seamless, and there’s still more work to be done to get as close as possible to that ideal. This is a first solid cut at it, at the very least.
The issue tracker will give you a decent idea of things that are not implemented yet or are known to be broken, but here is a list of notable things that won’t work, so you aren’t surprised:
- The “Mouse and Touchpad” settings dialog (but whatever settings you’ve set under X11 will be applied under xfwl4) (issue).
- The “Workspaces” settings dialog (issue).
- Screen margins (issue).
- xfdesktop’s minimized window icon view, and the middle-click window menu (issue and issue).
- Pager thumbnails in the panel (no tracking issue yet).
- Taskbar apps can only change maximize/minimize/fullscreen state (issue and issue).
- Keyboard shortcuts for application/application-window switching (regular all-window cycling works fine) (issue).
- Most (all?) apps will not be able to restore their window positions or workspace on startup (issue and issue).
(This is not an exhaustive list, just a few things I thought worth calling out.)
Over the coming weeks and months, I plan to write a blog series on how I built xfwl4. I’ll update this to link each new post here as they’re published. Anyhow, give it a spin!
How to start contributing to Xfce or any other open source project
It’s been a while since I’ve updated this website and even longer since
I’ve written anything useful. But since I’ve received a couple of mails
from people looking to contribute to Xfce recently, I thought I’d share
some “wisdom” acquired over the past few years while working on Xfce and
doing a lot of community work. My thoughts are not limited to Xfce and
will apply to a lot of other projects out there as well.
Here’s the bitter truth for those looking for some quick pointers to
start contributing to Xfce: you’ll have to find out yourself.
The reason is not that we are lazy or wouldn’t welcome your
contributions. In fact, the reason, I believe, is very simple: you will be more
excited, motivated and, ultimate, be more successful if you work on
something that interests you. We can help you in making the decision
what to invest your time in easier, e.g. by listing projects, features or
issues that we or our users consider worth working on. Some projects do
this very visibly (e.g. through bounties). In Xfce, this information is
hidden in the depths of the wiki. Here are a few links that you may find
interesting:
- Design SIG – working on improving the user experience of Xfce
- Component wish list – populated by our users
- Panel plugin wish list – populated by our users
Clearly, the above information could be more visible. There could be a
prominent link on the Xfce website to a well-maintained and up-to-date
list. Would that help people? Maybe.
Perhaps it is a good thing that the information isn’t just one click
away. Open source projects have always been about scratching your own
itch. This is how I got involved in everything I’ve done over the
years. this approach is reflected by what people do and sometimes even
by how companies make money. Thinking about it now, it is a concept
deeply rooted in the evolution of mankind (think: the invention and
improvement of tools, industrialisation and all that shit).
So: scratch your own itch.
If you want to start contributing to a project, try this exercise:
- Look at the project, think about what you don’t like or what you feel could be improved
- Try to collect information on what pieces are involved in e.g. the feature you’re missing or the bug you’ve spotted
- Try to find the place where you could try adding your feature or fixing your bug
- Ask whether developers are interested in the feature or look at whether there already is an item for your issue in the bug tracker
- The rest is communication and coding
It’s not a fast path because you might not be able to contribute
something of great value in the beginning. But if you’re dedicated,
have enough spare time to make a difference and are keen on improving
things step by step, you might eventually reach a point where you take
over responsibility for more and more exciting or important tasks.
Good luck!
FOSDEM 2012
This year’s FOSDEM is over and I hope that most of us have by now recovered from an exhausting weekend that was first and foremost exciting and a lot of fun! With about 12 people, the Xfce group was—I think—larger than ever before. Add to that a fairly large number of my colleagues from Codethink, into which I bumped at the beer event and FOSDEM itself from time to time. Despite mostly staying with Xfce, I enjoyed knowing and meeting people all over the place.
Unfortunately, some of us—myself included—missed half of the beer event because our trains and planes arrived late. Snow in Brussels, a cold weekend ahead. When we arrived at the Delirium Café at around midnight, I was glad to see that all the others had already made friends again. Olivier, Stephan, Peter, Nick, Simon, Christoph, everyone was there, some of them sufficiently drunk, I imagine. Although to be be fair, you wouldn’t really notice. Most of us left not to long after that in order to be in a good condition in the morning. Having only caught up half on drinking, Christian, Mike and I ended up staying at the Delirium with a few Codethink colleagues including Sam, Luc and Javier—until they finally kicked us out at around four in the morning.
Food, taxi, 2 1/2 hours of sleep later and we were sitting in the hotel, enjoying a fantastic buffet breakfast. Admittedly, I couldn’t eat that morning, ending the night in the Delirium had lead to quite a strong hangover. After the majority of us had gathered in the hotel lobby, we squeezed ourselves into the 71 bus in two groups and finally arrived at FOSDEM. I do not remember the details of the day, but it was a great mix of talks (including my own one about Tumbler, which I felt was not very special, picture below), chatting and minor hacking (at least on my side; Nick made good progress with the settings editor in the meantime). During the day, Jean-Francois, Jens and Mark joined us and we (or most of us at least) ended the day having food in a Vietnamese restaurant close to the hotel and a beer in the hotel lobby.
Sunday was similar, except that I could finally enjoy the breakfast. Lovely. Unfortunately, we didn’t manage to get everyone together anymore, so our initially large group was now split up into smaller ones for the rest of Sunday. We still managed to have a few technical chats about Xfce that day and made a few decisions (see below). Regards talks, I mostly remember the Wayland Q&A session and a talk about social engineering in free software communities, Most of us left in the afternoon or evening. I met up with Luc, Sam, Javier and a bunch of other people to have food in a very nice restaurant. Got up at six in the morning, walked to the central station, took a plane home from the airport and went back to work in the afternoon. Unlike a few others I seem to have escaped the typical illnesses (cold, broken sleep cycles, general exhaustion) that events like FOSDEM always bring along.
Xfce-Related News — Fresh from FOSDEM
Wayland was big this year. I will spare you the details of how it works. Throughout the weekend, we had various discussions that involved Wayland. While it may take some load of Olivier by eventually making window managers obsolete, there is still a major problem with it: it does not support the XEmbed protocol, and therefor will break pluggable settings dialogs and panel plugins. We have sent mails to the wayland-devel list to find out how they feel about this. For now, I suppose this is all we can do.
Reorganization of the settings dialogs
One thing we decided on Sunday was to reorganize the settings dialogs so that the location of particular types of settings becomes more predictable. This applies to appearance and window manager themeing, and the application keyboard shortcuts and window manager keyboard shortcuts in particular. We will rearrange some of these tabs and merge them so that all related settings are in one place. We will also merge the window manager and window manager tweaks dialogs into one.
Release Schedule for Xfce 4.10
Despite a lack of completed features in Thunar (which are unlikely to get finished before 4.10), there are only a few things that really keep us from releasing Xfce 4.10. We have not decided on a release date, but if things go well, we should be able to roll the first pre-release one month from now, in early March. This would mean that a final release in May or June would be feasible.
Possibility of a hackfest
Meeting up with the team is always great fun. Unfortunately, FOSDEM is a busy event and only lasts two days. Like last year, we discussed the possibility of an Xfce hackfest in the future. I would love to see this idea becoming reality. If half a dozen of the relevant people can make it for at least a couple of days, this could greatly benefit the development of Xfce. Ideally, such a hackfest would span over at least 4-5 days, ideally including a weekend to make it easier to attend for people with jobs. Given a relatively small group, it might even be possible to hold an event like this at someone’s flat. This is definitely something that we will look into soon.
Like every year, FOSDEM 2012 was a great event. And like every year, a few more nicknames have turned into real faces that, unsurprisingly, belong to incredibly friendly human beings! I only wish that we had more time to discuss things face to face and do some serious work on Xfce together. In any case, this calls for another iteration next year. And with that, I shall end this wrap-up.
On MeeGo
Whatever MeeGo was, it never made it into the open source mainstream, which I consider to consist of projects actively worked on by volunteers and companies alike, and didn’t manage to become an project attractive enough for individual open source enthusiasts not driven by money to make substantial contributions.
There is enough room to speculate over the reasons why this is. My personal take is that MeeGo failed to be a successful open source project because the corporate commitment to the open source idea was not strong enough and expectations were too high right from the start.
Open source projects start with an idea and evolve into a proper product over time. Sometimes they are developed incrementally, sometimes it happens that big parts of them are replaced all at once. The idea behind an open source project may be huge but they all start off with baby steps. MeeGo, however, wasn’t supposed to. The idea behind MeeGo was big, and due to market pressure it was expected to become complete and successful quickly. It occurs to me that the idea was to sort of guarantee success by providing the project with professional, corporate governance.
I think everyone who started working on open source as a hobby knows that this is something a lot of hackers don’t are comfortable with. An open source project under corporate leadership may easily suffer from top-down decisions that give developers the feeling of working in a restrictive environment rather than a playful one. I’m not surprised by the fact that the only people I know ever contributed to MeeGo worked either for/with Intel or Nokia.
It isn’t the technologies, tools or frameworks that are reason for the failure of MeeGo. KDE and GNOME are large and successful projects based on Qt, GTK+, Clutter, D-Bus-based desktop middleware etc. What has lead to failure in my eyes—-the eyes of an outsider, opn source developer and potential user—-is that the dynamic nature of open source projects conflicted with corporate expectations and hopes for a quick success they needed so badly. Add to that the pressure on Nokia, the corporate culture clash of two global information technology companies and the fast pacing world of mobile devices and interfaces, and you have a pretty explosive mixture.
Personally, I won’t place my bets on Tizen. I can only imagine how frustrated and disappointed everyone who tried to get involved may be today, even those who contributed to MeeGo as part of their work for Intel, Nokia or one of the many smaller companies that make up the corporate part of the open source ecosystem. It is also frustrating for me as a developer aiming for a job in open source and desktop/mobile/UI technologies.
I guess the mobile open source platform we are all hoping for will be there some day. But it will only appear slowly, driven by the efforts of enthusiastic individuals with big ideas, realistic expectations and sound knowledge of the pace and dynamics with which open source projects grow and mature. This of course relies on open hardware and I don’t know enough about the manufacturing industry to predict the availability of open, hackable devices in the near future.
In the meantime, the best we can do as open source software developers is improve the base OS level and innovate in desktop/mobile/UI technologies by experimenting with new ideas and extending existing frameworks. I’ll help where I can.
Looking for a full time job in Open Source
Two years ago I was really close to canceling my studies and looking for a job instead. In the end I continued studying, passed the final exams of my Diplom (the German old-school equivalent to a Master’s degree) with excellent results and started working on my graduate thesis. Today, I am 1 1/2 months away from the submission deadline and it is clear that I will make it.
So, this time I’m serious: I’m looking for a full time employment in Open Source software development, engineering or management starting November this year. Hiring me will get you an experienced and talented hacker with a natural intuition for software architecture and aesthetics as well as a scientific and painstaking approach to software planning and implementation.
Through my work at the university and within the Xfce and Lunar Linux projects, I have gained experience in/with
- many programming languages (including C, C++, Ruby, Python, Vala, Lua, XSLT, TeX, Java, Bash and a couple of others),
- many frameworks (the whole GTK+/GLib stack including D-Bus, a bit of Clutter, XLib and Qt/QML, SWT/JFace, the FOX toolkit as well as web frameworks like Sinatra and Rails; some knowledge about the Linux kernel, its facilities and kernel-userspace communication mechanisms included),
- many developer tools (GNU compilers, Autotools, VIM, NetBeans, Eclipse and others),
- many software versioning systems (Git, Subversion, CVS and Mercurial), and
- various areas of computer science and software engineering (complexity theory, signal processing, graph drawing, micro-controller programming and sensor-based networking, software planning, testing etc.).
I feel equally at home developing for the desktop or for the web. Granted, my main area of expertise is user interface and middleware development on Linux, which my fellow Xfce hackers and I have successfully participated in, but I’ve always found web development with Ruby to be a refreshing change.
There are many other things related to open source that I love doing. Over the past years I’ve enjoyed being able to improve the transparency of the development and release management of Xfce. Streamlining the release process and providing tools for making release management fun was an initiative I am particularly proud of. The same goes for community efforts like the Xfce Foundation, which we’ve launched in early 2011 and which I am currently heading as president.
This post is not just about the past though, it’s also about what lies ahead. Things I am particularly interested in with regards to the future include
- mobile platforms and applications (iOS and Android are not good enough, I think we need open alternatives),
- multi-touch interfaces on Linux (yep, this is on the way, but there still is a lot of potential work to be done, I guess),
- cloud-based applications (I know I can store files and data on the web, but where are the mind-blowing features that go beyond availability of personal data everywhere?), and
- environmental and power saving applications (living responsibly will become important soon enough; how can we generate awareness and support environmental causes with the help of software?).
I am excited and curious what my role will be in all this. Anway, I guess this is enough information about me for now. After all, this is no biography but a job-search post. ;)
If you read this and you happen to be Microsoft or Apple, do not even bother to send a headhunter. I prefer to work in the open and I believe in Open Source for many reasons. This ecosystem that we’ve created over the past two decades provides a great way for people from all around the world to collaborate on projects they care about, in an honest and tolerant way. I think that’s an inspirational model from which our entire society can and hopefully will benefit. Why would we want to have it any other way?
If you are a member or leader of a company dedicated to Open Source software and are interested in hiring me, please let me know. Linked below are my resumé, software projects and email address. I’m looking forward to talking to you!
Download my resumé/CV — A list of references is included. Feel free to contact them; they are aware of being listed and I’m sure they will be happy to answer any of your questions.
My software projects — A list of open source software projects I am or have been working on.
Email address: jannis@xfce.org
important strategic decisions
Posting our recent decisions for Foresight Linux as sent to the mailing list by doniphon:
With the ongoing mess with the gtk2 -> gtk3 migration, followed by
the announcement of the gnome reschedule, and the gnome-shell/unity
rift, we do think our 2 major desktops gnome and xfce are rendered
unusable for the unforeseeable future. Same counts for kde as nokia
started to drop support for qt. Therefore we decided to focus our work
on getting in e19, a major enhancement to enlightements e17, using an
improved and hw accelerated curses library, done by us on a still
private bitbucket repository. This change also involves getting rid of
the much hated combination of pulseaudio/alsa in favour of the much more
modern and stable OSS 4.2, and entirely dropping Xorg and evolving to
Xfree2k. We’re looking foreward to provide a superior user experience
soon with fl:3++. We’ll shortly set the e19 repository to public, so you
all can benefit (and contribute) after signing our standard contribution
agreement that cedes all your present and future rights to Paris Hilton.
As a side note we’ll be moving our default kernel to MinixNG too.
Have a nice day.
Porto, 1th April 2011
The Foresight Linux Council
Xfce 4.8 on BSD flavors
I should’ve made this more clear in the Xfce 4.8 release announcement but for a moment there I forgot that not everyone knows what we developers are dealing with under the hood.
Many users have been asking what the BSD problems are that I mentioned in the announcement. As some of you may recall is that HAL, the hardware abstraction layer that has for the past few years been used for volume and power management as well as a few other things, has been deprecated and replaced by a variety of frameworks. Today there is udev for device information, udisks for volume management, upower for power management as well as ConsoleKit and PolicyKit for session and permission control.
At least udev is strongly linked to Linux and as far as I know is not available on any of the BSD flavors. Unfortunately it is now the only good way to detect storage devices, cameras, printers, scanners and other devices using a single framework. That’s why we use it in Xfce now in situations where HAL provided us with device capabilities and information to distinguish between the different device types before. The consequence is that thunar-volman no longer works without udev and thus only compiles on Linux. In Thunar itself udev remains optional.
I don’t know what the porting status of the other frameworks is. But I am pretty sure not all of them have been ported to other platforms yet which is why I felt the need to express our disappointment in the announcement. For 2-3 years now all this has been a big mess. New frameworks were invented, dropped again, renamed from *Kit to u* and somewhere on the way it became impossible to keep Xfce as portable as it was before. I know that this is nothing new and that BSD folks faced the same situation as they do now back when HAL was invented but I don’t think it has to be this way.
For the question how we can improve the situation I have no answer yet.