Grafické programy v Qt 4 – 9 (prezentace dat – architektura model/view)

19. 11. 2009 | Petr Vaněk

Články - Grafické programy v Qt 4 – 9 (prezentace dat – architektura model/view)  

Dnes se naučíme používat widgety, kterými programátor dokáže zobrazit související data: seznamy, tabulky, stromy. Jejich plnění, editaci, ale také přizpůsobení vlastním potřebám. Pořadem vás provází Úžasný Móric a krásná dívka.

Obsah

• Model-View a Controller?
  • Příklad použití
• Modely
  • Typy modelů
  • Role prvků
• View
  • Typy view widgetů
• Delegát
• Proxy Modely
• Item View Widgety
• Popis příkladu a shrnutí

Po delší odmlce v seriálu o Qt4 jsme zpět. Doufám, že přestávka způsobená mou leností bude omluvena následujícími články, a zároveň doufám, že vážený čtenář snese dočasnou změnu autora.

Tento a příští článek seriálu bude poněkud jiný. Nebude obsahovat tolik kódu jako díly předchozí, ale přesto o oblíbený příklad nepřijdete.

Zároveň ale předpokládám, že tento článek bude pouze odrazovým můstkem ke studiu oficiální dokumentace, kde jsou popsány další metody, signály a závislosti.

Model-View a Controller?

V dávných dobách Qt3 se data do všelikých widgetů se seznamy, tabulkami a stromy plnila pomocí tzv. itemů. Qt4 sice takové plnění umožňuje také, ale jedná se pouze o obalené základní (a preferované) třídy view s vhodným modelem. Autoři Qt4 si od nového frameworku slibovali jednodušší práci a zásadní zrychlení interakce s datovými widgety. To druhé se podařilo beze zbytku, to první nechť si rozhodne každý sám dle osobních preferencí.

ukázka widgetů s modely: vlevo QListView, vpravo nahoře QTableView, dole QTreeView

Model-View-Controller (dále MVC) je klasický princip SW architektury. Je tak klasický, až prastarý, že budu dále předpokládat čtenářovu znalost, zkušenost anebo schopnost samostudia. Jen ve stručnosti:

• Model se o data stará, tj. drží je fyzicky (nebo je dokáže načíst z externích zdrojů – databáze, soubor, síť).
• View je zobrazuje.
• Controller obhospodařuje události, které data mění – uživatelské vstupy.

Všechny tyto části by měly být nahraditelné jinými a zároveň na sobě nezávislé.

V terminologii Qt4 je všechno trošku zjednodušeno a roli Controlleru přebírá View, respektive se o práci dělí s objekty Delegate. Proto v Qt platí:

• Úloha Modelu zůstává stejná jako ve standardním schématu MVC. Model musí implementovat alespoň minimální API, aby mohl spolupracovat s Qt View.
• View data zobrazuje a nabízí základní editační nástroje (implicitní Delegate), pokud je podporuje Model, tj. pokud Model umí nebo má nastaven zápis dat.
• Složitější interaktivní vstup dat spravují specializované instance Delegate.
• Komunikace mezi jednotlivými komponentami probíhá přes signály a sloty.
• Jednotlivé komponenty jsou vždy potomkem své abstraktní třídy. Tyto abstraktní třídy nejsou nikdy použity samy o sobě, ale pouze reimplementovány dědičností. (Ony třídy s čistě virtuálními metodami přímo použít ani nejdou.)

Příklad použití

QStringModel * m = new QStringModel();
 
QStringList lst;
lst << "foo" << "bar";
m->setStringList(lst);
 
QListView * v = new QListView();
v->setModel(m);
 
// oba view widgety budou zobrazovat stejna data
QTableView * t = new QTableView();
t->setModel(m);

Modely

Všechny modely v Qt musí být potomkem třídy QAbstractItemModel. Data samotná nemusí být přímo agregována v instanci modelu, ale model je může na vyžádání načítat podle potřeby (např. modul QtSql).

Jakákoliv informace z modelu je z view odkazována přes QModelIndex, tj. dočasný odkaz na pozici v modelu. Tyto odkazy jsou platné pouze v aktuální okamžik a po změně hodnot dat (oznámeno signálem) se mohou změnit. QModelIndex určuje pozici dané položky svými atributy:

• rodič (parent)
• sloupec
• řada

Všechny indexy daného modelu mají alespoň jednoho rodiče – tzv. Root Item. Parent indexu je zásadním údajem ve stromových strukturách, zatímco v jednoúrovňových seznamech není příliš podstatný. Řada a sloupec indexu je vždy uváděna relativně ke svému rodiči.

Typy modelů

• QAbstractItemModel: Základní třída všech modelů. Je možné implementovat seznam, tabulku a strom.
• QAbstractListModel: Abstraktní třída, tedy není určena k přímému použití, s pomocnými nástroji pro seznamy a stromy.
• QAbstractTableModel: Abstraktní třída s pomocnými nástroji na implementaci tabulek.

K přímému použití jsou už implementovány některé další třídy:

• QStringListModel: Zobrazení QString řetězců v seznamu.
• QStandardItemModel: Funkční základní model, který umožňuje pracovat se složitými strukturami. Svým použitím se blíží Item Widgetům (vizte dále) nebo starším widgetům z Qt3.
• QDirModel: Plně funkční model, který zobrazuje obsah lokálních souborových systémů.
• Modely z modulu QtSql. Více v následujícím dílu seriálu.

Subjektivní postřeh z praxe: QStandardItemModel jsem přestal používat poměrně brzy a začal si reimplementovat modely vlastní přímo z odpovídajících modelů abstratních. Přišlo mi, že spojovaly nevýhody MVC a Item Widgetů.

Role prvků

Každý prvek (item) modelu může obsahovat různá data, která se ve widgetech view zobrazují v různých rolích. View si pak sám přes metodu QAbstractItemModel::data() jednotlivé role načítá a zobrazuje je podle své implementace. Role definují, co bude pro daný index zobrazeno. Celou problematiku nejlépe osvětlí krátká ukázka kódu, popř. přiložený příklad (vytrženo z reálného programu):

QVariant CharTableModel::data(const QModelIndex &index, int role) const
{
    if (!index.isValid())
        return QVariant();
…
    // ctecky pro nevidome, nebo se casto pouziva jako zdroj dat pri drag&drop
    if (role == Qt::AccessibleTextRole && column == 0)
        return m_characters[ix];
    // tooltip
    if (role == Qt::ToolTipRole)
    {
        QString tmp;
        tmp.sprintf("%04X", currentChar);
        return "Unicode:\n0x"+tmp;
    }
    // vygeneruj obrazek, ktery se zobrazi jako ikona
    if (role == Qt::DecorationRole && column == 1)
    {
         … generuj obrazek…
         return QVariant(QPixmap::fromImage(pix));
    }
    // jestlize je to cislo, pak zarovnej doprava jako v tabulkovem procesoru
    if (role == Qt::TextAlignmentRole)
    {
        bool ok;
        curr.toDouble(&ok);
        if (ok)
            return QVariant(Qt::AlignRight | Qt::AlignTop);
        return QVariant(Qt::AlignTop);
    }
…

View

V Qt se jako View označují widgety, které jsou schopné zobrazovat data, která jim předává asociovaný model. Přičemž jeden model může být napojen na několik view widgetů.

Všechny view widgety musí být potomkem třídy QAbstractItemView a implementovat alespoň minimální API. Zobrazení dat je plně v režii view widgetu, proto není problém data jednoho modelu jednou zobrazovat jako tabulku, zároveň jako graf anebo třeba stromovou strukturu.

rozdílná vizualizace jednoho modelu: vlevo tabulka (všechna data modelu), vpravo koláčový graf (pouze „Quantity“)

Jednotlivé prvky modelu, identifikované svým QModelIndexem, může view zobrazovat sám anebo může použít zobrazení pomocí delegáta tak, jak je použito v příkladu – vizte kapitolu „Popis příkladu“.

Další velmi podstatnou úlohou view widgetů je správa označených prvků modelu (selections). Abychom byli přesní, tak výběry nezpracovává přímo view, ale další specializovaný model QItemSelectionModel, který je ale přístupný pouze z dané instance view (QAbstractItemView::selectionModel()).

Typy view widgetů

Standardní widgety, které lze rovnou použít bez jakéhokoliv zásahu:

• QListView – view, který zobrazuje jen jeden sloupec dat.
• QTableView – zobrazí model jako tabulku
• QTreeView – stromová struktura dat. Model musí strom implementovat.

Delegát

View widgety se také starají o uživatelský vstup. Proto je v Qt zaveden pojem delegate/delegát. Delegát je widget, kterým view:

• zpracovává uživatelské vstupy, přičemž různé indexy modelu (sloupce, řady) mohou mít nastavené různé delegáty,
• umožňuje implementovat specifické zobrazování dat – na rozdíl od rolí dat v modelu je možné např. využít složitější kreslení přímo do widgetu (bez generování QPixmap v DecorationRole) atd.

Pokud uživatel aktivuje (závisí na jeho platformě/operačním systému) prvek view widgetu (model musí být editovatelný, viz metoda flags()), view vytvoří potřebný delegát a naplní jej odpovídajícími daty z modelu. Pokud programátor nenastavil nově vytvořeného delagáta, view použije jeden z předdefinovaných implicitních delegátů v závislosti na typu editovaných dat – delegáta založeného na QLineEdit, QSpinBox apod.

Na jednoduché editace tyto implicitní editory často stačí, ale komplexnější data je většinou potřeba editovat jinak. Typickým příkladem mohou být multimediální data, struktury geografických systémů atd.

Vlevo implicitní delegát založený na QLineEditu.
Vpravo reimplementovaný delegát s rozsáhlejší
funkcionalitou (editace v databázi, tlačítka
„vlož NULL hodnotu“ a „otevři editor jako modální dialog“).

Implementace specializovaných delegátů musí vycházet z API třídy QAbstractItemDelegate, což bude vyžadovat více ruční práce, anebo použít QStyledItemDelegate či starší QItemDelegate.

Proxy Modely

Modely samy o sobě neumí zobrazovaná data řadit a filtrovat. Existuje ale specializovaná třída QSortFilterProxyModel, také potomek QAbstractItemModelu, která filtrování a řazení dat umí, aniž by se tato data fyzicky měnila ve zdrojovém modelu.

Modelová situace:

• existující (reimplementovaný) standardní model s daty
• view, ve kterém chceme data řadit a zobrazovat jen ta, která odpovídají uživatelskému filtru

  MyModel * model = new MyModel(); // predpokladejme, ze konstruktor nacte data
  QTableView * view = new QTableView();
  // view->setModel(model); nepouzijeme, protoze chceme filtrovat a tridit
  QSortFilterProxyModel * proxyModel = new QSortFilterProxyModel();
  // model se zdrojovymi daty podstrcime proxy modelu
  proxyModel->setSourceModel(model)
  // a proxy model nasatvime do view
  view->setModel(proxyModel);
  …
  // uzivatel v nejakem widgetu nastavil filtr,
  // ten se pres signal a slot prenese do naseho proxy modelu.
  // Proxy model sam zablokuje nechtena data. Ta ale ve zdrojovem
  // modelu stale zustavaji
  proxyModel->setFilterWildcard("foo*");

Existující implementace QSortFilterProxyModel umí řadit pouze lexikograficky, tj. vše se pokusí převést na řetězce a ty pak porovná. Pokud chceme řadit data ve sloupci např. podle číselné hodnoty, anebo podle „ikonek“, musíme implementovat vlastní proxy model, který bude potomkem QSortFilterProxyModelu, a dokáže rozhodnout, které číslo nebo která QPixmapa je větší než druhá (metoda lessThan()).

Item View Widgety

Jedinou možností, jak plnit data do „seznamových“ widgetů v Qt3 a starších byly tzv. item widgety. V Qt4 je funkcionalita zachována, přičemž se jedná o specializované spojení modelu a odpovídajícího view widgetu.

Vezměme například jednoduchý seznam: Místo QListView a vlastnoručně implementovaného modelu je možné použít QListWidget a data plnit do instancí QListWidgetItem. Často používaný způsob práce je např.:

QListWidget * w = new QListWidget();
QString temp("%1");
for (int i = 0; i < 10; ++i)
    w->addItem(new QListWidgetItem(QIcon("foo.png"), temp.arg(i));

Z ukázky je patrná zřejmě největší výhoda item widgetů: práce s nimi je, alespoň na první pohled, jednodušší. Není třeba implementovat vlastní modely, vkládání dat je „klasické“.

Na druhý pohled, anebo časem v reálném nasazení, se ale objeví některé zápory daného řešení:

• Item widgety jsou obecně výkonnostně náročnější než obdobná implementace model-view. Příklad z praxe: V jednom programu se mi podařilo odstranit „tuhnutí“ GUI právě přepsáním z QTableWidget na QTableView s vlastním modelem. Původní řešení načítalo data z databáze a v cyklu je plnilo do QTableWidgetItemů. Doba zpracování se dala měřit ve vteřinách. Nová implementace načítá stejná data s využitím metod QAbstractItemModel::canFetchMore(), QAbstractItemModel::fetchMore(). Naplnění modelu je lidským okem nepozorovatelné.
• Jakákoliv další úprava (změna pozadí, písma, zarovnání textu, složítější editace) itemu je sice možná, ale je náročnější a složitější než model-delegate.
• Úprava a mazání dat ve většině případů znamená projít všechny itemy. A protože je programátor líný, tak stejně použije enterprise metodiku: „Všechno smaž, pak naplň znovu.“ Výrobci hardwaru se radují.

Proto je, stejně jako v jakémkoli jiném případě, velmi vhodné používat mozek a dopředu si zanalyzovat, jaká, kolik a jak často měněná data budu v daném případě zobrazovat. Na seznam tří ikonek v konfiguračním dialogu se mi opravdu psát vlatní model nevyplatí.

Popis příkladu a shrnutí

V přiloženém balíčku je ukázkový spustitelný program, který ukazuje tak trochu nestandardní použití model-view-delegate. Hlavní funkčnost spočívá v jakési „lupě“, tedy zobrazení fotografie v tabulce, kde každá buňka tabulky patří právě jednomu pixelu obrázku. Při změně aktuální buňky tabulky se mění další informace o buňce v externích widgetech.

Zdrojové kódy příkladu (qmake; make).

Příklad v akci.

Co mne vedlo zrovna k takovému příkladu? Rád bych, aby si čtenář hned zpočátku (pokud je Qt začátečník) uvědomil, že popisovaná doména může mít celu řadu použití, a že jako programátor ji nemusí využívat na prosté seznamy a strohé tabulky.

Implementaci jsem zvolil pomocí výše uvedené techniky „delegát zobrazuje data“, protože je v tomto případě subjektivně snazší kreslit do samostatného widgetu, delegáta, než generovat bitmapu a ošetřovat její korektní umístění do view přes model::data() – není nutné řešit otázku zarovnávání apod.

Klasické použití model-view-delegate si ukážeme v díle následujícím, přičemž celou problematiku okořeníme trochou SQL a databázemi obecně.

Seriál Qt 4 - psaní grafických programů (dílů: 12)

První díl: Grafické programy v Qt 4 - 1 (úvod, hello world), poslední díl: Grafické programy v Qt 4 – 12 (stylování GUI pomocí CSS).
Předchozí díl: Grafické programy v Qt 4 – 8 (TCP klient)
Následující díl: Grafické programy v Qt 4 – 10 (SQL)

Diskuse k tomuto článku

[dad]

na me to vsechno pusobi silene depresivne. Hlavne mam problem vubec vyjadrit, co me tak tisni. Presto se to pokusim nejak formulovat.

Celym clankem se nese jakasi abstrakce. Samej model, proxy, jeden element neco neumi, ale o to se stara zase nekdo jiny, v detailu ovsem ten 'tridic' umi jen stringy a ne cisla, to je treba si dodelat. Pripadam si na takovem rozcesti, kdy si rikam, kdybych to umel pochopit, co pan Vanek rika, tak bych byl asi zadanej specialista, ale pak mi neco naseptava , co je to s tou celou abstrakci, kdyz to vsechno visi jen na Qt.

Jako praktik se ptam, kdyz bych to mel prepsat do Qt, fox-toolkitu, fltk, wxwidget .. co vsechno by zbylo.

Co me ale nejvic trapi je takovy pocit, ze je treba vynalozit silene moc energie na to 'mysleni' v tom systemu misto toho , abych se venoval zakaznikovi. Neco mi nejak rika, ze tohle neni spravna cesta. Lide kteri delaji zakaznicke software se s necim takovym nemohou prece do hloubky zabyvat. Chybi mi tady nejaka mezivrstva pro aplikacni programatory.

[Espinosa]

Jo na mě působil na univerzitě každý druhý předmět depresivně. Těch knížek, teorií, vzorců, huh, i po osmi letech mě to někdy budí ze sna (hmm, ne, nejvíc mě budí ze sna chybějící kredity, nejlépe když se na ně přijde těsně před státnicí

Jestli to myslíte s programováním alespoň trochu vážně, tak se připravte na to, že hromada tísnivých, zdánlivě neuchopitelných, informací se na vás povalí s každým novým projektem. Technické záležitosti, jako MVC, je obvykle ta lehčí záležitost! Jsou k tomu manuály, tutoriály, poradny, články na ABC. Horší je to s věcnou problematikou. Naprogramujte si účetnictvý (workflow, procurement, metadata processing etc.) firmy, když některým vnitřním postupům, specifickým jen a jen pro tu firmu, rozumí jediný člověk ve firmě a ten to ještě neumí vysvětlit a dokumentace je neexistující nebo zastaralá. Podívejte se, jak tu na ABC ztěžka vzniká aplikace pro Datové Schránky. Zdá se vám to příliš abstraktní? Berte to jako drobný úvodní tréning.

Na Qt se mi líbí, že rozumě využívají existující patterny. Jakmile jednou pochopíte MVC, třeba právě na příkladu Qt, nebude vám dělat takový problém porozumět Javovskému Swingu, Springu, Jave EE, JSF, Struts, Eclipse RPC, tam všude se MVC používá, pravda trochu uzpůsoben specifikům platformy (desktop, web, ..) a jazyku (Java, C++).

[dark]

Řekl bych, že toto je právě o tom. V Qt je fungující koncept MVC a vy si ho jen upravíte do podoby, kterou potřebujete. Je jasné, že Qt nemůže vyhovět všem, ale Model/View architektura se povedla.

[xxxx]

problem je, ze v byznysu je vetsina aplikaci psana jako M-V-C, takze je to dobre znat.

[Petr Bravenec]

Ale tohle je mezivrstva pro aplikační programátory! Bohužel není zadarmo. Nic není zadarmo. Ponořte se do studia MVC a až se prokoušete přes temné, depresivní stránky nevědění, osvítí vás jasné světlo poznání, svět se rozzáří a už nikdy nebudete chtít programovat jinak. V Qt je to možná složitější, na druhou stranu je zde MVC model velmi obecně vytvořený a neuvěřitelně flexibilní.

[Ivan]

Me prijde divny ze u QT MVC je velkej rozdil mezi examplem, kterej je vice-mene jasnej, strucnej a pochopitelnej, a mezi realitou. Priznam se, ze MVC jsem "pochopil" uz nekolikrat a presto mi nektere zmeny v kodu zaberou neumerne mnoho casu. Kdyz totiz chcete jit az do hloubky tak zjistite ze neni mnoho examplu ani dokumnetace. Zatim jsem treba nenasel jasnou odpoved na tohle:

• kdy musim implementovat sizeHint metodu?
• proc to funguje kdyz ji neumplementuju?
• kdy a kdo ji bude volat?
• jak se registruje u delegatu registruje tovarna?
• jak se aplikuji styly na vlastni delegaty?

No mozna, ze uz jsem v minulosti znal odpovedi na tyhle otazky, ale mezitim jsem se venoval necemu jinymu a zase jsem zapomel jmena trid/metod, ktery to resi. Tim nechci rict ze by na tom konceptu bylo neco spatne, spis mi chybi nejaky komplexnejsi example ktery by sel vice do hloubky a ukazal jasneji vazby mezi tridami. Na to abych prochazel dokumentaci ke vsem tridam QT, ktery by mohly mit neco spolecnyho s MVC, tak na to jsem linej :(.

[Unable]

Nevím jestli je to chyba, ale článek se nezobrazuje v seriálu Grafické programy v Qt 4, ale samostatně.

Jinak děkuju za prima článek a už se těším se na desáté pokračování :)

[David Watzke]

Je to chyba, ale ne redaktora. Článek tam totiž podle mě zařazenej je, jenže to nějak blbne. Z nějakýho důvodu ho furt vidím jako čekající na vydání... Bude to muset vyřešit někdo s vyššími právy.

[wix]

Pekny clanek..ovsem pro zacatecniky mozna trochu narocny..verim ze v pristim clanku o sql bude vsem vsechno jasnesji..dopurucoval bych sqlite..aby jsi na ne nemusel valit prekladani sql driveru treba pro mysql..v linuxu pohoda ale ve win trosku opruz kvuli stahovani untilit do mingw..

[David Watzke]

Jde o to, že model/view není zrovna záležitost pro začátečníky...

[Petr Bravenec]

Ve win je opruz i s sqlite. To, co přibalili ke Qt je nějak divně funkční, takže to v mém případě skončilo opět překladem sqlite driveru

[couker]

Co je tam divne funkcni ? Zatim jsem se s problemy nesetkal, ale rad bych vedel, na co vsechno muzu narazit, kdyz aplikaci pouzivaji zakaznici..

[s0]

sqlite3 driver dodávaný v binárkách Qt4 je zkompilován s ořezanou funkcionalitou (a je vždycky staršího data). Chybí např. podpora sqlite extensions (co si tak z hlavy pamatuju). Jinak jsem problémy nezaregistroval.

[Saljack]

Přesně tohle jsem potřeboval do jednoho svého projektu. Musím říct, že zrovna tohle není moc srozumitelně popsané v dokumentaci a dá se na to nalézt málo příkladů, tudíž jsem velmi rád, že se tu něco takováho objevilo a myslím, že to pomůže každému kdo se tímto bude zaobírat. Moc moc dík za to.

[Martin Stiborský]

Skvělé. Děkuji.