* Should be possible to resize columns in history and bookmarks
* Both columns should, by default, fit in the window in bookmarks (when
"title and address" is enabled) like they do in history
* History should allow horizontal scrolling when nessecery

I dont think there is a way to do any of these with current treeview
sizing, I'd appreciate improvements that fit in the current api
though, if you can suggest them

* Columns in Bookmarks should be sortable

Yeah make sense.

* History uses alternating row colours. Bookmarks doesn't. Perhaps they
should be the same?

I think we should not set any hint on the treeview. We dont have that
much columns.

Both seem easy fix for someone to contrib a patch :)

Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o

*** Bug 151937 has been marked as a duplicate of this bug. ***

What's the status of this bug? Is it still active?
IMHO, these features would add a lot to the usability of Epiphany.
Also, the history section of this bug relates to bug 111910, so adding it to deps.

Targeting for 1.10

* Should be possible to resize columns in history and bookmarks
* Both columns should, by default, fit in the window in bookmarks (when
"title and address" is enabled) like they do in history

I agree. Furthermore, it seems like the sizing of the columns are done by the
longest entry there is in bookmarks, and this is then used on all pages, even if
that bookmark isn't displayed. It's kinda consistent, but if you have added one
long bookmark somewhere, it distorts all other pages. Also, it seems it never
shrinks until restart. It expands if you create a longer name, but never shrinks
if you shorten, so a rename doesn't help, unless browser is restarted.

I think that, apart from the above suggestions:
* Column width should autosize both ways, if there is to be "live autosize".
* I'd personally prefer to have the autosize happen per view, it would look more
natural even though column width would change by the topic.

Updating version fields.

*** Bug 341658 has been marked as a duplicate of this bug. ***

Mass changing target 2.16 -> 2.18

*** Bug 353904 has been marked as a duplicate of this bug. ***

*** Bug 379854 has been marked as a duplicate of this bug. ***

Created attachment 78902 [details] [review]
Makes history and bookmarks windows consistent

(In reply to comment #0)
> * Should be possible to resize columns in history and bookmarks
I'm using gtk_tree_view_column_set_resizable (col, TRUE); but I get a weird bug... the <-> cursor remains like that until I click somewhere else.
In the patch.

> * Both columns should, by default, fit in the window in bookmarks (when
> "title and address" is enabled) like they do in history
Don't know how. I changed the min_size for cols but didn't help. If you change the max_size then resizing is useless. 


> * History should allow horizontal scrolling when nessecery
It does.

> * Columns in Bookmarks should be sortable
Check the patch.

> * History uses alternating row colours. Bookmarks doesn't. Perhaps they
> should be the same?
Check the patch.

The <-> cursor bug is really annoying and of course a showstopper for this bug. We should start thinking about history/bookmarks integration, we are breaking DRY heavily here.

Created attachment 78906 [details] [review]
History window part :P

I forgot to add this to the original patch.

Thanks for the patch! Please commit to trunk and gnome-2-16.

Easy dude, we don't want a <-> cursor that I don't know where it comes from :).

Hmmm. I need someone's help here, the <-> cursor is a major problem and I sincerely don't have any idea of what's causing it.

There will be no more 2.18.x releases; moving bugs off of that target milestone.

I tried to debug this one too and did not come up with a solution.
Anyway I found an interesting thing:
- apply dieguito's patch
- click to resize a column, resize it, leave the click, you will see the <-> cursor appear.
- move the cursor again to the resize separator and click to resize again
- now the bug does not happen anymore (cursor is restored to normal pointer).

You can repeat these steps and you'll see that <-> cursor appears on first, third, fifth try and so on, while it does not appear on second, fourth...
Also, when the cursor is <->, if you click on some other place, you will reproduce the bug (this strange "counter" is reset).
Anyway, I really think this is GTK-related...Christian, any hint?

Now that the dependencies are resolved, the only reason for leaving this bug open is the column resizability, correct?

Reinout: yes, that's the only thing that is leaving this opened.
I tried to have a look at the code again, but got only headaches reading gtk/gtktreeview.c and found no way to solve it.

It could be worthwhile to check how another app (Rhythmbox for example) does it...?

Cosimo queried me about this on IRC this afternoon.  As I have never seen this before I started out by suspected EphyNodeView ;)  When I quickly read over that code I saw some button-press handlers connected to the GtkTreeView.  These were not checking on which window the events were received -- this stroke me as very suspicious.  As I was not on a Linux machine this afternoon I could not verify this until now.  And it seems that my first suspicion is right ;)

If I patch EphyNodeView with the following, the problem goes away for me:

 Index: ephy-node-view.c
===================================================================
--- ephy-node-view.c    (revision 7685)
+++ ephy-node-view.c    (working copy)
@@ -812,6 +812,12 @@ ephy_node_view_button_press_cb (GtkWidge
        gboolean call_parent = TRUE, path_is_selected;
        selection = gtk_tree_view_get_selection (GTK_TREE_VIEW (treeview));
 
+
+       if (event->window != gtk_tree_view_get_bin_window (GTK_TREE_VIEW (treeview)))
+       {
+               return GTK_WIDGET_CLASS (parent_class)->button_press_event (treeview, event);
+       }
+
        if (gtk_tree_view_get_path_at_pos (GTK_TREE_VIEW (treeview),
                                           event->x,
                                           event->y,

Created attachment 99064 [details] [review]
proposed patch

Thanks Kris for the great help here! It works just fine with your fix.
This patch integrates Diego's one and yours, adding resize support to columns for both History window and Bookmark Editor.

Created attachment 99065 [details] [review]
adds ellipses to columns

I also noticed that the editors are ugly when having long bookmarks addresses (common if you use bookmarklets or bookmark dynamic websites pages) or (even more common) history addresses/titles (i got many unwanted GoogleAd pages in history with really long titles and addresses).
Attached patch ellipsizes columns so that the whole thing looks way better and integrates with new resizing ability.

For the ellipsisation, I'd rather you added a new flag to EphyNodeViewFlags that put the cell renderer to ellipsisation mode, and just used that in the bookmarks editor instead of fiddling with the node view internas from without.
Also, don't you also need to set the 'ellipsize-set' property too?

Created attachment 99307 [details] [review]
adds ellipses to columns v2

Attached patch for ellipses on columns is updated according to your last comment :)

Landed in trunk r7719. Closing this as FIXED, as this was the remaining issue among those described.

Reopening this bug. After running ephy HEAD for this first time, none of the columns in the history are enabled. I suggest Title + Address should be enabled by default.

Created attachment 99511 [details] [review]
patch to schemas.in

Attached patch modifies the schemas.in file to reflect the changes to the history window columns, and set default view to address and title.

Patch committed :)

------------------------------------------------------------------------
r7746 | cosimoc | 2007-12-02 21:11:21 +0100 (dom, 02 dic 2007) | 3 lines

Update epiphany.schemas.in according to the changes in bug #380156.
Fix bug #132808.