On Thu, 20 Nov 2003 14:14:57 -0600 Michael Urman <[EMAIL PROTECTED]> wrote:
> Thanks Walter and Doug for the wonderful TreeView DND example. > Finally I was able to go get the DND constraints I want in my > application. > > But what I still can't figure out is how to communicate these to the > user. There must be a way to tell GTK that i can't drop from that > source row to this dest row, so the DND doesn't look like it's going > to happen. > > I've tried connected 'drag-motion' events and conditionally calling > drag_context.set_reply(False, time) from it. Which does nothing until > i kill the normal handler, but then it just stops all drops. > > http://www.moeraki.com/pygtkreference/pygtk2reference/class-gtktreedragdest.html > row_drop_possible() looks like the right idea, but i don't know how to > hook it up. Any suggestions? > > If you want to talk in tested code, i have a base available at > http://mu.arete.cc/treeviewdnd.py ; in that example i'd like to make > it so you can only drop a row on a row of a preceding letter, but not > do this by filtering in drag_data_received. ________________________________________________________________ I suppose you are asking two questions: 1. how to tell gtk, that you can't drop to a certain row. 2. how to communicate that to the user before the drop occurs. 1. how to tell gtk 1.1 static "parentability" if the rows that could not be made parents are unchangeably set (e.g bookmarks organized in a tree or menus in a menueditor for a windowmanager) one could use an extra column with boolean values. (apply the appended diff to Dougs version. the resulting code is ugly and needs tidying up but shows the principle. you won't get the seventh row to be a parent any more.) 1.2 dynamic "parentability" I think it is not difficult to implement - comparing values of certain cells. 2. how to communicate to the user 2.1 static "parentability" placing a descriptiv graphic (i.e a foldericon) somewhere/somehow in the row would probably do the trick. 2.2 dynamic "parentability" there are two decisions to make: a) what kind of (temporary) visual changes a1) a graphic in a small column, that shows up. a2) changing the textcolor of a row/cell a3) changing the color of a row a4) placing a descriptiv graphic (i.e. a stop sign) at the row (a transparent one would be nice). this would be the most appealing possibility but very probably the most catchy too. b) _when_ to show up the visual changes b1) when the drag begins. that implies that the visual changes occours for all rows not to be made parent. it seems like a sound approach but may turn out to be too recource hungry. b2) when the drag-icon is hovering over the row. (seems to be a hairy one) ________________________________________________________________ My aim here was mainly to clarify the possible decisions concerning the user interface. it is surely not complete and inaccurate at some points but may be helpful. I did not put much stress on coding difficulties that may show up. walter
diff
Description: Binary data
_______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
