Abdelrazak Younes <[EMAIL PROTECTED]> writes: > On the implementation point of view, charstyle as inset has *many* benefit: > - shorter code > - cleaner code > - generic code
Yes, but we should never change the look and feel just because the code is short clean and generic. It is our role to strive for short, clean and generic code, but at the same time we should not force the consequences of the on the user. The interface we expose should be a consequence of our vision and be as much as possible independent of mundane problems like implementation. I know that what I write is just wishful thinking, but this thinking is important. Software written by technicians (even good ones) is not necessarily good software. The original LyX, with its mix of latex-like structure and word-like look-and-feel was successful because Matthias found the right balance between the interface and the inner working. We all know how horrible the code was, but it had an intuitiveness factor that was very cool IMO. We should not loose that. >> 1) spans --- which is how font attributes work today; > > And which is horribly complicated... Try to forget about implementation details. It is not the good argument for deciding what the UI should be. >> and (b) much more importantly, I just think that the *concept* of >> inset is wrong; and using the wrong concept is bound to cost a lot >> later on, because the better the concepts used for coding match the >> "real concepts", the easier it will be to handle new, currently >> unforeseen situations --- just because the code will "behave" more >> closely to how the "real world" it is trying to represent behaves. > > Again you are mixing up look&feel and implementation ;-) I do not know. I think we will know once we have found what the good UI concept is. The question is "how can we get a way to offer seamless nesting of character styles (or font change) in a way that will look natural and intuitive to a new user?". The implementation goes after that. JMarc
