Olivier Chapuis <[EMAIL PROTECTED]> writes: > On Tue, Jun 24, 2003 at 09:39:47AM +0200, Dominik Vogt wrote: > > On Tue, Jun 24, 2003 at 06:40:50AM +0200, Olivier Chapuis wrote: > > > On Thu, Jun 19, 2003 at 03:51:50PM +0200, [EMAIL PROTECTED] wrote: > > > > On Sat, Jun 07, 2003 at 07:20:12PM +0200, Olivier Chapuis wrote: > > > > > On Mon, May 19, 2003 at 01:44:27PM +0200, Dominik Vogt wrote: > > > > > > Should the StyleById patch be applied before 2.6? Please cast > > > > > > your votes here. > > > > > > > > > > Seems that there is no conclusion here. It seems that there is two > > > > > votes for it (me and Mikhael) one vote against (Dominik) and one > > > > > unclear vote (Dan). So I ask for more votes and clarification > > > > > (Dan?). For that I send an other version of the patch (attached). > > > > > I've followed all the advice (I can follow) that I get in this > > > > > thread. In particular, I've followed all the remarks (as I can) of > > > > > Dominik regarding the code. > > > > > > > > > So, Dominik I even hope you revert your vote (very little hope > > > > > ...). > > > > > > > > I don't know about your hope, but the chance that I do is zero. It > > > > is not the right time. > > > > > > The reason of my hope is that the new version of the patch take in > > > account the reasons why you reject it. > > > > Nothing on earth can make me agree to adding huge features in > > feature freeze. > > It is not a huge feature, it is one of the few features that fvwm miss > to become a perfect window manager. So let us have it!!
Looking at the patch, I agree, its not huge. Its not minor either. > > > You give 7 arguments. The new patch handle arguments 3, 4 and 6. > > > Moreover, I've worked on argument 5 and style list > > > simplification has been improved. > > > > As I said before, I reject making facts now that can never be > > changed again. The way the style list works has always been a > > mistake. No matter how much time you spend on optimising the > > style list code, it will always be a memory leak. This logic is > > due for replacement, not for expansion. > > I will say that this has almost nothing to do with the WindowStyle > cmd. This is a general problem regarding styles. Any way, I will > be interested to see a natural situation where the style list > go to infinity (with a fixed number of names). I don't agree that the Style code is fundamentally broken. But I know from past experience that Dominik's standards are higher than mine. To me, the style code does the job so I don't see a problem with it. The way matches work may seem odd, but I don't think there's a better way. I don't understand the comment about the memory leaks. I remember Dominik doing some work to combine styles as they were issued. There shouldn't be any leaking going on. > > > About 1 and 2 I can just say that I do not _think_ that the > > > patch can cause instability. > > > > It has already consumed much time in pointless arguments that > > could have been spent stabilising the code. There is a direct > > relationship between my motivation to work on the remaining > > problems and the amount of distractions on this list that have > > nothing to do with it. > > > Finally, I do not understand argument 7. > > > > It's an ad-hoc syntax that *will* be thrown away right when we > > start thinking. I have many enhancements in mind that have no > > chance of being implemented with this kind of just-throw-in-a-new- > > command-whenever-it-seems-to-work-for-the-moment approach. > > I do not see the problem. If I follow your logic the Style command > will drastically change. Moreover, I cannot imagine that we > rework the style stuff and that at the end it will be not possible > to set "window attributes" on a given window. > > > But, maybe the most important is that there is 4 votes for the > > > patch (Dan, Mikhael, Olivier and Tim) and one vote against (Dominik). > > > > Of course Dan can speak for himself, but according to the mail > > archive he did neither vote for nor against the patch. Not that I > > think it matters. > > In general Dan does not vote. He gives arguments. At the end there is > no arguments against. But yes it is possible that Dan use abstention. I agree with Dominik, my vote hardly matters. As I said before, I think votes should be in proportion to contribution. In this case, I've been agreeing with both sides. Dominik has some very good points. I don't agree about the Style code being a problem and therefore shouldn't be extended, but I do agree that we need to freeze features to create a stable release. I think Oliviers point about this nicely rounding out the feature set, and not being a big change is very good. Also, he supplied test cases, so it shouldn't hold back 2.6 on that account. > > > So, I think we should apply the patch. > > > > Then take the consequences and abandon the idea of a stable 2.6 > > release. > > Why? I don't want to put words in Dominiks' mouth, but I think he's been pretty clear, he doesn't want this patch applied. See his sentence above about motivation. Considering Dominik's strong opinion, it might be a good idea to hold that patch for a while. Use your judgement. Did I vote? I guess I should, even if it doesn't count for much. Damn, I can't make up my mind. I give up, I was hoping I could come up with some argument or line of reasoning that would settle this, but I admit, its beyond me. I'm not going to vote. Try to see the other persons viewpoint and then ask yourself, can I give in on this a little for the sake of the team. -- Dan Espen E-mail: [EMAIL PROTECTED] -- 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]
