hoist should be 'per-body-editor-pane'

[Mark Edgington]

Let's say we have an outline which looks like:
a
   a.1
   a.2
b
   b.1
   b.2

Doing the following causes problems:

1) select node a.1
2) create a new body editor pane (cmds->body editors->add editor)
3) change the focus to the new pane
4) select node b
5) click "Hoist"
6) Go back to the first body-pane (displaying a.1's contents) -- it is now not highlighted in the outline.

What would be preferable is for the 'hoist state' to be tied to a body pane. So, when a given body pane has the focus, an associated hoist-state (un-hoisted or node-x hoisted) is made active in the outline pane.

[Edward K. Ream (edreamleo)]

On Thu, Jan 8, 2009 at 3:49 AM, Mark Edgington <email address hidden> wrote:

> Public bug reported:

This may be a bug, but it will be very difficult to fix. The code that
handles multiple-body panes is fantastically complicated.

A simpler solution would simply be to outlaw hoists and dehoists when there
are multiple body panes :-)

Edward

[Mark Edgington (edgimar)]

If the code that handles multiple-body panes is complex, I would suggest that maybe (long-term) it should be simplified -- for example, treating panes as Thread objects could simplify the code a lot, and I'm sure there are various alternative possibilities that could simplify things.

By the way, is there any sort of UML documentation of Leo's code structure? This could make it easier to refactor some parts of the code into more manageable paradigms (while still maintaining the MVC architecture).

[Ville M. Vainio (villemvainio)]

On Fri, Jan 9, 2009 at 6:28 PM, Mark Edgington <email address hidden> wrote:

> If the code that handles multiple-body panes is complex, I would suggest
> that maybe (long-term) it should be simplified -- for example, treating
> panes as Thread objects could simplify the code a lot, and I'm sure
> there are various alternative possibilities that could simplify things.

Without exact idea about what's going on here, I'd just like to
mention that using threads for GUI related code is typically a very
bad idea, and will cause no end to problems and mystical crashes.

--
Ville M. Vainio
http://tinyurl.com/vainio

[Edward K. Ream (edreamleo)]

On Fri, Jan 9, 2009 at 11:49 AM, Ville M. Vainio <email address hidden> wrote:

> On Fri, Jan 9, 2009 at 6:28 PM, Mark Edgington <email address hidden>
> wrote:
>
> > If the code that handles multiple-body panes is complex, I would suggest
> > that maybe (long-term) it should be simplified -- for example, treating
> > panes as Thread objects could simplify the code a lot, and I'm sure
> > there are various alternative possibilities that could simplify things.
>
> Without exact idea about what's going on here, I'd just like to
> mention that using threads for GUI related code is typically a very
> bad idea, and will cause no end to problems and mystical crashes.

Have no fear. There is zero chance that I shall use multiple threads to
"solve" this problem :-)

Context-changing code is always exceeding tricky. There is no way around
this. In particular, it's never easy to switch from one set of state
variables to another because all assumptions that the code typically can
validly make suddenly become dubious. The switch has to happen at a low
level, with extreme care.

Furthermore, the two-way interaction between user actions and programmatic
actions make it impossible to handle events from the gui simply. A set of
interlocks must exist so that the code can distinguish between
user-generated events and events generated from Leo's commands. Again, this
adds unavoidable complexity.

In such situations, the slightest additional complexity in the user
interface can cause almost unimaginable difficulties in the code. In other
words, simplicity is an *illusion* created at the user level by complex
code. It is simply wrong to imagine that this illusion can be created
easily.

Edward

[Edward K. Ream (edreamleo)]

It is not valid to label suggestions for changes as bugs.

[Edward K. Ream (edreamleo)]

Ignore my previous comment. There is a real bug here. The fix will probably be simply to disallow hoists when multiple body panes are showing.