[umbrello-devel] [umbrello] [Bug 87104] Refactoring dialog: moving ops/attrs does not show moved ops/attrs

[Emmanuel Lepage Vallée]

https://bugs.kde.org/show_bug.cgi?id=87104

--- Comment #9 from Emmanuel Lepage Vallée <elv1313 at gmail.com> ---
Indeed,

Using models create a rather flexible API in general. While models cannot be
used everywhere in Umbrello as they don't support graphs topology, other
elements should use them. Getting there is a long, frustrating process, but
worth it. In:

https://projects.kde.org/projects/extragear/network/libringclient/repository/revisions/master/show/src

I It took me a while to get rid of the QWidget dependency and split
SFLPhone-KDE in 2 project. That link is a pure QAbstractModel driven API and
the UX is a thin client where almost all of the code is composed of QPainter
and QWidgets binding on the models. This also allowed us to write various QML,
GTK+ and Mac OSX native GUI on top of the Qt library without much pain.

>From what I recall of Umbrello code, there is a distinction, but it is using
inheritance rather than an abstraction layer. It does work fine, and is almost
what I used in SFLPhone-KDE before creating that API, but after doing all the
work, I would say I would do it again. It was worth the porting time.

The model code in the Umbrello-ng2 fork may not be the best starting point, as
it just create yet another layer on top of the (then) existing Umbrello
architecture rather than placing the models where they belong, but it was
faster to do it that way.

If you take a look at the previous implementation (circa 2010-2011), I used a
QTreeWidget/QTableWidget system, but it was a dead end and would not scale.

Another aspect where model/view shine is the flexibility of views and proxies.
Sorting, filters and proxy based addition to the model are trivial. Then
something like KDChart or QML can be used for the views without additional
code.

-- 
You are receiving this mail because:
You are the assignee for the bug.