On Tue, May 20, 2003 at 02:01:55AM +0000, Mikhael Goikhman wrote: > On 19 May 2003 20:47:13 +0200, Olivier Chapuis wrote: > > > > I recall my intention: style by id is a great feature, with a simple > > _hack_ we can get it, so it is difficult to me to do not wrote such > > code. Yes it is a "hack" it is not the new great "WindowStyle" > > command we want (which needs more discussion and an enormous code > > reworte). Yes it is just a simple piece of code with some theoretical > > problems, but ok I think in practice. > > How exactly "StyleById <id>" is different from "WindowStyle"? > Both implement exactly the same thing: individual window styles. > I see no reason to have a temporary syntax when there is a final syntax > that we like even if the current implementation may be not the best one. > > Regarding some Dominik concerns. > > First, probably the current Style and DestroyStyle implementation is > delicate and even problematic. But since the new command uses only the > existing implementation, it does not adds problems by itself. It may only > help to find the _existing_ problems faster since it does DestroyStyle > more often than usually. > > So, I would say the new command may only help to stabilize Style code if > it is not stable yet (seems pretty stable). The new code is really small > to add any instability by itself, I will test it throughly anyway. > > Second, I can understand some Dominik worries regarding the code purity, > but if we are honest, a possibility to have individual window styles in > this year (i.e. 2.6.0) is much more tempting than minor code issues. > It is not that the code is out of control now (I can understand what the > patch adds without looking at the rest of the code). > > I thought about weither individual window style entries (one per window) > could be stored in a separate list and never be merged (only deleted), > i.e they always take a precedence. But this seems to be non intuitive, > probably a user wants all terminals to be affected by "Style XTerm > Borders" even the ones that were individually defined to be borderless, > so the logics in the patch (merging both Style types together) is good. >
In fact I am not sure. Take this example: a user want a window with NeverFocus (an xterm as he has executed less -f .xerror and maybe later he will want to get SloppyFocus again on it if he quit less). So he set NeverFocus on this window (by id) ... then he reload some themes component which leads to "Style * SloopyFocus" ... the log xterm has SloppyFocus. Bad. The two approach seem reasonable. Regards, Olivier -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
