BTW, True NeXT look description can be found at http://www.cilinder.be/docs/next/NeXTStep/3.3/nd/UserInterface/ and I would *LOVE* to have this look at least as compile-time option.
Wow, thank you for this document. It is quite useful to understand the thinking behind the UI design, and I really enjoyed reading this. It also makes me realize that software documentation was a lot better in the past than it is now. Now to other things. It seems that there are two camps regarding WINGs++, one group wishes to see the exact same look as GNUStep/NeXT, and the other group wishes for something a bit more modern. While I would like to see something a bit more modern myself, I can totally understand why people like the current look, and people have also given compelling reasons for the look not to change (GNUStep interaction). Since I am scratching my own "itch", I will continue to develop the modern look, but I would like to do it in a way that also does not break the old look for those that want it. I see a few ways of doing this: 1) I put #ifdef NEW_LOOK/ #ifdef OLD_LOOK things all over the code. This makes it possible to select the look at compile time, but the code will be ugly. 2) We keep the WINGs and WINGs++ APIs exactly the same so that you can link against either library at compile time. This makes the code easier to read, but locks the API. Also changes to either WINGs or WINGs++ will need to be cross-ported to the other branch. 3) We make WINGs "themeable" so that either look can be applied at runtime. I have not yet looked at the implications of this, but maybe it is not so much work as it seems. 4) Something else. Hopefully someone can suggest a better way forward. At the moment I am leaning towards (2) --- because it is less work for me --- but it will mean we have to ship wmaker with WINGs, WINGs++, and wrlib, which is perhaps not ideal. So gentlemen, some ideas please. Regards, Johann -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.info.
