Implementácia QAbstractItemModel-u (diskuse)

[N/A]

K metodě QModelIndex QAbstractItemModel::index(...) se manuál staví tak, že by se měla volat metoda QAbstractItemModel::createIndex(). Takže bych se asi držel tohoto doporučení

[mirec]

Nie som až taká lama ;) Samozrejme vo svojom blogu predpokladám, že čitateľ pozná createIndex. Iná možnosť vytvorenia validného indexu vlastne ani neexistuje. To, čo ma na tej metóde trápi je posledný parameter - interný pointer, alebo interné id.

[mkoubik]

Architekturu Qt bych doporučoval nastudovat všem "lepičům webíků", aby pochopili jak to MVC soudruzi z Xeroxu před těma 40 lety mysleli. Pak by stěží tvrdili "Proč tu instanci modelu cpeš do view? To je strašná prasárna." Z toho pak pramení, že 90% php frameworků není MVC, ale MCV. Osobně mi přijde bližší ten smalltalkovský přístup.

To jen takový OT povzdech, Qt jsem pár let neviděl a tohle mi rozjasnilo den, asi se na to podivám blíž.

[void]

Já model vždy předávám viewu (sice ne u webíků, ale obecně), podle tebe je to dobře, nebo špatně? To jsem úplně nepochopil, jak jsi to myslel.

[Luboš Doležel (Doli)]

Můžu říct, že implementace QAbstractItemModel byla ta největší pakárna, co jsem kdy s Qt měl. Pamatuju si, že jsem pár věcí ohledně ubírání a další manipulace s řádky tipoval a odhadoval, protože ta dokumentace moc detailní nebyla. Možná se to už zlepšilo.

[mirec]

Ja tipujem, že stále rovnaká, len už teraz viem ako implementovať. Ale stále sa nájdu veci, ktoré ma jednoducho zaskočia a neviem ako implementovať. Celkovo mám z toho zmiešané pocity. Na jednej strane je to skvelá myšlienka, na druhej strane sú tu veci, ako parent, ktoré ma vytáčajú. Napr. Cocoa (NSOutlineViewDataSource) nevyžaduje pri stromoch implementovať parent.

[s0]

Poslechnou, Mirec, nechtěj to nějak učesat, dát tomu nějakou formu, začátek a konec a poslat to jako článek, který by navazoval na totok: Grafické programy v Qt 4 – 9 (prezentace dat – architektura model/view)?

[lok]

+1, take se primlouvam za clanek. Bylo by to moc fajn.

[mirec]

No článkov o MVC v Qt je pomerne dosť. Neviem, či by som bol schopný priniesť tu niečo nové o čom ešte nikto nepísal.

Všetky články, ktoré som o implementácii vlastných modelov v Qt čítal sa zaoberali jednoducho riešiteľnými problémami. Buď sa vôbec nezaoberali stromovými štruktúrami, alebo stromy boli vždy priamo v pamäti a nebol teda problém urobiť cast na interný pointer. Existuje ale celá trieda problémov pri ktorých nie je možné všetky dáta udržiavať v pamäti a práve s takýmto problémom som sa ja stretol.

Rád by som tento blog upravil a urobil z neho článok, ale chýba mi naň pár zásadných vecí. V prvom rade hovorím o probléme, ktorý viem vyriešiť len veľmi mizerne nehovoriac o tom, že toto moje "riešenie" nie je vôbec univerzálne a na mnoho problémov vôbec fungovať nemôže. Nechcel by som si vziať na svoju zodpovednosť to, že naučím nových potenciálnych programátorov robiť zlé rýchlo zbastlené riešenia.

Stále ale verím, že sa nájde niekto, kto tomu rozumie viacej ako ja, napíše jeho správne rieštenie do diskusie, ja sa chytím za hlavu a pôjdem sa rovno zakopať ;)

[volvox]

Teda, nevím, jestli úplně rozumím popisu problému, ale co např. implementace QFileSystemModel? Ta nenačítá ihned všechna data náležící modelu a mimo jiné si drží vlastní keš:

QFileSystemModel keeps a cache with file information. The cache is automatically kept up to date using the QFileSystemWatcher.

[mirec]

Ja nemôžem načítať niekoľko miliónov prvkov. Nevojdú sa do RAM a aj keby trvalo by to pridlho. Môžem akurát udržiavať v cache pár prvkov a zvyšok načítať na požiadanie. QFileSystemModel má stálu cache, takže to, čo raz načíta už neodstraňuje, takže problém so zmenou pointrov tam nenastane. Snáď sa nikto nenahnevá za časť zdrojáku:

static_cast<QFileSystemModelPrivate::QFileSystemNode*>(index.internalPointer());

[volvox]

Popravdě, stále mi ten problém nějak uniká. Přijde mi, že je to spíš otázka návrhu, než implementace. Proč podobně jako QFileSystemModel nenačítat data na vyžádání (canFetchMore() a fetchMore()) a nepoužívaná data (tj. jedn. větvě stromu) neodmazávat z modelu dle potřeby. Proto, že by znovu načtená data měla jiný identifikátor/ukazatel? Čemu to ale vadí - k datům přistupuje přímo pouze model a ten už se postará, aby jedn. položky měly platné indexy. Co se týče fragmentu kódu, tak přesně pro tento účel se internalPointer ve stromové struktuře používá, nevidím na tom nic špatného - IMHO ho ale klidně můžete použít pro ukazatel na rodiče.

[mirec]

Proč podobně jako QFileSystemModel nenačítat data na vyžádání (canFetchMore() a fetchMore()) a nepoužívaná data (tj. jedn. větvě stromu) neodmazávat z modelu dle potřeby.

Vymazanie by zneplatnilo indexy a program by padol. Preto nemôžem použiť internalPointer, ale musím mať identifikátor, pomocou ktorého sa jednoznačne dajú nájsť dáta v databáze (internalId).

Čemu to ale vadí - k datům přistupuje přímo pouze model a ten už se postará, aby jedn.

Ak by sa už cache vymazala a ja by som dostal požiadavku na vrátenie dát k položke QModelIndex s neplatným interným pointrom tak môžem maximálne tak zhodiť aplikáciu. Nemám absolútne žiadnu informáciu o tom, ktoré dáta by som mal vrátiť. QModelIndex má akurát riadok, stĺpec a už neexistujúci interný pointer, takže v stromovej štruktúre neexistuje spôsob nájdenia správnych dát.

IMHO ho ale klidně můžete použít pro ukazatel na rodiče.

To viem, ale pre zjednodušenie som popisoval ako vytvoriť index z aktuálneho prvku. Bežne je ale pre mňa praktickejšie keď na prvej úrovni mám internalId 0 a zvyšné podľa rodičov. Stále to ale nie je riešenie, lebo ani rodičia sa do RAM nezmestia ;). S už zmazaným rodičom si teda tiež nijako nepomôžem.

[volvox]

Aha, tak už jsem to konečně pochopil.

Vymazanie by zneplatnilo indexy a program by padol. Preto nemôžem použiť internalPointer, ale musím mať identifikátor, pomocou ktorého sa jednoznačne dajú nájsť dáta v databáze (internalId).

Ano, vymazání položek by zneplatnilo indexy - o tom by se ale napojené pohledy a případné proxy modely dověděly. Při použití indexů si model musí sám hlídat, jestli je index platný (a mimo model by se internalPointer, resp. internalId IMHO používat nemělo - proto už to internal v názvu). Pokud se přesto někde používají, tak ochranou proti dangling pointers by bylo použití některé z smart pointer tříd v Qt.

Použití internalId tak, jak ho používáte teď, je IMHO v rozporu s určením třídy QModelIndex. Ta by měla sloužit jako index pro model, ne jako index pro data.

Co se týče řešení problému, napadají mě tyto možnosti:

1. napojit všechny objekty, které komunikují s modelem pomocí indexů tak, aby se dozvěděly, že došlo k zneplatnění indexu, ať už se postarají sami, co s tím - to zřejmě vyhovovat nebude
2. nemazat již vytvořené položky stromy, ale pouze jejich data - polovičaté řešení, ale v určitých případech by mohlo stačit
3. implementovat vlastní model index s informací, jak se dobrat k rodiči - tady je ale třeba mít na mysli, že indexy celkem masivně vznikají a zanikají a zásadně tím ovlivňují výkon a IMHO je to celkově v rozporu s návrhem indexů
4. mazat pouze nepoužívané položky (ve smyslu, že ve zbytku aplikace na ně nejsou indexy) - to by snad šlo implementovat pomocí QExplicitlySharedDataPointer a QSharedData

Případně nějaký mix, ale věřím, že s tím něco půjde dělat ;) Na druhou stranu s Qt (a vlastně i s c++) jsem začal teprve před půl rokem a napsal jedinou aplikaci, takže na nějakou odbornou diskusi nemám a popravdě jsem se už úplně vyčerpal ;)

[mirec]

Ja si tie indexy moc neviem ustrážiť v rámci modelu, inak mimo internalPointer nepoužívam.

Takže k dynamickému vymazaniu položiek ... no je to síce teoreticky pekné (a je na to zopár tried, takže stálo by to minimálnu námahu). Takýto postup som neskúšal, možno, že by navonok aj vyzeral ako funkčný ... ale nemám rád ani teoretickú možnosť zhodenia aplikácie takouto trivialitou.

Uvažujme situáciu, že mám model, view si z neho nejako berie dáta. V cache udržiavam pár položiek + cestu k nim. Cesta sa vyhodí z cache až vtedy keď sa odstránia aj položky cache, takže nejakým hrabnutím na parent nič nezhodím. Uvažujem situáciu, že užívateľ dosť brutálne scrolluje v zozname. Udalosti sa ukladajú do fronty. Povedzme, že vyhodím časť cache, ale vo fronte bude ešte požiadavka na volanie parent s parametrom index odkazujúcim na už odstránený prvok. Viem, že situácia, že toto nastane je pomerne zriedkavá, ale nie nemožná a mať aplikáciu, ktorá sa dá zhodiť obyčajným scrollovaním práve nechcem.

implementovat vlastní model index s informací, jak se dobrat k rodiči - tady je ale třeba mít na mysli, že indexy celkem masivně vznikají a zanikají a zásadně tím ovlivňují výkon a IMHO je to celkově v rozporu s návrhem indexů

V podstate je tu viacej zaujímavých nápadov, ale u tohto mi nedá nereagovať. Situácia je skutočne taká, že indexy dosť masívne vznikajú a zanikajú. Rozmýšľal som tak nad indexom, ktorý by mal odkaz na nadradený index a tie odkazy automaticky spravovať (automatické pointre a tak). Určite je tam veľa technických prekážok, ale to je asi tak moja predstava ideálneho indexu. Pomocou indexu by sa dala získať celá cesta. Len neviem ako by som to reálne implementoval ;)

[Jardík]

Ty vole, oni indexujou intama a já ve svém modelu potřebuju 3 miliardy položek a na mém systému to má rozsah jen -+2mld+-autobus ...
QModelIndex je akorát zpomalování a zabírá místo. Zlatý size_t/ptrdiff_t. Neustálé vytváření a ničení QVariant, to musí být opět rychlé. Já teda neříkám, že to je úplně špatné, třeba pro snadnost ano, ale pokud potřebuju napsat listview bez stromové struktury, tak je mnohem lepší mít pro indexaci nějaký POD typ (nejlépe něco stejně velikého jako pointer, třeba i znaménkový ptrdiff_t, ale pořád lepší než int).

Ja pre tento účel využijem hodnotu interného id. Ak vieme, že v tabuľke nebude > 2^30 hodnôt môžeme vrchné 2 bity obetovať na identifikátor tabuľky

Zase něco předpokládáme? Třeba velikost intu? Nebo jste použil něco jako qint32 (jestli to existuje)?

[mirec]

Tak od tohto komentáru som čakal viacej, takže pekne poporiadku ;)

Ty vole, oni indexujou intama a já ve svém modelu potřebuju 3 miliardy položek a na mém systému to má rozsah jen -+2mld+-autobus

Áno aj nie, je možné vytvárať model priamo z pointra a vtedy je veľkosť podľa platformy. Je možné vytvoriť index aj z ich 32-bitového int-u a ten zdieľa rovnaké pamäťové miesto ako pointer (klasický union, žiadna mágia). Klasický zoznam teda v žiadnom prípade nebude slabinou ich MVC architektúry. Ale stačí môj príklad s 3-úrovňovou štruktúrou a už neviem nájsť elegantné riešenie (to, ktoré som použil je len núdzové).

Zase něco předpokládáme? Třeba velikost intu? Nebo jste použil něco jako qint32 (jestli to existuje)?

createIndex(int row, int column, quint32 id) const

Ako alternatívu som mohol použiť interný pointer a správať sa k nemu nie ako k pointru, ale ako k číslu.

createIndex(int row, int column, void * ptr = 0)
zdroj

[Jardík]

createIndex(int row, int column, quint32 id) const

Ok, vždyť já se ptal. Oni v Qt rádi používají inty či longy k přetypování z pointeru, tak jsem se chtěl ujistit, jestli tu opravdu je typ s pevnou velikostí. Jinak to s tím indexováním intem souvisí i s tím int QAbstractItemModel::rowCount(const QModelIndex &parent = QModelIndex()) - vrací to int, takže počet řádků je daný intem - je to sice pro toho rodiče a tak by jich teoreticky mohlo víc, ale kdo ví, jak to pak Qt sčítá.

[Jardík]

Jinak s Qt nedělám, takže skoro nic o tom nevím, tak jestli plácám blbosti, tak sry.

[kralyk z abclinuxu]

Oni v Qt rádi používají inty či longy k přetypování z pointeru

Opravdu?

[Jardík]

Mám to hledat? Jestli o to opravdu stojíš, tak ti to najdu.

[Jardík]

Prosim. Projděte si commity a koukněte, co tam bylo za prasárny. Díky projektu mingw-w64 se je daří eliminovat, protože vývojáři chytře opatchovali či nastavili mingw, aby ve výchozím nastavení explicitní přetypování pointeru na číselný typ o jiné velikosti hlásil jako error a né jen obyčejný warning. MSVC build 64bit Qt (naposledy jsem zkoušel 4.6) byl právě plný náhodných pádů kvůli takovým kravinám - nahlásí warning, ale ten se v té smršti výpisů snadno ztratí.

[kralyk z abclinuxu]

Ok, díky za link.
Co se týče MSVC na 64-bitech tak to je demence největší. Qt se mi nepodařilo zkompilovat ve verzích 4.6.2 a 4.6.3 v žádné z možných konfigurací...
Takže musím mingw. Je to s mingw-w64 už funkční?

[Jardík]

Někde jsem tu kdysi dával 64bit Aroru (prohlížeč), tuším, že i s Qt knihovnama. Bylo to zkompilovaný s MSVC, ale občas to padalo (právě kvůli těm úchylným přetypováním). Jinak MSVC to zkompilovalo hned (s warningama), s mingw-w64 se mi podařilo (ručně jsem tam opravoval typecasty podle patchů pro jinou verzi) zkompilovat akorát debug build, release hlásil nedefinované symboli při linkování. Jinak už je to dýl, Qt 4.7 možná půjde v poho, netuším, možná zkusím.

[Ivan]

To kopirovani QVariant-u je fakt opruz. Zrovna ted jsem neco fixoval v jednom OS projektu a nestacil jsem se divit kolikrat se musi QVariant zkopirovat mezi nactenim dat z DB a jejich zobrazenim na obrazovce. V pripade ze QVariant obsahuje cislo nebo string tak to tak moc nevadi(QString-y jsou sdilene), ale QVariant umoznuje drizet "libovolny" datovy typ ktery je zaregistrovan pres Q_METATYPE a ktery ma copy-construktor.

Prislo mi, ze cely kod by byl efektivnejsi, kdyby byl napsany v JAVE nebo Pythonu, kde se vsechno predava referenci.

[Rezza]

Jak to cele vznikalo a to same i na videu.

[Jan Švec]

Poněvadž jsem už několik QtModelů implementoval (sice v PyQt, ale sémanticky to je totéž), dovolím si vložit kód metod index() a parent():

    def index(self, row, column, parent):
        if row < 0 or column < 0 or row >= self.rowCount(parent) or column >= self.columnCount(parent):
            return QtCore.QModelIndex()

        if not parent.isValid():
            # koren
            return self.createIndex(row, column, self.items[row])
        else:
            # deti
            item = parent.internalPointer()
            if item not in self._records_cache:
                self._records_cache[item] = list(item.records.values())
            records = self._records_cache[item]
            return self.createIndex(row, column, records[row])

    def parent(self, child):
        data = child.internalPointer()
        if isinstance(data, archive.Item):
            # koren
            return QtCore.QModelIndex()
        elif isinstance(data, archive.Record):
            # deti
            record = data
            item = record.item
            row = self.items.index(item)
            column = 0
            parent = QtCore.QModelIndex() # takto se ziska index pro ktery isValid() je False, tj. rodic je korenova polozka
            return self.index(row, column, parent)
        else:
            return QtCore.QModelIndex()

internalPointer slouží čistě k vašim potřebám. Dá se do něj uložit třeba primary key zobrazované položky, která se na tom indexu (buňce) nachází, cesta k elementu v XML, cokoli se vám zachce. V příkladu výše se do internalPointeru ukládá odkaz na SQLAlchemy položku z databáze.

Ještě jsem v komentářích viděl zmínku o neustálém vytváření a rušení QVariant - věřte, že view volá data() pouze pro položky, které má zobrazit. A na obrazovku se najednou více než pár stovek buněk nevejde. Jediné, kde to zpomaluje je pokud nastavíte přizpůsobení šířky sloupce view podle obsahu, pak to musí projít všechny indexy v daném sloupci, aby zjistilo ten nejdelší.

[mirec]

Tiež takto riešim implementáciu index a parent ak je to možné. V mojom príklade by to ale padlo na tomto:

 self._records_cache[item] = list(item.records.values())

U mňa totiž po určitej dobe nepoužívania (neberte to ako časovo, ale počet prístupov) vymažem položku item, takže internalPointer by už ukazoval na neplatnú pamäť. Preto to riešim znásilňovaním interného id vrchnými bitmi, ktoré v tomto prípade moc nevyužijem. To, čo zostalo dole je id v databáze.

Ještě jsem v komentářích viděl zmínku o neustálém vytváření a rušení QVariant - věřte, že view volá data() pouze pro položky, které má zobrazit.

Toto tvrdenie trochu poopravím pretože nie je to celkom pravda. Pri QTreeView-u ešte musí byť nastavené uniformRowHeights na true. No a keď už o tom píšem záťaž spôsobená QVariant-om je zanedbateľná.

[Jan Kundrát (jkt)]

Clanek i diskusi pod nim jsem cetl pomerne zbezne, ale mam pocit, ze problemy s "uz zneplatnenym internalid/ptr" jsou zpusobene tim, ze si aplikace "nekde" necha QModelIndex. V dokumentaci se dost jasne pise, ze se to nema delat, ze QModelIndex muze byt pomerne rychle zneplatnen (resp. explicitne se tam poukazuje na zneplatneni po modifikacich modelu). Verim tomu, ze pokud si aplikace potrebuje index pamatovat o neco dele, ma pouzit QPersistentModelIndex. Nejsem si ovsem jisty, jestli to zcela odpovida na autorovy dotazy.