Bug 97558

Summary: Improve confirmation when removing an ActionList
Product: [Unmaintained] kdelibs Reporter: S. Burmeister <sven.burmeister>
Component: kedittoolbarAssignee: David Faure <faure>
Status: RESOLVED UNMAINTAINED    
Severity: normal CC: bluedzins, nitram29, quazgar
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description S. Burmeister 2005-01-20 22:30:07 UTC
Version:            (using KDE KDE 3.3.91)
OS:                Linux

When you read the bug-title, what did you think? I hope it helps understand this bug-report.

When editing toolbars one can remove (i.e. delete) entries which cannot be brought back. This is a very bad idea.

First, the note informing the user about the consequences of removing the actionlist is hidden, as the window is too small.

Second, IMHO these actionlists break common rules. Buttons are not supposed to be items that cannot be brought back. Files can be deleted, yet not buttons. But even if we consider buttons to be deleteable one should follow the common rules. These common rules are implemented in every application within KDE: Before deleting a file, ask the user for confirmation!

Third, there is no other place in KDE where the user can delete files/buttons by dragging them. An exception is the trash but even in that case a confirmation is required.

An example might help to understand my criticism.
People might say: There is a warning and if users cannot read or are to stupid then we cannot do anything about it.
What would happen, if konqueror would no longer ask for confirmation when deleting a file but simply display a text-message at the bottom of the screen stating: Files once removed cannot be brought back?
Comment 1 Brad Hards 2005-01-23 12:06:30 UTC
I am completely mystified by this. Which application is this for? For all applications?

When you delete a button from a toolbar, you can easily get it back using Configure Toolbars...
Comment 2 S. Burmeister 2005-01-23 12:39:31 UTC
> I am completely mystified by this. Which application is this for?
> For all applications?
>
> When you delete a button from a toolbar, you can easily get it back using
> Configure Toolbars...

I am glad you take it as obvious too that one can/should bring buttons easily 
back!

You can e.g. go into kontact > kmail > right-click on the toolbar > chose 
kmailwin as toolbar > go to the bottom of the list on the right hand side > 
click on the last entry > actionlist: toolbar_filter_actions

Same thing in konqueror for actionlist: views.

Comment 3 David Faure 2005-03-02 00:57:26 UTC
Better would be to actually make removed actionlists available again...
E.g. saving them in a special tag in the local XML file, a bit like we do for custom icons.
Comment 4 Andreas Gungl 2005-08-12 21:14:19 UTC
*** Bug 110555 has been marked as a duplicate of this bug. ***
Comment 5 S. Burmeister 2008-05-08 13:12:37 UTC
Since kontact4 changed the custom toolbar with all the app-cions like kmail etc in ot to a normal toolbar, the user can now remove that action-list without the possibility to get it back. As a result, the user cannot switch applications in kontact because he removed one item from a toolbar!
Comment 6 quazgar 2022-02-15 13:45:12 UTC
FWIW: This is how the entries can be manually restored (in Kontact 5.15, KDE 5.78):

1. Open `~/.local/share/kontact/local-kmail2.rc` in a file editor.
2. Scroll down until you find an element called `<ToolBar name="mainToolBar" ...>`
3. Add the missing ActionList elements.  For me, the last elements of the mainToolBar are:
    ```
  <Separator name="separator_3"/>
  <ActionList name="toolbar_filter_actions"/>
  <Separator name="separator_4"/>
  <ActionList name="toolbar_messagetag_actions"/>
  <Action name="create_todo"/>
  <Separator name="separator_5"/>
  <ActionList name="kmail_toolbar_actions"/>
    ```
4. Save the file.

The exact separator names may vary, but the general idea should restore your removed ActionList entries.
Comment 7 Christoph Cullmann 2024-09-14 17:07:00 UTC
Hi,

kdelibs (version 4 and earlier) is no longer maintained since a few years.

KDE Frameworks 5 or 6 might already have resolved this bug.

If not, please re-open against the matching framework if feasible or against the application that shows the issue.

We then can still dispatch it to the right Bugzilla product or component.

Greetings
Christoph Cullmann