QAbstractItemModel::match()

[jerome_isAviable]

in the doc, i can not read if the match member function search inside childs of items or not (consider the model is for a QtreeView)... also, i can not read indications for be able to do it or not.
I try to search values inside all items of a QTreeView. this values comes from url files names datas. I do it for find a way to detect possible doubles and forbid doubles entries inside the QTreeView.

but, the doc is to short and poor for provide completes informations around this member "match" function of QAbstractItemModel. I don't know if Qt team would be able to consider the question and maybe complete/clarify the doc around this.

Is someone here know the answer (please) and maybe provide an exemple of match with QTreeView Model ?

thanks for any help.

[SGaist]

Hi,

From the documentation, match will perform a search on the column corresponding to the given start QModelIndex. So it won't traverse the tree unless you implement your own model overloading match to do that.

What model are you currently using ?

[jerome_isAviable]

Hi SGaist, and thanks for answer and try to help.

ok, i'm able now to use QAbstractItemModel::match function.
In fact, you can search inside the childs in the treeview model... but you need to indicate this option with the Qt:MatchFlags(Qt:MatchRecursive) inside the arguments of the match function.
Also, i implement my own model, because for use a treeView you need to do it. Also, i see some model for treeview and "filesystem", but never have the weight of each directory, so i do mine///

Qt is nice, but there is, for many peoples as i can read in forums and on irc channels, big pain with Qt documentation style. This documentation is big, but really bad quality.
But anyway... no one in the Qt team would like to hear this fact (lol).

So... my way in this treeView is to:
_drop files and/or directories
_with directory full name for first hierarchy up tree, and last directory name for next
_with files name in an other column
_with size for each file and for each directory in third column
_with an editable comment in the last column
_show all files inside directories dropped
_at drop time, forbid any bad stuff (like paste inside a child)
_at drop time, forbid doubles
(that is the part where i use match function...)
but.... i'm able to forbid doubles from a file or a directory dropped if exist allready inside the tree (and childs to...), but i can not forbid the drop if this directory is down more in the filesystem hierarchy.
for exemple, consider i have this files tree:
_/home/
_/home/myname/
_/home/myname/a_file.txt
_/home/myname/desktop/
.
.
.

if i have allready /home/myname/desktop/ inside the treeView and i drop /home/ the patch function will not see any double.
it can see only if there is /home/myname/ and i drop /home/myname/desktop/.

any idea for a solution ?

[SGaist]

I'd be happy if you could point me to an equivalent (as in functionality) framework with a better documentation (that might give ideas for improvement)

What do you mean by patch function ?

You can try to build a diff between the content of the target and dropped in folder

[jerome_isAviable]

Hi SGaist, yes sure, it is easy for see a better doc.
Also, you ask for "an equivalent in fonctionality"... i never talk about the fonctionality, but ONLY about the quality of the doc. And all your ather good arguments will never delete this.

here is an exemple of a good GUI with a really good doc:
http://docs.wxwidgets.org/3.0/classwx_dialog.html

But i not just tell: this is good or not... i also tell you WHY:

• the form:

titles are better separates from text (color and size) and then the look is clearest

diagram with logic search and link

a search editline who not give you back a google result, but a content of the doc directly...

and in general, a nice organisation with different logic of search

the organisation of titles inside each page is more human logiocal, as soon as first, there is a detailled description and not only a simple line with a link who go other place

as you can see by yourself (open your eyes), the presentation is not only more nice and clear, it is also more clean. This is important whan you search: what is clean is clear. The doc of Qt looks really dirty near this one and some other.

• the content:

the explain, for me, are more clear, not ambiguous many times

when there is some options or flags, there is also a list on the same description of this choices... you not have to go for search this list... or open again an other tabs (with Qt i open more than 10 tabs... and inside each, just pick a little part... it is totaly crazy...)

But if you want, also, you can go to have a look on the cpan site... who is really big and have much more libraries and complicate stuff than a GUI can have. But the fact of a good GUI (because QT is good) is absolutly not in relation with the fact of a bad and confused documentation.

I'm really surprise you not just see it. Also, i'm really surprise by your answer who make a link between quality of doc and quality of GUI.
For me, this doc is a big pain and i loose to much time around it.

Ok... is not path function, but match function (sorry for the fault).
I don't want to drop in a folder, i don't want to move files too.
On my application, i have two tree views, one for create some binders with description of each, and an other one for put some files and directories. each binders is linked with contents of files/directories lists.
And this works fine.
When i put a file, the directory and the filename is separate in 2 columns, the third show the size, the last column show the description.
When i put a directory, a line is for each top level directory, with there childs files and other directories (like in QFilesystem model... but with the total size of each directory... that is why i not use QFilesystem).

What i try with math function is to forbid doubles insertions of files. Next would be to really compare the files, not only by name of it, but by content relation (for exemple, if a hash of two same named files are same... if date of modification are same... if yes or not they are really the same files).
I can observe that the recursivity of the "match" QAbstractItemModel function goes only trough column 0... what i would like to said is that: for exemple, i can not search in column 1 but with a recursive search followed the column 0 in all childs of each entry...
not sure at this point, btu maybe i need to implement an other function than match for do the job.

Finally, these binders and files have to be write inside some Postgresql tables and refers to some organisations of structures/locations/projects/mesures/logs... theses files are documentations of each category of contents for a specific work.

[jerome_isAviable]

how... i forget a big detail for doc form...
the doc of QT (and all your web site) make the choice of only use a fixed width for content of the page... so on my screen, only 30% of the width is use for print the content of your pages... and users need to go up and down quickly... looks like a design for mobil phone... but fixed size.
It is maybe your choice... i think that if all the page is well used, it would be better.

[SGaist]

It's not my site ;)

My eyes are opened however I've been using this documentation since the Qt 3 days so there are certainly things I will miss that a newcomer will see. I've asked you this because I wanted to know what you consider a good documentation both in terms of content and presentation. I've mentioned the functionality equivalence to have a comparable base to talk about. Nothing more.

The wxWidget doc looks like a classic doxygen generated documentation (nothing wrong at all with that)

So if I understood you correctly, in terms of presentation, you'd like to have a hierarchy tree accessible for Qt's classes as well as having the various enums used repeated in subclasses documentation, is that correct ?

By confusing are you thinking of the presentation only or also the documentation content itself ?

I agree that the latest version of the online documentation might not be optimal (presentation wise) but it's something that you can help improve by opening a bug report on the "bug report system":http://bugreports.qt-project.org
You can also fill a feature request with your ideas to improve the documentation content/presentation (or if you find some that are already in the same idea as yours, vote for them/add your comments)