On Apr 23, 8:45 am, "Edward K. Ream" <[email protected]> wrote:
> It may be possible to allow significantly more flexibility for Leo's users.
> There are
> several possibilities:
Standing in the shower a few minutes ago I saw what is likely the way
forward.
The Aha is that Leo's components (body pane, outline pane, etc) don't
care where they appear on the screen. Otoh, these components know a
*lot* about each other: many events link the body pane, outline pane
and various parts of the log pane.
This Aha creates a new design space, in which some problems resolve
themselves automatically, and new problems and opportunities appear.
Here are some thoughts:
1. The interactions between Leo's components are built in to Leo.
There is no way for the user to change those interactions in qt
designer or any replacement for qt designer.
2. The user, could, however, place Leo's components anywhere in Leo's
main window. Thus, we could imagine an @layout setting that specifies
the layout of Leo's components. For example, Leo's default layout
would be specified something like this:
- @layout
- @icon-area
- @splitter
- @splitter
- @outline-pane
- @log-pane
- @body-pane
- @minibuffer
- @status-line
The Aha is that the components of the @layout tree are high-level
items. This greatly simplifies the job of the script that would turn
the @layout tree into actual code. There are very few possibilities,
so each could be handled with custom code. Some question remain, as
discussed below.
3. This new viewpoint suggests new possibilities and raises new
questions. First, we could imagine "packing" multiple commanders in a
single top-level window. Something like:
- @layout
- @leo-file
- @leo-file
In this context, each leo-file element corresponds to a commander, and
would contain, at least, corresponding body and outline panes. It
would take a little work to generalize Leo's core to handle this, but
not much. Presumably, the user might a single "global" minibuffer,
but it's not so clear whether one or multiple log panes and status
lines would be best.
In any case, such an approach would be similar to how Emacs packs
multiple buffers in a single top-level window.
The new viewpoint raises another question. What, exactly, is a high-
level "component" such as the body pane? In particular, I am
wondering whether it should be more flexible than the present pane.
Should it be a QTabWidget? A QStackedWidget? If it is a
QStackedWidget, then the body pane might become invisible, or more
interestingly, have multiple renderings...Happily, this new question
can probably best be answered at the code (api) level.
To summarize:
1. The user will be interested in specifying only the layout of
largely non-configurable components.
2. Dealing with high-level components greatly simplifies the
implementation details. An @layout tree becomes a distinct
possibility.
3. Some design questions remain.
Edward
P.S. I see no urgent need actually to do @layout now. It may not be
all that useful. But I do think that the reliance on qt designer
should end. It has nefarious effects, similar, in my mind, to the ill-
fated settings pane. It's time to do the work that will create code-
level flexibility.
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
-~----------~----~----~----~------~----~------~--~---
