[rekonq] Re: Rekonq's Firefox Solution for History Pulldown Menu Problem (Question)

[todd rme]

On Mon, Jan 17, 2011 at 12:11 PM, Andrea Diamantini <adjam7 at gmail.com> wrote:
> On Monday 17 January 2011 17:40:46 todd rme wrote:
>> How would this be implemented, though? As far as I can see there is
>> three ways to do this. The way for konqueror, and I think firefox 3,
>> has a button with a triangular expander to the side. The triangular
>> expander acts as its own, small button, so to activate the menu you
>> press the triangular expander. For firefox 4, there is no expander,
>> you just press and hold to get the menu. This is possible in KDE as
>> well, it just uses a smaller triangular expander embedded in the
>> button instead of off to the side. It may also be possible to hide
>> the triangle entirely, but I don't like this because it gives no
>> indication that the dropdown menu exists, so I think the triangle is
>> necessary on at least one button. I prefer the second method, since
>> it take less space, has a larger hit target, and accessing the menu is
>> probably uncommon enough that it should be its own button.
>
> I like the second one, too. The firefox 3 one.

The second one was firefox 4, do you mean the firefox 4 one or the
firefox 3 one?

>> This leads to a second issue: where to have the triangle (if at all).
>> As I said, I think having it is important. Having it on both buttons
>> seems redundant. You could overload the buttons so only the forward
>> button has this, I guess, but that would only really work for a
>> standard button layout. On the other hand, anyone who knows enough to
>> do non-standard button layouts should also know that the menu is
>> there. It may be possible to make a single button that has both back
>> and forward in it, but this is probably too complicated, and limits
>> customization options for the toolbar. Finally, it would be possible
>> to make a small button containing the triangular expander only, and
>> place that to the right of the forward button, and have that button
>> trigger the menu. So in that scenario the menu wouldn't be in the
>> back and forward buttons at all, it would only look like it is (this
>> could be combined with the press-and-hold method).
>
> I don't think using another action or another actionMenu could be good
> because they will not have a "smaller" dimension.

My suggestion, specifically, is to set enum
QToolButton::ToolButtonPopupMode to QToolButton::DelayedPopup, rather
than QToolButton::MenuButtonPopup.  I am not sure this is how it is
implemented in the code, but in terms of the approach it behaves like
MenuButtonPopup, while I think DelayedPopup is better.  That way we
can have it on both buttons.

In addition, you could have, perhaps optionally, an arrow-type button
(arrowType : Qt::ArrowType to Qt::DownArrow) which trigger the menu on
press (QToolButton::InstantPopup).  This could go to the right of the
forward button, at least optionally.  Once the menu is working, it
shouldn't be hard to put it on several different buttons with minimal
additional work.

> So, the easier implementation is as menu actions (the same way the
> backHistoryMenu is implemented).

Yes, naturally.

> The cleanest one is implementing another action with menu (the same way the
> rekonq menu is).

I agree, but there are several different ways to implement an action
menu in a toolbar button, so we need to figure out which one is best.

> In the first case, moving it from back button to forward button is something
> I'd like to let you decide.

What I am saying is to have the same menu on both the back and forward
buttons, and perhaps a third arrow-type button as well.

>> Also, I thought it worthwhile to point out that the konqueror way of
>> doing things and the firefox way of doing things are not mutually
>> exclusive. This may be more than you want to do, but it is possible
>> to have the standard buttons use the firefox method, but provide an
>> alternative set of back and forward buttons that behave like
>> konqueror. Not a configuration option, just a second pair of
>> back/forward buttons in the toolbar config list that behave like
>> konqueror. People could add those buttons and remove the existing
>> ones. As I said, you may not think this is a good
>
> Yes, but I think it is first of all a question of manpower :)

At least for the back menu, it is already implemented, and we have a
patch now to do the same thing for the forward button, so manpower
doesn't seem to be an issue.  My suggestions is, rather than removing
this, put them in, but don't include them in the default toolbar,
leave them as optional buttons.