Derrell's suggestion sounds very sensible. What do you think, Sebastian? Hugh
> > hard to use, even for me. Rethought the idea and came up with > > this one. Bit values for all incoming states are dynamically > > created. Each widget can only support a maximum of 30 states now > > (number overflow). The states field is not used anymore. Every > > incoming state is respected in bit-field generation. This means > > that even unsupported/unused states are substracted from the list > > of 30 possible states which is a bit bad, but should not really > > affect anyone. 30 states really seems to be a lot when looking into > > current widgets. > > Wasn't there someone in Redmond, Washington who asked, "Who would > ever need more than 640K of memory?" :-) > > Suggestion: reserve one bit as an "extension" bit which is not to > be used by any class for any purpose. This allows you to use it > later, should the need arise, to indicate that an additional bit > mask is also in use or that some other, possibly less efficient but > more expandable method of handling states is in use. This requires > that all current access to the bit masks themselves be disallowed > (i.e. only access is via accessor methods) so that adding an > alternate state implementation or an additional bit mask doesn't > break existing code. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
