<snip> >Yes, there would be two hardcoded looks in the Draw() method. I dont >necessarily see this as a hack though, as there are already a lot of >conditions in each Draw method: <snip> >....it would just be a case of wrapping another if (NewLook) around >that. > >I don't see why you would need to do design-specific stuff in other >methods for the huge majority of widgets. OK, so a curved button might >need a different check for a hit in MouseDown, but other than that the >sizes of the controls and the active areas should stay the same. > >If we want skinning, this is obviously not the way to go about it, and >R1 is also not the place for that kind of thing. But if we want a new I think that we can all agree on this. :-) >look, while keeping the possibility of switching back to the old one, >it seems like an acceptable solution. It is the best of what I have heard. I am still not convinced that it is worth doing. Just so we are not too "clubby", I will say this: I 100% agree with Erik - if you want to contribute code, *PLEASE* do something for R1. Please. We need people doing the work that we can all agree on. Issues like these are *EXACTLY* why, at the beginning, I said "Let's do R5 first and talk about anything else later". Because you have oh, about 100 messages, about what I would call the most trivial of issues (code wise). Imagine if we had opened the door to *ANY* feature for R1? What sort of a mess would we have? I have written privately to Simon, warning him that *ANY* such code would be heavily reviewed before being accepted, if it were to be accepted at all. But I would like to point out to everyone - look what adding a feature like this costs... My time and someone else's (DW's or Erik's) to review the code. Discussion between the reviewers and the submitter. 100 posts on this list. Compare all of that to the non-work generated by "Here is a class that works exactly like R5's and here are my test cases. Please check them in." Simon has some very good points about the marketing side of this. Our decision to call it "R1" is not set in concrete. R1 was/is a good working name. Some people have suggested "Release Walter" as an alternative. Hmmm. I am not personally inclined to change the look and feel for R1/Walter/Whatever. I think (as Simon and I have discussed) that getting a ton of new users is *NOT* a goal for R1. Look - our community has dwindled, somewhat. I don't think that will shock anyone. Furthermore, many of the very knowledgable people have left. If we released R1 tomorrow and we had 10,000 new users all with questions, we couldn't handle it. We need to rebuild a little more gradually than that. R1/Walter > R5. Networking, no cruft, new Media Kit, new Kernel, drivers, etc. We should be in good shape to draw in the departed and some new, brave people. I believe, and you can certainly tell me that I am wrong, that for R1/Walter, we need few users (other than devs) and a lot more devs. Devs understand "work in progress". Screenshots like Stubear's are sufficient, I think, for devs. Devs get excited about working code and about momentum. We have both. Not completed code, but working code. And momentum. Come R1/Walter, we will have a whole lot more of both. That is what draws devs. That and the chance to do great things. That we can certainly offer. >As you imply, it is by no means certain that OBOS will ever provide >full skinning support. I know from private mails that Michael and Erik >are both opposed. That is obviosuly a discussion for GE. But if it is >decided not to implement skinning support, will the widget set always >look like R5? While I did say that (and I will stand by it), there is a little context necessary for public consumption. I am ***PERSONALLY*** opposed to skinning. I hate it desperately. That doesn't mean that it won't ever happen, necessarily. I am not a Dictator for Life. That will be a decision made by the group when the time comes. And I think that Simon might be a little disingenuous here (with an arguement style that I love and have used myself) by setting up a false dichotomy. It is not a choice between skinning and never changing the look. There are other choices, like setting the look in the OS and changing it between releases. Look at Windows 3.1-->Win95. >If the decision is made to implement full skinning support in a future >release, just about all the widget code will need rewriting - it will >be much more work than just "undoing" my proposed changes. True. OTOH, if we don't go the skinning route, this proposed change could be the right direction to go.