Quick-and-Dirty Hoisting

Legacy MyInfo versions topics and topics that are no longer relevant
Locked
Fred
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Quick-and-Dirty Hoisting

Post by Fred »

Since people ask for hoisting, and since it's really difficult to implement, here's my 5 cent to it; would not be real hoisting, but would satisfy people awaiting hoisting, and would be easy to implement.

There could be a possibility to lay a subtree out to another tab, and then the ancestor item = father of that subtree could be automatically "deleted" with its subtree, being replaced by a placeholder; you would freely work on your outhoused subtree in its special tab; you could even do this with several subtrees at once.

Whenever you are done with such a subtree, it would not be saved into a new file / topic, but it would automatically be reintegrated into its parent tree, in place of the placeholder, and that parent tree would be saved normally, as if its subtree would never have left it.

Thus, I am speaking of a sort of an automated and a little bit enhanced cut-and-paste, after which the cut-and-paste in the opposite direction would be done automatically also; this way, no user mistakes in this, mistake-prone when done manually, process possible, and very easy implementation.

Just a detail: When you do the "Save All" command, and such a subtree is still outhoused - or several of them are, even from several parent topics / trees, those outhoused trees would be saved like any normal topic, but under a special, automatically attributed name, and the program would give a message, e.g., "2 outhoused subtopics saved for reintegration" - and if really something like a powerfailure happened after that, you could always take those specially named subtrees and paste them, in place of their placeholders, into their former locations.

The only, tiny, complication of my proposal would be indexing issues, but since it is very basic, indexing could easily be done with additional, temporary sub-indices.

For me, I would be completely satisfied with such a quick-and-dirty simili-hoisting even on a long-term basis; real hoisting might be "better" but there, the original subtree(s) in the parent tree stay(s) freely revisable, so there are many potentially complicated synch processes to be managed, whereas in my idea each subtree has, at any given time, only ONE location in which it is revised, so all the synching is avoided by placeholders for the affected root items instead.
Dr.J
Posts: 45
Joined: Fri Aug 24, 2007 3:11 am

Post by Dr.J »

I like the idea. We need hoisting!

An even quicker (but dirtier) approach would be to automatically "collapse all" in the tree view every time we switch to filter view. Then, when we double click on a topic it will return to that topic in a collapsed tree view - that give somewhat less visual clutter.

We need hoisting!

Dr.J
Fred
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Post by Fred »

Dr.J.: Absolutely.

I

So it would work like this, if I understand you well:

a) When this special click on an item = doc, instead of the normal behaviour: Do not show anymore any other item of that level or higher in this topic. (Technically, it would be a toggle and working on the currently selected item.)

b) This would technically be even less complicated than my proposal since this subtopic would not be temporarily exported, and the rest of the topic would not be accessible anymore as long as this "hoisting" works for that topic, and all would stay in the current tab.

c) The tab would be colored in a special way in order to remind you that this tab is "hoisted". Doing the same command would de-"hoist" that topic. Thus, as long as this "hoisting" is working, you cannot apply the command to an even lesser level, since the command works as a toggle.

Of course, there is a drawback with your proposal: Whenever working in such a way, i.e. within such a "hoisted" subtree, you could only work (= copy, paste, having reading access to, etc.) with these items here and with items in other topics, but there would be NO access to other subtrees of the SAME topic; in my proposal, technically less easy, there would always be access to all items in all loaded topics.

And this drawback is not a minor one since many times, you would like to split your work between the hoisted subtree and some other subtree in the SAME topic, more likely than to shuffle around between DIFFERENT topics, and then, in order to have access to those DIFFERENT subtrees of your actual topic, you would manually export them in other tabs, then afterwards forgetting to reintegrate those in your original tree, and so on...

But as stated, I agree that your proposal is even less complicated than mine, and so, if we can have yours, it would be much better than the actual situation. And then, there is always the possibility to paste, beforehand, that second (and also needed) subtree of your actual subject altogether as a sibling to the last item (of the highest level) of your subtree-to-be-"hoisted", and then shuffle around in this artificial "hoisted" tree; then, when you forget to paste it back to its natural position, afterwards, at least this second subtree would have stayed not in its original precise location, but in its original topic.

Of course, if you need to preserve 2 or 3 other subtrees within your "hoisted" subtree, clutter will not be tremendously reduced which had been the original idea behind hoisting though...

II

That's why I always prefer my idea, not because it's mine, but because I think it's not so much more complicated technically than yours and much more helpful for "power work". Technically, my idea would be something like this:

a) Replace current item by a placeholder item, and export it in its current state to a new topic.

b) When closing that new, otherwise quite normal, topic, instead of saving it normally, paste it instead of that placeholder item to its original location, and save it there.

between a and b) In the meantime, for security reasons, when "saving all", save it under an automatically given name.

between a and b) In the meantime, when "save x (= the original topic)", ask "Re-integrate outbound topic and close that tab or save it separately?"

And that special tab should not be shown as last tab, but directly on the right of your original tab, and even its automatically give name should be the name of the original topic plus some encoding at the end, thus even with the "Sort Tabs" command, it would stay right beside the original tab, which is important for a handy "Nex Tab" / "Prev Tab" toggling between the two, without manual fuss being necessary for it.

See my second posting in "Command Attribution to Custom Shortkeys" in this respect.
Dr.J
Posts: 45
Joined: Fri Aug 24, 2007 3:11 am

Post by Dr.J »

The more robust the better.

I really like MyInfo, but we really need hoisting.

Petko: How about a quick fix in the next patch with much more powerful hoisting fuctionality in the next major release?

Dr.J
Fred
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Post by Fred »

Dr. J.: You are perfectly right, this would be the way to go: Some basic functionality in that direction first, and doing it in some direction that would enable Milenix to rely upon this first development to enhance it further in the same direction. Something rather basic but RELIABLE, instead of too much fuss with high programming investment that perhaps would NOT really be acclaimed financially by too many people, and let's face, every effort HAS to pay off in order to be a win-win situation.

Up to then, let's not forget that basic (almost or really) stand-alone feature of MI: searching among all loaded files (and even among all files whatsoever): This way, it's a good idea to SPLIT UP subjects / trees into different subjects / trees anyway, not just for working on them.
Fred
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Post by Fred »

I

I had been a little bit led astray by other outliners' hoisting capabilities when precisely they adopt the philosophy "one tree for (mostly) all subjects, and as I stated elsewhere, the high interest of MI is precisely that MI does NOT ask you for stuffing all your things in one tree, but quite to the contrary, allows you for spreading your subjects very naturally into different topics = files, allowing you for finding "everything everywhere" in case you put something in the "wrong" place.

So, I had a second (or rather third) thought upon hoisting (which is in so great demand here), and indeed, there would be a very simple solution to it, here in MI, that could be put into work without any real difficulty.

II

Hoisting would be just hiding all other subtrees in your tree, whereas you would only display that subtree on which the cursor is on (="selected item") when you do that toggle "hoist / unhoist" - in order to indicate a tree is hoisted, the tree pane should have a chamois background instead of a white one then.

So there would be NO fussing with "loading some part of a topic into another tree", or "this part of the topic in this tab, another part of the same topic loaded in another tab, a third one in a third one, and how to synchronize all that, especially when you do some cutting here, some copying there, some inserting in a third place" -

It would be just a "display the whole topic" or "display just a given part of the topic", without any navigation in / into the part not being displayed (or any editing or inserting topics there).

III

Whenever you SEARCH for something, of course, you get into trouble, since there are two possibilities, no search results in the hidden part(s), or there ARE some search results there.

That's no REAL problem though, since as long as you do not CLICK onto those "hidden" search results in the "Search Results" pane, no technical problem whatsoever, and IF you do, well:

Every time a hidden item is going to be displayed in the tree, unhoist automatically.

IV

And thus, exactly the same with the Filter pane: Every time a filter is about to display a hidden item in the filter only, no problem whatsoever, just show it there, in the filter, even for editing purposes; and when you double-click there in order to display it in the tree view, unhoist automatically and show it at its normal position in the (then whole of the) tree.

V

And more than that, this technically very basic hoisting functionality would be PERFECT HOISTING from a GUI point of view since there would be all to make us happy, without any possible / important sub-functionality withheld. (As I said, it was Ultra Recall's shuffling various parts of the tree into other tabs that got me wrong, what they do is technically convoluted and completely unnecessary GUI-wise, it's just a display of their technical excellence, but without any real sense in it - well, they do NOT have searching over different trees at the same time, so their philosophy is "holding everything in the same tree" - and have a look to which problems they get in order to overcome that philosophy's idiosyncrasies...)

Have it simple AND PERFECT at the same time, like stated here. Or did I overlook something? I hope not. But as I said elsewhere, do not try to stuff a max of your things in ONE tree in MI, my 100,000 items are freely spread out over not quite a 100 topics, where there are rather big and quite tiny topics, and that's the force of MI indeed:

Allowing for spreading your things in a NATURAL way, and not within some technically-imposed framework, so CAPITALIZE ON that liberty!
Daly de Gagne
Posts: 52
Joined: Wed Feb 07, 2007 6:15 pm

Post by Daly de Gagne »

Hoisting is beneficial - it helps to focus the attention.

Daly
Fred
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Post by Fred »

You are perfectly right. But since this was a thing I overlooked in your post concerning Tags and Everything. I did not speak of UR not being able to put your things in many different trees, I just spoke of their philosophy to put almost all into one. Searching is only possible (yet) in one tree after another, so if you do some 3 or 4 big trees, no problem, but if you dissect your things into 4 dozen trees or so, even even much more, that inavailability of global searching (which in time will be remedied of, I am sure of that) isn't that handy of course -

and I am speaking of their one-tree philosophy also since they allow for opening 1 file different times in different tabs... but from then on, you really NEED their programming excellence, in order to not get total chaos on the technical level...

but it was, for me, total chaos on the GUI level, from that point on.

And so, hoisting is, in UR, an absolute necessity (and very well done indeed), whereas MI with its "put it into different trees, then do a global search here and there if really necessary" approach (as I understand and deeply like it) does simply not have as that much "necessity" for hoisting, but of COURSE we all want it anyway, and it's easy here, so it will be there I am sure!

But again, anytime I see too much need for hoisting, my second is, would it not have been preferable to split up my tree?! And a hint here: I do GROUP my topics, in 1- and 2-character names only (my system allowing for 3- and 4-digit names also of course, and then, when I want to work upon a specific thing, I load this; when I want to do some work upon a BUNCH of things, I load, with the mouse and Shift-Click (or more specifically sometimes, with Control-Click), the whole bunch belonging together, so sometimes I load a, b, c, another time a, b/ba/bb/bc, d, g, tg/ti, and so on and on.

First character is the group, second character is the title within that group, and you could easily do some aba, abc, abd and so on, and you could even do a.bc, a.ct and so on, one of the wonders of Windows from XP on, not only blanks in the file names allowed, but even more than one dot, not only for the extension.

You are NOT confined to my minimalistic system, you could perfectly do something like a.thisthing, b.thatthing, t.someotherthing, in full letters, but retaining just my idea to group subjects by this first character, and then loading all topics of one group in a row, by mouse shift-click, is done in just a second. (Yes, automatically loading "projects" on top of that would be even better!)

And this way, my "absolute need" for hoisting has diminished a lot... but that's no reason to not want, and not to have it, you are right! (It's all about smart use of even smarter programs, isn't it?)
Locked