Comment 4 for bug 584119

Hi,

On 05/22/2010 02:17 PM, Toby Dickenson wrote:
> On Saturday 22 May 2010, you wrote:
>> Hi Toby,
>>
>> Thanks for your interest in onboard and especially thanks for the
>> patch.
>
> Thanks for the quick reply.
>
>> Unfortunately, I don't like your approach very much because the
>> behaviour of the close button depends on the visibility of the
>> tray icon.
>
> I agree that maintaining consistent behaviour should be a goal, and I
> am interested in understanding specifically where you think my patch
> falls short.

What is disturbing me, is the fact that the close button quits onboard if the tray icon is not activated in the preferences; but the same button only hides/iconifies the window of onboard when the tray icon is enabled. Thus, two different bahaviours for the same button, and this behaviour depends on the activation or deactivation of another feature. That is not an evident behaviour in my opinion.

>>> From the user's point of view, the window's close button makes
>>> the window "go
> away". In one case the window is closed, in the other case it is
> hidden. I dont think the difference is visible to the user, and I
> agree any differences should be fixed.
>
> Again from a user's point of view, I believe my patch improves the
> consistency with other tray icons. network management, screen
> brightness, and volume tray icons can all be used to show a window,
> but in no other case is the icon removed when that window is closed.

So you are proposing to remove the option in the onboard preferences to activate and deactivate the tray icon and have it always visible. That would indeed make the close button have only one behaviour: hiding the onboard window. But it does not make sense to me to remove the option of the tray icon, to have at the end (after applying your patch) another button that behaves like the minimize button.

However, I will ping the other two maintainers for their opinion...

> If you meant inconsistent behaviour from an implementation point of
> view.... well, I'm happy to take implementation advice. This is my
> first trip into GTK.

No, I was arguing only from the point of view of the user.

>> Would a solution to the following bug not also help with your
>> problem? https://bugs.edge.launchpad.net/onboard/+bug/564040 I am
>> aware that it does not directly solve your problem, but I assume
>> that once there is a bigger "hide"-button available, it should not
>> take long for you to get the habit to use that hide button to hide
>> onboard.
>
> That bug calls for a "big (easily clickable) button to hide onboard",
> but in my usage Onboard already has *two* such buttons; the [x]
> button in the title bar, and the tray icon.

This are not two target that I would call big; to call it big, I would rather think at a button of the size of 4 keys with the letters.

>> Another solution that might suit you could come with the
>> implementation of rfe-bug:
>> https://bugs.edge.launchpad.net/onboard/+bug/443986
>
> That would be a great enhancement. Given a gentle push in the right
> direction I may be able to contribute.
>
> However, I dont think it eliminates the need for this patch. A new
> auto- show/hide feature wont totaly eliminate the need for manual
> hiding.

Depending on how that feature is implemented and how you work with your computer, it might have been a step in your direction.

Cheers