Re: [Epiphany] Bookmarks (was Armchair Dev...)

["Marcelo E. Magallon" <mmagallo debian org>]

On Tue, Oct 28, 2003 at 11:17:46PM +1100, Peter Harvey wrote:

 > In a similar vein, I'd like to bookmark my reference documentation by
 > sub-categories (Programming, Constraints, Web, etc). So we have two
 > examples here where shallow hierarchies are useful.

 I see what you mean.

 I still think the correct solution is to separate the bookmark thing
 from Epiphany, reimplement the current thing as a separate application
 and ship it with Epiphany.  And just for the fun's sake, make it damm
 hard to change the default... :-)

 "Add bookmark":

    Epiphany tells the bookmark application the URL, title and favicon
    to add to the bookmarks.  The thing that comes up is up to the
    application.

 "Edit bookmarks":

    Epiphany tells the application to open an edit thing, it's up to the
    application what the look of this thing is.  Since Epiphany doesn't
    allow for editing bookmarks from the menu no functionality is lost,
    although is is easy to implement if required.

 How to build the menu?

    The application transmits the list of entry type (menu item, menu
    separator, ...), submenu name, topic list (maybe empty), title, url
    and favicon filename to Epiphany.  Some of this stuff is metadata,
    careful readers will notice smartbookmarks are absent.  As a matter
    of fact, the application can transmit something much like Epiphany's
    current RDF data.  The point is that Epiphany doesn't go out of its
    way to enforce a one-level deep menu estructure and Epiphany doesn't
    try to build the menu structure on its own.  Upon updates the
    application sends an update event.

    The topic list is required in order to avoid killing a feature that
    some users find useful, namely being able to *type* a topic on the
    address bar and get a list of bookmarks with that topic.  This is
    something Epiphany itself does, not the bookmark application.  IOW
    Epiphany won't continously send queries to the application hogging
    the communication channel.

 This allows for things like collaborative bookmark systems, with the
 advantage of shifting e.g. all the caching logic outside Epiphany
 (where it doesn't belong in the first place).

 > I will say that I loved the idea put forward by Eric Newman for
 > auto-detecting the hierarchy
 > (http://mozdev.org/pipermail/epiphany/2003-August/000093.html) though
 > I am concerned that it wouldn't work well in practise.

 Any particular objection to that idea or is it just a hunch?  My
 problem with that is that it doesn't solve the "the menu is too large"
 problem.  It does solve the "I can't find anything in the submenu
 because it contains too much stuff" problem, for some users at least.

 Having the following bookmarks with topics:

        B0: T0
        B1: T0
        B2: T1

 you naturally cluster them as:

        T0: B0, B1
        T1: B2

 having:

        B0: T0
        B1: T0
        B2: T0, T1

 you can have (the current solution):

        T0: B0, B1, B2
        T1: B2

 or (Eric's proposal):

        T0: B0, B1
            T1: B2
        T1:
            T0: B2

 or (my preference):

        T0: B0, B1
            T1: B2

 What do you do with:

        B0: T0
        B1: T0
        B2: T0, T1
        B3: T1

 In this case I'd prefer:

        T0: B0, B1, B2
        T1: B2, B3

 yes, that's the current solution.  And yes, I can see this can lead to
 some pretty frustating situations.

 Marcelo