After comparing my model with Gtk::TreeView implementation I have come to a conclusion that Gtk architecture is better than original one. So I updated my design. Now it uses Gtk::TreeModel instead of custom model class. Besides this, multiple TileRenderers representing each data item are replaced by one. TileRenderer now resembles Gtk::CellRenderer. Each time rendering is needed, a render method is called and argument containing path to Gtk::TreeModel item is passed.
Drawing: https://www.dropbox.com/s/v7m5eoz8roins34/PreviewHolder2.pdf
Tomasz
On Wed, May 28, 2014 at 12:06 PM, Tomasz Boczkowski <penginsbacon@...400...>wrote:
Hi!
I have designed a new class layout for PreviewHolder. It's functionality is illustrated at [1] Because the new widget should support not only rendering paints, but also glyphs and symbols, a flexible architecture is needed. I've choosen MVC approach, heavily based on Qt MV model design [2].
It is shown at [3]. In the upper part of the picture there are generic model and view classes. The lower part shows the application in swatches dialog.
Model is organized as a hierarchy of lists. Qt documentation explains similar hierarchy of grids [4]. It enables navigating and iterating through the structure and defined signals when items are inserted, moved or deleted. Model class itself does not contain data (classes that inherit it do) and it's methods do not provide access to data items. Model index is array index generalization for hierarchical structures.
PreviewHolder belongs to the "View" part. It is the widget that displays items categories and places the preview tiles. To make things work it needs a model and a means to display (and access) model data. The latter is provided by TileRenderers. TileRenderers can render images associated with model data. When clicked they send signals.
How do TileRenderers access to data contained in model, while Model class does not provide access to them? They are all constructed by a TileRendererFactory. Concrete factories find appropriate data items by ModelIndex, and initialize concrete TileRenderers with it. They also bind tile renderer signals upon construction.
The example shows the use of PreviewHolder in swatches dialog. Displayed items are paints. They are stored in PaintsModel. This class represents paint servers stored in document and built-in ones. It reacts to changes in document, updates it's entries and sends generic model signals. The model consists of PaintItems, that represent paints servers and provide access to SPPaintServer objects.
PaintTileRenderer just fills it's content with pattern.
Swatches dialog besides being a dialog, defines a slot that is executed when a tile renderer is clicked. It invokes apropriate SVG tree actions to set current object fill and stroke or execute "paint properties" dialog.
TileRenderer can be implemented as plain class or it can inherit Gtk::Widget. The second solution would mean easier support for mouse and D&D events, but I'm not sure if it would affect performance (gobject construction, storing Gdk::Windows, initializing cairo context for each widget in GTK2). We will have several hundreds of those objects. Did you encounter any issues with Gtk performance? Which solution do you recommend?
[1] https://www.dropbox.com/s/7nbg1uzk1sal2kn/new_swatches_ui.png [2] http://qt-project.org/doc/qt-4.8/model-view-programming.html [3] https://www.dropbox.com/s/r5ph6tgp5halal6/PreviewHolder.pdf [4] http://qt-project.org/doc/qt-4.8/model-view-programming.html#parents-of-item...
Regards, Tomasz