Bluetile/Development

From HaskellWiki
< Bluetile
Revision as of 21:05, 26 February 2010 by JanV (talk | contribs) (Elaborated on minimal configuration idea)

Jump to: navigation, search

Development

This page is a place to brainstorm ideas for the further development of Bluetile. Comments and suggestions are welcome! I (JanV) currently don't have the time to work on any of these actively. So if you feel like trying your hands on some of these ideas, your patches are welcome.

The repositories listed on the main Bluetile website are for version 0.3.1, which is available on Hackage. If you want to dive into the code, you might want to use the development version instead, which only uses code from xmonad darcs now. That would be:

Bluetile doesn't have a separate mailing list or bug tracker. Since it is so closely related to xmonad, you can use xmonad's mailing list and bug tracker. Just make sure, you clearly state that you are referring to Bluetile. Happy hacking! :-)

Pretty window decoration

The current window decoration used by Bluetile is fairly bare bones, just sketching out the basic controls. I would like to improve on that. I'm not an artist, so if possible I would like to reuse something.

That gave me the idea to look into Compiz, which has several different possible decorators. Maybe it is possible to reuse the decorator of Compiz in Bluetile - like Compiz's gtk-window-decorator. This should allow for a very Metacity-like decoration.

Unfortunately, I couldn't find much documentation on how exactly Compiz talks with its decoration manager. These e-mails contain some information:

As far as I understand it, one marks the windows to be decorated with a special property. The decoration manager looks for windows with that property and prepares pixmaps with the decoration. The pixmaps are then communicated back to the window manager which draws them. Somehow a library called libwnck plays into all this and helps with some of the steps. It might be necessary to use Haskell's foreign function interface to make use of this library ( http://www.cse.unsw.edu.au/~chak/haskell/ffi/ ).

All of this is just a vague idea. I'm not sure if it is actually possible - especially considering that Compiz is a compositing window manager where different rules might apply (?). Comments from people with more insight into this area are appreciated. :-)

--JanV 23:16, 25 February 2010 (UTC)

Configuration system

It would be nice if Bluetile had a basic configuration system. The migration path to xmonad is fairly straightforward, so it is not impossible to configure Bluetile. But maybe someone just wants to change one key-binding or use a different terminal and there should be an easy way to make those minor tweaks.

Some thoughts about the design of a configuration system:

  • Nothing fancy, not everything has to be configurable, just some basics. Definitely no full-blown compiler step like xmonad does it. In my opinion that entails to many pitfalls for non-programmers. Maybe do something YAML-based.
  • Allow to: change key-bindings, global settings like the terminal and an option to hide Bluetile's dock. What about mouse bindings? Don't allow to: Change which layout algorithms are available etc. For that level of tinkering xmonad is better suited.
  • A verbose default configuration should be somewhere for the user to look at
  • The user configuration should be as minimal as possible, only containing the changes to the default configuration.
  • Add a button to the dock application that launches an editor with the configuration file. The configuration file in turn should contain some comments to teach the user how to modify the file and anything else he needs to know.

To elaborate on the minimal configuration: Many applications suffer from the problem, that they change their configuration scheme from time to time and break existing configurations. This should be avoided of course, but sometimes such a change is necessary to evolve the application further. Since it might be inevitable at some point, the user configuration should be as robust as possible to hopefully not need any adjustment. The user configuration should therefore be more of a changeset on top of the default configuration and only contain the changes the user made. That way, when something in the default configuration changes that the user hasn't touched, his configuration doesn't break. Mplayer is a good example for an application that works in this way.

--JanV 21:05, 26 February 2010 (UTC)