All ContactTreeView Issues, Rewrite

[GoogleCodeExporter]

There are several issues that have been reported that spawn from issues
with the contact tree. The following problems have been reported:

- Cannot Add/Move/Copy contacts to a group that is hidden.
- Toggle show empty groups can cause the tree to crash.
- Offline contacts are not grouped together properly.
- Expand/Collapse memory is not stored.

Overall the design of the tree seemed a bit overly complex, and having
found some new documentation and details about trees and GTK, Paul is going
to re-write the tree widget to be simpler, yet allow for lots of customization.

I've closed all other issues to this one.

Original issue reported on code.google.com by dra...@gmail.com on 2 Jun 2008 at 7:21

[GoogleCodeExporter]

you can add me (7774540) as contact and torture when I'm online (not away, not 
invisible and not offline) :> .

if you want better treeview, take a look at banshee 0.9x.x - it introduces 
selfmade treeview, very fast and nice.

Original comment by jakub.ru...@gmail.com on 2 Jun 2008 at 8:02

[GoogleCodeExporter]

I already have most of the stuff the old tree does working with my new tree 
code, and
some other nice improvements like the expanded/collapsed state being remembered.

I did look into the banshee code a few days ago but its a ListView not a 
TreeView, so
its not really suitable for Galaxium without a lot of changes.

Original comment by paulburt...@gmail.com on 2 Jun 2008 at 8:39

[GoogleCodeExporter]

don't do this before consulting me please, there are a lot of "complex" 
features that
we really want to have in the future, so please don't over-simplify the 
treeview (i'm
available on IRC tomorrow for a chat)

Original comment by ben.motm...@gmail.com on 2 Jun 2008 at 9:18

[GoogleCodeExporter]

I'm afraid I'd already started doing it before you wrote that and I finished it 
up
not long ago with r548. I enabled it for MSN purely to test it out but it's 
enabled
by a #define in MsnSessionWidget.cs and ContactListMenuCommands.cs and the old 
code
is still intact. The other protocols still use the old code for now.

The main reasoning behind this is that the current tree code seems insanely 
complex
for what we need, which makes it really difficult to understand and maintain 
for us
mere mortals. This is evidenced by the proportion of the bugs for 0.7 which were
related to the treeview before Phil closed them for this issue, and which have 
been
around for quite some time.

I'll be on IRC at some point tomorrow too so I'll see you on there to discuss 
it.

Original comment by paulburt...@gmail.com on 2 Jun 2008 at 11:15

[GoogleCodeExporter]

this is exactly what I mean with over-simplifying the tree

the tree only works with IContact objects, which has the following limitations:
* you can only show contacts in the tree, for example: suppose by version 0.8 I
wanted to make a treeview that combines all contacts from all protocols, like 
this:
> group
  > contact
    > msn
    > irc
    > ...
there is currently no way to do this

* the tree is build using the session, there is no way to customize it using 
addins,
it only supports some virtual groups like "offline", "online", ... but it 
doesn't
allow to customize this

* since the tree only knows about IContact, it isn't able to sort by anything 
other
then the nickname and the status (IRC for example, needs to sort based on the
ChannelModeFlags, which is only available in IrcContact)

* the treeview is always initialized using a CellRendererContact and a
CellRendererText, an approach like this will either result in an pidgin like 
treeview
that only shares the common stuff needed by all protocols or a treeview with a 
lot of
features while only 1 protocol needs some of those specific features (but all
protocols need to create the mem structure needed for all those features)

* the CellRendererContact can't be customized, which is a problem for IRC, 
since an
IrcChannel is essentially an IContact, but in the treeview it needs to show the 
Topic
of the channel instead of the 'normal' contact stuff

* ...

Original comment by ben.motm...@gmail.com on 3 Jun 2008 at 9:02

[GoogleCodeExporter]

OK, first off: the tree right now builds based on IGroup->IContact sure, but 
theres
no reason that can't be easily changed. It's quite simple to add more events to
ContactTreeView to allow this to be customized or even replaced.

The second would also partially be solved by firing off events whilst building 
the
tree, and it already does allow customisation of virtual groups by implementing 
a
subclass of ContactTreeGroup overriding ContainsContact to return true if the 
group
should contain the contact. An instance of this class can be given to the tree
through its CreateTreeGroup event.

Sorting is something that does need to be changed, the tree should allow a 
delegate
of some kind to do the sorting, where each user of the tree could give their own
implementation to sort differently.

Yes the tree is always CellRendererPixbuf and CellRendererContact. Again this 
would
be fairly easy to change, but I'm not entirely sure it should be. I'd rather the
contact list were consistent, an aim of mine is that in the future one contact 
list
could be used to show all sessions (hence the class is marked sealed). If we're 
going
to talk about memory then what about the overhead of the current massively
overcomplicated GtkTreeView class? I seriously doubt that this tree has more 
overhead
than that.

I don't quite understand the last point. CellRendererContact simply renders 
pango
markup and displays emoticons in the process (perhaps the name is misleading). 
If you
wanted to show different text it would be done by setting something different 
as the
Markup property from the RenderContactText event of the tree. The msn code 
already
uses this to display the contacts currently playing media for example, which 
the tree
would normally know nothing of.

I agree ContactTreeView needs more work, I wrote it in about 6 hours yesterday 
so
give me a little more time. However, I still think its a better approach than 
the
current tree which is, in my opinion, unmaintainable.

Original comment by paulburt...@gmail.com on 3 Jun 2008 at 12:09

[GoogleCodeExporter]

what I mean with customizing the CellRendererContact, is something like this:
http://www.voipmonitor.net/content/binary/google_talk_player.gif
so that in the future, we can show small icons of a phone, a webcam, ... to 
show the
capabilities of our contacts

also, keep in mind the contact list isn't used only in the MainWindow, It's 
also used
in group chats (like channel conversations in IRC). Those lists need almost the 
exact
same features as the tree in the mainwindow, only without grouping and less 
detailed
rendering

Original comment by ben.motm...@gmail.com on 3 Jun 2008 at 1:03

[GoogleCodeExporter]

Oh, I forgot to mention something

the right-click context menu's are added using an event, which will become a 
serious
pain in the ass when you want to create a treeview that combines all sessions 
(since
the path is decided in the session widget, meaning the session widget needs to 
know
all possible protocols that can be shown in the treeview in advance, which kind 
of
ruins the whole addin concept)

Original comment by ben.motm...@gmail.com on 3 Jun 2008 at 1:21

[GoogleCodeExporter]

OK, r551 changes lots of the tree. It's now somewhere in between the old tree 
and
where it was yesterday. The layout of the tree is fixed to image - text - image 
and
the rendering code (which can be protocol specific) decides if the images 
should be
displayed.

Theres a generic GalaxiumTreeView class which handles the storage of any object
inside a treeview, returning TreeRowReferences instead of TreeIters to the 
outside
world. There are still a few things I want to do with it, such as moving parts 
of the
treeview and menu code from ContactTreeView into GalaxiumTreeView, but this is 
a lot
closer to what I think is required.

I consider the trees in the contact windows to be very much separate from the 
main
contact tree, and thats the case already with the current code. Sure they share 
the
common GtkTreeView ancestor, but they can also share GalaxiumTreeView with the 
new code.

Original comment by paulburt...@gmail.com on 3 Jun 2008 at 10:14

[GoogleCodeExporter]

Found a rendering issue:

2008/06/05 00:41:39 [WARNING] [GLibLogging.LogFunc] Gtk-Warning: Failed to set 
text
from markup due to error parsing markup: Error on line 3: Character reference 
'f'
does not encode a permitted character
Stack trace: 
   at GLib.Object.g_object_set_property(IntPtr , IntPtr , Value ByRef )
   at GLib.Object.g_object_set_property(IntPtr , IntPtr , Value ByRef )
   at GLib.Object.SetProperty(System.String name, Value val)
   at Gtk.CellRendererText.set_Markup(System.String value)
   at Galaxium.Gui.GtkGui.HintTreeNodeRenderer.RenderText(Gtk.CellRendererText cell,
System.String text, Boolean darken) in
/home/draek/Projects/galaxium/src/Galaxium.Gui.Gtk/TreeView/HintTreeNodeRenderer
.cs:line
91
   at
Galaxium.Protocol.GaduGadu.GtkGui.ContactTreeNodeBuilder.RenderText(Galaxium.Gui
.TreeNodeContext
context, Galaxium.Gui.GtkGui.HintTreeNodeRenderer renderer, ITreeNodeWidget 
widget)
in
/home/draek/Projects/galaxium/src/Galaxium.Protocol.GaduGadu.GtkGui/ContactTree/
ContactTreeNodeBuilder.cs:line
195
   at Galaxium.Gui.GtkGui.GtkTreeView`1[[Galaxium.Gui.GtkGui.HintTreeNodeRenderer,
Galaxium.Gui.GtkGui, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=null]].TextDataFunc(CellLayout , Gtk.CellRenderer , TreeModel ,
TreeIter ) in
/home/draek/Projects/galaxium/src/Galaxium.Gui.Gtk/TreeView/GtkTreeView.cs:line 
265
   at GtkSharp.CellLayoutDataFuncWrapper.NativeCallback(IntPtr cell_layout, IntPtr
cell, IntPtr tree_model, IntPtr iter, IntPtr data)
   at GtkSharp.CellLayoutDataFuncWrapper.NativeCallback(IntPtr , IntPtr , IntPtr ,
IntPtr , IntPtr )
   at Gtk.Application.gtk_main()
   at Gtk.Application.gtk_main()
   at Gtk.Application.Run()
   at Galaxium.Client.GtkGui.MainWindow.ExecuteEntryPoint(System.Object[] args) in
/home/draek/Projects/galaxium/src/Galaxium.Client.Gtk/Windows/MainWindow.cs:line
 182
   at Galaxium.Core.EntryPointExtension.Execute(System.Object[] args) in
/home/draek/Projects/galaxium/src/Galaxium.Core/Extensions/EntryPointExtension.c
s:line 42
   at Galaxium.Core.AddinUtility.Initialize() in
/home/draek/Projects/galaxium/src/Galaxium.Core/Utilities/AddinUtility.cs:line 
88
   at Galaxium.Startup.Program..ctor(Boolean debug, System.String appName) in
/home/draek/Projects/galaxium/src/Galaxium.Startup/Program.cs:line 81
   at Galaxium.Startup.Program.Main(System.String[] args) in
/home/draek/Projects/galaxium/src/Galaxium.Startup/Program.cs:line 65
2008/06/05 00:41:41 [WARNING] [GLibLogging.LogFunc] Gtk-Warning: Failed to set 
text
from markup due to error parsing markup: Error on line 3: Character reference 
'f'
does not encode a permitted character

Original comment by dra...@gmail.com on 5 Jun 2008 at 6:47

[GoogleCodeExporter]

2 things:

  1 - Thats the old tree
  2 - It looks like thats caused by incorrect markup (maybe not escaped?) from
GaduGadus ContactTreeNodeBuilder

Original comment by paulburt...@gmail.com on 5 Jun 2008 at 11:11

[GoogleCodeExporter]

Tooltips are not showing the correct items in the tree. some dont show tooltips 
at
all. its out of sync.

Original comment by dra...@gmail.com on 6 Jun 2008 at 8:35

[GoogleCodeExporter]

Insanely complex tooltips fix committed in r571 :P

Original comment by paulburt...@gmail.com on 6 Jun 2008 at 9:49

[GoogleCodeExporter]

I think that this issue can be closed. The tree works for all options that I 
know of
and does not crash.

Original comment by dra...@gmail.com on 8 Jun 2008 at 3:49

• Changed state: Fixed

[GoogleCodeExporter]

is the tree able to show a list of contacts instead of a tree of groups with 
their
contacts as children, otherwise this issue needs to be re-opened (the IRC addin
requires this)

Original comment by ben.motm...@gmail.com on 8 Jun 2008 at 8:45

[GoogleCodeExporter]

ContactTreeView itself cannot but its trivial to use GalaxiumTreeView for a 
simple list.

Additionally I'll be adding a BasicContactTreeView or something similar for the 
lists
of IContacts in group chats, which is what I guess you'll need for IRC.

Original comment by paulburt...@gmail.com on 8 Jun 2008 at 11:49