Boj s modelmi v Qt4 - Epizóda 2

16.9.2010 20:40 | Přečteno: 1090× | Linux | poslední úprava: 16.9.2010 20:38

Môj dnešný blog o modeloch v Qt sa bude podobne ako ten predchádzajúci zaoberať jediným konkrétnym problémom, na ktorý sa budem snažiť nájsť elegantné a všeobecné riešenie. Tým dnešným orieškom na zamyslenie bude použitie QAbstractProxyModel-u na filtrovanie podstromu.

Tento blog začnem popisom problému, na ktorý som narazil. Problém je mierne modifikovaný tak, aby sa nedal vyriešiť rovnakým spôsobom, aký som použil.

V poslednej dobe využívam pri tvorbe GUI jazyk QML. Pre zobrazenie dát modelu existuje niekoľko elementov, ale žiaden nepodporuje priamo zobrazenie stromu. Pre zobrazenie stromovej štruktúry som sa rozhodol použiť 2 elementy ListView. Jeden z nich bude zobrazovať ako zoznam prvú úroveň stromu. Druhý zoznam bude mať rozbaľovacie prvky a bude zobrazovať všetky podúrovne od 2. úrovne. O zobrazenie podstromov sa budú starať elementy zoznamu (delegate). Samotným zobrazovaním sa v tomto blogu nebudeme zaoberať, jediné, o čo sa pokúsime bude príprava modelu.

Našim cieľom je vytvorenie nového modelu filtrujúceho dáta iného modelu takým spôsobom, aby vybraný index v starom modeli vystupoval v novom modeli ako koreňový index. Pokúsime sa dosiahnuť rovnaké správanie, ako QAbstractItemView::setRootIndex. Výsledok by mal vyzerať asi takto:

K článku je zverejnený aj ukážkový program, ktorý demonštruje to, čo chcem dosiahnuť.

Filtrovanie modelu

Základnou triedou pre filtrovanie modelov v Qt je QAbstractProxyModel. V podstate ide o obyčajný model, ktorý ako zdroj dát používa iný model. Pre tento prípad filtrovania nie je možné použiť QSortFilterProxyModel.

Pre jednoznačné určenie prvku v modeli používa Qt triedu QModelIndex. Napriek tomu, že QAbstractProxyModel bude len odkazovať na dáta iného modelu musí používať vlastné unikátne indexy. V novom modeli budeme musieť implementovať niekoľko nasledujúcich metód.

QModelIndex index(int row, int column, const QModelIndex &parent)

Volanie tejto metódy si vyžaduje vytvorenie vlastného indexu modelu. Metódy na vytvorenie indexu sú: createIndex(int row, int column, void *ptr) a createIndex(int row, int column, quint32 id).

Prvý problém, ktorý musíme vyriešiť je nájdenie indexu v zdrojovom modeli, ktorý zodpovedá indexu parent v proxy modeli. Na vyhľadanie môžeme využiť metódu mapToSource.

Ďalším problémom je posledný parameter metódy creteIndex. Ten musí byť zvolený tak, aby sa podľa neho dal jednoznačne nájsť index v zdrojovom modeli. Nepoznám korektný spôsob ako vytvárať tieto indexy bez toho, aby proxy model obsahoval dátovú štruktúru (strom), ktorý sa musí synchronizovať s podstromom zdrojového modelu.

QModelIndex parent(const QModelIndex &index)

Táto metóda má vracať nadradený index. Pre vyhľadanie indexu v pôvodnom modeli použijeme znovu metódu mapToSource. Podľa zdrojového modelu zistíme nadradený prvok a z neho vytvoríme index. Pre koreňový index nebude nadradený index validný.

QModelIndex mapFromSource(const QModelIndex &sourceIndex)

Táto metóda slúži na prevod indexu zo zdrojového modelu na index proxy modelu. Pri vytvorení indexu musíme vedieť interné id, alebo interný pointer. Tie musia byť vo vhodnej dátovej štruktúre tak, aby sa dali rýchlo vyhľadať. Neexistuje spôsob ako získať interné id / pointer priamo zo zdrojového indexu (ak neberieme do úvahy možnosť používania interného id / pointra zdrojového indexu).

QModelIndex mapToSource(const QModelIndex &proxyIndex)

Prevod indexu z proxy modelu na index zdrojového modelu zabezpečuje táto metóda. Pri jej implementácii musíme zase použiť štruktúru pre vyhľadanie, ktorá sa musí udržiavať synchronizovaná so zdrojovým modelom.

Synchronizácia so zdrojovým modelom

K synchronizácii uvediem len zoznam signálov zdrojového modelu, ktoré treba odchytiť, vyslať podľa nich príslušné signály a podľa potreby aj upraviť dáta proxy modelu.

dataChanged(QModelIndex,QModelIndex)
headerDataChanged(Qt::Orientation,int,int)
rowsAboutToBeInserted(QModelIndex,int,int)
rowsInserted(QModelIndex,int,int)
columnsAboutToBeInserted(QModelIndex,int,int)
columnsInserted(QModelIndex,int,int)
rowsAboutToBeRemoved(QModelIndex,int,int)
rowsRemoved(QModelIndex,int,int)
columnsAboutToBeRemoved(QModelIndex,int,int)
columnsRemoved(QModelIndex,int,int)
layoutAboutToBeChanged()
layoutChanged()
modelAboutToBeReset()
modelReset()

Záver

V tomto blogu som sa snažil načrtnúť ďalší z problémov, na ktoré som narazil pri použití MVC. Napriek veľmi jednoduchému zadaniu sa problém ukázal byť omnoho zložitejší než som čakal. Dokážem síce tento problém vyriešiť tak, aby kód fungoval, ale nebolo by to čistým spôsobom. Prakticky akákoľvek manipulácia s interným id / interným pointrom modelu mimo samotného modelu je veľmi nebezpečná.

Ak máte akýkoľvek nápad na korektné riešenie budem veľmi rád ak to zverejníte do diskusie.

       

Obrázky

Komentáře

[mirec]

Příloha:

• itemview.tar.bz2 (1475 bytů)

Sľúbený ukážkový program

[Jardík]

Zdravím. Potřeboval bych do listview dát 3 miliardy položek, jak toho docílím? Musím psát vlastní widget?

[mirec]

Nie len widget, ale aj celú MVC architektúru ;) Radšej ani nespomeniem aký typ sa používa na adresovanie v QVector-e ;)

[Ladicek]

Předpokládejme, že paměťové nároky na jednu položku v listview jsou 10 bajtů (ve skutečnosti to bude výrazně víc). To je 30 giga jen na ten listview – s dostatkem swapu je možná naalokuješ, ale to je všechno. Už jsi poslal ten životopis do SUSE?

[mirec]

Lenže tie dáta nemusia byť v RAM. Berme čiste teoretickú situáciu, že chceme postaviť hex editor, ktorého základom bude MVC z Qt. Vďaka tomu, že model môže načítavať dáta až keď sú potrebné bude editor pomerne rýchly a nenáročný. Lenže povedzme, že užívateľ chce na jednom riadku zobrazovať 4 bajty (teda spolu v hex zobrazení 8 znakov). To už sa dostaneme na celkom rozumných 12 giga. Ak si predstavíme, že niekto chce vyhrabať informáciu z konca 12 GB súboru (povedzme, že je to HD video s hlavičkou na konci) tak bude mať smolu len kvôli tomu, že bol použitý nesprávny typ pri adresovaní. Ale v podstate ani keby používali size_t nebola by to na 32 bitovom systéme výhra. Na adresovanie súborov tu máme offset_t, takže ani size_t by v takom prípade nebolo najsprávnejšie.

[Jardík]

Stejně nechápu, co je vedlo k použití typu int. Alespoň od Qt4 to mohli "opravit" a použít nějaký normálnější typ. Třeba size_t, intptr_t, uintptr_t, ptrdiff_t, ... prostě něco stejně velkýho jako pointer. Vždyť teď ani do toho QVectoru nenarvu 3mld intů (to je nějakých 12GB, takže s 16GB to není problém).

[Josef Kufner]

Dej tam (pokud možno reprezentativní) dva tisíce a doufej, že si toho uživatel nevšimne

[Heron]

Nevšimne, protože při listování se mohou dynamicky načítat další položky. Pak bude list obsahovat 2000 položek a uživatel si jich může prohlédnout klidně 3mld.

[xkucf03]

Na webu se taková situace běžně řeší pomocí stránkování – buď ručního (klíkání na čísla nebo další/předchozí) nebo automaticky – např. tabulka, dojedeš k jejímu konci a v tu chvíli se přes AJAX dotáhnou další záznamy. V klasické aplikaci to chce řešit podobně.

Navíc je nesmysl cpát do GUI (které je určené pro člověka) miliardy záznamů (ono i tisíce jsou dost), protože člověk si je stejně nikdy nepřečte. Takže tu stejně musí být nějaký další mechanismus, např. filtrování nebo hledání, aby ses dostal na rozumný počet položek. Je otázka, jestli má smysl někde zobrazovat i ten nefiltrovaný výsledek, který stejně nikdo číst nebude.

[mirec]

Ehm čo tak okteta? Hex editor schopný pracovať s pomerne veľkými súbormi, skokom na konkrétnu adresu, vyhľadávanie ... Na použitie s MVC ako vyšité.

[Jardík]

Naposledy, když jsem zkoušel oktetu, tak s velkými soubory (10GB+) pracovat rozhodně neuměla. Takový wxHexEditor to umí docela dobře.

[mirec]

A kto tu tvrdí, že vie? Už len kvôli MVC to vedieť nebude. Ja som len uvádzal príklad programu, kde by sa niečo väčšie ako int oplatilo použiť a nie je to len nejaký vymyslený umelý príklad.