[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

pl.comp.programming

Re: Qt 4, model-widok

Wysota

5/6/2007 8:35:00 PM

On 23 Kwi, 20:26, "TmP" <o...@o.pl> wrote:

> I to dziala w momencie gdy w funkcji rowCount zamiast return
> obiektZLista.count () wpisze return 15; //na przyklad
> Przynajmniej do 15 wierszy w liscie, bo pozniej tradycyjnie juz nie
> wyswietla kolejnych wierszy...
>
> O co chodzi? Moze mi ktos wyjasnic czemu tak sie dzieje?
>

Polecam sygnaly layoutChanged() i rowsInserted() :)

A MVC w Qt wcale nie jest przekombinowane, powiedzialbym, ze jest dosc
elegancko zrobione.

6 Answers

Zbyszek Malec

5/6/2007 9:07:00 PM

0

Dnia 6 May 2007 13:35:25 -0700, Wysota@gmail.com napisa3(a):

> Polecam sygna3y layoutChanged() i rowsInserted() :)
>
> A MVC w Qt wcale nie jest przekombinowane, powiedzia3bym, ?e jest do?a
> elegancko zrobione.

Nie zgodzi3bym sie. Modele powinny bya specyficzne, a s? uniwersalne, co
powoduje ich za?miecanie i zaciemnienie. Ponadto w model wepchana jest
tak?e funkcjonalno?a widoku (model decyduje jakie dane bed? wy?wietlane w
jakiej roli, a powinno to bya za3atwione po stronie widoku). I jeszcze to
beginRowsInserted (czy jak jej tam) - brrrr.

--
Zbyszek Malec Ustronie 104
jid: zbyszanna@chrome.pl

Wysota

7/2/2007 10:49:00 PM

0

Odgrzejmy starawy w?tek, o którym mi sie zapomnia3o...

Zbyszek Malec wrote:

>
> Nie zgodzi3bym sie. Modele powinny bya specyficzne, a s? uniwersalne, co
> powoduje ich za?miecanie i zaciemnienie.

Przecie? "specyfika" zale?y jedynie od implementacji konkretnego modelu.
Nikt nie ka?e sie ograniczaa jedynie do abstrakcyjnego interfejsu
QAbstractItemModel. Tyle tylko, ?e interfejs ten _musi_ bya
zaimplementowany, ?eby widoki mog3y go u?ywaa. Je?eli kto? chce miea w3asne
metody obs3ugi modelu (np. dodawania elementów), to nie ma przeszkód.


> Ponadto w model wepchana jest
> tak?e funkcjonalno?a widoku (model decyduje jakie dane bed? wy?wietlane w
> jakiej roli, a powinno to bya za3atwione po stronie widoku).

No... nie. Tzn nie do konca. Rzeczywi?cie, model przypisuje fragmenty danych
do konkretnych ról. Natomiast to jak (i czy w ogóle) zostan? one
przedstawione w widoku, zale?y ju? od samego widoku, wzglednie od delegata
(realizacji QAbstractItemDelegate). Wg mnie jedyna nielogiczno?a zwi?zana z
rolami danych to taka, ?e model pos3uguje sie takimi rolami
jak "czcionka", "kolor czcionki", "kolor t3a" - ewidentnie s? to pojecia,
które nie powinny miea miejsca w akademickim modelu tej architektury (tzn.
powinny bya w widoku b?d? w delegacie a nie w modelu danych). Tylko ?e
prawd? jest to, ?e te role s? po prostu potrzebne :) Poza tym nikt nie ka?e
ich u?ywaa we w3asnych modelach/widokach/delegatach.

> I jeszcze to
> beginRowsInserted (czy jak jej tam) - brrrr.

beginInsertRows :)

To akurat ma swoje uzasadnienie (wraz z endInsertRows). Dzieki temu widoki
dostaj? informacje o tym, ?e dany fragment modelu uleg3 zmianie. Prosze
sobie wyobrazia, ?e model trzyma informacje o tysi?cach wierszy. Gdyby
powiadamianie widoków by3o jedynie na zasadzie "zmieni3 sie model" (np.
poprzez sygna3 layoutChanged() albo bodaj?e reset()), to ka?dy widok
musia3by na nowo od?wie?ya ca3y model - powodzenia :)

Wskazanie precyzyjnie ile wierszy (b?d? kolumn, bo przecie? istniej?
bli?niacze metody dla kolumn) i w którym miejscu zosta3o dodanych pozwala
na optymalizacje od?wie?enia widoków przy?pieszaj?c tym znacznie ca3?
architekture. Dla porównania prosze wzi?a prosty model i dodaa do niego
pojedynczo pare tysiecy elementów. Nastepnie prosze spróbowaa zrobia to
samo, dodaj?c na raz wszystkie b?d? wieksze grupy (np. po 500) elementy (tu
przyda sie w3asna metoda dodawania). Ró?nica czasów od?wie?ania widoków
bedzie kolosalna. Bior?c pod uwage, ?e metody te nale?y wywo3aa jedynie z
poziomu implementacji modelu i u?ycie ich jest po prostu trywialne, niezbyt
rozumiem powód wzdrygania sie na ich widok. Lepsze to, ni? updateAllViews()
w MFC :)

To, czego wg mnie brakuje, to jeszcze informacja przy zmianie zawarto?ci
elementu o tym, co konkretnie w tym elemencie sie zmieni3o (np. poprzez
emisje sygna3u dataChanged z dodatkowym parametrem QList<int> (lub
podobnym) przenosz?cym liste zmienionych ról).

Pozdrawiam i przepraszam osoby niezainteresowane tematem za od?wie?anie
kilkumiesiecznego w?tku, ale akurat mi sie o nim przypomnia3o.

Pozdrawiam,
W.

Zbyszek Malec

7/2/2007 11:16:00 PM

0

Dnia Tue, 03 Jul 2007 00:48:51 +0200, Witold Wysota napisa3(a):

>> Nie zgodzi3bym sie. Modele powinny bya specyficzne, a s? uniwersalne, co
>> powoduje ich za?miecanie i zaciemnienie.
>
> Przecie? "specyfika" zale?y jedynie od implementacji konkretnego modelu.
> Nikt nie ka?e sie ograniczaa jedynie do abstrakcyjnego interfejsu
> QAbstractItemModel. Tyle tylko, ?e interfejs ten _musi_ bya
> zaimplementowany, ?eby widoki mog3y go u?ywaa. Je?eli kto? chce miea w3asne
> metody obs3ugi modelu (np. dodawania elementów), to nie ma przeszkód.

Nie o takiej specyfice mówie. Je?eli pisze model dla tabelki, to spodziewam
sie ?e bed? tam metody dostepu do danych charakterystyczne dla tabelki.
Teraz s? takie same dla listy, drzewa i tabelki i to jest moim zdaniem z3e.

>> Ponadto w model wepchana jest
>> tak?e funkcjonalno?a widoku (model decyduje jakie dane bed? wy?wietlane w
>> jakiej roli, a powinno to bya za3atwione po stronie widoku).
>
> No... nie. Tzn nie do konca. Rzeczywi?cie, model przypisuje fragmenty danych
> do konkretnych ról. Natomiast to jak (i czy w ogóle) zostan? one
> przedstawione w widoku, zale?y ju? od samego widoku, wzglednie od delegata
> (realizacji QAbstractItemDelegate).

Moim zdaniem to jest tylko dodatkowe zaciemnianie. Podejrzewam ?e da sie to
zrobia pro?ciej.

> Wg mnie jedyna nielogiczno?a zwi?zana z
> rolami danych to taka, ?e model pos3uguje sie takimi rolami
> jak "czcionka", "kolor czcionki", "kolor t3a" - ewidentnie s? to pojecia,
> które nie powinny miea miejsca w akademickim modelu tej architektury (tzn.
> powinny bya w widoku b?d? w delegacie a nie w modelu danych).

No w3a?nie!

> Tylko ?e
> prawd? jest to, ?e te role s? po prostu potrzebne :) Poza tym nikt nie ka?e
> ich u?ywaa we w3asnych modelach/widokach/delegatach.

Qtwego MVC te? mi nikt nie ka?e u?ywaa, tak wiec ten argument odrzucam. Co
do potrzebno?ci - w przyjetym rozwi?zaniu s? potrzebne. W innym nie
musia3yby bya potrzebne. Rozwi?zanie z rolami nie jest najgorsze, ale
pozostawia troche do ?yczenia.

>> I jeszcze to
>> beginRowsInserted (czy jak jej tam) - brrrr.
>
> beginInsertRows :)
>
> To akurat ma swoje uzasadnienie (wraz z endInsertRows). Dzieki temu widoki
> dostaj? informacje o tym, ?e dany fragment modelu uleg3 zmianie. Prosze
> sobie wyobrazia, ?e model trzyma informacje o tysi?cach wierszy. Gdyby
> powiadamianie widoków by3o jedynie na zasadzie "zmieni3 sie model" (np.
> poprzez sygna3 layoutChanged() albo bodaj?e reset()), to ka?dy widok
> musia3by na nowo od?wie?ya ca3y model - powodzenia :)

Chodzi mi o rozdzielenie begin i end, nie o potrzebe istnienia sygna3u
powiadamiaj?cego o wyrzucenia wiersza (tej nie neguje).

--
Zbyszek Malec Ustronie 416
jid: zbyszanna@jid.pl

Wysota

7/3/2007 11:12:00 AM

0

Zbyszek Malec wrote:

> Nie o takiej specyfice mówie. Je?eli pisze model dla tabelki, to
> spodziewam sie ?e bed? tam metody dostepu do danych charakterystyczne dla
> tabelki. Teraz s? takie same dla listy, drzewa i tabelki i to jest moim
> zdaniem z3e.

Przecie? napisa3em, ?e nikt nie broni dodaa w3asnych metod dostepu do danych
(wystarczy spojrzea np. na QSql{Query,Table,RelationalTable}Model). A jeden
uniwersalny interfejs pozwala na wy?wietlenie modelu drzewiastego zarówno w
widoku drzewiastym, tabelarycznym jak i listowym. Gdyby ka?dy z nich mia3
inny interfejs, nie by3oby to mo?liwe. Co wiecej metody dostepu posiadaj?
domy?lne parametry, co pozwala np. na pominiecie parametru rodzica przy
tabelarycznym modelu. Dodatkowo mamy abstrakcyjne specjalizacje
najogólniejszej klasy modelu, które dostarczaj? od razu prawid3owej
implementacji metody index() dla modeli poszczególnych kszta3tów.

>> No... nie. Tzn nie do konca. Rzeczywi?cie, model przypisuje fragmenty
>> danych do konkretnych ról. Natomiast to jak (i czy w ogóle) zostan? one
>> przedstawione w widoku, zale?y ju? od samego widoku, wzglednie od
>> delegata (realizacji QAbstractItemDelegate).
>
> Moim zdaniem to jest tylko dodatkowe zaciemnianie. Podejrzewam ?e da sie
> to zrobia pro?ciej.

Mo?liwe, ?e sie da - pytanie, co sie wtedy traci.

>
>> Tylko ?e
>> prawd? jest to, ?e te role s? po prostu potrzebne :) Poza tym nikt nie
>> ka?e ich u?ywaa we w3asnych modelach/widokach/delegatach.
>
> Qtwego MVC te? mi nikt nie ka?e u?ywaa, tak wiec ten argument odrzucam.

Oczywi?cie, ?e nie ka?e, natomiast u?ywanie go zwieksza drastycznie
kompatybilno?a i reu?ywalno?a raz napisanego kodu, co jest, my?le,
argumentem istotnym, szczególnie dla a) pocz?tkuj?cych programistów i b)
jednostek, które zawodowo zajmuj? sie tworzeniem oprogramowania.


> Co
> do potrzebno?ci - w przyjetym rozwi?zaniu s? potrzebne. W innym nie
> musia3yby bya potrzebne.

Wcale nie s? potrzebne... Wystarczy zmodyfikowaa QItemDelegate i hulaj dusza
piek3a nie ma. Domy?lny delegat jest jedyn? encj?, która w ogóle pobiera
dane z tych ról.

> Rozwi?zanie z rolami nie jest najgorsze, ale
> pozostawia troche do ?yczenia.

np?


> Chodzi mi o rozdzielenie begin i end, nie o potrzebe istnienia sygna3u
> powiadamiaj?cego o wyrzucenia wiersza (tej nie neguje).

Implementacja metod "begin..." wyglada tak :

void QAbstractItemModel::beginInsertRows(const QModelIndex &parent, int
first, int last)
{
Q_ASSERT(first >= 0);
Q_ASSERT(last >= first);
Q_D(QAbstractItemModel);
d->changes.push(QAbstractItemModelPrivate::Change(parent, first, last));
emit rowsAboutToBeInserted(parent, first, last);
d->rowsAboutToBeInserted(parent, first, last);
}

d->rowsAboutToBeInserted(...) zapewnia synchronizacje trwa3ych indeksów.

My?le, ?e niedogodno?a wywo3ania tej metody w jednym (!) miejscu w modelu
jest niewielk? cen? w zamian za mo?liwo?a posiadania trwa3ych indeksów i
precyzyjnej kontroli rozmiaru modelu (bo jak inaczej zagnie?dzia wywo3ania
insertRows()? Trzeba kontrolowaa stos zmian, a skoro ma bya to stos, to
musi istniea operacja odk3adania i zdejmowania z niego).

Je?eli kto? chce pisaa w3asne architektury do wszystkiego, to droga wolna.
Je?eli kto? chce wykorzystywaa Swoj?Ulubion?ArchitektureModelWidok, to te?
nie ma problemu, tyle, ?e nie skorzysta wtedy z ?adnej zalety Qt. Uwa?am,
?e "akademicko?a" interfejsu to nie jedyna cecha, któr? nale?y sie
kierowaa - w informatyce czesto istotniejszy okazuje sie pragmatyzm.
Aspekty takie jak oszczedno?a, wydajno?a i uniwersalno?a staj? sie coraz
istotniejsze w naszym zabieganym ?wiecie. Ja nie mówie, ?e Interview jest
najpiekniejszym mo?liwym rozwi?zaniem architektury _zbli?onej_ do MVC,
natomiast bede sie upiera3, ?e jest jedn? z najpraktyczniejszych. A to
w3a?nie dla mnie jest cecha istotna. Mo?liwo?a podmiany za pomoc? jednej
linii kodu magazynu danych np. z pliku trzymaj?cego liste stringów na
tabele relacyjnej bazy danych bez konieczno?ci zmieniania istniej?cego kodu
w ?adnym innym miejscu wydaje mi sie warta posiadania abstrakcyjnego
interfejsu modelu. A u?ytkownik (w sensie programisty) gotowego modelu nie
musi sie k3opotaa wywo3ywaniem metod typu beginInsertRows - jest to
wewnetrzna sprawa modelu i jego twórcy.

To tak, jakby marudzia, ?e ?eby z poziomu metody wirtualnej otrzymaa
funkcjonalno?a klasy bazowej, trzeba j? explicite wywo3aa w implementacji
pochodnej. No trzeba - tak dzia3a C++. Mo?na sie z tym zgadzaa lub nie, ale
taka w3a?nie jest struktura tego jezyka. Dzieki temu sami mo?emy decydowaa,
czy chcemy te funkcjonalno?a czy nie.

Pozdrawiam serdecznie,
W.


Zbyszek Malec

7/3/2007 11:37:00 AM

0

Dnia Tue, 03 Jul 2007 13:11:31 +0200, Witold Wysota napisa3(a):

> Zbyszek Malec wrote:
>
>> Nie o takiej specyfice mówie. Je?eli pisze model dla tabelki, to
>> spodziewam sie ?e bed? tam metody dostepu do danych charakterystyczne dla
>> tabelki. Teraz s? takie same dla listy, drzewa i tabelki i to jest moim
>> zdaniem z3e.
>
> Przecie? napisa3em, ?e nikt nie broni dodaa w3asnych metod dostepu do danych

Ale widok z nich nie skorzysta. Ja nie chce dodawaa do modelu metod, ja
chce odj?a.

> A jeden
> uniwersalny interfejs pozwala na wy?wietlenie modelu drzewiastego zarówno w
> widoku drzewiastym, tabelarycznym jak i listowym.

I to jest z3e.

> Gdyby ka?dy z nich mia3
> inny interfejs, nie by3oby to mo?liwe.

Gdyby twoja klasa modelu by3a tak uniwersalna, to mog3a by implementowaa
ka?dy z tych specyficznych interfejsów osobno.


> Co wiecej metody dostepu posiadaj?
> domy?lne parametry, co pozwala np. na pominiecie parametru rodzica przy
> tabelarycznym modelu. Dodatkowo mamy abstrakcyjne specjalizacje
> najogólniejszej klasy modelu, które dostarczaj? od razu prawid3owej
> implementacji metody index() dla modeli poszczególnych kszta3tów.

Czyli dostajemy metody które musz? robia wszystko, przy czym najcze?ciej
wykorzystuje sie jedynie u3amek tej funkcjonalno?ci (bo akurat
implementujemy model tabeli a nie drzewa).

>> Moim zdaniem to jest tylko dodatkowe zaciemnianie. Podejrzewam ?e da sie
>> to zrobia pro?ciej.
>
> Mo?liwe, ?e sie da - pytanie, co sie wtedy traci.

Nic? Wszystko? Zale?y jakie sie rozwi?zanie zastosuje.

>> Qtwego MVC te? mi nikt nie ka?e u?ywaa, tak wiec ten argument odrzucam.
>
> Oczywi?cie, ?e nie ka?e, natomiast u?ywanie go zwieksza drastycznie
> kompatybilno?a i reu?ywalno?a raz napisanego kodu, co jest, my?le,
> argumentem istotnym, szczególnie dla a) pocz?tkuj?cych programistów i b)
> jednostek, które zawodowo zajmuj? sie tworzeniem oprogramowania.

Ja chce mvc, ja nie chce qtwego mvc.

>> Co
>> do potrzebno?ci - w przyjetym rozwi?zaniu s? potrzebne. W innym nie
>> musia3yby bya potrzebne.
>
> Wcale nie s? potrzebne... Wystarczy zmodyfikowaa QItemDelegate i hulaj dusza
> piek3a nie ma. Domy?lny delegat jest jedyn? encj?, która w ogóle pobiera
> dane z tych ról.

Teraz mamy taki bardzo ogólny twór który robi absolutnie wszystko. To nie
jest dobre.

>> Rozwi?zanie z rolami nie jest najgorsze, ale
>> pozostawia troche do ?yczenia.
>
> np?

To co ju? pisa3em wcze?niej plus pare innych.

> My?le, ?e niedogodno?a wywo3ania tej metody w jednym (!) miejscu w modelu
> jest niewielk? cen? w zamian za mo?liwo?a posiadania trwa3ych indeksów i
> precyzyjnej kontroli rozmiaru modelu (bo jak inaczej zagnie?dzia wywo3ania
> insertRows()?

A co je?li ja nie mam gdzie tej metody wykonaa?

> Je?eli kto? chce pisaa w3asne architektury do wszystkiego, to droga wolna.
> Je?eli kto? chce wykorzystywaa Swoj?Ulubion?ArchitektureModelWidok, to te?
> nie ma problemu, tyle, ?e nie skorzysta wtedy z ?adnej zalety Qt.

Po prostu uwa?am ?e MVC da3o by sie zrobic pro?ciej i lepiej ni? to jest
zrealizowane tutaj.

Dla mnie EOT. Pozdrawiam.

--
Zbyszek Malec Ustronie 416
jid: zbyszanna@jid.pl

Wysota

7/3/2007 8:12:00 PM

0

Zbyszek Malec wrote:

>
> Ale widok z nich nie skorzysta. Ja nie chce dodawaa do modelu metod, ja
> chce odj?a.

Czemu?

>
>> A jeden
>> uniwersalny interfejs pozwala na wy?wietlenie modelu drzewiastego zarówno
>> w widoku drzewiastym, tabelarycznym jak i listowym.
>
> I to jest z3e.

Nie zgodze sie. Jest wiele przypadków, gdzie to jest po prostu niezbedne.
We?my za przyk3ad QDirModel. Wyobra? sobie, ?e musia3by? miea
QTreeDirModel, QTableDirModel i QListDirModel, ?eby w ró?nych widokach
ogl?daa drzewo katalogów. O wspó3dzieleniu zaznaczen ju? w ogóle by mo?na
zapomniea...

>
>> Gdyby ka?dy z nich mia3
>> inny interfejs, nie by3oby to mo?liwe.
>
> Gdyby twoja klasa modelu by3a tak uniwersalna, to mog3a by implementowaa
> ka?dy z tych specyficznych interfejsów osobno.

Podobno chcesz zmniejszya liczbe metod :)

>
>
>> Co wiecej metody dostepu posiadaj?
>> domy?lne parametry, co pozwala np. na pominiecie parametru rodzica przy
>> tabelarycznym modelu. Dodatkowo mamy abstrakcyjne specjalizacje
>> najogólniejszej klasy modelu, które dostarczaj? od razu prawid3owej
>> implementacji metody index() dla modeli poszczególnych kszta3tów.
>
> Czyli dostajemy metody które musz? robia wszystko, przy czym najcze?ciej
> wykorzystuje sie jedynie u3amek tej funkcjonalno?ci (bo akurat
> implementujemy model tabeli a nie drzewa).

Nie. Je?eli implementujesz model tabeli, to dziedziczysz po
QAbstractTableModel i nie przejmujesz sie pojeciem rodzica, bo domy?lna
implementacja za3atwia to za Ciebie, a rodzic jest w ka?dej metodzie
argumentem z warto?ci? domy?ln?. A dodatkowo widok drzewa taki model
równie? wy?wietli poprawnie.

>
>>> Moim zdaniem to jest tylko dodatkowe zaciemnianie. Podejrzewam ?e da sie
>>> to zrobia pro?ciej.
>>
>> Mo?liwe, ?e sie da - pytanie, co sie wtedy traci.
>
> Nic? Wszystko? Zale?y jakie sie rozwi?zanie zastosuje.

Podaj konkretn? propozycje.

>
>>> Qtwego MVC te? mi nikt nie ka?e u?ywaa, tak wiec ten argument odrzucam.
>>
>> Oczywi?cie, ?e nie ka?e, natomiast u?ywanie go zwieksza drastycznie
>> kompatybilno?a i reu?ywalno?a raz napisanego kodu, co jest, my?le,
>> argumentem istotnym, szczególnie dla a) pocz?tkuj?cych programistów i b)
>> jednostek, które zawodowo zajmuj? sie tworzeniem oprogramowania.
>
> Ja chce mvc, ja nie chce qtwego mvc.

Ale? nie u?ywaj, nikt Ci nie ka?e. Tylko nie mów, ?e jest "be", bo Ci sie
nie podoba jego uniwersalno?a.

>
>>> Co
>>> do potrzebno?ci - w przyjetym rozwi?zaniu s? potrzebne. W innym nie
>>> musia3yby bya potrzebne.
>>
>> Wcale nie s? potrzebne... Wystarczy zmodyfikowaa QItemDelegate i hulaj
>> dusza piek3a nie ma. Domy?lny delegat jest jedyn? encj?, która w ogóle
>> pobiera dane z tych ról.
>
> Teraz mamy taki bardzo ogólny twór który robi absolutnie wszystko. To nie
> jest dobre.

Nie robi wszystkiego, robi du?o w spójny i 3atwo rozszerzalny sposób (vide
QDataWidgetMapper). Domy?lne zachowanie praktycznie ka?dego komponentu jest
intuicyjne, tak?e je?eli nie potrzebujesz jakiej? funkcjonalno?ci, po
prostu jej nie dotykaj, bedzie dzia3aa sensownie samo z siebie.

>>> Rozwi?zanie z rolami nie jest najgorsze, ale
>>> pozostawia troche do ?yczenia.
>>
>> np?
>
> To co ju? pisa3em wcze?niej plus pare innych.

Tzn? Pytam nie po to ?eby j?trzya, tylko ?eby ewentualnie podchwycia pomys3
i zasugerowaa odpowiedni? modyfikacje Interview.

>
>> My?le, ?e niedogodno?a wywo3ania tej metody w jednym (!) miejscu w modelu
>> jest niewielk? cen? w zamian za mo?liwo?a posiadania trwa3ych indeksów i
>> precyzyjnej kontroli rozmiaru modelu (bo jak inaczej zagnie?dzia
>> wywo3ania insertRows()?
>
> A co je?li ja nie mam gdzie tej metody wykonaa?

To j? olej. Je?eli twój model jest statyczny (tzn. inaczej, je?eli ma
statyczy wymiar), to domy?lna implementacja insertRows wystarczy. Minimalna
implementacja trójwymiarowego modelu wymaga jedynie zaimplementowania metod
data(), parent(), index() oraz rowCount() i columnCount(). Przy modelach
dwu i jednowymiarowych odpada od tego metoda index(), a parent jest
trywialne (return QModelIndex()). Czyli zostaje data() do zwrócenia danych
oraz rowCount() i columnCount() do zwrócenia wymiarów modelu.

>
>> Je?eli kto? chce pisaa w3asne architektury do wszystkiego, to droga
>> wolna. Je?eli kto? chce wykorzystywaa
>> Swoj?Ulubion?ArchitektureModelWidok, to te? nie ma problemu, tyle, ?e nie
>> skorzysta wtedy z ?adnej zalety Qt.
>
> Po prostu uwa?am ?e MVC da3o by sie zrobic pro?ciej i lepiej ni? to jest
> zrealizowane tutaj.

Mo?esz zasugerowaa jaki? kierunek poszukiwan? Je?eli dobrze rozumiem, to
sugerujesz oddzielne interfejsy dla listy, tabeli i drzewa. Tylko, ?e to
raczej skomplikuje a nie upro?ci sytuacje. |wiat informatyki (i nie tylko)
ma tendencje do abstrachizacji wszystkiego, co sie da. Tendencja ta wydaje
sie utrzymywaa ju? do?a d3ugo (na moje oko minimum od pocz?tku lat 90-tych
zesz3ego stulecia, chocia? zdecydowanie mo?na sie doszukiwaa jej prekursora
co najmniej w systemie Unix, czyli 20 lat wcze?niej) i ma do?a mocn?
pozycje i ogromne grono zwolenników (z ruchem FOSS i Microsoftem na czele,
poprzez ?wiat teleinformatyki, nie wiadomo w3a?ciwie na czym koncz?c).
Dlatego nie widze powodu, ?eby akurat w przypadku MVC odstepowaa od tej
(chyba niepisanej, choa ogólnie znanej i "przestrzeganej") regu3y. Ca3y
paradygmat programowania obiektowego opiera sie w3a?nie o abstrakcyjno?a i
uogólnianie i wydaje mi sie, ?e ca3e Qt (mo?e z drobnymi wyj?tkami w paru
bardziej ukrytych miejscach) doskonale wpisuje sie zarówno w ten
paradygmat, jak i te tendencje. Je?eli co? u?ci?lisz (tak jak, je?eli
dobrze rozumiem, proponujesz), to ograniczasz obszar zastosowan (czysta
matematyka). Zgodze sie, ?e nie mo?na w ten sposób rozumowaa w
nieskonczono?a (chocia? fizycy od zarania dziejów twierdz? co? przeciwnego
i chyba w swojej dziedzinie maj? racje), bo abstrachowanie to jednocze?nie
komplikowanie (wystarczy spojrzea np. na biblioteke Crypto++). Natomiast
uwa?am, ?e Interview jest dalekie od osi?gniecia tej nieprzekraczalnej
granicy - w koncu jedyne, co _trzeba_ zrobia, to zaimplementowaa trzy
proste metody, a to i tak jedynie w przypadku, gdy QStandardItemModel oka?e
sie niewystarczaj?cy.

>
> Dla mnie EOT. Pozdrawiam.

Eee... uciekasz od dyskusji a temat sie nie wyczerpa3. Bardzo mnie
interesuj? Twoje uwagi, dlatego nalegam, aby?my jeszcze troche
podyskutowali, a mo?e i kto inny sie pod3?czy do dyskusji.

Pozdrawiam serdecznie,
W.