On Fri, Apr 24, 2009 at 12:23 PM, Ville M. Vainio <[email protected]>wrote:
> > > I'll leave the useUI switch in the code indefinitely for those who > > want to use qt designer for experimentation, but I shall do all > > further work in code. Don't try to talk me out of this approach--I'm > > a happy guy again. > > I'm definitely not trying to talk you out of this Thanks for these understanding remarks, Ville. I'd like to emphasize that the approach I have chosen is largely driven by personal preference. I am much more comfortable dealing with code than with tools that generate code. It reminds me of remarks that Bjarne Stroustrup about the C++ parser. I can't find them now, and perhaps I am misremembering them, but as I remember it he said that he chose an LL1 parser for cfront because LL1 parsing was supposedly the best way. But he regretted the choice. He, like me, is much more comfortable with recursive-descent parsing. So he ended up constantly fighting the supposedly "better" LL1 tool. > What I've been saying is - don't throw the baby out with the bathwater. I'm not sure how much of value remains, but I plan to keep the useUI switch indefinitely so that people can experiment. Perhaps we agree that one advantage of qt designer is experimentation. If you cut the ui designer out of the loop altogether, it's a one way road > with no going back; I don't plan to use qt designer, except to steal the code that is qt_main.py. But others can do as they please. But I *have* used qt designer because I have based the code on qt_main.py. What I'm basically saying is "go for it", though. Everyone will still > be able to use qt designer, say, to create their own widgets for tab > widget. Modifying the main ui will require more "inside" knowledge, > but I'm not sure how big a problem that will be in practice. I am happy with yesterdays work. However, it highlights another problem with qt designer. Yesterday's work was based on a much simpler version of qt_main.py, that was not in synch with qt_main.ui. In some sense, that was a happy accident. The old, out-of-synch, code was easy to understand. Today I'll use fold in the complex code, especially for the body pane, which at present does not look right when useUI is False. In my mind, the present work is a kind of repackaging. It does not much matter how createMainWindow and its helpers is created. What matters is: 1. The (helper) methods are flexible: they support alternate views of Leo's outline, body and log panes. 2. The methods are complete: they support all features of the Tk gui, including multiple body panes. 3. There is clear programming model, with corresponding api, for gui programmers to use the capabilities. I haven't yet accomplished all these goals, but they certainly are doable (by me) in the new framework. This morning I saw that to do this it will be important to decouple the code that "renders" a pane from the code that places a pane. At the code level, this is straightforward. The pane renderers will have a parent parameter. Thus the creation of frames (layout) will be distinct from rendering of the frames. To repeat, substantial work remains, but everything is straightforward now in the new approach. It's a matter of designing helper functions. That's something I know how to do. Edward P.S. Rewriting the code from qt_main.py is a substantial amount of work, partly because no competent programmer would likely write the kind of code that pyuic4 generates. The generator doesn't know how the code interacts, so it makes ivars of everything, which pollutes the namespace. But the larger reason for substantial rewrite is that neither qt designer nor pyuic4 knows anything about the 3 design goals listed above. EKR --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
