GNOME Bugzilla – Bug 111315
contents of topics in toolbars should be alphabetized, as in the bme
Last modified: 2004-12-22 21:47:04 UTC
In the bme, all bookmarks listed for a given topic are shown alphabetically. However, when using a topic that has been dragged to a toolbar, the bookmarks are displayed in seemingly random order. Having these alphabetized would be very nice.
I'm on this.
Created attachment 15989 [details] [review] Unnecessarily long patch...please forgive me
OK Marco please forgive me here for making this patch so long. The core code for this patch is in src/bookmarks/ephy-topic-action.c. However while doing the patch i decided that it would be cool if special topics also were bolded. To do this would have required depeding on ephy_node_view.h for just a simple enum. I thought the enum was generic enough that I moved it into ephy_node.h. Another nicety of this is that I could add ephy_node_get_property_priority (EphyNode *node, guint property_id), which is really just a wrapper for ephy_node_get_property_int. However ephy_node_get_property_priority, does a check for priority == -1 and in that case return EPHY_NODE_NORMAL_PRIORITY. This check was being done numerous places in the code after ephy_node_get_property_int, so this leads to some code reuse and less confusion. ok to commit?
This is the patch that implemented ephy_node_children_reordered, ok to commit before implementing the actual sort stuff?
Created attachment 15994 [details] [review] patch
Yeah please do.
Xan posting rationale of why I dont we should go that way. From a teoric pov mixing views and data is wrong. And that's what we would be doing by sorting nodes. The order is a presentation thing, it should be kept in the model. From a more practical pov, what happens if you mix content and view. - You cant have two differently sorted views of the same data. While there is still not a use case for this, I dont think we should block it. - You cant let the user sort data in the treeview. We are not doing it now, but it would be bad to block it - You would have to update order everytime on startup. You cant assume the user is using the same language everytime it start epiphany I'm sure there is more. In general it's conceptually wrong, it's not even worth thinking to the problems it raise ;)
About the implementation of the menu thing what I would do is. Add node ids to to a list, run g_list_sort on it and then build the menu. It should not take too much code, also I'd not expect performance problems from it ...
And yeah, Xan I suck again. I dont understand why I keep making you waste time ... :/ About priority defs, I'd use a ephy-node-common.h in lib/, we can move to it also node stuff in ephy-types.h
So if I understand it ok, you want to create a GList with the nodes strings, sort that and make the menu from it? And what about the favicon icons? It wil be a huge pain to locate the node for each string, see if it has a favicon, etc... I talked a bit with kris and he suggested creating a dummy struct with the string and a pointer to the node... but it's a bit hackish... ideas?
Oh wait, you mean creating a Glist with nodes id, and make the sort func do its work on the node title/name getting each node with ephy_node_get_from_id () ? Why we could not do the same sorting on a local copy of the g_ptr_array of childs?
>Why we could not do the same sorting >on a local copy of the g_ptr_array of childs? Because I have not found a nice way to do dup a ptr array ;) That works too though, if you find a way. What I care is that sorting is done in a local structure, not on the real data.
Fixed in cvs.