Problem with workingsets and temporary area switching

[David Nolden]

Am Montag 30 November 2009 19:00:04 schrieb Alexander Dymo:
> понеділок, 30-лис-2009 10:28:05 David Nolden ви написали:
> > Ideally switching area would cause no flickering.
> > A good solution would be making area-switching faster. But this will
> > always stay slow, as opening the first tab means loading the kate
> > editor-component and the C++ language support.
> 
> The problem is that I can make area switching faster, but it will not
>  resolve the fundamental issue.
> 
> Area is currently the named set of opened views AND toolviews AND their
> layout.
> Workingset is the unnamed set of opened files AND their layout.
> 
> Fundamental issue I'm talking about is that workingset should not change
>  the area, because it should just open files into the current area. For
>  example, opening new file(s) should never affect toolviews. Currently it
>  does.
> 
> Actually, I can see the clash between "Area" and "Workingset". Maybe it
>  would be good to make areas hold toolview list/layout and workingset hold
>  view list/layout. Then we'd have no problem with recreating the central
>  widget with another workingset while still having the same area selected.
Hmm at least from what I remember, a working-set only holds information about 
the view list/layout and nothing more. So it shouldn't affect the toolviews. 
Only the temporary area-switching might _temporarily_ affect the tool-views, 
that's true. But actually that should be fixable with a 
"setUpdatesEnabled(false)" on the main-window during the switch.

You should also notice that a working-set may be active in multiple areas, so 
you cannot simply move the central widget into the working-set.

Generally I think you shouldn't try to change any fundamental design stuff in 
this area of development (shortly before releasing). What might make sense is 
adding some functionality to areas to allow "hidden" re-building of the 
contained view layout so we don't need to do the temporary area-switching, but 
that's not easy. For example you've got to consider that as soon as the 
current view is closed during the rebuilding, many parts of the GUI react to 
that by: Changing KDevelop title, rebuilding menu, toolbar, etc., and whatever 
else is listening to the activeViewChanged() signal.

The area-switching trick done right now saves us from all that complex 
interaction.

Greetings, David