text:
Jannis Pohlmann - Tag - thunar 2014-05-14T01:45:44+02:00 Jannis Pohlmann urn:md5:16f97b812a4543b6712787fdb1c817e7 Dotclear Xfce 4.8 on BSD flavors urn:md5:fd534bd4d7e2652fd9c4ffe1b484c697 2011-01-19T17:29:00+01:00 Jannis Pohlmann BSDConsoleKitcross-platformopen sourceossPolicyKitportabilitypower managementthunarthunar-volmanudevudisksupowervolume managementxfcexfce48
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.
 http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors#comment-form http://gezeiten.org/feed/atom/comments/58 Xfce 4.8 released! urn:md5:27fbc3a3f3c6614b63d08e4e70af16c5 2011-01-17T00:31:00+01:00 Jannis Pohlmann communityconferencefosdemgioHALopen sourceossreleasessoftware developmentthunartransifextranslationsudsvolume managementxfcexfce48
Today, after almost two years of work, we have the special pleasure of announcing the much awaited release of Xfce 4.8, the new stable version that supersedes Xfce 4.6.

We hope that everyone will enjoy this release as much as we do. Sadly, this will not be the case as the folks using any of the BSD systems will notice a sudden loss of features. We think that this announcement is a good opportunity to express our disagreement with the recent "Linux-only" developments in the open source ecosystem, especially with regards to the utilities we need in desktop environments.

Xfce 4.8 is our attempt to update the Xfce code base to all the new desktop frameworks that were introduced in the past few years. We hope that our efforts to drop pieces like ThunarVFS and HAL with GIO, udev, ConsoleKit and PolicyKit will help bringing the Xfce desktop to modern distributions.

With Xfce 4.8 our users will be able to browse remote shares using a variety of protocols (SFTP, SMB, FTP and many more). The window clutter has been reduced by merging all file progress dialogs into a single one.

Our panel application has been rewritten, thereby improvingpositioning, transparency, item and launcher management. It also introduces a new menu plugin to view directories. Its plugin framework remains compatible with 4.6 plugins.

We also improved our settings dialogs. The display configuration dialog now supports RandR 1.2, detects screens automatically and allows our users to pick their favorite resolution, refresh rate, rotation. Screens can be configured to either work in clone mode or be placed next to each other. Keyboard selection has become easier and more user-friendly. Also, the manual settings editor has been updated be more functional.

Aside from the features implemented in Xfce, the 4.8 development cycle brought us a bunch of other goodies. For the first time we had a serious release strategy formed after the "Xfce Release and Development Model" developed at the Ubuntu Desktop Summit in May 2009. A new web application made release management a lot easier. We worked hard on improving the situation of Xfce translators which led us to setting up our own Transifex server. Something else you will hopefully notice is that our server and mirroring infrastructure has been improved so that our servers hopefully will not suddenly surrender shortly after this release announcement.

There is a lot more to discover and we hope a lot of you will give Xfce 4.8 a try! There is a brief tour online on

http://xfce.org/ and http://xfce.org/about/tour

A summary of the changes since the 4.8pre3 preview release is available on the following URL (it also includes links to the changes introduced in all preview releases):

http://xfce.org/download/changelogs/4.8.0

The release can be downloaded either as individual releases or as a fat tarball including all these individual versions:

http://archive.xfce.org/xfce/4.8/

2011 has just begun and we are already planning for the future. The 4.10 schedule will be worked on soon and hopefully, we will be able to turn Xfce into a non-profit organization at this year's FOSDEM, so stay tuned!

But until then we hope you will enjoy today's release and join us in celebrating. Thanks go out to all our contributors, bug reporters as well as the awesome efforts of our translators and packagers.

Best regards,
The Xfce development team
 http://gezeiten.org/post/2011/01/Xfce-4.8-released%21#comment-form http://gezeiten.org/feed/atom/comments/57 Xfce 4.8pre1 released! urn:md5:5a2e1b68d229199da342ec950c796619 2010-11-07T17:57:00+01:00 Jannis Pohlmann alacartebugsbugzillacommunitygioHALlibxfce4menulibxfce4uireleasesthunarthunar-volmantransifextranslationsudevxfcexfce48
Xfce 4.8pre1 is now available for download.

It includes the following releases of Xfce core components:

 exo 0.5.4 gtk-xfce-engine 2.6.0 libxfce4ui 4.7.4 libxfce4util 4.7.3 libxfcegui4 4.7.0 thunar 1.1.4 thunar-vfs 1.1.1 xfce-utils 4.7.1 xfce4-appfinder 4.7.1 xfce4-dev-tools 4.7.3 xfce4-panel 4.7.4 xfce4-session 4.7.1 xfce4-settings 4.7.4 xfconf 4.7.3 xfdesktop 4.7.2 xfwm4 4.7.1

Release tarballs can be retrieved from the following mirrors (please note that it may take a few hours for the mirrors to catch up):

 http://archive.xfce.org/xfce/4.8pre1/src http://www.tx-us.xfce.org/archive/xfce/4.8pre1/src http://www.p0llux.be/xfce/xfce/4.8pre1/src http://www.ca-us.xfce.org/archive/xfce/4.8pre1/src

A tarball including all individual releases can be downloaded here:

 http://archive.xfce.org/xfce/4.8pre1/fat_tarballs http://www.tx-us.xfce.org/archive/xfce/4.8pre1/fat_tarballs http://www.p0llux.be/xfce/xfce/4.8pre1/fat_tarballs http://www.ca-us.xfce.org/archive/xfce/4.8pre1/fat_tarballs

Release notes for 4.8pre1

The Xfce development team is proud to announce the first preview release for Xfce 4.8. Together with this preview release, the Xfce project announces the feature freeze for the final 4.8 release which is set to be pushed out to the world on January 16th, 2011.

This release incorporates major changes to the core of the Xfce desktop environment and hopefully succeeds in fulfilling a number of long time requests. Among the most notable updates is that we have ported the entire Xfce core (Thunar, xfdesktop and thunar-volman in particular) from ThunarVFS to GIO, bringing remote filesystems to the Xfce desktop. The panel has been rewritten from scratch and provides better launcher management and improved multi-head support. The list of new panel features is too long to mention in its entirety here. Thanks to the new menu library garcon (formerly known as libxfce4menu, but rewritten once again) we now support menu editing via a third-party menu editor such as Alacarte (we do not ship our own yet). Our core libraries have been streamlined a bit, a good examplle being the newly introduced libxfce4ui library which is meant to replace libxfcegui4.

Perhaps the most important achievement we will accomplish with Xfce 4.8 is that, despite suffering from the small size of the development team from time to time, the core of the desktop environment has been aligned with today's desktop technologies such as GIO, ConsoleKit, PolicyKit, udev and many more. A lot of old cruft like has been stripped from the core as well, as has happened with HAL and ThunarVFS (which is still around for compatibility reasons).

Thanks to the awesome Transifex translation platform, our language teams have been able to update their translations at an incredible pace. Please include them when praising this release!

A complete list of all changes since the latest stable release is available on

http://mocha.xfce.org/documentation/changelogs/4.8pre1

Below you will find download information for Xfce4.8pre1. Please give our mirrors a few hours to synchronize. We hope you will enjoy this release, feel encouraged to blog and tweet about it! Feedback is welcome in all forms. Bugs can be reported in our bug tracker as usual. We need your help to make Xfce 4.8 our best release ever!

Kind regards and thanks to everyone who has contributed to this release,

The Xfce development team
 http://gezeiten.org/post/2010/11/Xfce-4.8pre1-released%21#comment-form http://gezeiten.org/feed/atom/comments/52 Final exams, diplom thesis and thunar-volman urn:md5:4f86edebbd4f7d9f05653928da54151c 2010-07-17T14:25:00+02:00 Jannis Pohlmann diplomexamsgioreleasesstudiesthesisthumbnailsthunarthunar-volmantumblerudevuniversityvolume managementworkxfcexfce48
I guess it's time for an update.

This week I passed the last of four final exams in computer science and human-computer interaction at my university. Not only am I pleased that nine months of learning are over; I am also blessed with excellent grades. And while my understand of good grades is similar to that of money (nice to have it but nothing to focus on and/or brag with), I have to admit that this time I'm at least a little proud of myself. Five years at the university are slowly coming to an end, the first friends are leaving town and it will soon be time to take the next big step in life.

I cannot leave this city before writing another thesis, however. Thus, I am currently looking for a Diplom thesis at the university or at companies related to open source technologies. If you happen work for such a company with interesting thesis ideas or opportunities, please let me know. The thesis is supposed to take about 6 months, ideally starting early in September. After that it's time to pack my stuff and look for an employer. I'm hoping for a position in open source software development. Areas I'm particularly interested in include Linux, mobile computing, desktop-related technologies as well as renewable energy, environment protection and open government. I'm here to make a difference.

On to something else. A few weeks ago I was offered sponsoring in order to work on thunar-volman for a few days. I accepted the offer, so for the entire next week from 2010-07-19 to 2010-07-26 (including the weekend) I'll do some sponsored work on porting Thunar and thunar-volman to udev and GIO! The goal is to finish all major features (storage devices, cameras etc.).

Yesterday I did some warm-up hacking on tumbler to verify that if I'm still up to the task. The results: a new ffmpegthumbnailer-based video thumbnailer plugin (written by Lionel Le Folgoc), a new PDF/PostScript thumbnailer plugin based on poppler-glib and a new tumbler release (0.1.2). The master branch contains another commit adding arbitrary URI support to the PDF/PostScript thumbnailer but for that you'll have to wait until the next release.

That's it for now, I'll be a lot more active next week. Take care everyone!
 http://gezeiten.org/post/2010/07/Final-exams%3B-hacking-and-thunar-volman#comment-form http://gezeiten.org/feed/atom/comments/49 Xfce 4.8 Schedule Changes urn:md5:8105857b558716c0a7b42493fc36c79d 2010-01-26T01:30:00+01:00 Jannis Pohlmann communityDeviceKit-disksexogioHALidenticalibxfce4menulibxfce4uireleasesstudiesthunarthunar-volmanudevuniversityvolume managementworkxfcexfce4-settingsxfce46xfce48
As the Xfce release manager, I'd prefer to be the bringer of good news. Unfortunately, we have to make some adjustments with regards to the Xfce 4.8 release schedule.

You may well remember last year's chaos with the 4.6 release date. We're trying our best not to repeat that and if it should happen again, we'll at least keep you posted about the issues as good as we can.

So, what's the deal with 4.8?

One thing that hasn't changed much is that our development team is very small. A hobby project of this size requires a certain amount of time to be invested by each individual developer. Time not everyone has as much has he would like to dedicate to Xfce.

Today, Brian announced his absence for the coming months due to his new job, leaving 2-3 of our core components (xfdesktop, xfconf and xfce4-session) more or less unmaintained (aside from bugfixes). The good news is that Jérôme (who has recently started to improve xfce4-settings and port xfce4-session to libxfce4ui) and Daniel (the maintainer of the thunar-shares-plugin) have offered their help with xfdesktop and xfce4-session.

Brian is not the only one having little time at hand though. I'm preparing myself for my final university exams, so ideally I'd be sticking my nose into lecture notes all day long. I still have the time to write mails like this but there hasn't been much activity around thunar and related projects lately.

Again, I'm really happy to see people volunteering to help because that's what we need right now. There's a lot left to do before we can release 4.8. Let me get to that now.

As some of might have heard, thunar was ported to GIO this summer. Through GVfs, GIO brings new features such as SMB, SFTP, FTP browsing which some people use one a daily basis already. Now, GVfs has turned out to be problematic for us for various reasons. At first it shipped a HAL-based volume monitor with a hard-coded dependency on gnome-mount. Today it ships a volume monitor based on gnome-disk-utility (uses DeviceKit-disks itself) which proves to be inconsistent and somewhat incompatible to the HAL mounting code in exo.

The result: thunar-volman (not part of the core but important for thunar nonetheless) and xfdesktop will have to be ported to udev (the mounting being done with GIO, ideally). I've started working on this but this is far from being finished.

Question to the other developers: Didn't xfce4-session use HAL for logging out and stuff? We might have to look into replacing those portions of code with something based on ConsoleKit, I guess?

HAL/udev is not the only issue however. With Xfce 4.8 we'll be replacing libxfcegui4 with a new library called libxfce4ui. Not all core applications (again, xfdesktop being one of them, I think) have been ported to it yet. In most cases, this is no big deal and probably could be resolved within a few days though.

Then we have garcon, the much improved menu library that is supposed to replace libxfce4menu. At the time of writing the only feature it is lacking that is crucial for 4.8 is file system monitoring. We'll probably implement basic monitoring like we had in libxfce4menu. Work on this hasn't started yet.

Also, xfdesktop needs to be ported not only from ThunarVFS/HAL to GIO/udev but also from libxfce4menu to garcon.

So, as you can see there is quite a lot of work ahead of us. Taking into account the little free time some of us have these days, we've decided to postpone the 4.8 release until June 12th instead of April 12th. The entire release phase in our schedule has been moved by two months in time, as you can see on the official schedule wiki page:

 http://wiki.xfce.org/releng/4.8/schedule

To be honest, I wouldn't consider this new date fixed either. It all depends on how much we can do until the feature freeze on April 1st. I'm optimistic that meeting the deadlines is possible though.

For all of you who can't wait until June, try out our development releases which are announced on http://identi.ca/xfce. I have at least something good to share: For a few weeks now I've been running Fedora 12 with a mixture of Xfce 4.6 packages and development package from the upcoming 4.8 series and the new components have proven to be very stable already.

I'm especially happy about the new panel which works almost flawlessly (except for a few dual head issues) and not only supports real transparency and more comfortable launcher creation based on garcon, but is also compatible to panel plugins written for Xfce 4.6. (Good work, Nick!)

So, I guess this is it. A mixture of good and bad. I hope nobody is too disappointed. As always, we're doing the best we can.

Cheers!
 http://gezeiten.org/post/2010/01/Xfce-4.8-Schedule-Changes#comment-form http://gezeiten.org/feed/atom/comments/48 Thunar-volman and the deprecation of HAL in Xfce urn:md5:1377f59ba819ec72abc1b189b00cca78 2010-01-17T00:24:00+01:00 Jannis Pohlmann communityDeviceKit-disksexogioHALsurveythunarthunar-volmanudevudisksvolume managementxfcexfce48
Last week I started looking at thunar-volman (a program that performs certain actions when new devices are plugged in) with the goal to make it compatible with the latest release of thunar which uses GIO instead of ThunarVFS for almost everything that takes place under the hood.

Until now, volume management (monitoring and mounting) in Xfce was done through HAL, the hardware abstraction layer that is currently being deprecated and dropped by major distributions. The functionality previously provided by HAL has been moved into udev, udisks (formerly known as DeviceKit-disks) and upower (formerly known as DeviceKit-power).

Volume management is transparently supported by GIO, meaning that applications don't have to worry about the backend implementation. It should, in theory, not matter whether HAL is used or udev/udisks. Unsurprisingly, in reality, things are not that trivial, mainly for two reasons:

Due to its focus on file management, GIO only supports monitoring and detecting storage devices (DVD drives, USB sticks etc.). There is no way to be notified when e.g. a digital camera or a portable media player is plugged in. This is critical for the functionality of thunar-volman which until now supported everything from cameras, media players, blank CDs/DVDs, audio CDs, PDAs and printers to input devices like keyboards, mice and tablets.

Mounting volumes with udisks seems to be somewhat incompatible with HAL. I tried to mount volumes with thunar-volman and exo-mount (both implemented on top of HAL) and was for the root password upon unmounting in Thunar (using GIO and gnome-disk-utility/DeviceKit-disks). It seems like volumes mounted with HAL are assumed to be mounted by a different than the current user and thus, require root privileges to be unmounted.

HAL being deprecated and somewhat incompatible with udisks, what are the consequences for Xfce, and for thunar and thunar-volman in particular?

Let us, for a moment, assume Xfce 4.8 and thunar 1.0 were released as they are today, with thunar using GIO (and udisks instead of HAL in all major Linux distributions) and the rest (like thunar-volman and exo-mount) depending on HAL. As mentioned before, exo-mount and thunar wouldn't work together in multi-user setups. Thunar would no longer detect cameras, PDAs, audio CDs, blank disks, mice, keyboards, tablets, media players and thunar-volman would end up being completely useless, as it is not detecting devices by itself. I think it is safe to say that this is not what we want.

In the following, I will focus on how to deal with thunar-volman. The rest of Xfce faces a similar roadmap, however. With regards to thunar-volman, there are (at least) three sane options:

Drop thunar-volman and only support auto-mounting storage devices from now on, directly implemented in thunar. What is very obvious about this solution is that a lot of possibly useful functionality is lost.

Port thunar-volman to (g)udev/udisks/GIO and make it a standalone daemon so that thunar no longer has to spawn it when new devices are plugged in. The advantage of this approach is that thunar only needs to depend on GIO and doesn't have to implement the device detection part.

Port thunar-volman to (g)udev/udisks/GIO as described above and make thunar depend on (g)udev for device detection. Spawn thunar-volman when devices are added/removed. The advantage over the previous approach is that thunar-volman doesn't have to run permanently as a daemon. The additional thunar dependency on (g)udev could be seen as a disadvantage but on the other hand, it basically replaces another (HAL).

Now, everyone knows that programmers are lazy people. So, in the hope of being able to save some work, I started a survey on the usage of thunar-volman. The idea was to find out which of its features are used most and whether there are some that nobody really cares about. Here are the results:

 ======================================================================================= Feature #Users Percentage --------------------------------------------------------------------------------------- Mount removable drives when hot-plugged 86 92.5% Mount removable media when inserted 83 89.2% Browse removable media when inserted 69 74.2% Cameras: Import digital photographs when connected 31 33.3% Play video CDs and DVDs when inserted 31 33.3% Play audio CDs when inserted 30 32.3% Burn a CD or DVD when a blank disc is inserted 21 22.6% Portable Media Players: Play music files when connected 11 11.8% Auto-run programs on new drives and media 7 7.5% Automatically run a program when a printer is connected 7 7.5% Auto-open files on new drives and media 6 6.5% Sync Palm devices when connected 5 5.4% Automatically run a program when an USB keyboard is connected 3 3.2% Automatically run a program when an USB mouse is connected 3 3.2% Automatically run a program when a tabled is connected 2 2.2% Sync Pocket PC devices when connected 2 2.2% ======================================================================================= Thunar Volume Manager Usage Survey with 93 participants

According to the results of this survey, auto-mounting and browsing of removable drives and media have highest priority among the 93 participating thunar-volman users. This more or less covers the functionality we could cover with GIO alone (plus automatically running a program when new drives and media are inserted). However, a third of the users also use thunar-volman for importing photographs from digital cameras and for playing video and audio CDs as well as DVDs automatically. Almost a 25 percent of all users use thunar-volman to start their favorite burning software when a blank CD or DVD is inserted. Slightly more than 10 percent want thunar-volman to start playing music on portable media players when they are plugged in. Printers and Palms are also somewhat relevant.

This survey confirms my expectations that handling storage devices alone is not enough even though they clearly are the most important use case for thunar-volman. Our users seem to like the flexibility of thunar-volman and make use of it. This disqualifies option 1 and leaves us with options 2 and 3. I'm inclined to avoid another daemon and go for number 3.

In preparation for porting thunar and thunar-volman to udev/udisks/GIO, I've created a wiki page to collect information about how we can reliably distinguish the different device types based on udev properties: http://wiki.xfce.org/dev/thunar-volman-udev. If you have blue-ray disks, video CDs, a digital camera, a Pocket PC, a Palm, a USB printer or a graphics tablet, you could make me very happy if you inserted them or plugged them in and sent me the output of udevadm info --export-db to my Xfce email address together with a short hint what devices you've plugged in. Alternatively, you can paste/upload the output somewhere on the internet and comment on this blog post, and thereby help making future versions of Xfce better.

Cheers!
 http://gezeiten.org/post/2010/01/Thunar-volman-and-the-deprecation-of-HAL#comment-form http://gezeiten.org/feed/atom/comments/47 News From Busyland urn:md5:8065732ef9eee9047d8f778f7fede8c2 2009-11-25T16:29:00+01:00 Jannis Pohlmann conferencefosdemgioreleasesstudiestalksthesisthumbnailsthunartumbleruniversityxfcexfce48
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…
 http://gezeiten.org/post/2009/11/News-From-Busyland#comment-form http://gezeiten.org/feed/atom/comments/44 Things I Miss on Maemo urn:md5:0ea0ddea5763dfce1052bce6b4bf35cc 2009-11-01T13:25:00+01:00 Jannis Pohlmann giomaemothunartumblerui-design
After hacking on Tumbler for a while, I decided to install the Maemo SDK and see how Maemo runs in Xephyr. I have to say it runs nicely and I really like the interface. The three level zooming interface from application overview to window overview to panorama desktop works well for me. The conversations view and IM notifications make it easy to concentrate on what you want to do without being interrupted too much. I'm chatting with a friend via Jabber at this very moment. Running apps in parallel rocks too.

Now, I'm a rather unorganized person and I've always wanted to keep track of meetings and other events using some kind of tool in order to get them out of my head. So, after playing with the Maemo interface for a few hours, I'm considering buying an N900. I'd love to get it at a discount but that doesn't seem to be easy and I'm not sure my work on Tumbler for Harmattan qualifies enough for that.

Even though I'm considering the N900, there are things that I'd like to see improved. Here's a list of what I'd consider worth improving. I might even start hacking on one or two of them over the next weeks.

File Manager

The file manager is very basic. No typeahead and global search, no bookmarks, no remote file systems, weird label alignment. I tried running Thunar but its interface is too complex of course. It ran well though which makes me think that there is room for improvement. I could imagine a main view listing entries point on the built-in storage, the SD card and bookmarks (which would then be more than just local bookmarks, it could be anything from local to SFTP to SMB). GIO makes it easy. For the browsing interface something like the browser interface might be nice, except that there is no need for the URI input field. Instead, maybe one could make the bottom bar display the folder name.

Chat Rooms

Chat Rooms like on Jabber conference services don't seem to be supported. At least there's an open bug for it on bugs.maemo.org. I've been thinking about how this could be implemented without breaking out of the Maemo conversations concept too much. The best idea I came up with within a few minutes would be a separate Chats application where you can define chat rooms, plus a "New Chat" button in the conversations overview. The chats could then show up in the conversations overview and the only that would be different in chat rooms would be that there needs to be a way to show who's online in the room (maybe with privilege status). This could be done via the pull-down title menu or an additional button next to the smilies or send button, I guess.

I don't know about the internals and available APIs yet, so these ideas might be impossible to implement. Dunno yet.

eMail

I'm writing plain text mails only and it's really annoying that I have no control over newlines. This might be a problem with Xephyr, I'm not sure. Also, when replying to someone on a mailing list "- Original Message —" is not enough to mark quotes. I need at least the name of the original author there. This shouldn't be too hard to implement but of course I first need to find out whom to convince about this. ;)

So, these are just a few ideas. What do you think of them? The next step will be to find out how to get started, investigate what components and APIs are affected and whether these improvements (you may disagree here) are possible or not.

Cheers.
 http://gezeiten.org/post/2009/11/Things-I-miss-on-Maemo#comment-form http://gezeiten.org/feed/atom/comments/42 Using Tumbler in Client Applications urn:md5:7947ff4b058c2e0ef98d0a86755bc9b2 2009-10-30T00:50:00+01:00 Jannis Pohlmann D-Busfreedesktop.orgmaemothumbnailsthunartumblerxfcexfce48
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 (normal is 128x128px, large is 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)

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:

Started is emitted together with the request handle as soon as the service starts processing the URIs of the request.

Ready is 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.

Error is 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.

Finished is 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, GetFlavors and GetSchedulers. A SupportedChanged signal 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 GtkTreeView or 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.
 http://gezeiten.org/post/2009/10/Using-Tumbler-in-Client-Applications#comment-form http://gezeiten.org/feed/atom/comments/41 Design of the Thunar Progress Dialog urn:md5:6cd6307e10246e00036d14caf3867dd3 2009-09-14T03:21:00+02:00 Jannis Pohlmann communitythunarui-designxfcexfce48
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!
 http://gezeiten.org/post/2009/09/Design-of-the-Thunar-Progress-Dialog#comment-form http://gezeiten.org/feed/atom/comments/40 Xfce 4.8 Release Cycle Information urn:md5:0f0db4fa35378556c05c0a1f485c43a7 2009-09-13T19:51:00+02:00 Jannis Pohlmann communityexogiolibxfce4uireleasesthunarxfcexfce4-appfinderxfce4-settingsxfce48xfdesktop 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!
 http://gezeiten.org/post/2009/09/Xfce-4-8-Release-Cycle-Information#comment-form http://gezeiten.org/feed/atom/comments/39 Long Overdue Update urn:md5:e5a00c5c512fed2f7d9f60997b0c8a80 2009-09-08T01:17:00+02:00 Jannis Pohlmann buildbotcommunitygiohardwarereleasesstudiesthesisthunartransifextranslationsuniversityxfcexfce48
I haven't posted anything in a while, but I'm not complaining. The last month I've been mostly busy pretending to be busy. Ok, to be honest, that's not entirely true. Over at Xfce, we have achieved a lot in August:

We've moved all Xfce repositories (including the goodies) over to Git. Kudos to Brian for doing most of the work.

All Xfce translation updates are now submitted via Transifex. Thanks to the Transifex developers for all the support and for being such a friendly bunch. It amazes me that Dimitris, the founder of Indifex, is also active on our translations mailing list to support people!

The migration of the Thunar core to GIO is complete and has been merged into the main development branch. The overall delta was 2.9MB, although admittedly, a big part of that is due to the removal of ThunarVFS, so I can only take credit for about 16,000 of the 24,335 insertions and 6,000 of the 41,356 deletions.

We've kicked off the Xfce 4.8 development cycle on August 16th. The schedule and all other details are available on the wiki. Xfce 4.8 is scheduled for April 12th, 2010. Expect development releases of the various core components soon!

Other things I've been planning to blog about but didn't have the time to:

Samuel is still busy setting up Buildbot. With less time than he had hoped for at hands this might still take a while.

I was provided with a free Linutop 2 in June. I'd like to thank the Linutop company again for this gift! So far, I've only found the time to give it a few test boots but I'm planning to set it up as a Xfce test machine soon. Its limited hardware makes it much better platform than my rather powerful laptop and/or virtual machines for testing the speed and memory demand of Xfce.

My thesis is progressing slowly. I think I have at least 3/4 finished now. I'll keep you posted about the result. I'm hoping to kick off the six month learning phase for my final exams before October because a friend of mine is already waiting for me. ;)

 http://gezeiten.org/post/2009/09/Long-Overdue-Update#comment-form http://gezeiten.org/feed/atom/comments/38 Preview: Browsing SFTP with Thunar urn:md5:fff6b87bb67cf23ea1281627a4c444c9 2009-06-16T02:40:00+02:00 Jannis Pohlmann giothesisthunartumblerxfcexfce48
It feels like I'm finally getting somewhere. My GIO migration branch of Thunar now generates thumbnails using the D-Bus service provided by Tumbler (which is still in development but almost ready for a release). It has no references to ThunarVFS anymore, except for one function required by Thunarx, the Thunar extension library. The next step will be to prepare thunarx-2 with a ThunarVFS-free API. All plugins shipped with Thunar itself need to be updated. ThunarVFS will be moved out of the Thunar tarball and into its own, so that applications depending on it will still work. And then we only need to fork the HAL based volume monitor from GVfs and of course thunar-volman needs to be rewritten on top of GIO ...

Anyway, just a few moments ago, I did something I thought is worth sharing: I browsed one of our servers remotely over SFTP! Mounting still needs to be done from the terminal but after that, you can simply type in the SSH or SFTP URI and it will display its contents. Thumbnails are generated over D-Bus. Here's a screenshot:

Update

Thunar can now mount remote URIs on demand:

FTP browsing also works:

 http://gezeiten.org/post/2009/06/Preview%3A-Browsing-SFTP-with-Thunar#comment-form http://gezeiten.org/feed/atom/comments/34 News Update urn:md5:4b0816e82dc70b29fd2cd47e887cf3f1 2009-06-05T01:25:00+02:00 Jannis Pohlmann buildbotconferencemaemoreleasesristrettothesisthunartransifextranslationstravellingtumblerudsuniversityworkxfcexubuntu
A lot of things are going on lately and it turns out I'm way to busy to update my weblog on a regular basis. So, this is just a short post to keep you all updated.

Last two weeks

I took a new student job at the university, at the Institute of Theoretical Computer Science, which I love most. I'll be working on haplotyping algorithms.

I went to Barcelona and had a great time at the Ubuntu Developer Summit overall. Stephan and I were very productive. One evening during dinner we discussed our development and release process and later started writing it down. The result is a beautiful document that still needs a bit of polishing. I hope it'll serve as a good foundation for the development and release process of Xfce in the future. Several others commented on it and it looks like we'll give the proposed concept a shot after we've switched to git and all that.

Even though the week in Barcelona was great for Xfce, I was disappointed with how it went with regards to the cooperation between Xubuntu and Xfce. I talked it through with Stephan and after I got back, I resigned from my position as the Xubuntu Xfce4 Liaison.

At the moment

I've started to implement the so-called thumbnail management D-Bus specification. My implementation is called Tumbler and it will hopefully start serving thumbnails for other apps soon. I'm planning to use it in Thunar, Stephan has expressed interest in using it in Ristretto and when discussing the specification and the existing hildon-thumbnail implementation, Philip van Hoof told me that Hildon/Nokia might be interested in dropping hildon-thumbnail in favor of Tumbler if it's flexible enough. I'm working on it as much as I can and I'm hoping to do a release within the next few weeks.

I'm still working on the Transifex installation for Xfce. It's already running but I still need to import all the projects, releases and of course create accounts for maintainers automatically.

The migration of Xfce to Git is still work in progress. Brian has most of the repository issues sorted out and is now waiting for me to finish the commit mail script. I have two or three possible implementations lying around but I need to have a look at that again.

Jim needs the documentation repository next week, so I'm about to set it up.

Our Buildbot server has arrived in Sweden. Today I set up the firewall. Samual is taking care of setting up the Buildbot host VM and other things. We're considering to move a lot of the services not related to development (like the Xfce websites) into separate VMs on that server too, in order to make the current server a development-only machine.

Besides that I'm trying to catch up with the work and personal stuff that piled up while I was away last week. And I really should go and sleep.
 http://gezeiten.org/post/2009/06/News-Update#comment-form http://gezeiten.org/feed/atom/comments/32 Another Thunar/GIO Status Update urn:md5:4a85e5d61eb3dee00f411e4b4d168c83 2009-05-01T02:44:00+02:00 Jannis Pohlmann giostudiesthesisthunarxfce
I'm more or less done with migrating the volume management code in Thunar to GIO. As of today there's not a single reference to ThunarVfsVolume or ThunarVfsVolume manager in Thunar anymore. While that is pretty neat and another thing I can mark as (almost) done, there are a few quirks also:

There's no way to find out whether a volume is removable or not. Actually, there are APIs for that but they don't seem to yield reasonable results for any of my USB and DVD drives.

GIO doesn't handle repeatedly issued mount requests too well. If you try mounting a DVD volume several times in a row, you'll end up G_IO_ERROR_FAILED errors exposing private D-Bus error messages. That's nothing the user should be bothered with but unfortunately there's no way to avoid this. G_IO_ERROR_FAILED is an error type you normally want to display. I think in this case raising a G_IO_ERROR_PENDING would be more appropriate.

So what's next? I'll just pick the list from my last post because I'm lazy:

Move the thumbnail related code into exo.

Load ThunarFile objects asynchronously. This will be a pain. A lot of functions will have to be split up to fit into the asynchronous concept.

Migrate Thunarx to GIO.

Migrate thunar-volman to GIO.

Integrate functionality similar to Gigolo (remote/virtual places management) into the file manager.

Write GNOME-independent GIO extensions for volume management and the trash.

I'm not so sure I want to load ThunarFiles asynchronously. It'll only work in some situations anyway. However, the possibility of the loading process blocking the GUI is quite high, especially with remote mounts. I guess the next thing I'll work on (next week) is moving thumbnailing out of Thunar and into exo.

Oh, by the way, here are some boring stats of my work in the past four weeks:

 thunar/Makefile.am | 44 +- thunar/main.c | 8 + thunar/thunar-abstract-icon-view.c | 4 - thunar/thunar-application.c | 655 +++++++-------- thunar/thunar-application.h | 25 +- thunar/thunar-chooser-button.c | 131 +-- thunar/thunar-chooser-dialog.c | 232 +++--- thunar/thunar-chooser-model.c | 450 +++------- thunar/thunar-chooser-model.h | 23 +- thunar/thunar-clipboard-manager.c | 53 +- thunar/thunar-clipboard-manager.h | 3 +- thunar/thunar-create-dialog.c | 155 ++-- thunar/thunar-create-dialog.h | 25 +- thunar/thunar-dbus-service.c | 47 +- thunar/thunar-debug.c | 4 - thunar/thunar-deep-count-job.c | 373 ++++++++ thunar/thunar-deep-count-job.h | 48 + thunar/thunar-details-view.c | 20 - thunar/thunar-dialogs.c | 100 ++- thunar/thunar-dialogs.h | 42 +- thunar/thunar-dnd.c | 21 +- thunar/thunar-enum-types.c | 57 ++ thunar/thunar-enum-types.h | 56 ++ thunar/thunar-file.c | 1455 +++++++++++++++++++++++-------- thunar/thunar-file.h | 309 ++----- thunar/thunar-folder.c | 192 +++-- thunar/thunar-gio-extensions.c | 355 ++++++++ thunar/thunar-gio-extensions.h | 63 ++ thunar/thunar-gtk-extensions.c | 4 - thunar/thunar-icon-factory.c | 13 +- thunar/thunar-io-jobs-util.c | 139 +++ thunar/thunar-io-jobs-util.h | 36 + thunar/thunar-io-jobs.c | 1074 +++++++++++++++++++++++ thunar/thunar-io-jobs.h | 54 ++ thunar/thunar-io-scan-directory.c | 123 +++ thunar/thunar-io-scan-directory.h | 37 + thunar/thunar-job.c | 1001 +++++++++++++++++++++ thunar/thunar-job.h | 112 +++ thunar/thunar-launcher.c | 521 +++++++----- thunar/thunar-list-model.c | 155 ++-- thunar/thunar-location-button.c | 29 +- thunar/thunar-location-buttons.c | 31 +- thunar/thunar-location-entry.c | 151 +++- thunar/thunar-marshal.list | 4 + thunar/thunar-metafile.c | 42 +- thunar/thunar-metafile.h | 5 +- thunar/thunar-path-entry.c | 65 +- thunar/thunar-permissions-chooser.c | 263 +++--- thunar/thunar-preferences-dialog.c | 103 +-- thunar/thunar-preferences.c | 71 +- thunar/thunar-progress-dialog.c | 152 ++-- thunar/thunar-progress-dialog.h | 7 +- thunar/thunar-properties-dialog.c | 108 ++-- thunar/thunar-renamer-dialog.c | 20 +- thunar/thunar-renamer-model.c | 11 +- thunar/thunar-sendto-model.c | 196 ++--- thunar/thunar-shortcuts-icon-renderer.c | 45 +- thunar/thunar-shortcuts-model.c | 433 +++++----- thunar/thunar-shortcuts-view.c | 594 +++++++++---- thunar/thunar-simple-job.c | 223 +++++ thunar/thunar-simple-job.h | 64 ++ thunar/thunar-size-label.c | 81 +- thunar/thunar-standard-view.c | 212 +++--- thunar/thunar-templates-action.c | 7 +- thunar/thunar-text-renderer.c | 19 - thunar/thunar-transfer-job.c | 888 +++++++++++++++++++ thunar/thunar-transfer-job.h | 60 ++ thunar/thunar-trash-action.c | 9 +- thunar/thunar-tree-model.c | 280 ++++--- thunar/thunar-tree-view.c | 730 ++++++++++------ thunar/thunar-user.c | 833 ++++++++++++++++++ thunar/thunar-user.h | 88 ++ thunar/thunar-util.c | 105 ++- thunar/thunar-util.h | 16 +- thunar/thunar-window.c | 274 +++--- 75 files changed, 10491 insertions(+), 3947 deletions(-)

The overall size of the patch is 844kb already.
 http://gezeiten.org/post/2009/05/Another-Thunar/GIO-Status-Update#comment-form http://gezeiten.org/feed/atom/comments/29 Thunar/GIO - Quick Status Report urn:md5:086f06df60dc41f8204de3eb66568419 2009-04-24T01:27:00+02:00 Jannis Pohlmann giostudiesthesisthunarudsxfcexubuntu
I've started hacking on the migration of Thunar to GIO on April 9th. In about 61 commits, I've reduced the original number of ThunarVFS references in the Thunar source code dramatically. The most important and probably most time-consuming part of this work is only mentioned briefly on those pages: rewriting all recursive copy/move/trash/restore/chmod/chgrp/chown jobs -- by now most of the jobs have been rewritten based on GIO and the new ThunarJob framework ... and Thunar still works (for me at least)!

All in all, I suppose that about a third of the implementation work is done. Ok, maybe just a quarter, but an important one. I now have a very good overview over the source code and I'm almost done with one of the most critical parts of the migration.

If you want to know how that looks like for me, here's a screenshot:

These are the most important/big things that are still waiting for me:

Replace ThunarVFSVolumeManager with GFileMonitor. Volume management is a large and complex subsystem of both ThunarVFS and GIO.

Load ThunarFile objects asynchronously. This will be a pain. A lot of functions will have to be split up to fit into the asynchronous concept.

Move the thumbnail related code into exo

These two are a bit out of scope but very important nonetheless:

Integrate functionality similar to Gigolo (remote/virtual places management) into the file manager.

Write GNOME-independent GIO extensions for volume management and the trash.

On a side node: Xubuntu 9.04 is available as of today! Go and grab it if you're interested in a nice distro based on Xfce. If you're interested in the Xubuntu development, you'll be able to meet Stephan, several Xubuntu folks and me at the Ubuntu Developer Summit in Barcelona from May 25th-29th. I'm very excited already!
 http://gezeiten.org/post/2009/04/Thunar/GIO-Quick-Status-Report#comment-form http://gezeiten.org/feed/atom/comments/28 Writing Your Own GIO Jobs urn:md5:0f8174ed8a7ce207b3b4dc12f41c83dc 2009-04-07T03:00:00+02:00 Jannis Pohlmann giothesisthunaruniversityxfce
After having moved into a new apartment I'm now back at working on my thesis about Thunar. There are a few things which are solved very differently in GIO than in ThunarVFS. One of them is the way jobs are handled. A job basically is a task which may take a while to run and thus is executed in a separate thread (so it doesn't block the GUI).

ThunarVFS has a framework called ThunarVfsJob. It lets you create different kinds of jobs e.g. for changing file permissions recursively or for computing the total number of files and the total size of a directory. These jobs report back to the GUI thread using signals such as "new-files" (when new files are added and need to picked up by the GUI) or "progress".

GIO has something similar ... but it's not so obvious how it works. When I tried to figure out how to migrate ThunarVfsJob to GIO I thought: hey, GIO must have something like this already! It contains several job-like functions such as g_file_copy_async() after all.

So here's what I found out after spending some time on reading gfile.c and glocalfile.c: there is a job framework in GIO ... but it's hidden behind easy-to-use asynchronous functions. It's based on GCancellable, GAsyncResult and a bunch of callback types. It uses GIOScheduler internally to glue everything together to something that is actually pretty convenient (but still kinda tricky).

So, what do you need in orderto write your own jobs in the GIO style?

First of all, you need an example task. I picked counting files and computing the total size of a directory to understand how it works. What we want is an asynchronous function which does exactly that and uses a callback to report the progress back to the GUI thread ... just like g_file_copy_async() does.

First of all, you define the callback type and two functions for starting the job (sync and async version):

The Public API

typedef void (*GFileCountProgressCallback) (goffset current_num_files, goffset current_num_bytes, gpointer user_data); static gboolean g_file_deep_count (GFile *file, GCancellable *cancellable, GFileCountProgressCallback progress_callback, gpointer progress_callback_data, GError **error); static void g_file_deep_count_async (GFile *file, int io_priority, GCancellable *cancellable, GFileCountProgressCallback progress_callback, gpointer progress_callback_data, GAsyncReadyCallback callback, gpointer callback_data);

The Implementation

All the function g_file_deep_count_async() will do is to create a GSimpleAsyncResult, put the callback information into it and then tell the GIOScheduler to run the job. Here's how that looks like:

static void g_file_deep_count_async (GFile *file, int io_priority, GCancellable *cancellable, GFileCountProgressCallback progress_callback, gpointer progress_callback_data, GAsyncReadyCallback callback, gpointer callback_data) { GSimpleAsyncResult *result; DeepCountAsyncData *data; g_return_if_fail (G_IS_FILE (file)); data = g_new0 (DeepCountAsyncData, 1); data->file = g_object_ref (file); data->progress_cb = progress_callback; data->progress_cb_data = progress_callback_data; result = g_simple_async_result_new (G_OBJECT (file), callback, callback_data, g_file_deep_count_async);

 g_simple_async_result_set_op_res_gpointer (result, data, (GDestroyNotify) deep_count_async_data_free); g_io_scheduler_push_job (deep_count_async_thread, result, g_object_unref, io_priority, cancellable); }

DeepCountAsyncData is a simple struct which needs no further explanation, I think. First data with callback and user data information is added to the GSimpleAsyncResult and then the job is added to the GIOScheduler. As you can see, there is another function involved: deep_count_async_thread. This is the function which runs in a separate thread and does most of the work (well, not quite ... but almost). Here's how it looks like:

static gboolean deep_count_async_thread (GIOSchedulerJob *job, GCancellable *cancellable, gpointer user_data) { GSimpleAsyncResult *res; DeepCountAsyncData *data; gboolean result; GError *error = NULL; res = user_data; data = g_simple_async_result_get_op_res_gpointer (res); data->job = job; result = g_file_deep_count (data->file, cancellable, data->progress_cb != NULL ? deep_count_async_progress_callback : NULL, data, &error); if (data->progress_cb != NULL) g_io_scheduler_job_send_to_mainloop (job, (GSourceFunc) gtk_false, NULL, NULL); if (!result && error != NULL) { g_simple_async_result_set_from_error (res, error); g_error_free (error); } g_simple_async_result_complete_in_idle (res); return FALSE; }

As you can see it runs the synchronous function g_file_deep_count() and makes sure the progress callback is called at least once. It does one more thing though: it defines it's own progress callback: deep_count_async_progress_callback. This is required for the real progress callback to be called inside the GUI thread. This is the code for the internal callback:

static gboolean deep_count_async_progress_in_main (gpointer user_data) { ProgressData *progress = user_data; DeepCountAsyncData *data = progress->data; data->progress_cb (progress->current_num_files, progress->current_num_bytes, data->progress_cb_data); return FALSE; } static void deep_count_async_progress_callback (goffset current_num_files, goffset current_num_bytes, gpointer user_data) { DeepCountAsyncData *data = user_data; ProgressData *progress; progress = g_new (ProgressData, 1); progress->data = data; progress->current_num_files = current_num_files; progress->current_num_bytes = current_num_bytes; g_io_scheduler_job_send_to_mainloop_async (data->job, deep_count_async_progress_in_main, progress, g_free); }

deep_count_async_progress_callback() is called from within the job thread. It then tells the scheduler to call deep_count_async_progress_in_main from the GUI thread. And finally deep_count_async_progress_in_main calls the real progress callback e.g. to update the GUI.

Now you still haven't seen any code related to counting files and computing the total file size of a directory ... let's get to that now. Here's the synchronous deep count function which is called from within the job thread:

static gboolean g_file_deep_count (GFile *file, GCancellable *cancellable, GFileCountProgressCallback progress_callback, gpointer progress_callback_data, GError **error) { ProgressData data = { .data = NULL, .current_num_files = 0, .current_num_bytes = 0, }; g_return_val_if_fail (G_IS_FILE (file), FALSE); if (g_cancellable_set_error_if_cancelled (cancellable, error)) return FALSE; return g_file_real_deep_count (file, cancellable, progress_callback, progress_callback_data, &data, error); }

Damn ... it still doesn't do any real work! Ok, but this time there's no big rat-tail of nested function calls anymore, I promise. There's just one function left: g_file_real_deep_count(). Before we can call it, however, g_file_deep_count() has to initialize the progress data. After that we can call g_file_real_deep_count() recursively and do something useful. Here we go:

static gboolean g_file_real_deep_count (GFile *file, GCancellable *cancellable, GFileCountProgressCallback progress_callback, gpointer progress_callback_data, ProgressData *progress_data, GError **error) { GFileEnumerator *enumerator; GFileInfo *info; GFileInfo *child_info; GFile *child; gboolean success = TRUE; g_return_val_if_fail (G_IS_FILE (file), FALSE);

 if (g_cancellable_set_error_if_cancelled (cancellable, error)) return FALSE; info = g_file_query_info (file, "standard::*", G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS, cancellable, error); if (g_cancellable_is_cancelled (cancellable)) return FALSE; if (info == NULL) return FALSE; progress_data->current_num_files += 1; progress_data->current_num_bytes += g_file_info_get_size (info); if (progress_callback != NULL) { /* Here we call the internal callback */ progress_callback (progress_data->current_num_files, progress_data->current_num_bytes, progress_callback_data); } if (g_file_info_get_file_type (info) == G_FILE_TYPE_DIRECTORY) { enumerator = g_file_enumerate_children (file, "standard::*", G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS, cancellable, error); if (!g_cancellable_is_cancelled (cancellable)) { if (enumerator != NULL) { while (!g_cancellable_is_cancelled (cancellable) && success) { child_info = g_file_enumerator_next_file (enumerator, cancellable, error); if (g_cancellable_is_cancelled (cancellable)) break; if (child_info == NULL) { if (*error != NULL) success = FALSE; break; } child = g_file_resolve_relative_path (file, g_file_info_get_name (child_info)); success = success && g_file_real_deep_count (child, cancellable, progress_callback, progress_callback_data, progress_data, error); g_object_unref (child); g_object_unref (child_info); } g_object_unref (enumerator); } } } g_object_unref (info); return !g_cancellable_is_cancelled (cancellable) && success; }

And that's it. We can now compute the number of files and the total size of a directory recursively using a GCancellable and one or two callbacks. All of this is done using threads, so you don't have to worry about blocking your GUI main loop.

If you want to see this in action, visit the job framework page in my thesis wiki and download deepcount.c and the Makefile.
 http://gezeiten.org/post/2009/04/Writing-Your-Own-GIO-Jobs#comment-form http://gezeiten.org/feed/atom/comments/27 Thesis: Migrating Thunar to GIO urn:md5:2f41aa7ec135f00d2e2953412471fc50 2009-03-20T17:43:00+01:00 Jannis Pohlmann giostudiesthesisthunarxfcexfce48
I've semi-officially (whatever that means) started working on my thesis on migrating Thunar from ThunarVFS to GIO. I'll work on it in public. That means research material, testing results, status reports and of course the code will be publically available in a read-only wiki and our Subversion repository in a special branch respectively.

I'm always open to suggestions and opinions. Just drop me a mail if you have something to say.

If everything goes as planned (err, did I really sayplanned?) GIO will land in Thunar 1.2 which is supposed to be released along with Xfce 4.8. There's no warranty for this though.
 http://gezeiten.org/post/2009/03/Thesis%3A-Migrating-Thunar-to-GIO#comment-form http://gezeiten.org/feed/atom/comments/25 A Day Like Any Other urn:md5:ee4c3223092c8d51b7c06c9043f2c29b 2009-03-14T04:26:00+01:00 Jannis Pohlmann donationsthunarxfce
After having finished watching Barfly, I kinda felt like I had to sum up the day. It went like this:

Wake up hungover at noon

Raise 265€ during the day with a call for Xfce server donations

Buy groceries and have breakfast at 6pm

Work out at the gymn

Eat pizza

Review and commit a patch

Watch Barfly

Finish the day with a glass of Redbreast 12 Years Old

That's it.

There won't be many days like this in the next few weeks. I'm about to move in with a friend of mine at the beginning of next month. I'm going to start working on my thesis about Thunar next week. I still have a voluntary oral exam in software verification ahead of me in 12 days (I think ...) and of course I need to find someone to take over the appartment I'm currently living in. Lots and lots of things to keep me more than busy.
 http://gezeiten.org/post/2009/03/A-Day-Like-Any-Other#comment-form http://gezeiten.org/feed/atom/comments/22 Topics raised at UDS urn:md5:4ccd85b438c8a1cbb795a0e6a5f868b8 2008-12-24T14:42:00+01:00 Jannis Pohlmann buildbotconferencegiogstreamernetbookspulseaudiothunartravellingudsxfcexubuntu
Ok, this post is long overdue and has been around as a draft for more than a week now, so here it is. As readers of this weblog already know, I was at the Ubuntu Developer Summit from December 8th to 12th. We had quite a few discussions on topics I'm interested in outside the scope of the official sessions held at UDS. Let me just list them here in random order:

Buildbot

Arnaud Quette told me about Buildbot which can be used to test your repository for compilation errors on various systems. I suppose it can be a real time saver if you want your project to compile on a variety of distributions and UNIX flavors and want immediate response as to whether compilation is going to succeed on these. That way you don't have to wait for packagers and users to report compilation errors back to you and don't have to enter that typical ping pong developer-reporter dialog. Buildbot not only catches compilation errors but is also capable of sending notification emails and provides detailed information about the compile log and so on. It's implemented based on a server/client concept where each client tests compilation on one system and the server collects data from the clients. By using virtualization you can set up server and clients on the same machine. This would be very nice to have for Xfce but I suppose it would require another dedicated server just for running all these compilations. If anyone is interested in looking in to that, I'd be happy to establish contact to someone from Buildbot to provide you with more information. As a funny coincidence, Frédéric Péters recently announced build.gnome.org which is a great example of Buildbot usage.

Thunar and GIO

I talked to Christian Kellner about GIO/GVfs a bit in order to get information on how remote/virtual filesystems work. One thing I've thought about is how to allow for a list of user-defined remote/virtual filesystems which show up in the side pane of Thunar. There are different approaches to that. One is to use bookmarks which seems to be what, according to Christian, Nautilus does right now. While this seems to work quite well it seems to confuse users a bit. Personally, I'd like to see them separated from bookmarks. There has been a proposal for Nautilus to make the side pane look better by using sections. One thing I could imagine would be to have a "Virtual Volumes" section listing the user-defined filesystems and provide some sort of GUI for creating/removing/editing these. From what I've heard there also is a third approach, which is to make remote filesystems to appear as fake volumes in HAL or DeviceKit. I'll have to look into that in order to decide what the best way to go is, I guess.

PulseAudio and GStreamer

PulseAudio and GStreamer: We discussed the limited PulseAudio backend for GStreamer in a group of up to five people and agreed that it really needs improvement (as in more tracks have to be added to the GstMixer interface) if we don't want users to be able to control PulseAudio through the mixer applications they know. PulseAudio-specific applications like pavucontrol are not really what we want them to use.

Xubuntu Remix for Netbooks

During one of the Xubuntu sessions I talked to a member of the Ubuntu Mobile team about Xfce in general, the modularity of Xfce and the dependencies it has. He seemed to be very interested in it but he was also worried about Xfce becoming less lightweight, eating up more memory and disk space. It wasn't the first time during UDS that someone mentioned LXDE and asked me about my opinion on it. Two main reasons for Xfce being lightweight always were the small number of dependencies and applications which you could call the Xfce stack. With more and more applications and libraries being added, Xfce naturally feel less lightweight, even if these applications are not considered a part of the core desktop. You always have to keep that in mind. It seems like the high modularity of Xfce compensates parts of that and is why people are interested in Xfce in the context of mobile devices. Despite being modular and somewhat lightweight, Xfce also has improved in terms of user experience lately. I think we can push this even further. Giving accessibility more attention might also be worth considering. Usability is something I don't really see in LXDE (yet). That's what I usually tell people if they ask me for my opinion on it.
 http://gezeiten.org/post/2008/12/Topics-raised-at-UDS#comment-form http://gezeiten.org/feed/atom/comments/5


text:
BACK IN THE 1970s when ABC created "Monday Night Football," the network introduced a lawyer named Howard Cosell to its team of announcers. During the 14 years Howard blustered his way through games, he was often named America's most popular football announcer. He was also often named America's least popular football announcer.
Love him. Hate him. Sometimes both … at the same time.
Pittsburgh Pirates fans can identify. Pittsburgh third baseman Pedro Alvarez can amaze with his prestigious blasts out of any part of any ballpark in the major leagues.
But he can also infuriate with his lack of production — especially at the plate — often failing when just making contact could produce a key run — something he absolutely must do, especially as the team's cleanup hitter.
He's one of those players gifted with the ability to "carry a team on his back" when the streaky hitter is hot. But he also one of those players weighted down with the consequences of those interminable cold spells — which have happened far too often this year.
Make no mistake about it: The Bucs need Alvarez to be an offensive force — especially when his defensive shortcomings happen with such unacceptable frequency. So removing him from the lineup is difficult; can you justify sitting a player who socked 36 homers and knocked in 100 teammates last year, even with a league-leading 186 strikeouts.
But after Alvarez's first 42 games this season, manager Clint Hurdle had seen enough. He dropped Alvarez to sixth in the batting order and bluntly explained why.
"The production hasn't matched up with the opportunities," Hurdle said of his third baseman.
Alvarez drove in 24 runs in the cleanup spot. But 15 of those came on his eight home runs.
Post-Gazette writer/stats guru says that nobody in the National League has seen more runners on base than Alvarez. Of the 162 runners on base when Alvarez came to bat in those 42 games, he drove in 17 of them. Only Toronto's Edwin Encarnacion saw more mates on base (164), and he drove home 26 of them.
In 42 games, Alvarez drove in a run 10.5 percent of the time, 136th out of 174 major-league regulars. The best? Detroit's Miguel Cabrera (29.3 percent of the time).
O'Neill also gave the stats for the rest of the Pirates' semi-regulars, with a minimum overall 72 plate appearances: Russell Martin (20.9 percent), Tony Sanchez (17.9), Andrew McCutchen (16.1), Ike Davis (14.8), Josh Harrison (14.3), Walker (13.3), Travis Snider (12.3), Jose Tabata (11.4), Alvarez (10.5), Starling Marte (10), Gaby Sanchez (9.7) and Jordy Mercer (5.5).
Alvarez drove in 14.8 percent of runners last season. O'Neill says that percentage this year would have added seven more runs for the Pirates' sluggish offense.
Davis moved into the number four slot, as his May figures made the Alvarez move possible. "[The change is] to provide more consistency through the lineup. It's been seven weeks," Hurdle said of Alvarez's missed opportunity. "Pedro and I chatted. I just feel it's time, given Ike's work over the last three weeks—and this is not a new situation for him."
Davis, who has hit .328 in 19 games this month, predominantly batted cleanup with the Mets; in 173 career games in that slot, he hit .240, with 42 homers and 112 RBIs, O'Neill recounted.
"We're not even looking for power [from the position], but the quality of the at-bat," Hurdle said." And the Bucs did have success last September with Justin Morneau batting fourth, even though he went homerless with the Pirates.
There is no doubt that Alvarez can do it; he simply hasn't done it—consistently.
Still, Alvarez will get $20 million minimum from a team in New York City when he becomes a free agent after the 2016 season.
Can the Bucs afford to pay him? Can they afford not to pay him?
He most assuredly poses a dilemma for management as they ponder the future. The have — at most — two and one-half years to decide.
Jim Sankey is a baseball columnist for The Allied News.

subset: commoncrawl


text:
Sign up for Yardbarker's daily Top 10 newsletter, the Morning Bark! Customize to get news on your favorite sports and teams.
Found November 01, 2013 on Razzball:
PLAYERS: Yordano Ventura, Sammy Davis
We're gonna try something different today. We're not going to talk about a lot of extraneous shizz. We're gonna talk about Yordano Ventura. We're not going to talk about Ruben Studdard on The Biggest Loser and how his rolls have rolls while wishing he had a Rolls. We're not going to talk about the newest season of The Voice and how Christina's coaching style is to sing the songs better than the singtestants, how Blake and C. Lo can't sing worth a lick and how Adam just purses his lips like Zoolander. We're not going to talk about the new Drake album and how I've listened to it on repeat for the last three weeks. The Language is my jammie jam! No, we're not going to talk about any of that. We're especially not gonna talk about how I'm getting married tomorrow. HOLY EFFIN EFF ARE WE NOT GOING TO TALK ABOUT THAT! Can we never talk about that? Is it too late to run off to Miami and be with Giancarlo forever and ever amen? We...
Original Story: http://razzball.com/yordano-ventura-2...
What do you think?To leave a comment, you can:
All Sports News
Delivered to your inbox
You'll also receive Yardbarker's daily Top 10, featuring the best sports stories from around the web. Customize your newsletter to get articles on your favorite sports and teams. And the best part? It's free!
Follow us on Twitter
THE HOT 10: Who's Trending
|Latest Rumors
|Best of Yardbarker
Today's Best Stuff
For Bloggers
Join the Yardbarker Network for more promotion, traffic, and money.
Company Info
What is Yardbarker?
Yardbarker is the largest network of sports blogs and pro athlete blogs on the web. This site is the hub of the Yardbarker Network, where our editors and algorithms curate the best sports content from our network and beyond.


text:
You have no items in your shopping cart.
Stay up to date with style tips, trends and new arrivals!
* Required Fields
See what Halsbrook pairs it with
Availability: In stock
Keep it simple and chic in this bright white casual summer jacket from 'S MaxMara. In easy-to-wear and easy-to-clean diagonal weave stretch cotton, it offers fresh summer style with a slightly a-line shape body, a sweet shirt collar, and casual patch pockets. Pair it with its matching pant for a polished daytime look.
Share with friends