Bug 92994

Also found in version 3.5.5-3
see http://bugs.debian.org/348941

*** Bug 126469 has been marked as a duplicate of this bug. ***

*** Bug 191399 has been marked as a duplicate of this bug. ***

I guess that this bug is because when you insert a new attribute/template/operations, a slot apply inside the class(umlattributedialog.cpp) is already called. Isn't a slot addNewFoo, the slot apply is called automatically, so that's why the file is automatically updated in add or remove this features.
I think that the best way is remove the button "apply", because we have two ways of include new attribute/template/operations, by the dialog of properties or using direct access, and since the dialogs of this features have his own "Ok" button that already update the file, the button "apply" lost his purpose.

(In reply to Lays Rodrigues from comment #4)
> I guess that this bug is because when you insert a new
> attribute/template/operations, a slot apply inside the
> class(umlattributedialog.cpp) is already called. Isn't a slot addNewFoo, the
> slot apply is called automatically, so that's why the file is automatically
> updated in add or remove this features.
yes. 
Many property items are hold only in the widget and are written back to the related object on pressing okay or apply. Pressing cancel simply do not write back the data into the object.

> I think that the best way is remove the button "apply", because we have two
> ways of include new attribute/template/operations, by the dialog of
> properties or using direct access, and since the dialogs of this features
> have his own "Ok" button that already update the file, the button "apply"
> lost his purpose.
But cancel button also looses its purpose. After adding new operations you cannot undo these adds yet. There may be a way to use the Qt undo framework (http://doc.qt.io/qt-4.8/qundo.html) on which umbrello undo support is based to revert changes after pressing cancel.

(In reply to Ralf Habacker from comment #5)
> (In reply to Lays Rodrigues from comment #4)
> > I guess that this bug is because when you insert a new
> > attribute/template/operations, a slot apply inside the
> > class(umlattributedialog.cpp) is already called. Isn't a slot addNewFoo, the
> > slot apply is called automatically, so that's why the file is automatically
> > updated in add or remove this features.

A quick check shows that QUndoStack::beginMacro() (see http://doc.qt.io/qt-4.8/qundostack.html#beginMacro) may help here.

Created attachment 98862 [details]
attachment-26376-0.html

Ralf, just to refresh my memory, in this bug I will make the queue and
remove the button apply?
I'm working in the others bugs right now.
Cheers,


On Thu, May 5, 2016 at 12:24 AM, Ralf Habacker via KDE Bugzilla <
bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=92994
>
> --- Comment #6 from Ralf Habacker <ralf.habacker@freenet.de> ---
> (In reply to Ralf Habacker from comment #5)
> > (In reply to Lays Rodrigues from comment #4)
> > > I guess that this bug is because when you insert a new
> > > attribute/template/operations, a slot apply inside the
> > > class(umlattributedialog.cpp) is already called. Isn't a slot
> addNewFoo, the
> > > slot apply is called automatically, so that's why the file is
> automatically
> > > updated in add or remove this features.
>
> A quick check shows that QUndoStack::beginMacro() (see
> http://doc.qt.io/qt-4.8/qundostack.html#beginMacro) may help here.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
> _______________________________________________
> umbrello-devel mailing list
> umbrello-devel@kde.org
> https://mail.kde.org/mailman/listinfo/umbrello-devel
>

BTW yesterday I had discovered that the changes in the general menu aren't updated automatically. But with that, I have doubt in remove the "apply" button.

(In reply to Lays Rodrigues from comment #8)
> BTW yesterday I had discovered that the changes in the general menu aren't
> updated automatically. But with that, I have doubt in remove the "apply"
> button.
Agreed.