Apache restart with Vim autocmd
In order to execute a command right after saving a file in Vim, you can use the :autocmd command. Here is a quick example how it can be useful with Apache files.NB: on my system, Debian in this case, an Apache file is automatically recognized as filetype=apache.
augroup apache
autocmd BufWritePost */sites-enabled/* !/etc/init.d/apache2 restart
augroup END
How to start contributing to Xfce or any other open source project
It’s been a while since I’ve updated this website and even longer since I’ve written anything useful. But since I’ve received a couple of mails from people looking to contribute to Xfce recently, I thought I’d share some “wisdom” acquired over the past few years while working on Xfce and doing a lot of community work. My thoughts are not limited to Xfce and will apply to a lot of other projects out there as well.
Here’s the bitter truth for those looking for some quick pointers to start contributing to Xfce: you’ll have to find out yourself.
The reason is not that we are lazy or wouldn’t welcome your contributions. In fact, the reason, I believe, is very simple: you will be more excited, motivated and, ultimate, be more successful if you work on something that interests you. We can help you in making the decision what to invest your time in easier, e.g. by listing projects, features or issues that we or our users consider worth working on. Some projects do this very visibly (e.g. through bounties). In Xfce, this information is hidden in the depths of the wiki. Here are a few links that you may find interesting:
- Design SIG - working on improving the user experience of Xfce
- Component wish list - populated by our users
- Panel plugin wish list - populated by our users
Clearly, the above information could be more visible. There could be a prominent link on the Xfce website to a well-maintained and up-to-date list. Would that help people? Maybe.
Perhaps it is a good thing that the information isn’t just one click away. Open source projects have always been about scratching your own itch. This is how I got involved in everything I’ve done over the years. this approach is reflected by what people do and sometimes even by how companies make money. Thinking about it now, it is a concept deeply rooted in the evolution of mankind (think: the invention and improvement of tools, industrialisation and all that shit).
So: scratch your own itch.
If you want to start contributing to a project, try this exercise:
- Look at the project, think about what you don’t like or what you feel could be improved
- Try to collect information on what pieces are involved in e.g. the feature you’re missing or the bug you’ve spotted
- Try to find the place where you could try adding your feature or fixing your bug
- Ask whether developers are interested in the feature or look at whether there already is an item for your issue in the bug tracker
- The rest is communication and coding
It’s not a fast path because you might not be able to contribute something of great value in the beginning. But if you’re dedicated, have enough spare time to make a difference and are keen on improving things step by step, you might eventually reach a point where you take over responsibility for more and more exciting or important tasks.
Good luck!
Google TV and Native Libraries
The Google TV runs a fairly unusual flavor of Android (at least the 2nd-gen ARM-based devices). I have a Sony Internet Player (not the Blu-Ray version), so what I’m about to write applies to that device, but maybe not any other, though it stands to reason that the other ARM-based GTVs are the same.
Phone-and-tablet Android doesn’t look much like a Linux desktop or server system. It uses the Linux kernel, to be sure, but a lot of the userspace libraries are custom. It even does not use Glibc, but a C library that Google wrote called Bionic. It’s fairly stripped down and lightweight, and while it implements most things you might need out of a standard libc, it does not pretend to be POSIX compliant.
From some simple investigation, I’ve learned that the Sony GTV is running a EGlibc 2.12.2, and probably a mostly-unmodified version of it. Someone with an @google.com email address stated that the reason for this was that they couldn’t get Chrome running against the Honeycomb version of Bionic.
Due to this, a Native Development Kit (NDK) is not yet available for the GTV. So the question remains: can we hack one together that works? The answer is… sorta.
With this knowledge in hand, I built a relatively standard arm-linux-gnueabi toolchain using crosstool-ng. Then I ‘adb pull’-ed the contents of /system/lib from my GTV and merged them with the new toolchain’s sysroot, copied some headers out of a stock NDK, and ended up with a sysroot that approximates what you’d find in platforms/ in a stock NDK, just without Bionic, and with EGlibc.
I didn’t get to modifying the NDK’s build system (it would need to be changed to find the new toolchain), so I built my native library manually, and got a simple “hello world” type app with a native lib. (It just calls a native method that returns a string, and displays the string on a label.)
One annoying thing is that the ABI string in the Sony GTV is set to “none”, so you have to unpack the APK, rename lib/armeabi-v7a/ to lib/none/, and repack and resign it. All of this means that this would be strictly hobbyist for now: no chance that you could distribute something in the Play Store. Not only does Google have to release an officially-working NDK, but they need to decide on an ABI string, and get Sony (etc.) to push updates out to their customers that update build.prop on the devices with the new ABI string.
There’s also the possibility that Google doesn’t want to create and officially support that much native drift between phone-and-tablet Android and GTV Android, and will wait until manufacturers are running a more-stock Android 4.x on GTV (that uses the 4.x version of Bionic) before releasing an NDK that works… in which case we’re at the mercy of Sony for updates, unless XDA or CyanogenMod wants to take a crack at it. My money’s on this scenario, unfortunately.
One of the main things people have been screaming for is a version of XBMC that runs on GTV. I have been able to get it to build using my hacked-together toolchain, but not actually to run. I ran into problems with runtime linking: the built binaries depend on a shared libstdc++ and libgcc_s, neither of which appear to be included on the GTV’s filesystem. I tried including them in the APK, but, weirdly, when the GTV unpacks the native libs from the APK at install time, it discards those two libraries. Static linking of those two may not be possible since XBMC’s APK includes a bunch of native libs. A possible solution would be to build all of libxbmc.so’s dependencies as static libs, and then just make one big static library.
But I haven’t had time to work on this over the past couple weeks…
Google TV and Native Libraries
The Google TV runs a fairly unusual flavor of Android (at least the 2nd-gen ARM-based devices). I have a Sony Internet Player (not the Blu-Ray version), so what I'm about to write applies to that device, but maybe not any other, though it stands to reason that the other ARM-based GTVs are the same.
Phone-and-tablet Android doesn't look much like a Linux desktop or server system. It uses the Linux kernel, to be sure, but a lot of the userspace libraries are custom. It even does not use Glibc, but a C library that Google wrote called Bionic. It's fairly stripped down and lightweight, and while it implements most things you might need out of a standard libc, it does not pretend to be POSIX compliant.
From some simple investigation, I've learned that the Sony GTV is running a EGlibc 2.12.2, and probably a mostly-unmodified version of it. Someone with an @google.com email address stated that the reason for this was that they couldn't get Chrome running against the Honeycomb version of Bionic.
Due to this, a Native Development Kit (NDK) is not yet available for the GTV. So the question remains: can we hack one together that works? The answer is... sorta.
With this knowledge in hand, I built a relatively standard arm-linux-gnueabi toolchain using crosstool-ng. Then I 'adb pull'-ed the contents of /system/lib from my GTV and merged them with the new toolchain's sysroot, copied some headers out of a stock NDK, and ended up with a sysroot that approximates what you'd find in platforms/ in a stock NDK, just without Bionic, and with EGlibc.
I didn't get to modifying the NDK's build system (it would need to be changed to find the new toolchain), so I built my native library manually, and got a simple "hello world" type app with a native lib. (It just calls a native method that returns a string, and displays the string on a label.)
One annoying thing is that the ABI string in the Sony GTV is set to "none", so you have to unpack the APK, rename lib/armeabi-v7a/ to lib/none/, and repack and resign it. All of this means that this would be strictly hobbyist for now: no chance that you could distribute something in the Play Store. Not only does Google have to release an officially-working NDK, but they need to decide on an ABI string, and get Sony (etc.) to push updates out to their customers that update build.prop on the devices with the new ABI string.
There's also the possibility that Google doesn't want to create and officially support that much native drift between phone-and-tablet Android and GTV Android, and will wait until manufacturers are running a more-stock Android 4.x on GTV (that uses the 4.x version of Bionic) before releasing an NDK that works... in which case we're at the mercy of Sony for updates, unless XDA or CyanogenMod wants to take a crack at it. My money's on this scenario, unfortunately.
One of the main things people have been screaming for is a version of XBMC that runs on GTV. I have been able to get it to build using my hacked-together toolchain, but not actually to run. I ran into problems with runtime linking: the built binaries depend on a shared libstdc++ and libgcc_s, neither of which appear to be included on the GTV's filesystem. I tried including them in the APK, but, weirdly, when the GTV unpacks the native libs from the APK at install time, it discards those two libraries. Static linking of those two may not be possible since XBMC's APK includes a bunch of native libs. A possible solution would be to build all of libxbmc.so's dependencies as static libs, and then just make one big static library.
But I haven't had time to work on this over the past couple weeks...
Google TV and Native Libraries
The Google TV runs a fairly unusual flavor of Android (at least the 2nd-gen ARM-based devices). I have a Sony Internet Player (not the Blu-Ray version), so what I’m about to write applies to that device, but maybe not any other, though it stands to reason that the other ARM-based GTVs are the same.
Phone-and-tablet Android doesn’t look much like a Linux desktop or server system. It uses the Linux kernel, to be sure, but a lot of the userspace libraries are custom. It even does not use Glibc, but a C library that Google wrote called Bionic. It’s fairly stripped down and lightweight, and while it implements most things you might need out of a standard libc, it does not pretend to be POSIX compliant.
Due to this, a Native Development Kit (NDK) is not yet available for the GTV. So the question remains: can we hack one together that works? The answer is… sorta.
From some simple investigation, I’ve learned that the Sony GTV is running a EGlibc 2.12.2, and probably a mostly-unmodified version of it. Someone with an @google.com email address stated that the reason for this was that they couldn’t get Chrome running against the Honeycomb version of Bionic.
With this knowledge in hand, I built a relatively standard arm-linux-gnueabi toolchain using crosstool-ng. Then I ‘adb pull’-ed the contents of /system/lib from my GTV and merged them with the new toolchain’s sysroot, copied some headers out of a stock NDK, and ended up with a sysroot that approximates what you’d find in platforms/ in a stock NDK, just without Bionic, and with EGlibc.
I didn’t get to modifying the NDK’s build system (it would need to be changed to find the new toolchain), so I built my native library manually, and got a simple “hello world” type app with a native lib. (It just calls a native method that returns a string, and displays the string on a label.)
One annoying thing is that the ABI string in the Sony GTV is set to “none”, so you have to unpack the APK, rename lib/armeabi-v7a/ to lib/none/, and repack and resign it. All of this means that this would be strictly hobbyist for now: no chance that you could distribute something in the Play Store. Not only does Google have to release an officially-working NDK, but they need to decide on an ABI string, and get Sony (etc.) to push updates out to their customers that update build.prop on the devices with the new ABI string.
There’s also the possibility that Google doesn’t want to create and officially support that much native drift between phone-and-tablet Android and GTV Android, and will wait until manufacturers are running a more-stock Android 4.x on GTV (that uses the 4.x version of Bionic) before releasing an NDK that works… in which case we’re at the mercy of Sony for updates, unless XDA or CyanogenMod wants to take a crack at it. My money’s on this scenario, unfortunately.
One of the main things people have been screaming for is a version of XBMC that runs on GTV. I have been able to get it to build using my hacked-together toolchain, but not actually to run. I ran into problems with runtime linking: the built binaries depend on a shared libstdc++ and libgcc_s, neither of which appear to be included on the GTV’s filesystem. I tried including them in the APK, but, weirdly, when the GTV unpacks the native libs from the APK at install time, it discards those two libraries. Static linking of those two may not be possible since XBMC’s APK includes a bunch of native libs. A possible solution would be to build all of libxbmc.so’s dependencies as static libs, and then just make one big static library.
But I haven’t had time to work on this over the past couple weeks…
Xubuntu is not a refugee camp
In growing amounts, people are migrating to Xubuntu from Ubuntu and other derivatives. While many of our new users tell they love Xubuntu, some of them would like to see a feature from their old configuration, be that a feature from their desktop environment or an application closely tied with it.
I don’t blame them for wanting different features than I do. I truly think there is users for every major and minor desktop environment. There will not be one desktop environment to rule them all, just because peoples opinions on looks and the perfect workflow differ thoroughly.
When our new users ask if they can have their feature, we have to ask them, and especially, what the user needs to ask theirself is if the feature, or the lack of, is really something that makes or breaks their experience. If they don’t think they can be at home without that feature, I wholeheartedly recommend them to keep using what they had.
If they are uncertain, I’d really like them to try to see the coin from the other side. Xfce nor Xubuntu have never tried to be like GNOME or Ubuntu. When Unity came around, Xubuntu never tried to become a substitute for GNOME 2 -like Ubuntu either, or specifically persuade migrating users.
The Xfce team has always been executing their own vision of the perfect desktop environment. Since the vision has been in some parts similar to GNOME earlier, some might argue that Xfce should still follow GNOME’s footsteps by implementing some new features similar to GNOME’s new features. I don’t think this is logical thinking, and it sounds like it comes from somebody who thinks Xfce should satisfy people who are migrating from GNOME.
The same goes with Xubuntu too: we are still building Xubuntu on top of Xfce because we like how it is and can agree with their vision. If this will ever change, it’s self-evident that either the people running Xubuntu need to change or Xubuntu needs to stop being. That being said, I don’t think that’s going to happen in the foreseeable future.
Finally, I’d like to emphasize that all users migrating from Ubuntu and other desktop environments are warmly welcome to the Xubuntu community. There are many ways to achieve the same goal when it comes to desktop environments. We believe Xfce is the best one for us as it has been and as it is. We are not a refugee camp, we have decided to take this path. This is our home.
This article is part of the article series A day in an open source project.
Vim and Vala
I once wrote a quick note about Vala and Vim (or Vim and Vala) and the use of the Tag List plugin. Here is a clean post about these two beasts.Vim — probably the best editor out there, at least always after trying out different editors I end up with Vim — has great plugins. However there is a lack of support for the Vala language. So here are two basic add-ins to include in the Vim editor.
Vala syntax
First there is no syntax color for this language. A quick fix is to use the C# syntax with the command :set filetype=cs. That works but is not ideal, ideal is to install a vala.syntax file, and there is one available on this GNOME Live! page.First download the file from this page and save it under ~/.vim/syntax/. Next add the following lines to your ~/.vimrc file:
" Filetypes
augroup filetypedetect
au! BufRead,BufNewFile *.vala,*.vapi setfiletype vala
augroup END
augroup vala
autocmd BufRead *.vala,*.vapi set tw=100 efm=%f:%1.%c-%[%^:]%#: %t%[%^:]%#: %m
augroup END
Tag List
Tag List is a powerful plugin that lets you explore classes or functions from a source file, also called a source code browser. The installation steps are simple, they are also available bellow, and again to get it working with Vala there is a small hack to include inside the ~/.vimrc file.First download the latest version of taglist from this page. Then uncompress the archive with, for example, the command line:
unzip -x taglist_45.zip -d $HOME/.vim/Then go inside ~/.vim/doc, run Vim and inside Vim execute the command :helptags .:
cd ~/.vim/docFinally add the following lines inside ~/.vimrc:
vim
:helptags .
" Work-around Tag List for Vala
let tlist_vala_settings='c#;d:macro;t:typedef;n:namespace;c:class;'.
'E:event;g:enum;s:struct;i:interface;'.
'p:properties;m:method'
Now Vim is ready for Vala, and it's possible to browse source code by typing the command :TlistToggle.
 |
| Vim Vala Tag List |
Vim and Vala
I once wrote a quick note about Vala and Vim (or Vim and Vala) and the use of the Tag List plugin. Here is a clean post about these two beasts.Vim — probably the best editor out there, at least always after trying out different editors I end up with Vim — has great plugins. However there is a lack of support for the Vala language. So here are two basic add-ins to include in the Vim editor.
Vala syntax
First there is no syntax color for this language. A quick fix is to use the C# syntax with the command :set filetype=cs. That works but is not ideal, ideal is to install a vim.syntax file, and there is one available on this GNOME Live! page.First download the file from this page and save it under ~/.vim/syntax. Next at the following lines to your ~/.vimrc file:
" Filetypes
augroup filetypedetect
au! BufRead,BufNewFile *.vala,*.vapi setfiletype vala
augroup END
augroup vala
autocmd BufRead *.vala,*.vapi set tw=100 efm=%f:%1.%c-%[%^:]%#:\ %t%[%^:]%#:\ %m
augroup END
Tag List
Tag List is a powerful plugin that lets you explore classes or functions from a source file, also called a source code browser. The installation steps are simple, they are also available bellow, and again to get it working with Vim there is a small hack to include inside the ~/.vimrc file.First download the latest version of taglist from this page. Than uncompress the archive with, for example, the command line:
unzip -x taglist_45.zip -d $HOME/.vim/Than go inside ~/.vim/doc, run Vim and inside Vim execute the command :helptags .:
cd ~/.vim/docFinally add the following lines inside ~/.vimrc:
vim
:helptags .
" Work-around Tag List for Vala
let tlist_vala_settings='c#;d:macro;t:typedef;n:namespace;c:class;'.
\ 'E:event;g:enum;s:struct;i:interface;'.
\ 'p:properties;m:method'
Now Vim is ready for Vala, and it's possible to browse source code by typing the command :TListToggle.
|
| Vim Vala Tag List |
Questions after the 4.10 release
A short post to answerer some questions I’ve ready in comments on the 4.10 release news across the internet. If you have more questions, let me know in the comments and I’ll try to answer them.
A new stable release after 16 months? And no 4.8.1 release…
This is because Xfce has a different release model than for example GNOME or KDE when it comes to stable releases. Because of the limited team of developers we want to spend the least time possible on releasing packages. Big stable releases like other desktops do consume a lot of time, even with the small-ish amount of core packages in Xfce.
Therefore after 4.6 the following was decided: we only do 4 big releases (3 preview releases and 1 stable release) and after that only stable releases for individual packages. So the desktop version is 4.10 (notice the lacking micro-number), individual components could have higher 4.10.x numbers.
As an example, the last 4.8 stable release of xfce4-dev-tools is 4.8.0, the same as in the 4.8 fat-tarball release. The latest 4.8 release of xfce4-panel is 4.8.6 (6 stable releases after 4.8.0, which was in the 4.8 fat-tarball).
We know this is harder for starting users, who prefer to grab 1 tarball with all the latest versions, but instead need to crawl through /src/xfce and need to find the latest version. For distributions this is a lot easier: packagers are subscribed to the xfce-announce mailing list or peek identi.ca and once in a while they need to update 1 of the packages.
Nonetheless this is still a point where we can improve so I’ll see if I can provide more information on the website (announcements and links to the latest package versions).
4.10 only had 2 preview releases, because no critical bugs appeared and translations were in a good shape. Enough reasons for me to skip pre3 and release 4.10 instead.
Online Documentation Wiki
Just to be clear about this: we understand online docs are not a solution, but it was the best we could do in a short time. Hopefully the wiki-based setup will attract more contributors (who previously feared docbook or mallard, yes we tried that too) and lead to a complete set of documentation . When we feel satisfied with the content of the wiki we’ll look into a “wiki snapshot” for offline usage and ship that in an xfce4-docs package.
Gtk3
First 2 things: no Xfce 4.10 is not using gtk3, only the gtk-xfce-engine theme engine supports gtk3. Secondly we will discuss if Xfce 4.12 will be ported to gtk3. I’ll explain the latter:
Technically gtk3 is nothing different then gtk2 when it comes to programming. The hard parts are porting of some custom widgets (drawing and size allocation), replacements of some deprecated symbols and link to gtk3 libs. All things a user is not going to notice if we do it right.
Gtk3 is also not faster than gtk2, maybe there are some areas were it got a bit faster, but so there are areas where performance decreased a bit. Nothing shocking here.
An issue I’m aware of is theming issues in gtk3. From what I understand this changed back and forward in gtk 3.0, 3.2 and 3.4. So we need to decide which version we require to get this working consistently, because people will complain if only the Raleigh theme can be used :).
From the Xfce point of view there is (again) the resource problem for porting all plugins, because if for example the panel is ported to gtk3, also the plugins need to be ported. Not all goodies are maintained, but usually they work and distros can compile them. If in 4.12 suddenly 50% of the external plugins are not working that will be another thing users will notice.
At any rate, don’t get overly excited about gtk3, it’s just gtk 2.26 with a huge api break :). Once we decided which version we use in 4.12, I’ll post it on the blog.
LXDE still consumes less memory
*sigh* I’m not going to rant on this because as a user you should choose the desktop that makes you happy, but anyway it annoys me a tiny bit. So just to throw some information:
LXDE and Xfce are both based on the same toolkit and provide roughly the same set of features. That as a start makes it technically almost impossible to be much better or worse regarding memory usage. I think this whole myth started by comparing two distributions (clue: strcmp (distro_a + 1, distro_b + 1) == 0).
I’m sure Xfce consumes a bit more memory, because more processes are started. Especially when external plugins are added to the panel: a design decision to make the panel more stable.
I don’t know or care where this comparison started, but if somebody does this again the the future, please compare the actual memory usage and don’t use free. Or even better: don’t compare memory usage at all because it is pretty useless.
That said: if I start a default LXDE and Xfce 4.10 desktop (default Arch Linux packages) and use ps_mem.py, Xfce consumes 2 MiB more memory (same or desktop-equal applications are started). Do whatever you want this is number, as long as you compare apples and apples.
Not much accomplished in over 1 year
Sorry, I also work the entire week. But I don’t blame myself, Xfce is a fun project for all of us and if people move to another country, have a day job, a life, school/exams or simply don’t feel like working on Xfce not much progress is made.
Personally I don’t have the feeling not much was done in 4.10, we didn’t break anything major and a lot of the todo’s for 4.10 were completed in the release cycle. The focus was polishing and that’s what we did!
Updates:
- 01-05 13:34: Added “Not much accomplished in over 1 year”.
Xfce 4.10 released!
Today, after 1 year and 4 months of work, we are pleased to announce the release of the Xfce desktop 4.10, a new stable version that supersedes Xfce 4.8.
In the 4.10 cycle we mainly focused on polishing the desktop and improving the user experience in various ways. Highlights of this release are:
- A new application finder that has been completely rewritten and combines the functionality of the old xfce4-appfinder and xfrun4.
- The panel now has an alternative vertical display mode (a deskbar). What is more, panel plugins can be arranged in multiple rows, which is particularly useful in the deskbar mode.
- A new MIME type editor that allows you to easily change applications used for opening different file types. The mouse and touchpad settings dialog and the settings editor were extended in terms of functionality. The former now supports tablets in a much better way.
- It is now possible to launch applications and open files on the desktop with a single click of the mouse. In addition, the 4.10 desktop can display thumbnails and automatically advance through the wallpaper list.
- The window manager can be configured to tile windows when dragging them to the screen edges. The tab window (Alt+Tab) supports more flexible theming and cursor key navigation.
An online tour of the changes in Xfce 4.10 can be viewed here:
A detailed overview of the changes compared to Xfce 4.8 and Xfce 4.10 preview releases can be found on the following page:
http://xfce.org/download/changelogs
This release can be downloaded either as a set of individual packages or as a single fat tarball including all these individual versions:
http://archive.xfce.org/xfce/4.10
Thank you all the contributors, bug reporters, as well as translators and packagers for your efforts in making this release possible.
Best regards,
The Xfce development team