Sublime split view

[Andreas Pakulat]

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?

> 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. 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.

> 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 :)

> 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.

> 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). 

And sorry for taking so long, somehow I forgot about this, because the
of the great weather and me spending little time at the PC this weekend.

Andreas

-- 
After your lover has gone you will still have PEANUT BUTTER!