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$..$/
| [reply] |
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
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.
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] |
Hi, graff gave you a nice example, but I would just like to throw in this "coffee-machine-chatter". Most Tk list widgets have their own underlying method ( often incompatible with other list types) of storing their list data, and it often is easiest, to keep your data in a separate data structure which you control. Then do all your sorting in that data structure. Then just rebuid the whole HList, instead of trying to splice into the HList. I ran into considerable difficulty with HList's internal list counter when I played with it. What I mean, is if you add 100 items, delete them, then add another 100, the second set's first internal counter number will be 100. The internal counter assignes 0-99 for the first 100, the 100-199 for the second 100, even if the first 100 were deleted. If you try to splice into the HList, you MAY run into trouble with this internal counter, so it is best to just rebuild the entire HList in my opinion, to avoid this trouble. Here is a sortable HList example which may be useful to you
BTW, GTk2's treeview, handles this stuff much better. This particular example allows you to drag'n'drop. You can drag the parent (which will drag all children) or you can drag individual children. This clearly demonstrates why Gtk2 is technically superior to Tk...... everything in Gtk2 is based on a common object, whereas Tk is a hodgpodge of incompatible widgets( although it is easier to use)
| [reply]
[d/l]
[select] |