On 09 Jun 2003 12:08:39 +0100, Tim Phipps wrote: > > Mikhael Goikhman wrote: > > > On 08 Jun 2003 14:24:58 +0100, Tim Phipps wrote: > > > > > I've got some free time now and I was thinking of implementing the > > > WindowStyle command that was proposed ages ago. I think this means > > > I vote no (not very strongly) but I'd appreciate some help in > > > reviewing the proposal in the light of the current state of Fvwm. > > > > Can you please provide some arguments? > > > > Do you see your proposed WindowStyle command any different (in terms of > > syntax and meaning) from the new command added by the posted patch? > > For me they are identical, so your ideas become more real in the long run. > > > > Or you mean that there may be the different implementation after 2.6.0? > > Because starting to replace Style now before 2.6.0 is not a possibility. > > I don't mean to change or remove the Style command so I don't want to > wait until after 2.6.0. The old proposal is to create a new command > "WindowStyle" that sets the style of the target window. It would be > called as "WindowStyle Sticky" in which case it operates on the target > window or as "WindowID XXX (<conditions>) WindowStyle Sticky" in which > case it operates on the window XXX. The WindowStyle command would not > do any pattern matching, It would use the pattern matching of WindowId > so that if the WindowId command were to be upgraded to use a > "Class=<pattern>" that syntax would be usable in the WindowStyle and > Style commands for free.
The updated Olivier's patch in the parent message does exactly this. No less and no more. Actually it also adds DestroyWindowStyle command. > The old proposal is also to change the Style command to manipulate a > "StyleFunction" function rather than have it maintain a style list. The > StyleFunction would be run on every window that is created and would > consist of a sequence of "WindowId XXX (<condition>) WindowStyle YYY" > lines. The proposal would have to implement a command to delete lines > from a function as a method of controlling the growth of the style list. > As a debug aid there would be a PrintFunction command which would > probably be useful on its own anyway. Should changing "the Style command to manipulate a StyleFunction" be done before 2.6.0 or after it? I suggest to use "ThisWindow" as a better syntax than "WindowId $[w.id]". > As I see it the new StyleByID proposal would complicate the (already > complicated?) Style function and style list management. The old proposal > would simplify the style list management. While I agree that the old proposal may be a good thing, it is unclear whether its implementation is easier or open to less bugs than the Olivier's patch. > The new proposal would require extra code to handle the deletion of > windows, the old proposal does not need to do this. > > The new proposal may change the behaviour of Recapture by making the > StyleById settings more powerful than simple Style commands, I'm not > sure if this is the intention. If it isn't then the Recapture command > would have to delete all the Style "id=XXX" settings from the style list > or do something clever. As I understand the patch, window id entries are not more powerful than the usual Style entries. There was a discussion to make them more powerful by supplying an optional WindowStyle Permanent prefix. For example this should reduce the style list to only Sticky entry: Next (XTerm) WindowStyle !Sticky Style XTerm Sticky For me, the Olivier's patch is the safe thing to apply now before 2.6.0. Trying to change the Style command by replacing style list with StyleFunction before 2.6.0 is problematic. This maybe done after the new stable release or it requires a separate voting. At least I hope you agree with the syntax and meaning of the WindowStyle command as added by the Olivier patch, this is more important than the actual implementation. Regards, Mikhael. -- 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]
