Re: TreeView and row-reordering by Drag and Drop
- From: Kristian Rietveld <kris gtk org>
- To: sledge hammer <sledgehammer_999 hotmail com>
- Cc: gtk-list gnome org
- Subject: Re: TreeView and row-reordering by Drag and Drop
- Date: Sat, 4 Dec 2010 21:11:31 +0100
2010/12/4 sledge hammer <sledgehammer_999 hotmail com>:
> I am using a GtkTreeView and a GtkListStore as TreeModel. I want to reorder
> the rows by DnD. This is easy if I set "set_reorderable" to true. But I want
> to take extra actions when the rows are reordered. Eg I want to renumber the
> rows (think of a playlist). Also I want to do DIFFERENT things when a row is
> deleted or inserted. This, however, conflicts with my renumbering-code
> because after a row is re-ordered by dnd a set of row-deleted/row-inserted
> signals is emitted. I want a way to differentiate between the signals
> emitted by DnD and other actions.
> IMHO the DnD implemention of the TreeView
> should use different signals. Why doesn't it use the "rows-reordered"
> signal???
"rows-reordered" is mostly used when a model is being sorted, not when
rows are moved with drag and drop (I agree that the naming is
confusing). One reason why the DnD implementation does not use
rows-reordered is that rows-reordered can only handle moving a row
from and to the same level (or branch). So for example, if you are
using GtkTreeStore and you want to move a row from the root level to a
branch of some node, you cannot do this with rows-reordered, but you
will have to remove and re-insert the row. Now this does not
immediately apply to you since you are using GtkListStore, but to keep
things consistent GtkListStore uses remove/insert as well instead of
rows-reordered.
Currently, your only way of distinguishing between a DnD or non-DnD
row-deleted or row-inserted signal is by doing this yourself (e.g. you
could set a flag when your code is inserting or deleting rows and use
that information in your row-inserted/row-deleted handler).
> A way I thought of, is the following. But I am currently really confused on
> how to proceed. Maybe this is not possible the way I am thinking it. I want
> the CURRENT gtk implementation to work as-is up to the point where the row
> is deleted/inserted when dropped. At that point, I want my code to step-in
> and instead of calling delete/insert, it will call gtk_list_store_reorder()
> or gtk_list_store_move_*(), prevent the emission of delete/insert signals
> and then emit a custom signal. What do I need to do to achieve this? Derive
> from GtkListStore? If yes, what should I implement/handle? Any
> tutorials/links/docs on this?
You could look into subclassing GtkListStore and re-implement the
GtkTreeDragSource and GtkTreeDragDest interfaces.
> Sidenote: Do gtk_list_store_reorder()/gtk_list_store_move_*() emit a signal
> on their own?
Both emit rows-reordered and construct the order array that is passed manually.
regards,
-kris.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]