After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 95362 - can't drop rows on empty treeviews | treestore reordering broken
can't drop rows on empty treeviews | treestore reordering broken
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
2.0.x
Other Linux
: Normal normal
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
: 113619 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-10-10 00:53 UTC by Carlos Garnacho
Modified: 2011-02-04 16:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
primarily patch, might need some work later on. (5.85 KB, patch)
2003-05-29 00:35 UTC, Kristian Rietveld
none Details | Review
updated patch removing -drop-append object data usage as per #113314 (12.30 KB, patch)
2003-06-26 00:17 UTC, Kristian Rietveld
none Details | Review
galeon screenshot (30.96 KB, image/png)
2003-07-03 16:13 UTC, Dave O
  Details
updated patch (13.73 KB, patch)
2003-07-12 19:43 UTC, Kristian Rietveld
none Details | Review
updated patch (Aug 16) (17.11 KB, patch)
2003-08-17 01:56 UTC, Kristian Rietveld
none Details | Review
patch as committed (17.88 KB, patch)
2003-09-09 23:16 UTC, Kristian Rietveld
none Details | Review

Description Carlos Garnacho 2002-10-10 00:53:51 UTC
I am trying to enable drag and drop between 2 GtkTreeViews with the next
functions:

-gtk_tree_view_enable_model_drag_source
-gtk_tree_view_enable_model_drag_dest


obtained result:

When I drag a cell from one tree to another, I can drop only where there
are cells, and thus, If the dest tree is empty, I cannot drop anything.


expected result:

It should allow dropping in all the GtkTreeView area, not only in the area
filled by cells
Comment 1 Kristian Rietveld 2002-12-19 02:44:49 UTC
Moving remaining bugs to 2.2.1.
Comment 2 Kristian Rietveld 2003-01-22 23:52:41 UTC
I think I need a new entry in GtkTreeViewDropPosition in order to fix
this cleanly.

Moving to 2.4 API freeze.
Comment 3 Kristian Rietveld 2003-05-28 00:50:27 UTC
Euhm, not sure what I was smoking last time, I don't need a new entry
in GktTreeViewDropPosition. It's doable within the current situation,
provided using enough hacks/special cases.

I have a prototype patch, which works. Though I need to rewrite it
first before I even dare to attach it here.

Moving back to 2.2.x.
Comment 4 Kristian Rietveld 2003-05-29 00:35:18 UTC
Created attachment 16930 [details] [review]
primarily patch, might need some work later on.
Comment 5 Kristian Rietveld 2003-06-26 00:17:41 UTC
Created attachment 17777 [details] [review]
updated patch removing -drop-append object data usage as per #113314
Comment 6 Dave O 2003-07-02 23:51:24 UTC
I applied this patch (id=17777) to debian gtk+ 2.2.1-6 looking for a
possible solution to galeon bug #93234, but the behavior is now that I
cannot drop a TreeView (bookmark editor) row into *any* folder rather
than just an empty one.

Before, the row would simply not drop at all if the destination folder
was empty.  Now, it will drop immediately above the folder in the same
level, empty or not.
Comment 7 Kristian Rietveld 2003-07-03 16:03:02 UTC
Is there some screenshot of this bookmark dialog and folder dialogs? I
really need some more context here to understand what you are exactly
saying.

I tested my fix with testtreecolumns and it works fine there.
Comment 8 Dave O 2003-07-03 16:13:03 UTC
Sorry, I forgot to clarify, the application I was talking about is the
bookmark editor in Galeon 1.3.5 which uses TreeView.  In the screenshot:

Without the patch, I can drop the Google bookmark into Folder 1, but
not Folder 2

With the patch, I cannot drop it into either.
Comment 9 Dave O 2003-07-03 16:13:34 UTC
Created attachment 18017 [details]
galeon screenshot
Comment 10 Kristian Rietveld 2003-07-03 16:33:43 UTC
Oh, right. Then you are a dup of 113619 and not this bug ;).
Comment 11 Dave O 2003-07-03 16:48:40 UTC
That may be the case, but if this fix is applied to 2.2.x and 113619
is 2.4, things that need to be able to do that will be MORE broken
until 113619 is fixed (the duration of 2.2.2+)
Comment 12 Kristian Rietveld 2003-07-12 19:41:22 UTC
*** Bug 113619 has been marked as a duplicate of this bug. ***
Comment 13 Kristian Rietveld 2003-07-12 19:42:42 UTC
Will attach an updated patch which also fixes treestore reordering as
per bug #113619. The updated patch uses doesn't use object data
anymore, but just adds flags to GtkTreePrivate which results in
cleaner code.
Comment 14 Kristian Rietveld 2003-07-12 19:43:42 UTC
Created attachment 18244 [details] [review]
updated patch
Comment 15 Dave O 2003-07-21 16:37:45 UTC
This patch seems to work pretty well.  It seemed a little hard on the
CPU, though that could have been other circumstances.  No complaints here.
Comment 16 Kristian Rietveld 2003-08-15 16:23:52 UTC
http://mail.gnome.org/archives/gtk-devel-list/2003-August/msg00101.html


Moving to 2.4.
Comment 17 Kristian Rietveld 2003-08-17 01:56:50 UTC
Created attachment 19279 [details] [review]
updated patch (Aug 16)
Comment 18 Kristian Rietveld 2003-09-09 23:16:25 UTC
Created attachment 19835 [details] [review]
patch as committed
Comment 19 Kristian Rietveld 2003-09-09 23:17:32 UTC
Finally committed on HEAD. yay.
Comment 20 Carlos Garnacho 2003-09-09 23:56:04 UTC
great! I suppose that HEAD will be 2.4, can't wait to port my current
programs to 2.4 and test it :-)

great work, kris!