Bug 87104 - Refactoring dialog: moving ops/attrs does not show moved ops/attrs
Summary: Refactoring dialog: moving ops/attrs does not show moved ops/attrs
Status: CONFIRMED
Alias: None
Product: umbrello
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: LO normal
Target Milestone: ---
Assignee: Umbrello Development Group
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-13 09:19 UTC by Sebastian Stein
Modified: 2021-03-09 07:00 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Dark (15.36 KB, image/png)
2015-03-09 22:34 UTC, Emmanuel Lepage Vallée
Details
light (145.31 KB, image/png)
2015-03-09 22:38 UTC, Emmanuel Lepage Vallée
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Stein 2004-08-13 09:19:38 UTC
Version:           1.3.0 (using KDE 3.2.3, compiled sources)
Compiler:          gcc version 3.3.3
OS:                Linux (i686) release 2.4.26

1. add a class with an operation
2. add another class
3. add an implement association between both classes
4. call the refactoring dialog for one of those classes
5. mvoe the operation to the other class
-> the operation will be inserted several times in the dialog
Comment 1 FiNeX 2009-08-08 21:27:48 UTC
On the current version (trunk) the operation is moved but the refactor dialog is not updated.
Comment 2 Ralf Habacker 2015-03-08 17:45:07 UTC
(In reply to FiNeX from comment #1)
> On the current version (trunk) the operation is moved but the refactor
> dialog is not updated.
still present in 15.04 and git master.
Comment 3 Ralf Habacker 2015-03-09 09:07:46 UTC
The issue is caused by an implementation bug in class RefactoringAssistant. 

Refactoring (= moving of operations, attributes a.s.o) could be mostly performed with the currently implemented tree view (except moving classes up/down hierachy)  The question is if it would not be better to extend the tree view with a "Class Hierachy" variant, and to drop refactoring assistant completly.
Comment 4 Oliver Kellogg 2015-03-09 18:39:15 UTC
(In reply to Ralf Habacker from comment #3)
> [...] The question is if it would not be better to extend the
> tree view with a "Class Hierarchy" variant, and to drop refactoring assistant
> completely.

Sounds interesting.
How would this class hierarchy view be different from the current tree view?
Comment 5 Ralf Habacker 2015-03-09 22:13:11 UTC
(In reply to Oliver Kellogg from comment #4)
> (In reply to Ralf Habacker from comment #3)
> > [...] The question is if it would not be better to extend the
> > tree view with a "Class Hierarchy" variant, and to drop refactoring assistant
> > completely.
> 
> Sounds interesting.
> How would this class hierarchy view be different from the current tree view? 
The recent tree view shows  a "package hierachy" in the opposite to the derived and base classes , which would form the hierachy.
  
Visual it could be implemented similar to  Qt-Creator ?  As shown at http://upload.wikimedia.org/wikipedia/commons/4/4d/QtCreator-Linux-2.0.1.png It has on the left a dock widget with a combobox on top (currently showing "projects"). 
You can switch to "class hierachy" and the dock window shows the hierachy of the currently selected class. 
Transformed to umbrello: Above the tree view there is a combobox with which the display of the tree view could be changed from the recent default (which is a kind of package hierachy to "class  hierachy".  
On selecting of classes in the diagram window the related class hierachy is displayed in the tree view using the same style and icons for classes, operations, attributes as done with the default view.
Comment 6 Emmanuel Lepage Vallée 2015-03-09 22:34:56 UTC
Created attachment 91514 [details]
Dark
Comment 7 Emmanuel Lepage Vallée 2015-03-09 22:38:47 UTC
Created attachment 91515 [details]
light

While not ready for prime time. Some of the features I did while umbrello-soc and umbrello-svn were being merged (and thus, became unmergeable) could help here. As the code was made before git was used for KDESDK, the code is here https://github.com/Elv13/Umbrello-ng2

The bottom input dialog for entity relationship diagrams and class one would still be nice, but I don't have much time these day for this (but I still use Umbrello, so I can keep dreaming I eventually will everytime I look at it)
Comment 8 Ralf Habacker 2015-03-10 07:54:38 UTC
(In reply to Emmanuel Lepage Vallée from comment #7)
> Created attachment 91515 [details]
> light
> 
> While not ready for prime time. Some of the features I did while
> umbrello-soc and umbrello-svn were being merged (and thus, became
> unmergeable) could help here. As the code was made before git was used for
> KDESDK, the code is here https://github.com/Elv13/Umbrello-ng2
Having additional tree view variants like your special diagram view are useful contributions. 
As far as I remember from your previous talks are you using a model/view approach. 
That means if umbrello's tree view would use a model/view implementation it is easy to display variants by simply changing the model instance.
Comment 9 Emmanuel Lepage Vallée 2015-03-10 14:20:36 UTC
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.
Comment 10 Ralf Habacker 2015-03-10 21:57:44 UTC
I filed bug 345029 for dedicated model/view discussions.
Comment 11 Justin Zobel 2021-03-09 07:00:30 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.