In a nutshell, the navigational problem I'm talking about is that gtk.TreeView not handles keystrokes properly when it is unfocused (which happens a lot in deskbar). I tried to fix this in gtk, but I failed. The next problem is that there actually is now easy way of selecting next/prev nodes in a treeview taking into account expandedness of branches and general parent vs sibling issues. Natively gtktreeview uses a GtkRBTree which is not part of the public gtk interface so we're stomped...
Last night I had an idea - why not compute the next/prev elements "graphically"? I graphically computing the next/prev cell and then selecting that?
Behold (self is a CuemiacTreeView):
def move_cursor_up_down (self, count):
"""
Move cursor one step up or down in the tree.
@param count: 1 for up/next, -1 for down/previous.
@return: True if the move was succesful.
"""
path, col = self.get_cursor ()
rect = self.get_cell_area (path, col)
new_cell_y = 0
if count == -1:
# Select a point in the cell above the cursor
new_cell_y = rect.y - 5
print "ctv move up", new_cell_y
else:
if count != 1:
print "WARNING in CuemiacTreeView - in move_cursor_up_down, the count must be 1 or -1."
# Select a point in the cell below the cursor
new_cell_y = rect.height + rect.y + 5
print "ctv move down", new_cell_y
# Select the cell meeting the point ( rect.x, new_cell_y)
cell_ctx = self.get_path_at_pos (rect.x, new_cell_y)
if cell_ctx is None:
return False
path, col, x, y = cell_ctx
self.set_cursor (path, col)
# TMP
model = self.get_model ()
print "new path", model.get_string_from_iter(model.get_iter(path))
return True
What a hack!!!! OMG somebody will surely kill me :-D Anyway - I'm gonna merge this unless there are major objections, LOGICAL_AND we somehow find an alternative approach.
Cheers,
Mikkel
_______________________________________________ deskbar-applet-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/deskbar-applet-list
