Sublime split view

[Manuel Breugelmans]

On Monday 28 July 2008 14:10:25 Andreas Pakulat wrote:
> On 25.07.08 01:42:52, Manuel Breugelmans wrote:
> > As discussed a couple of days ago on irc, veritas splits it's test runner
> > tool view from the corresponding results tool. Reason for this is
> > obvious: runner contains a test suite tree and hence should be vertical,
> > but the results view contain descriptive messages + file names and thus
> > should be horizontal. Andreas insisted on sending something to this ml
> > about it so here goes.
> >
> > Problem is that sublime was not designed with linked toolviews in mind.
>
> Why do toolviews need to be linked? In particular what exactly is the
> link between runner and results view that causes problems when either is
> missing?

Runner and results view communicate. Selection of an (aggregate) test filters 
just those failures, and vice versa selection of a failure will scroll to the 
owner test in the test tree runner.

> > StandardOutputView works around this by digging quite deep into sublime
> > internals, store tool view data, connect to internal controller signals
> > and so forth.
>
> Uhm, outputview doesn't store the "toolview" data at all, it also
> doesn't dig into sublime - it simply uses its public interface.

That's not quite the whole truth :P It stores Sublime::View pointers in a 
ToolViewData class and subscribes to Sublime::Controller signals to get 
notified of view creation/deletion. It gets at these internals through a method 
with the docstring:

    /**
     * This is meant to be used by IDocument subclasses to initialize the
     * Sublime::Document.
     *
     * This cannot be used for anything else, without linking to the sublime
     * library, which is forbidden and may break your plugin
     */

> It
> isn't concerned at all about linking of toolviews, except that it makes
> sure to provide some commonly used toolviews with standard names. This
> wouldn't actually need to be put into standardoutputview, we could've
> declared that the string "Build" always refers to the outputview for
> building-messages. However I think having a defined API to get a
> toolview for the "Build" output is better than that. And it should be
> quite clear that its better to have 1 Build outputview than
> make,cmake,qmake,ant,... all creating their own outputview.

Yes that is an option for the runner thing too (tabs instead of multiple 
views). I suppose best would be to have this user controlled 'promote tab to 
view' or something.

> > The link I need in veritas is however a bit stronger: result should not
> > be around withtout a runner and vice versa, id est a 1:1 mapping.
>
> Why? Thats actually what I wanted you to write to the list :)

Well the other options are:
- tabs in a results view
- dropdown boxes to select the corresponding runner tool
- disallow multiple runners/results tools altogether

> > I have more or less implemented this in veritas, which is not quite
> > the right place. The only extension I _will_ need is control over
> > which tools get written to config, the child one should not.
>
> The position of each and every toolview needs to be written to
> configuration. If you can provide good reasons for why the results view
> needs to be hidden initially then that might be an option, but the
> position needs to be stored.

There is no 'the' results view, it's all plural. The reason that it should not 
get saved is to implement the parent-child thing. Only the parent will 
instantiate views, not the sublime restore code. And yes, that's not the 
proper way.

> > Code which accomplishes this is totally out of place though ...
> > veritas/testrunnertoolview.cpp:240
> > plugins/xtest/qtest/qtestplugin.cpp {removeResultsView and friends}
>
> That code indeed does know a lot of sublime internals :) And I'm not
> opposed to having API that forces a given toolview to be unique inside
> the mainwindow (not across mainwindows though).

That would solve most of the issues as well and would get rid of the whole 
one-off thing + do not save to config. Patch?


Manuel