Sublime split view

[Andreas Pakulat]

On 29.07.08 09:44:25, Manuel Breugelmans wrote:
> 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.

Ok, but neither of the two needs to have the toolview visible or added,
right? I mean they're communicating over the plugin and via
signals/slots I hope, in which case just "nothing" happens if the other
toolview doesn't exist yet.

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

That comment is outdated and I don't see any problem linking to sublime.

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

I think I'm not following. Why would there be multiple runners? As I
said already, we really need API  to tell wether a toolview is unique or
not (for example konsole isn't needed as unique toolview, but clearly
testrunner is). However this "unique" would be bound to one mainwindow,
we currently don't support multiple mainwindows, but if we do at some
point we have the same dilemma again. I guess this could be easily
solved by doing something like isSameMainWindow( QWidget* w1, QWidget*
w2).

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

You're still not explaining why :( I understand that you change the
current content of the results view based on the selection in the runner
- and vice-versa. But I fail to see how tabs would give any benefit
here, or any of the other options - except the 3rd. Which is what we
really want.

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

See above. Currently all toolviews suffer from problems when you create
more than one, Sublime simply doesn't take that into account.

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

Not from me today or tomorrow, shouldn't be too hard though - just a
flag on the tooldocument thats used for createView() to always return
the same view once its created.

Andreas

-- 
You fill a much-needed gap.