Category: Fedora

Fedora related blog posts

WindowMaker command generated proplist menus

The next-style X11 window manager WindowMaker has been around forever. For a while now development has continued in the -crm branch mainly cleaning up code and integrating patches found in the packages of various linux distributions. Eventually this effort ended up in new official releases.

One of these additions down the road was the tool wmmenugen which can be used to parse xdg style desktop files into proplist files. The generated proplist files can in turn be read by WindowMaker e. g. as menus. However, up to now there was no direct way to dynamically use the proplists generated by wmmenugen as menus.

With this patch series the OPEN_PLMENU option has been added to WindowMaker to allow dynamically generated proplist menus. This allows for some nice dynamic menus like

(
 Applications,
 OPEN_PLMENU,
 "|| find /usr/share/applications -type f -name '*.desktop' | xargs wmmenugen -parser:xdg"
 ),

for a well known application menu or

(
 Desktop,
 OPEN_PLMENU,
 "|| find ~/Desktop -type f -name '*.desktop' | xargs wmmenugen -parser:xdg"
 ),

for a desktop menu.

Fedora users can already test this new feature in rawhide or fedora 18 with this update.

wine-gecko coming to a fedora wine installation near you…

It is always a nice feeling when you can close a bug on your package which has been open for about two years. In this case I am talking about rhbz#573530 – titled “package gecko support”.

What does this mean? Wine implements its own version of the Internet Explorer. For this it uses a customized version of the Mozilla Gecko layout engine (see Wine Gecko). If wine creates a new wineprefix for a user or a version upgrade of wine wants a new version of wine gecko the user is asked to download a windows build of the gecko engine (~17M). On systems with 64bit & 32bit wine the download has to be done twice. This needs to be done per wineprefix, even if you need to start with a fresh prefix the files will have to be downloaded again.

What can be done about this? Wine has a search path for wine gecko which includes a central place on the system. This is done so distributions can bundle wine gecko. While wine gecko is licensed under OSS licenses we are talking about building a windows build of the gecko engine. For the past two years this was not possible in fedora due to the available mingw. With the inclusion of a new mingw stack for the upcoming fedora release 17 (see mingw-w64 cross compiler) wine gecko can be cross compiled on fedora out of the box.

Thus wine 1.5.0 will pull in one (or on 64bit installations two) new packages on upgrade – mingw{32,64}-wine-gecko – which contain a system managed version of the wine gecko engine. All users upgrading from an older wineprefix (before 1.5.0) or creating a new wineprefix will not have to download wine-gecko from an external source and will be automatically using the shipped version.

rxvt-unicode 9.09 upgrade

I have taken some time last week to cleanup the rxvt-unicode package and upgrade it to 9.09. This cleanup features some nice new functionally (256 color support) and a package split which will be interesting for multi-language users. The package is now split into four parts (similar to debian) as a lot of options are set at compile time:

  • rxvt-unicode: standard version
  • rxvt-unicode-ml: version enhanced for multi-language support, including unicode3 support
  • rxvt-unicode-256color: standard version with 256color support (TERM will be rxvt-unicode-256color)
  • rxvt-unicode-256color-ml: version enhanced for multi-language support and 256colors

Builds for F13 and F14 are in updates-testing. If you want to try out the 256color support beware of #653081. As a workaround you can run

tic /usr/share/doc/rxvt-unicode-9.09/etc/rxvt-unicode.termcap

which will put the needed terminfo files in ~/.terminfo

Feedback as always welcome.