in reply to Tk::Hlist item movement

Hi otto,

What do you have for code so far, and where within that code are you having problems?

Providing us with an example will go a long way in helping us to help you with your problem, especially when we can visualize how far you've gotten.  Otherwise we may be misassessing (positively or negatively) the degree to which you are proficient with Tk::Hlist, or even Tk, for that matter.

Otherwise, we can give you examples of working Hlists, but they may not adequately address your specific question or needs.

s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/

Replies are listed 'Best First'.
Re^2: Tk::Hlist item movement
by otto (Beadle) on May 23, 2007 at 02:27 UTC
    Hi Liverpole,

    I could post code, but sometimes it causes one to miss the forest because of the trees. Lets start with concepts, then I can post code if needed.

    Lets consider the algorithm needed given the methods of an hlist to move a node, with all its children, before another node. So lets say that I have 

    n1
n1.c1
n1.c2
n2
n2.c1
n2.c2

    [download]

    and I want to move n2 and all its children, before n1.

    It seems that all I can do is either 'add' and item to the hlist, or delete it, and all its children if there are any.

    It would then seem that I would need to delete n2 and hence all its children, then re-create n2, specifying its location in the hlist::add method, so that it is before n1. I could then re-create all its children, simply specifying the entrypath.

    This is hugely wasteful. Especially if the deleted node had many descendants.

    It seems that the hlist has good methods for the initial creation of a tree, but once created, re-distributing nodes seems painful.

    What am I missing?

    ..Otto

[reply]
[d/l]
      You're not missing anything. Tk does tend to be wasteful -- quick and dirty, favoring speed of development and prototyping over efficiency of resource consumption. In general, the trade-off still ends up being a good bargain.

      So the key to "solving" your problem is to make sure you have a simple, modularized method for adding items to the HList. The following is a somewhat simple-minded, first-stab approach that keeps the HList config data in a HoH (keyed by "entrypath" string and by attribute name), and passes that to the function that (re)configures the entrypaths in the HList widget. Highlight a line in the HList, push the button, and you'll see how it works.

      Read more... (3 kB)

      It's admittedly klugey -- it doesn't even check to see whether deleting and adding of entries can be skipped (it merrily deletes and re-adds the first portion of the tree if that's what you selected for "moving to the top") -- but the "waste" is not really noticeable to the user, and that's all that counts.

      (updated to fix grammar)

[reply]
[d/l]
        Thanks Graff,

        This is what I was thinking I would have to do... I was just hoping there was a better way. In your example, selecting n2.2 (ie 6th piece of data) and clicking MoveButton, moves the whole n2 up before n1. The desired result is to have it move n2.2 before n2.1, ie movement within a set of siblings, but not movement of a parent. That should be fixable. This may be resolvable by not seeking the highest parent, but the immediate parent, but then needs to understand the need to also place the selected item before the prior adjacent sibling, provided there is one.

        Bottom line that I have learned is that one must delete and re-create. Wishful thinking was there may be some method of movement within the widget.

        Thanks for the help

        Best regards

        ..Otto
[reply]

In Section Seekers of Perl Wisdom