Bluetile/Development

From HaskellWiki
< Bluetile
Revision as of 22:16, 28 February 2010 by JanV (talk | contribs) (Managing dialog windows)
Jump to navigation Jump to 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)

Managing dialog windows

Bluetile tries to deemphasize the floating layer and provides a stacking window manager layout to be used instead. However, the floating layer still exists and is used in some cases. Mainly when things like dialog windows are opened. They are detected - just like xmonad does it - and automatically moved to the floating layer. In most cases this is what the user expects, because for things like an about box it usually doesn't make sense to tile the window. But occasionally a window might get such a treatment, where the user doesn't expect it and is confused why he can't manipulate the window in the usual way (floating windows aren't handled by a layout so they don't get any decoration). This confusion should be prevented. It might be enough to just add another button to the dock application to allow to 'de-float' a window. The tooltip for the button should contain a good explanation. Alternatively an extra control could be displayed in the upper right corner of a floating window enabling the user to do the same thing.

Currently a window can be 'de-float'ed with the keyboard shortcut Alt+t and floated with Alt+Shift+t. Most users will however not know this and in my experience the whole floating layer is somewhat of a confusing concept for users coming from traditional window managers.

--JanV 22:16, 28 February 2010 (UTC)

Retrieved from "https://wiki.haskell.org/index.php?title=Bluetile/Development&oldid=33884"