News From Busyland
This is just a short heads up concerning Tumbler. I just merged Philip’s last critical commit to complete support for specialized thumbnailer services into master. We’ll have to give this some testing but I’m quite optimistic that we’ll be able to release 0.1.0 this weekend or next week. A new release of Thunar will follow shortly after that in preparation for 1.2 (to be released along with Xfce 4.8), supporting virtual and remote file systems based on GIO.
I’ve been pretty occupied lately. Aside from learning for my final university exams I finished my short thesis on porting Thunar to GIO. I already got the very positive results back and I’m going to publish the official version of the thesis soon. Unfortunately, being busy has started to cause not-so-positive developments as well. I haven’t had much time to hack on anything lately and my attendence of FOSDEM 2010 is uncertain. I might still go but I failed to organize anything related to Xfce this year, leaving us without a devroom and talks. So it’d be more like a private meetup rather than an organized team trip with the goal to represent Xfce.
Another consequence of me being busy is that Xfce 4.8 might include less features than planned, at least with regards to the ones I had in mind. For now let’s just hope that I’ll find a little more time for hacking the next months. It doesn’t look too well right now but who knows…
November Xfce desktop
Decided I'd shake things up a bit this month, after keeping the same look for nearly three straight months. Thus, I present:
icons: Area o.43
gtk+: Rele (Rezlooks engine)
xfwm4: Rezlooks-gtk (yes, it is confusingly named)
background: rassilon
It's grungy, but rather sleek. Surprisingly easy on the eyes, too. The lighter elements of the Rele gtk+ theme aren't overpoweringly white, but are just light enough to provide a decent contrast to the generally darker Area icons.
There's also an uncluttered version here.
I've been looking to assemble themes that are grungy, and themes that are warmer-yet-wintry. I like winter. I still have some hope that these 80 degree weeks will come to an end soon. We're almost to the middle of November. Surely we'll see gray sky, cool breezes, and maybe even rain here in SoCal at some point, right? Right? Well, if not, I can at least put it on my desktop.
Help needed for Xfce4 Screenshooter documentation
The current git version of Xfce4 Screenshooter is starting to be in a pretty good shape and I think it is almost ready for a new release. Unfortunately, a lot of things changed during this release cycle so the documentation needs a major refactoring. I need your help for this !
I think this is a good opportunity for someone willing to start contributing to Xfce, I'm ready to provide all the help needed to build the git version of Xfce4 Screenshooter, to explain how the documentation system works and to cooperate to get the documentation ready as soon as possible. I see this as an opportunity to attract new contributors (this task does not require any particular skills, just time, will and a good English level).
Feel free to contact me by mail.
New Personal Bugzilla Policy
I’m herewith announcing a new policy I’m going to follow when dealing with reports on bugzilla.xfce.org. This one goes out to all ignorant wise-asses among you claiming to be superior to us, thinking they are the center of the universe:
If you behave disrespectful, insulting, arrogant or demanding when reporting bugs or feature requests, I will close your bugs with WONTFIX. I don’t care about your name, I don’t care about your title, and I don’t care about your reputation. I do care about social skills and willingness to do your homework. Contributions of all sorts are welcome but as soon as you’re impolitely trying to tell me what I have done wrong or what I have to do in your opinion, you’re out. I call it the social intelligence requirement and it is a must. The more experience you claim to have the higher I’ll set the barrier for you to fulfill the requirement.
Thanks for your attention.
New features of xfce4-notifyd
Back in June, I started to hack on xfce4-notifyd to implement a smart notification placement. In the current stable version, if more two notifications are triggered at the same time, the new ones overlap with the old ones which makes them unreadable. My goal was to shift the notifications so that they would be all visible at the same time.
This turned out to be far more complicated than I had first thought, particularly because of multiple monitors support, but this has finally been committed to the master branch of xfce4-notifyd. I would like to thank Brian who took a lot of time to review my patch and gave me a lot of kicks advises on how to make things work or improve them.
Today, Brian also implemented a cool feature: it is now possible to display gauges (progress bars) or only an icon in a notification, as with notify-osd. Steve Dodier already took advantage of that in xfce4-volumed, which allows you to change the volume using the volume keys of your keyboard and displays beautiful notifications.
The following screen cast shows how things look currently:
New features of xfce4-notifyd (Jérôme Guelfucci) from Xfce on Vimeo.
As you can see notifications are displayed using columns. If a side of the screen is reached, another column is started. That way, you never get two overlapping notifications (well, in fact this can happen if the screen is full of notifications, but that shouldn't happen very often!). If you have several monitors, notifications are displayed on the active one. If a monitor is unplugged, notifications are moved to the other one.
Using Tumbler in Client Applications
Yesterday, Philip briefly wrote about Tumbler, the new D-Bus thumbnailing service that is going to be used on Xfce 4.8 and Maemo 6. Today, I'd like to explain how to use this service in client applications. Depending on the application type, the usage varies a little, so I'll focus on the basics here. I'll discuss some tricks at the end of this post though. What I'm not going to do is to talk about how to connect to D-Bus, how to call methods on D-Bus objects and so on. See the D-Bus tutorial or toolkit-specific documentation for more information about that.
A separate post with information on how to extend the thumbnail service will hopefull follow soon.
The Service Architecture
The thumbnailer specification defines four D-Bus service APIs. For most client applications only two of these are interesting: org.freedesktop.thumbnails.Thumbnailer1 (the thumbnailing service) and org.freedesktop.thumbnails.Cache1 (the thumbnail cache manager). The thumbnailing service can be used to request thumbnails and get feedback on the progress of requests. The cache manager can be used to keep the cache synchronized with the hard drive contents by notifying it when files are deleted, copied or renamed.
Thumbnail Request Workflow
Thumbnail requests include the following information:
- An array of URIs for which thumbnails should be generated
- An array of MIME types for these URIs (each element corresponding to the URI with the same index in the URI array)
- The thumbnail flavor to generate for the URIs (
normalis 128x128px,largeis 256x256px, ...) - The scheduling mechanism to be used for the request (foreground, background, ...)
- An optional handle of a previous request that should now be cancelled
Because the service implementation might vary depending on the system (right now there's only Tumbler, but who knows about the future...) there is no fixed set of thumbnail flavors and schedulers. The specification is supposed to define a standard set of flavors and schedulers that all implementations have to support (like a normal flavor and the scheduler default). The URI schemes and MIME types supported by the thumbnailing service also depend on the implementation and the availability of thumbnailer plugins and applications extendending the thumbnailing service via D-Bus. So, the first thing an application should do is to to determine which flavors, schedulers, URI schemes and MIME types are supported.
Determine flavors, schedulers, URI schemes and MIME types supported by the service
The thumbnailer service provides the methods GetFlavors, GetSchedulers and GetSupported for this. They all return string arrays with supported flavors, schedulers and URI scheme and MIME type pairs. GetSupported is a bit special, as it returns two arrays (one with URI schemes, the other with MIME types). These are to be interpreted as arrays of scheme/type pairs, each pair of which means that files with both the scheme and the MIME type at a certain index are supported. Applications can use this information to avoid requests for unsupported files. Once all this information is collected, we can continue with...
Requesting Thumbnails
Let us assume for a moment that only one thumbnail is needed and that the flavor we want is normal, the scheduler is foreground, the URI is file:///tmp/foo.png and the MIME type obviously is image/png. We can request a thumbnail to be created for this URI by calling the Queue method of ...thumbnails.Thumbnailer1 like this (written in some kind of fantasy language with dynamic D-Bus bindings ;)):
handle = service.Queue ("file:///tmp/foo.png", "image/png", "normal", "foreground", 0)
!["file:///tmp/foo.png"](http://gezeiten.org/post/2009/10/"file%3A///tmp/foo.png"){kind=link}
As you can see here, requesting thumbnails for more than this one URI is simple: just append one more URI to the first array and one more MIME type to the second array.
If you perhaps need to cancel the request later, remember the handle returned by the service. In complex applications with asynchronous APIs you'll sometimes need to link internal request handle to thumbnailer service handles, so the handle returned by the service is not only useful for canceling requests.
Being Notified About the Progress of a Thumbnail Request
Once you have requested one or more thumbnails, you'll probably want to be notified about the progress of your request. Tumbler will emit D-Bus signals for the following status updates:
Startedis emitted together with the request handle as soon as the service starts processing the URIs of the request.Readyis emitted together with the request handle and an array of URIs whenever the thumbnail for one or more of the URIs of the request were generated and can now be used. The array passed to you contains the source URIs, not the URIs of the thumbnail files.Erroris emitted together with the request handle, an array of URIs, an error message and an error code whenever the generation of a thumbnail for one or more URIs of the request failed.Finishedis emitted together with the request handle once the thumbnail service has finished processing the request. This can happen when all URIs have been looked at or when the request was cancelled.
Please note that there is no guarantee for the Ready and Error signal to be emitted for all URIs of the request if the request is cancelled. So, if you maintain an internal thumbnail state for URIs depending on the thumbnail progress, you'll have to remember which URIs were queued. In any case you're advised to make sure to free up your own resources in case the service dies or D-Bus crashes. This can be achieved using a timeout (which will also be helpful if the service hangs) or by connecting to the destroy signal of the DBusGProxy (or whatever equivalent D-Bus API is used in your application).
Cancelling Requests
If you want to cancel certain requests, all you need to do is to call the Dequeue method of the service and pass the correct request handle to it.
Loading the Thumbnails
Where to look for the actual thumbnail files after they have been generated depends on the platform. If Tumbler is built with the default cache backend (which should be built on normal desktop systems), files are stored according to the thumbnail managing standard. On Maemo, files are stored as JPEGs. Philip might be able to give a more detailed description about how to access them.
Thumbnail Cache Synchronization and Cleanup
Some applications like file managers or image viewers allow users to rename, copy, move or delete files on the disk. Since renaming, copying and moving doesn't affect the contents of a file, you can avoid to regenerate its thumbnail by notifying the thumbnail cache of this change. When a file is deleted the thumbnail is no longer needed, so in order to prevent the cache from being polluted with dead thumbnails, you can notify it as well.
This is what the ...thumbnails.Cache1 service interface is for. It provides the following D-Bus methods for the above scenarios:
Copy (string array from_uris, string array to_uris)Move (string array from_uris, string array to_uris)(this one is useful for both moving and renaming)Delete (string array uris)
If you want to clean up the cache in a more general sense by deleting very old thumbnails you can do this via the following method which deletes all thumbnail whose original files have not been modified in a long time and have a certain URI prefix (which may be empty):
Cleanup (string uri_prefix, uint64 original_mtime_threshold)
The above should give you an insight into how the thumbnail service can be used in applications. If you have any questions about this, please let me know. Ok, now let's reveal some tricks to perform optimization on the client side.
Tips and Tricks
- Use asynchronous D-Bus calls in your application to avoid your application to block. A separate worker thread might also be useful.
- It's wise to cache the arrays returned from
GetSupported,GetFlavorsandGetSchedulers. ASupportedChangedsignal is planned to allow applications to update their cached information when the thumbnailer is extended by additional URI schemes or MIME types at runtime. - If your application generates a lot of thumbnail requests, as file managers and picture viewers with gallery support usually do, you'll probably want to reduce the amount of messages being sent over D-Bus. You can do this by grouping individual requests. Often when you use a
GtkTreeViewor something similar involving stateless cell renderers, the easiest way to generate thumbnail requests is when the cell renderer renders a file icon. If you don't group these individual requests, the system might go nuts. So, to group these requests you could use a worker thread with a wait queue that is flushed (URIs in it are sent to the thumbnail service as a single request) at most every X milliseconds. When the first thumbnail is needed, you start a one-shot timeout handler that is executed after X milliseconds, grouping all URIs added to the wait queue in the meantime. I do this in Thunar and it has proven to work well. It also scales nicely by grouping more efficiently the more thumbnails are needed in the time slot. Heavier user scrolling won't make things worse.
I guess that's it for now. I hope you enjoyed reading this first real post about Tumbler coming from me (which is also pushed to Planet Maemo by the way). Again, if you have any questions, please let me know.
R700, KMS, 3D, SSD, and other hardware
Gosh, just look at all the buzzwords in the title!
As you may have guessed, I'll be talking a bit about the recent developments on the FOSS drivers for RadeonHD cards, specifically for R700 cards. And some other hardware stuff.
Radeon
Yesterday, October 3, I made some big ol' changes to my workstation.
I decided to try out the new video driver stack that all the kids have been talking about. Kernel Mode Setting, git Mesa/xf86-video-ati/libdrm, git kernel 2.6.32_rc1-git3. All that jazz. I wanted to see if the 3D and KMS features were really working on my RadeonHD 4550 or not. I normally run a stable graphics stack, with ~arch Mesa/x86-video-ati/libdrm where necessary to keep up on 2D acceleration and features.
This was a big leap for me. So I first consulted some of the X11 team members, remi and nirbheek, who were quite helpful. I installed the latest git-sources kernel, which at the time was 2.6.32_rc1-git3. Mike Pagano has since added -git5. Next, I downloaded the individual -9999 ebuilds for the git master packages from the X11 overlay, stuck 'em in my local overlay, and merged 'em. Only thing left to do was reboot.
Lemme tell ya -- KMS in action is awesome. The console output is just beautiful, and there's no more flickering when SLiM and Xfce load.
I did notice some minor graphical corruption of the default mouse pointer. However, the corruption isn't present when using any pointer but the default "arrow", and it also isn't seen when hovering inside a Firefox window. I was told this is because Firefox uses its own cursors. Anyway, I reported the bug upstream.
Disclaimer: I know glxgears isn't a benchmark. But folks always want to know its results anyway. I tried running glxgears, which gave me a result of over 1300FPS with desktop compositing activated. My window manager is xfwm4, so all compositing is via Xrender, not OpenGL. Disabling compositing resulted in a 500FPS boost to over 1800FPS. What's this mean? Who knows. Probably nothing. Moving on.
I took the advice of my fellow developers on IRC and installed quake3-demo. Couldn't run it, though. It blanked the screen, then a message from my LCD firmware appeared, some kind of "input not supported" or "input not detected" error. It slowly repeated the window, drawing it from center to the top right. I had to Ctrl-Alt-Bksp to get to the console. It also locked up SLiM in the background, pegging one of my CPU cores at 100%. At this point, I rebooted just to test that KMS was still working, then called it a night.
Today, I revisited my pointer corruption bug and tried the workarounds posted by Alex Deucher. To my surprise, each one worked! Booting with radeon.modeset=0 removes the glitch, though it makes each boot extremely ugly, of course. Specifying EXANoDownloadFromScreen "true" in /etc/X11/xorg.conf also fixes the corrupted pointer, though it may also be slowing down all screen drawing operations by the tiniest bit. The jury's still out on that one; it may just be my imagination. I decided to keep this second fix, as KMS is just too glorious to throw out. I like pretty boots.
I also revisited quake3-demo, since I found some pointers on the Phoronix forums that had a workaround, which is to run OpenGL applications prefixed by LIBGL_ALWAYS_INDIRECT=1. To my surprise, this worked nicely. I tested resolution has high as 900-something by 720. My screen is 1440x900, but I haven't felt like pushing it that far, yet. The game is fluid and playable. I need to figure out how to display FPS so I can properly record what I'm seeing.
With the success of Q3demo, I remembered that QuakeLive has recently added Linux support. I installed the add-on for Firefox and tried it out. Works nicely, though I'm also running Firefox with LIBGL_ALWAYS_INDIRECT=1 just to be sure. As Alex Deucher and John Bridgman have pointed out on the Phoronix forums, that variable really isn't the safest thing to do, since if something crashes it can take down the whole X server, not just the application. However, it's also the only way I get working 3D games.
QuakeLive is pretty playable, though the framerates in a few places aren't smooth -- I can't tell if this is because of my card's capabilities, or the driver stack, or the whole weird idea of playing a 3D first-person shooter inside a web browser. 
The big problem with QuakeLive is that the sound is terribly distorted: the voices are greatly drawn-out and slowed down, like playing an old tape recorder at 1/4 speed. There are some solutions on the QL forums, but they're mainly for Ubuntu/Pulseaudio users. I haven't found anything that works for me, yet. The effects and music are okay; it's just the voices that lag horribly.
I've also installed the latest Nexuiz, version 2.5.2, in anticipation of future testing. One of these days I'll reinstall UT2004, but I haven't read any succesful reports of that game on R700 cards. There's a lot of testing to do in the future!
Overall, I'm thrilled with the new driver hotness for my ATI card. I bought it specifically because I knew the 2D support at the time was excellent, and because there would be so many good things coming down the way for other features, including 3D acceleration. (Yes, just like the latest XKCD strip. I swear, it's like that guy listens to everything I say and watches everything I do. It's really spooky!)
Hats off to all the developers for making it happen. Many thanks!
SSD
After August's fiasco with a defective SSD, I decided to use my refund from the RMA and order a different SSD a few days ago. This time I've settled on a SanDisk enterprise SSD from an HP blade server. Only cost $49, no shipping charges. Brand new. eBay for the win.
It packs 16GB of SLC flash, which makes it perfect for mounting /usr/portage and /var on it. This way I can feel free to sync whenever I want, instead of only once a week or more. My system drive uses MLC flash, so I've been trying to ease the write load on it, which means putting the high-write activity on a dedicated disk.
The SanDisk SSD "only" has sustained reads/writes at 60MB/sec, but that's plenty for syncing Portage, as the real limiter is not how fast data can be dumped to the disk, but how fast the rsync servers can send it to my box. Same for /var writes -- it's mostly just log files and some tiny temp things, as /var/tmp is already mounted on a RAMdisk. No large files that need >100MB/sec bandwidth. I'm lookin' forward to shovin' it in my box!
More hardware
Since September 28 was my birthday and all, I've been treating myself to various bits of cheap hardware. Like a replacement AC adapter for my DC PicoPSU. The current AC brick is rated at 102W, which is way more than I need, but the problem is that it spins up its tiny fan at only 50%-75% load. This means that opening up a bunch of tabs, compiling packages, playing Quake, watching large-sized Hulu videos and whatnot turns on the fan right away. And it's the world's most annoying fan. It's loud, whiny, it hisses, and it blows the bad smell of very hot electronics out into the room. Lemme tell you, hot plastic and PSU guts do not smell good.
I just ordered a replacement fanless adapter. This thing is high-quality, designed to run very cool. And it's rated at 150W output, meaning it can match my 150W PicoPSU. My max system draw is maybe 60W, but I'll have overhead room in case I ever feel like upgrading a key component somewhere.
I also bought a $40 wireless router, an Asus WL-520gU. I already have a WL-500gP v2, which I hacked and flashed with DD-WRT a long time ago. This new router is so that I can hook up my Xbox 360 to the network without having to run 50 feet of cable across the carpet. I chose the 520gU instead of the gC because the gU supports Xlink Kai, which seems pretty cool to me, as I don't have a Gold Live account. Yay for tricky internets. Apparently it's pretty common to buy a cheap wireless router and put it into client mode, rather than buying the $100 official USB dongle . . . which doesn't even support WPA2-AES or any decent security. Asus routers are known for excellent open-source support, and I've had nary a complaint about my current one. Yay for Linux on routers! Yay for online gaming!
* * *
Oh yes, and before I forget, this month's Xfce desktop:
It's October, but my current desktop is so pretty (gallery link) I haven't felt the need to switch for the last couple of weeks. There's another clean version that just shows off the wallpaper in my devspace.
Thunar tips and tricks
I was recently reminded of two Thunar features which are useful and not very well known.
First, Thunar comes by default with a fancy mouse gesture feature. The mouse gestures must be done with a middle click, if you don't have one, it can often be emulated by pressing the left and the right button at the same time. To perform a mouse gesture, press the middle button without releasing it, move the mouse in the direction required by the gesture and release the button. The following gestures are available:
- Moving the mouse up moves to the parent directory of the current directory.
- Moving the mouse down reloads the current folder.
- Moving the mouse left moves to the previous directory in the browsing history.
- Moving the mouse right moves to the next directory in the browsing history..
The second tip I recently discovered is that drag and dropping a file using the right mouse button opens a contextual menu which provides the following options: copy here, move here and link here. Link here is particularly cool, I used to launch a terminal and use ln... To use this right click drag and drop, you need to be faster than the traditional contextual menu: right click on the file/folder and start moving your mouse before the normal contextual pops up; once you release your mouse, the über-cool context menu will pop up.
Design of the Thunar Progress Dialog
Today, I merged the shared progress dialog into Thunar. I can be seen on vimeo. This evening I started thinking about the waste of space in it. For each copy/move/link/delete/trash operation we have: one icon and two lines of text, followed by another line with a progress bar (with text) and a cancel button. That's not too much and it looks kinda clean. Thunar has always hidden too detailed information from the user, like the size of the files, how many megabytes have already been transfered/deleted or what the MB/s rate is. But still, three lines of widgets for each operation is a waste of space. And the more space we waste for each operation, the earlier we have to add something like scrollbars around the widgets, as can be seen in the video.So I've made a few mockups to test alternatives. But first, let's have a look at how other file managers do it.
Nautilus / Finder
The progress dialog used in Nautilus is almost a 1:1 copy of the OS X Finder progress dialog. It too follows a three-line design with the first line either showing how many files are being transfered (e.g. Copying 2 files to "Desktop") or what files is transfered at the moment (this is what you can see in the screenshot below, which I am shameless linking here from Bob Peers' weblog). The second line contains the progress bar and a cancel button without any text and the third line shows some stats, again shown in the screenshot.
Now, the problems of this dialog are quite obvious (although not everything can be seen in the screenshot). If you're transfering more than one file, it will be almost impossible to figure out which of the progress views corresponds to this operation unless you know exactly how many files you're transfering and/or how large these are in total. Another problem is that the dialog grows and grows with each operation added to it until it finally grows beyond the height of the screen. Last but not least the progress bar and button heights are different, making the dialog look slightly unpolished.
Dolphin
I have to admit, this is a poor comparison. I couldn't find a screenshot of Dolphin's progress dialog on the net and I'm too lazy to install KDE in a virtual machine. Suffice it to say that I'm not a big fan of KDE GUIs in general. I think the KDE folks have a lot of great ideas but as nice as plasma and all that 4.x goodness may be, most of the windows and dialogs are too busy and cluttered for my taste.
Thunar Experiments
The original design can be seen on vimeo.
The first attempt of an improvement is the equivalent to Nautilus and Finder omitting the statistics by replacing them with a simple <time> remaining text on the progress bar. Like the Nautilus dialog it doesn't display the name of the current file when an operation includes multiple files. This is not shown in the screenshot, because that one is just a hard-coded mockup. All in all, this design makes it even more unlikely to find a job with multiple files again at a later point due to the left out stats.
The second mockup appends the number of files involved to the title (e.g. (1 of 2)) and because of that, it can always display the name of the file being transfered at the moment. The downside is that this of course requires the user to read more text.
Ideas and Opinions?
I'm not 100% sure which way to go here. I kinda lean towards the second mockup but since Thunar is designed to have no redundant options/elements in the GUI, I'm wondering whether the (1 of 2) isn't too much already.
What do you think? Any opinions or ideas for improvements? Sketches and descriptions are very welcome!
Xfce 4.8 Release Cycle Information
At the end of August, we've entered the development phase for the Xfce 4.8 release cycle. Today, we're hitting dependency freeze and I think this is a good time to inform you about how the cycle will look like and what we're planning to achieve for 4.8.The final 4.8 release is scheduled for April 12th, 2010, which is in about 8 months. We're trying to stick to a well-defined release policy for the first time. This includes frequent development releases of individual components and, most importantly, a time-based release cycle.
I'm confident that we can meet the schedule you can see below and would like to encourage everyone to participate in the development and continued improvement of Xfce 4.8, be it as a developer, a translator or a generally active member of the Xfce community.
Below you find detailed information about the 4.8 schedule, the release team, dependencies and planned features. This information is also available on the wiki.
Schedule
2009-08-16 - 2009-08-30: Planning phase
2009-08-31 - 2009-09-13: Extended planning phase
2009-09-13: Dependency freeze
2009-08-31 - 2010-01-31: Development phase
2010-02-01 - 2010-04-12: Release phase
2010-02-01: Xfce 4.8pre1 release / Feature freeze
2010-03-01: Xfce 4.8pre2 release / String freeze
2010-03-29: Xfce 4.8pre3 release / Code freeze
2010-04-12: Xfce 4.8 final release
Release Team
Release Manager: Jannis Pohlmann
QA Official: Stephan Arts
Release Assistants: Jérôme Guelfucci
Ali Abdallah
Yves-Alexis Perez
Robby Workman
Vincent Tunru
You can read up on the roles of these people on this page if you feel like you need to contact one of them because there's something going wrong with the development or release process.
Dependencies
Xfce 4.8 will depend on the following libraries and applications:
- cairo >= 1.0.0
- dbus-1 >= 1.0.0
- dbus-glib-1 >= 0.73
- gdk-pixbuf-2.0 >= 2.14.0
- gio-2.0 >= 2.18.0
- glib-2.0 >= 2.18.0
- gmodule-2.0 >= 2.18.0
- gobject-2.0 >= 2.18.0
- gthread-2.0 >= 2.18.0
- gtk+-2.0 >= 2.14.0
- libpng12 >= 1.2.0
- libwnck-1.0 >= 2.22
- x11 >= 1.1.0
The following dependencies are still left open:
- garcon-1 (no release yet, but used in different places)
- tumbler (no release yet, but used in different places)
- sphinx (for documentation)
Planned Features
In the following, we give you an overview of the features we are planning to implement for 4.8. Please note that due to the voluntary nature of the Xfce development, none of features are guaranteed to make it into the final release. This feature list may also not be complete as we might be able to implement even more during the cycle. This list is meant to give you an insight in what we're up to and what you might be able to expect in 8 months.
You can find a (hopefully) always up to date list on the wiki page. Each of the pages linked there contains more detailed information about the features, their implementation status and sometimes also who has taken the responsibility to work on them.
We welcome people to help in achieving these goals. All of our repositories are now managed using git (on http://git.xfce.org/) so it's easy to clone them and contribute code to Xfce.
exo
- Remove deprecated APIs and rename library to exo-1
- Add GIO module for URI handling to support gtk_show_uri()
libxfce4ui
- Port all Xfce core components to libxfce4ui instead of libxfcegui4
- Object-oriented session client
- GtkBuilder support for e.g. XfceTitledDialog
thunar
- Finish the migration to GIO/GVfs. Among other features, this will give us network browsing (windows shares, SSH, FTP etc.).
- Implement our own volume monitoring backend for GIO (based on HAL or DeviceKit-disks)
- Update thunar-volman to work with this volume monitoring backend and port it to xfconf
- Integration of remote locations in the side pane
- Improve integration of tumbler for thumbnailing
- Port all ThunarVFS thumbnailers to tumbler, write backwards-compatible tumbler plugin for thunar-thumbnailers
- Use a single progress dialog, grouping all file operations
- Extend the D-Bus interface so that e.g. xfdesktop can re-use the file properties dialog
- Startup notification support in the custom actions plugin
xfce4-appfinder
- Drop libxfce4menu and migrate to garcon
- Improve keyboard navigation
- Use startup notification when spawning applications
- Perhaps implement an extension API, so that xfce4-appfinder can act as a replacement for xfrun4 in the future.
xfce4-panel
- Finish the completely rewritten panel. This adds a lot of neat features and revamped dialogs. Amongst other things:
- Introduce an xfconf API for plugins
- Add an improved launcher plugin based on GIO, garcon and exo-desktop-item-edit
- Improved transparency support
- Better panel placement and multi-head support
xfce4-settings
- Netbook-friendly dialogs
- Improve keyboard shortcuts (seem to cause a lot of problems)
- Improve display and pointer settings dialogs
- Add a clipboard manager daemon
- Finish/fix the settings editor
xfdesktop
- Use GIO for the icon view
- Use garcon for the menu instead of libxfce4menu
- Improve icon view drawing routines
- Proper keyboard handling for the icon view
- Free icon positioning
- Allow right-click menus to be arranged differently
I think that's it. I hope you enjoy Xfce and are looking forward to the 4.8 release together with us!