STR #2828

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]

STR #2828

Application:FLTK Library
Status:5 - New
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Fl_Tree RFE's
Version:1.3-current
Created By:greg.ercolano
Assigned To:greg.ercolano
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
 
#1 cand
04:40 Sep 01, 2014
fltk-tree-dragging.patch
9k
 
 
#2 cand
02:49 Sep 04, 2014
fltk-tree-dragging-v2.patch
10k
 
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#1 greg.ercolano
10:04 Apr 18, 2012
A collection of requests from various folks for Fl_Tree enhancements:

    A) Show leaves + Show branches -> selectable independently
    B) Add 'FRONT/BACK' sort flags (FRONT: causes add() to insert(pos=0)
    C) Shaded entries (ie. ruled report). Include #items per ruler
    D) Multiple selection drag ignore (items aren't selectable)
    E) {Vertical|Widget} Gap (Fl_Tree has horizontal and top bottom)>
    F) Open on select: expand the node on select
    G) Allow global fg/bg colors (to override per-item colors) [fluid]
    H) A method to return all selected items as a list.
       (Perhaps an option to internally optimize this; see fltk.bugs
        thread on STR#2795, greg's long 04/16/12 21:16 reply to F.)

Regarding (D), Fabien writes:
"the selection mode 'drag_ignore' is in fact the capability *not*
 to select multiple items with a simple push in multiple selection
 mode, thus: only kbd operations can achieve that multi-selection,
 mouse only selecting one item at a time."

There are other implementation details in the fltk.bugs thread
on 04/16 regarding the above list.
 
 
#2 fabien
07:35 Apr 21, 2012
for Point D) more prcisely we still can select multiple items but with click and keyboard combination.
It is only the drag operations that are disabled.
Typically useful when dealing with performances cost on tree selections and willing no to penalize user for useless multiple intermediate selection steps.
 
 
#3 fabien
17:07 Apr 27, 2012
Hi Greg godd job for the recent enhancements you made on Fl_Tree,

something really mice to do to do would be to sync the item default bkgnd color to the box color instead of white, thus not making the assumption that the default bckgnd is white...
More precisely what could be done is make sure that first item creation use a lazy/late binding scheme that would ensure that an item (i.e. the root) would be created only after the default color has been set ?
 
 
#4 greg.ercolano
12:04 Apr 28, 2012
@Fabien: Yes, indeed, there was an intention to do this when I
designed the API.

The intention was to have it similar to the way the global
scrollbar size stuff works, where one control the scrollbar size
globally in an application, but also give individual control when
needed that overrides the global behavior.

Fl_Tree::item_labelfgcolor() and Fl_Tree::item_labelbgcolor() are
supposed to allow you to change the entire tree's fg/bg color
even /after/ the tree has been built. The only time an item's
own color would be used is if it were first SET by the app.

So I imagined I could use a bitflag to indicate whether a color
had been set or not. Apparently didn't get around to doing that.

So I think I can add bitflags for this.. I imagine it can work
this way:

    o If the app doesn't try to set Fl_Tree::item_labelfgcolor()/bg
      and doesn't try to set a specific item's fg/bg color,
      the widget's own color() and labelcolor() will be used
      for all the items. Changing the color()/labelcolor() will
      affect the items globally, even /after/ the tree is built.

    o However, if the app sets the Fl_Tree::item_labelfgcolor()/bg,
      then this globally overrides the use of the widget's color()
      and labelcolor(). This way, the app can still globally control
      the tree's item colors even after the tree is built, while still
      allowing the widget color() and labelcolor() to be different.

    o Finally, if one sets a particular item's color, this will
      cause that item to be drawn in that color, overriding the above.
 
 
#5 greg.ercolano
22:40 Nov 06, 2013
Add:
     I) Option flag to be able to drag+drop items (to move them)
 
 
#6 greg.ercolano
08:54 Feb 01, 2014
Some items on the list have been completed:

    A) Show leaves + Show branches -> selectable independently
    B) Add 'FRONT/BACK' sort flags (FRONT: causes add() to insert(pos=0)
    C) Shaded entries (ie. ruled report). Include #items per ruler
    D) Multiple selection drag ignore (items aren't selectable)
    E) {Vertical|Widget} Gap (Fl_Tree has horizontal and top bottom)>
    F) Open on select: expand the node on select
    G) (DONE: special color 0xffffffff for items uses widget's
       own colors) Allow global fg/bg colors (to override per-item
       colors) [fluid]
    H) (DONE: r10016) A method to return all selected items as a list.
       (Perhaps an option to internally optimize this; see fltk.bugs
        thread on STR#2795, greg's long 04/16/12 21:16 reply to F.)
    I) Option flag to be able to drag+drop items (to move them)
    J) (DONE: r10034) Implement horizontal scrollbar!
    K) (DONE: r10071) A way to define custom draw behavior for items
        without using Fl_Widget's.
 
 
#7 cand
06:21 Aug 21, 2014
I) Option flag to be able to drag+drop items (to move them)

+1 for this one. I may get to it in a couple days/weeks.
 
 
#8 cand
04:40 Sep 01, 2014
Attaching patch that implements dragging in an ABI-safe way. Please review.  
 
#9 greg.ercolano
22:35 Sep 01, 2014
Neat -- it works pretty well.
Some comments:
___________________________________________________________________________

(A) Something is unstable; can get the tree to crash if I move items
    around then open a folder. e.g. move 111 below 222 then click
    'Ascending' folder to open it. I'm zonked from Labor Day or I'd investigate.

(B) In draw(), suggest moving the call to _root->find_clicked(_prefs,1);
    inside the test for _prefs.selectmode() == FL_TREE_SELECT_SINGLE_DRAGGABLE
    to avoid the extra tree walk that find_clicked() implies on /all/ redraws,
    even for apps that don't use dragging.

    Can think of two approaches to solve; (1) maintain ABI by splitting the one
    large if() into two separate if()s, e.g.
----
  // Draw dragging line
  if (_prefs.selectmode() == FL_TREE_SELECT_SINGLE_DRAGGABLE) {
    Fl_Tree_Item *item = _root->find_clicked(_prefs, 1); // item we're on, vertically
    if (Fl::pushed() == this && item && item != _item_focus) {
      ..adjust indent of this code here..
----

    ..or (2) avoid the find lookup in draw() by doing it only in handle() and
    save it in a new data member (breaks ABI, but see (C)).

(C) IMHO when adding a new feature, if it makes better code by breaking ABI
    then do it and warn in the docs the feature can only be used by setting
    FLTK_ABI_VERSION (in this case) to 10303 or higher.
___________________________________________________________________________

I'm kinda zonked from Labor Day, or I'd investigate (A)
It's probably something wrong with the way insert() is being used here, not sure.

If it would help, perhaps we should add an item->move_above(someitem)
which can move "item" above "someitem", and maybe a move_below() as well.
 
 
#10 greg.ercolano
18:43 Sep 03, 2014
cand: please see STR# 3127 which includes three new methods
that allow one to move() items around in the tree.

Have a look and see if that helps.

I believe the crash issues I mentioned are related to the moved
items not being reparented properly (e.g. dangling pointers for
prev/next siblings and parent() for the item and surrounding items.)

The new move() methods handle all this, and allow you to move items
above, below, into, and to specific child index positions. (You may
only need the latter for what you're doing)
 
 
#11 cand
02:53 Sep 04, 2014
Posted v2. It uses the move_* methods and so solves (A), can't crash it here. (B) is solved as well by changing the if as suggested.

There is one bug in the move_ functions, but the code this side should be good.

I made it ABI-safe on purpose, as I'd like to have this functionality in shared distro builds, which cannot change the ABI defines without recompiling all dependent apps.
 
 
#12 cand
05:05 Sep 05, 2014
With the fixed move_*(), everything works great. Committed a slightly modified v2 patch (the other drawing path also needed the if-amendment).  
 
#13 AlbrechtS
16:56 Sep 05, 2014
Please take care not to add trailing commas to enums before the closing curly bracket. This is from hunk #2 (FL/Fl_Tree_Prefs.H):

-  FL_TREE_SELECT_MULTI=2 ///< Multiple items can be selected by clicking
+  FL_TREE_SELECT_MULTI=2, ///< Multiple items can be selected by clicking
                                   ///< with SHIFT, CTRL or mouse drags.
+  FL_TREE_SELECT_SINGLE_DRAGGABLE=3, ///< Single items may be selected, and they may be
+                                     ///< reordered by mouse drag.
 };

Such a comma doesn't matter for many compilers, but there are pickier ones that issue at least a warning.
 
 
#14 cand
02:32 Sep 06, 2014
Fixed, thanks.  
 
#15 greg.ercolano
05:41 Sep 06, 2014
Suggestion -- instances of the code:

+      int tgt;
+      if (before) {
+        tgt = item->y();
+      } else {
+        tgt = item->y() + item->h();
+      }

..can perhaps better be reduced to just:

       int tgt = item->y() + (before ? 0 : item->h());
 
 
#16 greg.ercolano
13:18 Oct 27, 2014
Current state of this STR not a showstopper for 1.3.3 release.
These are mostly RFE's, and items addressed are stable.
 
 
#17 greg.ercolano
22:16 Jul 25, 2015
Remaining items:
    A) Show leaves + Show branches -> selectable independently
    B) Add 'FRONT/BACK' sort flags (FRONT: causes add() to insert(pos=0)
    C) Shaded entries (ie. ruled report). Include #items per ruler
    D) Multiple selection drag ignore (items aren't selectable)
    E) {Vertical|Widget} Gap (Fl_Tree has horizontal and top bottom)>
    F) Open on select: expand the node on select
 
 
#18 greg.ercolano
18:07 Jul 13, 2016
Just mentioning this item was committed by cand on 09/06/2014:

    I) (DONE r10280) Option flag to be able to drag+drop items
       (to move them)
 
 
#19 greg.ercolano
18:12 Jul 13, 2016
Comment #15 implemented as r11806  
 
#20 greg.ercolano
14:46 Dec 06, 2017
Adding new RFE: (G) "tooltips" for Fl_Tree_Item's

Remaining items:
    A) Show leaves + Show branches -> selectable independently
    B) Add 'FRONT/BACK' sort flags (FRONT: causes add() to insert(pos=0)
    C) Shaded entries (ie. ruled report). Include #items per ruler
    D) Multiple selection drag ignore (items aren't selectable)
    E) {Vertical|Widget} Gap (Fl_Tree has horizontal and top bottom)>
    F) Open on select: expand the node on select
    G) Tooltips for Fl_Tree_Item's
 
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2020 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.