On Sun, Oct 5, 2008 at 2:41 PM, Edward K. Ream <[EMAIL PROTECTED]> wrote:
> In the past, the only choices (I saw) for classes like leoQtTree were > to "be" a qt tree or to "have" a qt tree. But there is another > choice: to "refer" to a qt tree. This makes leoQtTree a two-way > adapter class. It has two interfaces: one to Leo's core, the other to > Ui_MainWindow. Actually, UI_MainWindow is just a mixin class that provides setupUi method. Window is the concrete leo window. Yeah, it's a crappy name. But basically, wat you are saying here is what I've been thinking all along. Adapter or "bridge" class is much more flexible solution than subclassing, and I don't generally like the idea of subclassing unless really needed (unless it's "implement this interface" kind of subclassing, of course, but that is unnecessary in python). Regarding the division of labor, I think it's indeed a good idea. The leo gui plugin framework is a bit too involved for me at this point. Is it ok if I move UI_MainWindow to separate file, and add qllmain.ui from qleolite (the designer data file) in trunk? -- Ville M. Vainio http://tinyurl.com/vainio --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
