Re: Bookmarks reworked

On Thu, 2004-09-02 at 02:47, Peter Harvey wrote:
> On Wed, 2004-09-01 at 20:43 +0200, Marco Pesenti Gritti wrote:
> > Bookmarks toolbars are somewhat special because they can be manipulated
> > outside editing mode. It's not intuitive for example to have to open the
> > toolbar editor to remove a bookmark from the toolbar.
> I have still retained the 'remove' option for bookmark and topic items
> on the toolbar, but only because it was necessary to retain it. Just to
> make your point further, the most unintuitive behaviour I found was
> this:
>       * Open bookmarks editor.
>       * Select topic.
>       * Add it to the "bookmarks bar".
>       * Close bookmarks editor.
>       * Turn on "show bookmarks bar" from menu.
>       * Open toolbar editor.
>       * Drag topic toolbar item from the bookmarks bar to the main
>         toolbar where I want it.
>       * Close toolbar editor
>       * Turn off "show bookmarks bar" from menu.
> Was there an easier way to do this?

Hm? I probably dont get your point here. I was talking about
removing/reordering not about adding bookmarks to other toolbars, not
sure how that did get in the game ...

> > Even if I'm not convinced the editing of the two types of toolbars
> > should/will be identical the consistency can be improved and normal
> > toolbars needs some sort of keyboard bindings/context menus when in edit
> > mode too.
> > Though there are no reasons to introduce regressions.
> This patch tries to 'clear the path' in preparation for a consistent
> method for modifying the toolbar, and in doing so I have removed things.
> I've tried to introduce some consistency already (like consistent drag-
> and-dropping to add toolbar items). If I was to go further I would add a
> consistent popup menu for all toolbar items with a 'remove' entry and a
> 'move' entry which allows the item to be moved around on the toolbar (by
> mouse or by cursor keys!).

Looks like there are 3 possible approaches.

- Move Left/Move Right
- Move (like the panel I guess)
- Cut/Paste

We need to find out which is the better for our needs.

> What I have submitted is only phase 1 and I expect features to be added
> back in phase 2. I would have gone much further with this patch but I'd
> have an even harder time getting the code accepted. And, since I didn't
> have high hopes of it being accepted in the first place, I shouldn't
> spend too much time going down one development path. But I couldn't do
> any less because I didn't know if what I wanted was possible. :) At
> least I understand the Epiphany code better now.

Sure we appreciate and support your effort. We have some issues with
your design (Christian will post about them later) but I think they can
be sorted out.
We just prefer to go about it gradually and not introduce regressions.
Once we discussed the design issue we can see how to get the patch
integrated ...

> Finally (this is probably being insensitive but I have no other way to
> express it):
>       * If you are using a computer without a mouse can you use the
>         toolbar at all with current Epiphany?

Yeah gtk toolbars are key navigable, if something doesnt work then it's
a bug.
Posssibly this is relevant:

>       * Would you use the toolbar (with the exception of the location
>         bar) when you consider that practically everything on the
>         toolbar has a keyboard shortcut?

Are you trying to make the point that there is no need for toolbars key
navigability (and "editability") ? I'm not clued enough about
accessibility to give you a good answer and I have to admit I was a bit
surprised too about it.
Anyway there is Bill feedback here:


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]