panel item remove confirmation

[Fabian Nowak]

> On Mon, Oct 17, 2005 at 01:04:28PM +0200, Fabian Nowak wrote:
> > Am Montag, den 17.10.2005, 01:54 -0700 schrieb Brian J. Tarricone:
> > > 
> > > Do you *really* add and remove plugins from the panel so often
> that a
> > > dialog is that annoying?  If so, I'm sure you're in the small
> minority.
> > 
> > as above, yes when developing or improving or porting plugins.
> > 
> 
> This is an argument that holds no value from the user's standpoint.

the argument, yes. the fact, no. many users may have many plugins, or
play around with them to find out which ones they will keep. remember
there are 28-30 plugins already and even more are being developed
freshly.
> 
> One thing regarding usability is, that the user interface should
> prevent
> - or at least discourage - the user of making a mistake in the first
> place. Differentiating the items more clearly would probably be the
> way
> to go, but I can't think of a nice way of doing it. 

see below, images to differentiate the dialogs.
> 
> So, the confirmation
> dialog would be acting as a sort of "wtf are you doing?" wakeup call
> for
> most _users_ as - I'd guess - they are not adding and removing panel
> items that often.
see some paragraphs above.
> 
> If a developer has difficulties coping with this, he probably just
> should pay more attention on his actions, or just patch the panel for
> himself. :)
first one is true, but patching is too much act - you will have to do
this for every you new checkout.


Am Montag, den 17.10.2005, 13:47 +0200 schrieb Jannis Pohlmann:
> Fabian Nowak schrieb:
> >>>what about having a panel option "show remove confirmation on plugin
> >>>removal" which might be enabled by default, thus enabling me and perhaps
> >>>many others to not have this dialog.
> 
> This is something we use for InstallIt. A yes-no-question dialog
> providing the option to remember the user's answer. That's easy in
> Python (which InstallIt is based on) but could be integrated into
> libxfcegui4 or the panel with little efford as well. If others consider
> this interesting, I could come up with a solution for this.

sounds nice. but only for the plugins, not for the panel.

> 
> > "make similar things similiar. and unsimilar things unsimilar." 
> > this is what's being hurt when having two very similar dialogs for very
> > different actions.
> 
> Well, "similar" is something that has to be defined. In my opinion,
> removing something and removing something *is* the same thing. Most
> times you want it but if you accidently trigger the removal, you have to
> be warned in order to prevent (somtimes huge) trouble.

"removing panel" and "removing item" are very unsimilar, but presented
with the same dialog. so if you are used to getting the dialog after
removing items, you will surely press yes if you accidently hit "remove"
for the panel.
again, providing identification images for those dialogs might be a
solution to not confuse those dialogs.

actually, i think that having this toggle in the yes/no dialog is the
best solution to both have the dialog and not have the dialog. users
will find out if they like this dialog or don't like it and perhaps
switch off.


> > I see Jannis mentioned a "Don't ask me again"-type dialog, which I
> like,
> > but it breaks the usual behavior a bit.  Usually they imply "... and
> do
> > what I did this time from now on".  But of course, checking it and
> then
> > clicking "cancel" is absurd: then you can never remove panel items.
> 
> Oops, haha. Indeed, I must have forgotten about that ...

pressing cancel simply will not save the toggled option.
the signal handler for dialogs has this nice gint response_id to look if
GTK_OK o GTK_CANCEL was pressed.


without further citing, brian, i think there already was a
differentiation "remove item" and "remove panel" in 4.3.20?
this was replaced by dividing the menu into "item part" and "panel
part".
so my idea is to just use two pretty equivalent terms for removing
allowing users to better distinguish on the first time. this would also
be conform to HIC and MMI guidelines.

fabian