Best Practice For Sharing Selection Model And Proxy Models With Multiple Views

[texas]

I may be so off on this one.

Say ViewA has ProxyModelA and selection model "SelectModelA".
ViewB would like share SelectModelA with viewA.
However ViewB uses a different model, say ProxyModelB.
Both ProxyModelA and ProxyModelB sit on top (say directly for the time being) of the real deal - call it "ModelRoot".

When it comes to selection, viewB will receive model indexes from "ProxyModelA". viewB doesn't understand "ProxyModelA". So it has to either convert it or a conversion has to take place between.

Case 1 might look like the following since the model ptr is part of the modelindex (if this utterly horrible, say so!)

@
...
connect(standard_qtreeview_selection_model,SIGNAL(currentRowChanged(QModelIndex,QModelIndex)),
my_graphics_scene,SLOT(slot_model_select(QModelIndex,QModelIndex)));
...

void MyGraphicsScene::slot_model_select(const QModelIndex& idx_in,
const QModelIndex& prev_idx_in)
{
QModelIndex idx = idx_in;
QModelIndex prev_idx = prev_idx_in;

const QAbstractProxyModel* pmodel = dynamic_cast<const QAbstractProxyModel*>
                                    (idx.model());
if ( pmodel ) {
    idx = pmodel->mapToSource(idx_in);
    prev_idx = pmodel->mapToSource(prev_idx_in);
}

@

Another example, in the case of a Delegate that launches an editor which is a qtableview, the delegate may create a little proxy model based on the current model which could be a proxy itself... and well it's complicated to explain the interaction with the selection model... ughh

The thing is, I can do this, I just feel off... and hoping there was some advice.

[Franzk]

Hm. I think I tried to achieve the same you are doing here. It is hard to do and requires a lot of data management. I came to the following conclusion after achieving it: it's useless. Really. Semantically it doesn't make any sense to have two views with different models and then try to combine some selection out of it. One view may see data that the other doesn't and boom, there goes the predictability of your UI. Think hard if you really need this functionality.

[andre]

Selections and proxy models are indeed a pain to deal with. Luckely, you don't have to reinvent the wheel completely. Steveire has "blogged":http://steveire.wordpress.com/2010/04/20/sharing-a-qitemselection-between-views-through-proxy-models/ about this issue a couple of times, and has contributed "some code":http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKLinkItemSelectionModel.html to KDE that you could lift and use.

[texas]

Thanks for both responses.

Franzk, I think in this case, so far, the proxy modelling is worth the extra trouble because it is making it so I don't have to fiddle with the views. In theory, I am not using different models, I am using two lenses (proxies) on the same model.

Andre, thanks. I am looking forward to reading the blog and checking out the code.

[texas]

Andre, thanks for the links. Yes... perfect. I actually thought yesterday, "What I probably need is something outside to encapsulate hopping up and down a proxy chain..." Even if the code won't work for me, at least I'm know I'm not doing something crazy.

[Franzk]

[quote author="texas" date="1306418753"]Franzk, I think in this case, so far, the proxy modelling is worth the extra trouble because it is making it so I don't have to fiddle with the views. In theory, I am not using different models, I am using two lenses (proxies) on the same model.[/quote]I fully understand what you want to achieve, since I tried to achieve the same. That doesn't change the fact that you may have to make some behavioral decisions that can compromise the predictability of your project. I hope you can make it work though.

[texas]

Franzk, thanks. This sort of programming, using a framework, is new to me. I've always done lower level stuff. I feel like I'm wielding a huge sword. It's most likely that I will cut off my own foot here and there. I appreciate the guidance and tips.

[Franzk]

Heh, nice analogy. In my experience model/view selection handling can be a huge sword with a morning star at the butt end if you're not careful. I do like the framework though.

Edit: removed the link to http://en.wikipedia.org/wiki/Morning_star_(weapon) because I couldn't hide it neatly.