Bugs with patches (remove close toolbar-button)

[JL VT]

On Mon, Jun 20, 2011 at 6:01 PM, Sebastian Sauer <mail at dipe.org> wrote:
> On Monday 20 June 2011 22:29:15 Sven Langkamp wrote:
>> On Mon, Jun 20, 2011 at 9:20 PM, Sebastian Sauer <mail at dipe.org> wrote:
>> > On Sunday 19 June 2011 10:54:37 Boudewijn Rempt wrote:
>> > > We don't have many bugs with patches, but some of them are quite old
>> > > and others haven't had any attention yet.
>> > >
>> > > 260564        wis     NOR     calligra-bugs-null at kde.org      NEW
>> > >
>> >       calligra
>> >
>> > usabilit
>> >
>> > >       Linu    kword docker cant be hidden
>> > >
>> > > -> I still think that the toolbox shouldn't have a close button at all.
>> >
>> > I agree. We should remove the close-button from all dockers. Anyone
>> > against?
>>
>> We got many questions in the forum about ways to close the toolbox. I think
>> you should be able to close it.
>
> They can still be closed using the Settings=>Docker menu.
>
> An alternate idea:
>
> We could have a amarok-like View=>Lockj menuitem. If enabled the close and all
> other buttons are hidden. If disabled all things are like now (full control).
> The advantage is that we a) remove noise from the UI and b) prevent accidents
> like ups-my-docker-is-gone's.
>
> We could even enable that View=>Lock per default like it's the case already
> KDE-wide for the toolbars.
>
> Better?

Better, giving the user the options is always good, then they can
decide whether they want toolbars to have a close button or not,
without having to look at the code or change hardcoded properties.

Pidgin has the option to hide close buttons for conversation tabs too,
and it's very useful to avoid closing them accidentally.

In general I believe that whenever there's a contingency in UI, giving
the user the option to configure is better: that's the KDE way; let
the user configure and customize everything worth customizing (unlike
GNOME, which prefers to "just work").