apparently impossible qobject_cast is working!?

[FS Lover]

Because you shouldn't touch the proxy as the completer relies on modifying it.

I agree that we shouldn't modify it, but it's sufficiently clear that programmers need to use it directly (of course without modifying it or relying on stability it doesn't have, etc; these must be implemented in the code properly).
what you say is relevant to programming in general that I know already, you know, its abc that every real programmer should know; it is relatively easy to understand and documentations are full of such warnings and advises, since many tools can be misused similarly (specially in languages such as C and C++). but essential programmer's tools never are hidden in order that no one can misuse them!
so I think it is no reason for the documentation not telling that; obviously, we should be aware of the existence of a tool to make use of it.
documentation could add extra explanations and advise about any misuse of a tool, which is very ordinary and frequent in qt and any other such documentations.
mentioning implicit knowledge about that could be a better reasoning.

[wysota]

I agree that we shouldn't modify it, but it's sufficiently clear that programmers need to use it directly (of course without modifying it or relying on stability it doesn't have, etc; these must be implemented in the code properly).

"Need"? Can you show me a case where you would "need" to use the QAbstractProxyModel API of the completion model ?

what you say is relevant to programming in general that I know already, you know, its abc that every real programmer should know;

There are many things so trivial people forget to do because they are so trivial that everybody knows them so they don't think about them and miss them.

but essential programmer's tools never are hidden in order that no one can misuse them!

Of course they are. For instance the "private" sections of classes in C++ are examples of such case.

so I think it is no reason for the documentation not telling that; obviously, we should be aware of the existence of a tool to make use of it.

No. The case with the completion model is an exact case where you should not know there is a proxy hidden behind. And in the next release of Qt there might not be a proxy there but the API has to remain unchanged.

documentation could add extra explanations and advise about any misuse of a tool, which is very ordinary and frequent in qt and any other such documentations.
mentioning implicit knowledge about that could be a better reasoning.

It's documentation, not a copy of the source code. Take a look at the source code and nothing will be hidden from your eyes.

[FS Lover]

Can you show me a case where you would "need" to use the QAbstractProxyModel API of the completion model ?

<qt installation dir>/examples/tools/treemodelcompleter/mainwindow.cpp: highlight member function.

every time we need to map the highlighted completion item to the original model the completion is performed for,
we need to use the QAbstractProxyModel API of the completion model.

in this qt's own example we need to do so in order to highlight the user's choice of the completion in the original model.

Of course they are. For instance the "private" sections of classes in C++ are examples of such case.

it is access to them in the programming environment that is restricted, not the knowledge about the existence and function of them in the documentation.
at least for those that programmer can makes use of them (e.g. in subclassing).

[wysota]

<qt installation dir>/examples/tools/treemodelcompleter/mainwindow.cpp: highlight member function.

every time we need to map the highlighted completion item to the original model the completion is performed for,
we need to use the QAbstractProxyModel API of the completion model.

This is a special case and qobject_cast is here so that you can do the mapping properly. If at all, I would say the completer should return an index from a base model instead of its own internal one but I don't agree it should return a proxy model api.

in this qt's own example we need to do so in order to highlight the user's choice of the completion in the original model.

As you see the example works, so you don't need it.

it is access to them in the programming environment that is restricted, not the knowledge about the existence and function of them in the documentation.
at least for those that programmer can makes use of them (e.g. in subclassing).

No. It's still internal and you shouldn't care.

[FS Lover]

This is a special case and qobject_cast is here so that you can do the mapping properly.

for what reason do you think it is special?
furthermore, what do you mean from special? what difference does it make regarding such uses we need?
you wanted an example case and I showed you one clear, simple, standard, and completely official one.
I think its clear enough to everyone.
so you have the responsibility to prove any further claim you make here.

I would say the completer should return an index from a base model instead of its own internal one but I don't agree it should return a proxy model api.

base model may be any model that can be potentially complex, costly to process, harder to work with, etc.
but regarding auto completion's suggestions and user's choice among them, many times we need only simple features without any further/external dependencies,
so a simple and shortened model that contains only the relevant items is the best to work with. that is what completionModel gives to us (a simple list model).
but sometimes we need to map indexes of this simple and shortened model to the original model that we want to work with directly.
on the other hand, this tells us what is the set of completion suggestions. this is essential.
so qt's way is the most efficient method. its not improperly designed.

As you see the example works, so you don't need it.

maybe I don't understand your meaning clearly.
can you explain more?
clearly, some feature of the example will not work without that functionality.

[wysota]

for what reason do you think it is special?

Because here you don't care that it is a proxy, you just want your original model index back. It's a shortcut over using the activated() signal that carries a string and finding that string in your model. So the same functionality could be obtained without qobject_cast with one or two additional lines of code.

what difference does it make regarding such uses we need?

This is not a need where you want to use the completionModel for anything. You just want the original model index back.

you wanted an example case and I showed you one clear, simple, standard, and completely official one.

No, you didn't.

I think its clear enough to everyone.

So file a bug report to Qt Software. They won't change the API because it would break compatibility with existing applications but they might say "you're right, it should have been a QAbstractProxyModel".

so you have the responsibility to prove any further claim you make here.

I don't have a reponsibility to prove anything. You should always use the most general interface to an object and that's a rule of a thumb in OO Software Engineering.

base model may be any model that can be potentially complex, costly to process, harder to work with, etc.
but regarding auto completion's suggestions and user's choice among them, many times we need only simple features without any further/external dependencies,
so a simple and shortened model that contains only the relevant items is the best to work with. that is what completionModel gives to us (a simple list model).

I take it that in your implementation of Qt the source of QCompleter::setModel() doesn't contain a line:

d->proxy->setSourceModel(mode);

d->proxy->setSourceModel(mode);

To copy to clipboard, switch view to plain text mode 

which sets the source model of the completion model to the model you pass to it. So sorry, but there is no "simple list model" here. You have all the drawbacks of your original model plus an additional layer that returns the currently used list model to the user. And still you shouldn't care what it does. To you this is just "some" model that can be completely unrelated to your base model, especially if you subclass QCompleter and reimplement setModel - there might not be any proxy there anymore.

maybe I don't understand your meaning clearly.
can you explain more?
clearly, some feature of the example will not work without that functionality.

Examples often use hacks or simplifications. This is one of them.

[FS Lover]

It's a shortcut over using the activated() signal that carries a string and finding that string in your model.

`activated ' isn't equal with `highlighted' in functionality.
QCompleter::highlighted:
This signal is sent when an item in the popup() is highlighted by the user.
QCompleter::activated:
This signal is sent when an item in the popup() is activated by the user (by clicking or pressing return).

So file a bug report to Qt Software. They won't change the API because it would break compatibility with existing applications but they might say "you're right, it should have been a QAbstractProxyModel".

it is now a QAbstractProxyModel.
first thing I questioned here was just "why is qobject_cast successful?"
the answer is, because returned object is indeed a QAbstractProxyModel subclass.
but it is not mentioned in the documentation.

You should always use the most general interface to an object and that's a rule of a thumb in OO Software Engineering.

apparently qt's own educational example does not follow that.
so I think you can fill a bug report!!

[wysota]

`activated ' isn't equal with `highlighted' in functionality.
QCompleter::highlighted:
This signal is sent when an item in the popup() is highlighted by the user.
QCompleter::activated:
This signal is sent when an item in the popup() is activated by the user (by clicking or pressing return).

Ok, then over "highlighter" carrying a string.

but it is not mentioned in the documentation.

Yes, along with many other things that are not mentioned there.

apparently qt's own educational example does not follow that.

???

Does it expose any API?

[nish]

good fight:

[FS Lover]

So the same functionality could be obtained without qobject_cast with one or two additional lines of code.

can you please write those two additional lines for that example?
please change the member function and insert the code here so that I can compile and examine it to understand the truth. I am not sure about anything, since I am a newbie anyway.
I think if it's so easy and short you can spend a little time on it to go to the practice and take this debate closer to it's destination. we should try to make it more clear and get benefit from the time and energy we spent here. further the topic will be much more of use for others if we can make a definitive conclusion.
personally I filled a bug report for the documentation (using non-standard method and undocumented API) and I sent the link of this topic for them too. but it's possible that they discard that bug report.

[wysota]

I just have to stop answering to all those flames... But what can I say, I do love them...

Use QCompleter::currentCompletion() to find a path in the original model and then use QAbstractItemModel::match() to find the proper index in the model.

A possible implementation:

QStringList path = completer->currentCompletion().split(".");
const QAbstractItemModel *model = treeView->model();
QModelIndex sourceIndex;
while(!path.isEmpty()){
    sourceIndex = model->match(model->index(0,0, sourceIndex), Qt::DisplayRole, path.first(), 1).first();
    path.removeFirst();
}
treeView->selectionModel()->select(sourceIndex, QItemSelectionModel::ClearAndSelect | QItemSelectionModel::Rows);
treeView->scrollTo(index);

QStringList path = completer->currentCompletion().split(".");
const QAbstractItemModel *model = treeView->model();
QModelIndex sourceIndex;
while(!path.isEmpty()){
    sourceIndex = model->match(model->index(0,0, sourceIndex), Qt::DisplayRole, path.first(), 1).first();
    path.removeFirst();
}
treeView->selectionModel()->select(sourceIndex, QItemSelectionModel::ClearAndSelect | QItemSelectionModel::Rows);
treeView->scrollTo(index);

To copy to clipboard, switch view to plain text mode 

[FS Lover]

your code does not work properly.
run the app, type 'p', scroll to 'Parent2'; 'Parent2' does not get selected and 'Parent1' remains selected.

[wysota]

your code does not work properly.

So improve it It's a proof of concept.

[FS Lover]

this was my submitted bug report: [Issue N255532] using a non-standard method in an example

<qt installation dir>/examples/tools/treemodelcompleter/mainwindow.cpp: highlight member function

it uses completionModel's QAbstractProxyModel interface which is
apparently non-standard and not documented in the class reference.
why an educational example should make use of non-standard methods and
undocumented interfaces?

I received the answer recently:

Basically, the implementation of QCompleter uses a QAbstractProxyModel
subclass to wrap the model, and the writer of the example relied on this
knowledge to write the highlight() function.

Note that the return value of completionModel() is a QAbstractItemModel
pointer purely for generality - it could have been a QAbstractProxyModel
(this would have made things clearer).

I doubt that anyone will change the implementation of this class now, so
we'll go ahead and document the behavior.

Regards,

David
--
David Boddie
Senior Technical Writer
Nokia, Qt Software