Re: Bookmarks reworked

On Thu, 2004-09-02 at 10:25 +0200, Marco Pesenti Gritti wrote:
> 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 ...

Sorry, got caught on the "It's not intuitive for example to have to open
the toolbar editor" sentence. Was just giving another example of non-
intuitive behaviour caused by the difference between the 'bookmarks bar'
model and the normal toolbar model.

> > > 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:

I just tried to get to the toolbar in Evolution 1.5.93, and couldn't.
Similar in Nautilus (I can get to the location entry but not the main
toolbar when in browser). Maybe I was doing something wrong but the
standard principle of "press tab until you get to the widget you want"
didn't work. Are GTK 2.x toolbars still meant to be key navigable? If
they are this seems to be a pretty wide problem.

> >       * 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") ?

Pretty much, yes. I guess that sentence wasn't as clear as it could be.
In reality, I'm saying there is no need for toolbars *at all* (with the
exception of the location entry) if you don't use the mouse.

> 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:

Yeah, I have been reading bug 105129 tonight. Although statements like:
        if we want the epiphany toolbar editor to be integrated into
        gnome in the long term, its going to need some accessible
        interfaces. In particular, we need to make toolbar editting
        possible using the keyboard.
are there, I'm still not convinced that toolbar editing from the
keyboard is that important. 


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