On Sun, Jan 01, 2006 at 08:37:28PM +0100, Viktor Griph wrote: > While looking at the possible options for implementing a Style setting > functionality for window types based on EWMH. I got as deeply into the > style code that I decided to give the syntax specification in the 3.0-todo > a try. > > I've got the 'Style (conditions)' syntax working quite well, with the old > Style syntax supported by a compability mode. Styles are applied in the > order: Golbal (*), (Not completely implemented: ewmh window type), > compability layer (not Style * ..., nor WindowStyle), Resource, Class, > Icon, Name and WindowID. The style lists are not split on > wildchar/non-wildchar, but are split on the priority fields.
This splitting idea really needs some discussion anyway. The current style housekeeping is difficult to manage because of the cleanup operations of old styles. Separate style lists are a method to simplify that work, but then the order to apply styles becomes unclear. > I'm not going to commit this, but will keep it for future reference, for > the folowing reasons: In any case, you can commit it in an experimental development branch: $ cvs tag experimental_style_rewrite_base $ cvs tag -b experimental_style_rewrite_branch then commit your changes to the branch. (The first tag command sets a label on the version the branch is based on; without that it's almost impossible to find out the base of the branch). > * I don't know how far away 2.6 is (I don't really know if there is > anything I can do to help out get 2.6 out the door) and I don't want to > add new big features at this time. > * The current implementation isn't 100% behaviour backward compatible > (Style * is given lowest priority, and WindowStyle highest), meaning that > some configs using styles in strnage manners might change how they work. > It wouldn't be hard to put Styl * into the compability layer, but putting > the WindowStyle command into it would make WindowStyle different from > Style (WindowID $[w.id]), which is a bad thing. > * I'm not sure that the syntax is the best. It might be good to have an > alias for a style, since the DeleteStyle gets rather nasty withou a name > to delete. > * Finally I don't know what that plan is to replace UseStyle with, and it > might be good to have that in mind when impementing the syntax. > > I do however attach the diff if anyone want's to test it out. Phew, you've taken on a big task that still needs a lot of discussion. Note that the list in the todo-3.0 file is a collection of ideas, not something we've already decided on. There is one big item missing on the list that plays a major role in how the style rewrite is implemented. I'd like to strictly separate window state (= the current state of a window) and style (= the initial state of a window). This is listed as (22) in the file. What's not on the list is that in the end I want the same style name in styles, states and conditions, e.g. InitialStyle Iconic on WindowState Iconic off Next (WindowState Iconic on) ... All (InitialStyle Iconic on) ... Echo $[InitialStyle.Iconic] (Replaced by 1 or 0) Echo $[WindowState.Iconic] (dito) Echo $[is.InitialStyle.Iconic on] (Replaced by 1/0 if the window has the queried style) Echo $[is.WindowState.Iconic off] (dito) And all that without duplicating the code four times. To implement this it is necessary to redesigning the window structure in addition to the style code/structures. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
