Re: Bookmark behaviour
- From: Marco Pesenti Gritti <marco gnome org>
- To: Peter Harvey <pah06 uow edu au>
- Cc: Christian Persch <chpe gnome org>, "epiphany list at gnome.org" <epiphany-list gnome org>
- Subject: Re: Bookmark behaviour
- Date: Sun, 08 Aug 2004 14:02:53 +0200
On Tue, 2004-08-03 at 06:06, Peter Harvey wrote:
> On Mon, 2004-08-02 at 23:22, Christian Persch wrote:
> > This is by design. The goal was to allow presentation of imported
> > hierarchical bookmarks (from Mozilla/Firefox/Galeon/etc) without giving
> > up our native, keyword based bookmarks system. Althoughin hindsight we
> > should probably have chosen a different separator than '/'...
>
> Now I understand the purpose of ensure_folder in ephy-bookmarks-menu.c!
>
> A few design Qs:
>
> Does this mean that, after importing bookmarks from Galeon, if I try to
> add a bookmarks I'll be presented with a list of topics like
> "Reference/Programming" and "Reference/Constraints" ?
>
> Looking at the code in ephy-bookmarks-menu.c, if I choose to rename one
> of the above topics to "Reference/Coding" I don't think that will be
> reflected immediately in the bookmarks menu. I've been using
> ephy_topic_action_new in my patch because the created action has a
> topic_child_changed_cb to immediately reflect changes in the topic name.
Good catch, if you could post a bug that would be helpfull.
> I'm not trying to be rude, and I understand what's trying to be achieved
> here. But if Epiphany wants to support hierarchical bookmark structures
> in the sense that other browsers do, then this should probably be
> reflected in the way the EphyNode class is used and not just in the way
> the bookmarks menu is constructed.
The target is not to support hierarchical bookmarks but to make
importing easier. In 1.2 we was destroying the hierarchy and so causing
information loss. Now we are preserving it so that migrating to the new
approach is easier.
By (user interface) design we want only the bookmarks menu to be
hierarchical, that's why the structure is not reflected in EphyNode.
> Note: I still support the topic-based approach, and I'll continue to
> maintain my patch as long as Epiphany uses it. But trying to support a
> 'stop-gap' measure for other browser fans like this really messes up my
> code. :(
It's not meant to be a stop-gap. We surely have a migration problem and
we need to do something about it.
If there are specific problems we are causing to your code I'm surely
available to discuss them.
Thanks
Marco
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]