Sebastian Werner <[EMAIL PROTECTED]> writes: >> As to appearance theme changes at runtime, I think it's perfectly reasonable >> that those completely override any manual settings that had been made. > > No not really. As appearance also controls some incompatible values. For > example when you have a horizontalBoxLayout where: > > width = auto > > then the user configures > > width = null > left = 0 > right = 0 > > After this the appearance changes a reconfigure the width to > > width = auto > > This means, that a this moment the width, left and right properties are > configured at the same time. And this is problematic. It would be better to > also keep the user-configured null (or even undefined if we get implemented > this).
Hmmm... Ok, I don't think of appearance involving *sizes* of things; only their colors and decorations. I wonder if the appearance might best be split into two separate categories: one category for things that apply to colors and decorations, and one that applies to things that affect layout. (Decorations can affect layout, as borders could be different width, so there is some interaction that needs to be worked out.) >> If the programmer wants to override settings after every appearance theme >> change, it's reasonable that they would either modify the appearance theme >> itself, or apply the manual settings each time the appearance theme is >> changed. > > Even better is to always handle user-configured stuff with a > higher-priority, as then, there is no implicit change to properties which > the user have already configured previously. For example I would like it if > I change the appearance of a button, to "mybutton" and this redefines the > width, where I have previously defined it to be statically to 100px. In my > opinion this isn't intuitively understandable for the user. Just using priority isn't enough either, though. If you have, for example, a menu of themes and can then override various aspects of the theme, if you then select a different theme, you'd expect all of your user settings, which were really particular to the previous scheme, to be overridden by the new scheme. A good example of this is with KDE or even Windows. You can select a theme and you can override various aspects of the theme, but when you select a new theme, all of your overrides become gone. I believe that's intuitive, and I think that's also how qooxdoo should behave. For implementation of this, when a widget is instantiated, the appearance properties can be set based on the current theme. The user can then make manual changes to the appearance properties. When a new appearance theme is selected, all widgets are located, and the appearance properties of all widgets are set to those in the new theme. This overrides any previous user settings which had been applied to the old theme. For disabled/enabled widgets, a theme should include an appearance for both the disabled and enabled version. The user may override either or both. Again, though, if a new theme is selected, all user settings get overridden by the newly-selected theme. Am I off base here? It sounds to me intuitive and "reasonably" easy to implement. The attributes specified in themes are used at only two times: in a widget's constructor, and when a new theme is applied. In both cases, the widget's properties are set to the theme's settings just as if the user had issued a setXXX() call to set the property, and may be overridden by future setXXX() calls issued by the user. Cheers, Derrell ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
