On Wed, Nov 20, 2002 at 05:13:46PM +0100, Olivier Chapuis wrote:
> On Tue, Nov 19, 2002 at 11:40:07AM +0100, Dominik Vogt wrote:
> > On Mon, Nov 18, 2002 at 10:14:05PM +0100, Olivier Chapuis wrote:
> > > On Mon, Nov 18, 2002 at 10:40:55AM +0100, Dominik Vogt wrote:
> > > >
> > > > Well, I won't stop you doing it, but are you all aware that the
> > > > whole code is going to be thrown away, probably next year? As I
> > > > said before, I think no new functionality should be added to the
> > > > {Button,Title,Border}Stlye commands anymore. My estimation is
> > > > that at least 50% of the code doing this will be just thrown away
> > > > and on the other hand makes the big decoration rewrite much more
> > > > complicated.
> > >
> > > :o)
> > >
> > > I do not want to wait 3 years or more before to see colorset in
> > > TitleStyle for a stable release.
> >
> > We already have a Colorset and a HilightColorset style. I won't
> > say anything against using more parts of the colour set in the
> > window decorations. But why does it have to be in the BuggyStyle
> > commands?
>
> Because replacement for {Button,Title,Border}Stlye commands will lead
> to interminable discussion which will end after the feature freeze.
> I think this is in the 3.0 todo. Moreover, {Button,Title,Border}Style
> are widely used
>
> BTW, there is this in the man page:
>
> This command is deprecated and will be removed in
> the future.
>
> in the top of the {Button,Title,Border}Style commands. It seems
> to me that "deprecated" means that these commands should not be
> used. No? If yes which commands can do the same job?
Style * HilightColorset
Okay, that won't give us the MultiColorset things, but I don't
think they are this important for 2.6. The advantage is that we
can keep the code unmodified in 3.0.
[snip]
> > Well, if we don't stop adding things, we won't have 2.6 anytime
> > soon. Remember that 2.6 was planned as a quick follow-up to 2.4
> > to add some nifty functionality before the big clean up.
>
> I was not aware of this. They were very few discussion on the goal
> of 2.6.
Well, I know most of the time it is that I just make the
decisions, chiefly because we lose interest in the discussions and
nobody cares too much about the outcome. But I really think it
would be good to communicate more about strategy. We (you, me and
Mikhael) seem to have orthogonal goals in many aspects.
> > > Moreover, I do not see the problem with the {Button,Title,Border}Style
> > > commands. There are dramatically powerful (yes there are some odd
> > > things, there are missing feature and yes I will add maybe some).
> >
> > They are also horribly inflexible (all configs are global), buggy
> > (leaking memory) and unintuitive (*weird* syntax).
>
> I will try to fix the memory leak during the freeze.
I hope you know what you're doing ;-) Good luck.
> > > The
> > > only real pb I see is that they are not fvwm Style and this pbs is not
> > > really a drawing pbs.
> > >
> > > BTW, here my 2.6 todo list (optimistic).
> > >
> > > - Colorset in {Button,Title,Border}Style
> > > - A type of "gettext" support in config file
> > > - Better key/mouse binding in the Pager
> > > - minimal randr support (XFree-4.3 will have a functional randr for
> > > resizing and rotation)
> > > - Style by Id (maybe Dominik)
> > > - Icon background (maybe Dominik)
> > > - bug fix, testing, bug fix, testing, bug fix ........
> >
> > Wow! I already mentioned that I want to put 2.6 into feature
> > freeze no later than 31st of December, did I?
>
> Yes, I know. I think it is a very good date. Maybe the feature
> freeze for modules can be delayed a bit. As I say this list
> is optimistic. I will have to make some choice.
Okay.
> > My list looks like this:
> >
> > - Clean up tear-off menus (a huge task)
> > - bug fix, testing, bug fix, testing, bug fix ........
> >
> > In my eyes, adding the "Style by Id" thing would delay the next
> > stable release by at least a year.
>
> Or you sure that this will be so difficult. I do not ask for
> conditional style.
Yes, absolutely sure. It is very disruptive and requires a full
fledged rewrite of the style code - unless we hack up some
temporary syntax that is dumped in 3.0.
Bye
Dominik ^_^ ^_^
--
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]
