[rekonq] Re: Rekonq's Firefox Solution for History Pulldown Menu Problem (Question)
Andrea Diamantini
adjam7 at gmail.com
Mon Jan 17 18:11:31 CET 2011
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. I think this could be
implemented just changing actual code to let the backHistoryMenu show instead
full tab history.
> 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.
So, the easier implementation is as menu actions (the same way the
backHistoryMenu is implemented).
The cleanest one is implementing another action with menu (the same way the
rekonq menu is).
In the first case, moving it from back button to forward button is something
I'd like to let you decide.
> 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 :)
> -Todd
> _______________________________________________
> rekonq mailing list
> rekonq at kde.org
> https://mail.kde.org/mailman/listinfo/rekonq
--
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F
rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq at freenode
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/rekonq/attachments/20110117/79075ff8/attachment.htm
More information about the rekonq
mailing list