Xfce window manager now includes its own compositing manager
It tooks me a while and a lot of work to get the compositing manager working in xfwm4, the Xfce window manager (obligatory screenshot)
I’ve been asked why making a separate compositor rather than using X.org’s xcompmgr.
To make it short, because it makes perfectly sense. The compositor is like a WM on its own, it manages a stack of all windows, monitor all kinds on X event and reacts accordingly.
Having the compositing manager embedded in the window manager also helps keeping the various visual effects in sync with window events.
An RPM archive for fedora with compositor enabled is available here (source RPM here)
This package is to be used in place of the regular xfwm4 package from Xfce 4.2 RC2 available here
Beta release, Bugzilla
Hi everyone… As you might have heard on the xfce4-dev list, we’re very close to releasing Xfce 4.1.90, which will be the first beta release of the next version of Xfce, 4.2.0. I’ll take this opportunity to re-introduce our new release manager, Biju Chacko. He’s been working this past weekend to get his system into a state to churn out release tarballs. After the release, I hope you’ll all be able to give it a try and give us your feedback so we can move quickly toward a final 4.2.0 release.
Also, many of you have probably noticed that http://bugs.xfce.org/ now points to our new install of the Bugzilla bug tracking system. I finished setting that up about a week ago, and it should help us to more easily track and fix bugs. If you had an account on the old bug tracker, it’s been migrated to the new one. Your username is now the email address you used to register, and you’ll have to ask it to reset your password, as I was unable to migrate the encrypted passwords from the old tracker. If you’re unfamiliar with Bugzilla, I’ve written up a “cheatsheet“, which is linked from the main page. You might also want to try the “guided format” to reporting a bug, which will guide you, step-by-step, in gathering the info you need to submit a useful bug report.
file manager changes
With the upcoming release of 4.1.90, changes to the xfce file manager are worth mentioning. Where to begin?
– The double treeview. In 4.0.x, this feature was a different view of the *same* treeview. Which is downright confusing. With 4.1.90, both treeviews are independent. Changes to one will not affect the other.
– The main menu. Now we have independent treeviews. To which treeview do the main menu functions apply? The old menu was confusing, so we have a new one. Actions which apply on a global scale are included in the main menu, those that are treeview specific are in the popup menu (except for the “goto” commands, which gray out when ambiguity is present).
– The applications branch. This branch was fun to program, but practically useless. Click: removed and replaced by a panel toolbar. The panel toolbar is useful if you are running the file manager on a remote machine (like a server), and you want a minimalistic remote xfce4-panel. Since remote server administration is rare, this option will not be compiled unless “–enable-panel” is specified during build (something server administrators know how to do). So don’t expect to see it unless you look real hard.
– The fork executor (Tubo). Select() replaced the equivalent glib function (which happened to be buggy). This allows a much faster response for all xfsamba functions, mount/unmount, find, tar creation and other commands.
– The copy/move routines were replaced by system defined cp/mv and run by Tubo. Thus, confusion is avoided by using the same default behaviour and error messages you would get by command line execution (plus, memory footprint is cut down).
– Other things that have changed significantly (I’ll explain these some other day): trash management, dropdown toolbar buttons, sidebar, column title popups, popup menus, sort methods, recent and frequent branches, mimetype icon editor, mimetype file association, icon theme handling, in-row cell editing for name and mode and owner/group changes, use of sudo for sudoizable commands, verbose diagnostic messages, recursive scrambling/unscrambling of directories, mount/unmount of smb shares, conversion of treeview branches to plugin architechture and something else I can’t remember now.
– During the 4.1.9x and 4.2.x release period you can expect to see changes within the internal organization aimed exclusively to bug fixes, optimization and code clean up.
– When optimization and code cleanup is complete, we might be ready for testing the icon-view representation (target 4.4, God willing).
Updates, Updates, Updates …
Alright, with me being back from Spain and a string freeze in CVS (Yes, string freeze .. get the idea?) I finally decided to do some work on the German translations again and (As you may witness here) I’m almost done. Xfprint has been updated recently (doesn’t show up yet since the overview is updated only once a day) so there is only Xfwm4 left which is being worked on by Olivier for two weeks now. So I’m going to wait for Olivier to finish his work and right after that I’m done with the translations for our first alpha release of the 4.2 branch.
Apart from that our new fish in bowl, Maarten Boekhold, is making progress on Xfce’s CGYWIN integration. We’re all eagerly awaiting screenshots of Xfce riding Billies best horse ;-).
Thats it for today .. I’m Moritz Heiber, saying, good fight .. good night
New Features?
I realise often that I tend to be very reluctant when anyone asks about a new feature in anything I work on. Generally, if it didn’t occur to me as a feature, my immediate reaction will be to not want to include it. I know that seems a bit silly, and perhaps mean. I’ve never really been able to explain before (in anything but general “this is just how I feel” terms) why I ususally react like this, but after reading Havoc Pennington’s Free Software Maintenance: Adding Features, I realise that this pretty much sums up my reasons. I think it also enumerates some really good rules of thumb that everyone should try to follow when submitting a feature request (even if you’re submitting the patch, too) to any kind of open source project.
So this is why I sometimes seem like to act like an ass when people are bugging me on IRC about adding features to xfdesktop or xfmusic4. It’s nothing personal, but I need to see some compelling justification before adding a feature when I’m not sure it’s worthwhile.
Base dir spec
We were in development freeze for a 4.2 alpha release, but this has temporarily been postponed for Olivier to add support for the new XOrg Composite extension (dropshadows!).
We took the opportunity to convert all Xfce modules to use the freedesktop.org Base Dir Spec to look up their files. Basically this means user configuration files will now be in ~/.config/xfce4/.
The transition isn’t complete yet, but we’re getting there. I do hope more projects will start to use this spec.
Sofar for president
If I were American I’d vote for sofar.
He’s much better at fixing things than any of the other candidates. You want proof? This blog is working again, isn’t it? Thanks to sofar!
Heat and computers
Hey all,
I’m back from my hollidays, but I’m still rather incommunicado. Temperatures here were up to an uncharacteristic 32 degrees C, so naturally my computer — not being used to these temperatures — decided to die on me :^/
I’ll be back up and running soon … I hope.
xfmusic4, goneme
those of you following the xfce4-dev mailing list know that i’ve been working on a lightweight music player, which i’m calling xfmusic4. i’ve made a couple alpha releases, and put up a public CVS repository. more info can be found on the project page.
apparently a critic of gnome has decided to put his money (or the OSS equivalent) where his mouth is, and has formed the goneme project. i think it’s nice to see someone stop complaining and actually do some work, but, after reading his arguments about what’s wrong with gnome, it sounds to me that he’s just mostly ignorant and uninformed, and, in some places, blatantly incorrect. my prediction: he gets a lot of support initially, but mostly from a crowd that doesn’t have much development ability to speak of. the project produces little code beyond the simple patch that’s already up there, and fizzles out relatively quickly.
on an unrelated note, planets gnome and freedesktop are linking to us now. i wonder if they did that before or after i put up links to them here. probably before… i’m not that special ^_~. anyway, if anyone gets here from there, hi guys!
ok, i’ll stop editing this post after this one, i promise. i came upon this, some usability info on .desktop files. we should probably start doing something like this for xfce. i’m kinda against the “GenericName” concept – i think it really dumbs down the user experience. there are many many windows users that honeslty believe that microsoft internet explorer is “The Internet”, and i don’t want to see similar things happening in our world. at the same time, i feel for new linux users that fire up their desktop and have no idea what any of the apps do. i wish menu items would display tooltips when you assign them…
Bugs
We currently have 62 bugs in the database. Of those bugs, 20 are marked RESOLVED, so that leaves us with 42 bugs to handle.
A little more than half of the open bugs are assigned to someone, the rest is still marked ‘new’. Some bugs are actually feature requests, while others are ‘real’ programming errors. Most bugs already have some comments on them, to clarify what is going on or to ask for more information.
If you are feeling bored or are looking for something to help us with, this is a good place to start. You could look at some of the unassigned ones, or — hey, I can try — start fixing the ones assigned to me ;-)
Oh, and if you feel something is wrong with Xfce, please help us by reporting it in the bug tracker.
Just thought I’d try and draw some extra attention to this very useful development tool. Happy bug hunting!