Two Hints

[Fred]

Up to now, I just had a look upon 5.5, working on my 200 plus files in 5.0, since, as you might expect, I've got a lot of keyboard assignments I didn't want to lose / re-do manually, for a non-"final" version (= manually re-entering all this would cost me more than an hour, so I only would have been willing to do it for a version which I'd use for at least several months then). I got to two hints in trying some things out then.

I

In searching for transfer aids, I've seen, in the MI folder, the file "options.ini"; in this text file, the 6th line is

DefaultTopics=... (with entries)

This gave me the idea that by a (menu) macro (outside of MI), you could automatically pre-set different "projects", with different lists of MI files to be loaded on opening, including just a

DefaultTopics=a.mio

for just taking some notes and without loading, for 2 minutes or more, the whole bunch of 20 or more "current" files you're working on.

Your macro could then replace line 6 in the options.ini file with this macro-preset line, and then only, your macro would load MI.

This way, some sort of "project management system" could be added to MI even in the current absence of a table to choose from BEFORE the opening of the rest of MI (= with the chosen files) - this feature, developed by me elsewhere in this forum, should indeed be implemented in version 6, so my idea is better than nothing for the waiting time for version 6.

II

In order to transfer the shortkeys to 5.5, I tried to do this:

I renamed c:mi5 to c:\mi50 (whereas my files are in c:\mi; I'm speaking of the portable (prof.) version)

I installed MI 5.5 portable, into c:\mi5

In MI 5.0's subfolder "Configuration", there is a file "custom_shortcuts.dat"; there is no such file in the "Custom" subfolder of the "virgin" MI 5.5 portable installation (= my "c:\mi5" now).

Thus, I opened the new 5.5, did one new assignment to any command in the shortcuts-assigning table, and closed 5.5, in order for the "custom_shortcuts.dat" file to appear in my 5.5 installation.

Then only, I copied my old custom_shortcuts.dat file (= from 5.0) over the new one (=to 5.5 = c:mi5\Configuration).

Then, I opened my new MI5 (=5.5 now) again and had a look into the shortcuts-assigning table.

Since there are new commands assigned to their keys, their appear as such and have to be changed manually; they seem to have overwritten some of your custom assignments also. But here's the good news: Most or all of your custom-assigned shortkeys are indeed transferred into your new file, so for those you don't need to re-assign them manually; just browse the list in order to re-assign some old assignments overwritten by new default assignments, and for general comparing.

Of course, this is not perfect, but it's much better than to re-do the list from scratch on.

I'm a little bit surprised so many people around here did the transfer weeks ago, WITHOUT giving any notice on their ways to facilitate the process a little bit. Whenever you discover a hint, you sit on it, folks?

[Fred]

I've said it some days ago: There is a possibility to have the search options in a menu... but then, I had problems to recall it, so here is how to do it:

You can NOT (?) insert the search options into the search menu; at least I didn't get to it, but you can do TOOLS-OPTIONS-TOOLBARS-NEW, and to this new toolbar "Custom1" or whatever, you can then drag and drop the search options; normally, it will be a list, but you can widen this list by mouse so as to have a "menu" or in fact toolbar that displays all the options in text form.

As said before, this is not really beautiful, far from it, and I would much prefer some ONE character only, in the search menu, T for this topic, O for open topics, B for this branch only; and a second character there, D for Show Details, and nothing for "Dont show details" (perhaps between the right arrow and the down arrow in the search field). (For other things in the search field, i.e. unbound, and elongible by mouse, see elsewhere.)

[Fred]

Since I explained some weeks ago how to use the command "Insert Web Doc" to do links IN THE TREE EVEN to other MI files, and since there is an option, in the options, "open links with normal mouse click" (= instead of double click), could you please implement this "open links with normal mouse click" functionality of that option (=whenever that option is ON) to those clicks on the so-called "Web Doc" links in the tree, at least when the real link there is file:// and not http:// ?

In fact, up to now, a single click on such a link just gives a Windows dialog: "Would you like to OPEN or to SAVE that doc?", when, of course, I always want to OPEN the link!

For intercepting this Windows behavior, the "file://" part of the link could be used if really there is a sense (which I do not capture at this moment) for Windows to intervene here for REAL web resources; Windows intervening for MI files (= for which we happily can MIS-use this command, and I have hundreds of such links now, doing my projects with them, in the waiting for a better project functionality of MI) is without sense indeed, so please do some two three lines of code there in order to intercept, and thus allow me for loading other MI files with a SINGLE mouse click.

And then, "me" is "us" the moment fellow users will have tried out this spectacular MI feature: For me, it's one of MI's best, even when it had never be intended to work for objects other than web resources.

[Fred]

I

Since, in the tree, over "Documents" and "Tags" (or other attributes), there is a frame, and since the item title of the current item, over the text frame, is (happily) without a frame over it, and since those three pieces of text are regular and in the same font size, the item title over the text frame appears, optically, to be slightly lesser sized than the two others, not even the same size. Thus my hints some days / weeks ago to do the item title above the text frame 0.5 points BIGGER than the "Documents" and other inscriptions above the tree, and / or perhaps do it bold. Anyway, it should not appear LESS prominent than those, but that is the case today.

II

As said before, there is a normal "indentation" of the text in the text frame, in order for the first characters of each line not being directly on the left text frame border, and thus the same "basic indentation" should be allowed for the item title above the text frame.

EDIT: Technically, indent the field in the frame, no need to try to indent the text within the field. (Normally, I would not have given this precision, but since no indenting is there, perhaps indenting the text within the field did not give a precise result?)

EDIT: The main problem, besides the non-indenting, with the title above the text field, seems to be that my default text formatting is Arial 10 points, and the title being regular and lesser than 10 points, the title is not as big as my text. Since indeed, there is not too much room for the title, and according more room to the title would be less room for the text (and for the tree, also), I suppose that it would be best to offer an option, "Item title above text bold yes / no". Then, people who use tiny text size would be well-served with the current state of affairs, whereas people like me would option for "bold". Since this is NOT rtf or something (= as in an option "Item title above text formatted as in the tree"), this option could be implemented in the easiest possible way.

[Fred]

Since I said, I do my projects with that special "web resource link" in trees, I would like to clarify that I now have quit my "0.mio" file, with projects in the text pane: That tree got too big.

I now do this:

I have about 20 one-key files, a.mio, b.mio, etc. ; these files are loaded every time.

In these 20 "input / major / master" files, I do my inputs (from the web, and other).

In these master files, I have ALL my "detail files" = files with more-than-1-character titles, as links in the above-described way.

The tree entry then is, e.g.,

cim - MyInfo

It's automatically blue and underlined (= since it's a link), and I do it bold, manually.

The link underneath (= accessible by the command "Edit Hyperlink" is, in the above example,

file://c:\mi\cim.mio

Since the item line in the tree is different from the actual link, I can give "real, long names" to my files = items here in the "master files", whereas the "encoded name" of my files is shown in the tabs, as short as possible, and encoded in the way that it begins with the "group" of files in which it belongs the most, e.g. "oc" for cars and "oa" for assurances, both with the "o" for "organization".

Whenever I rename one of those "other" files, I do a search for that file name (e.g. "cim" for MI = comp / information management / MyInfo, but the same would apply to any other, "normal", not-encoded file names if you have such), in "all loaded files"; since those 1-digit files are loaded anytime, these searches will invariably find them, allowing me to to the renaming manually at least - of course this is far from perfect, but it's an intermediate solution.

Any input = new item, I try to insert it at the beginning of these 20 master topics (or, when in a hurry, into a special input box, "ac" for "Clippings", from which I then distribute them as soon as possible), or even, as SUB-items of those items there that are links to my "real" topics. In the above example, if I have a new item for MyInfo technical things / posts here, etc., I do it into "ac" when in a real hurry, at the beginning of "c" when in a hurry, and under "cim" (= within "c") when not in a hurry... but next time I load "cim" (= by clicking on the link "cim - MyInfo" in "c"), I copy all sub-items of "cim" (= in "c") into the beginning of the topic "cim", even if I don't have the time to insert those items for "cim" into their right places in the tree of topic "cim" - since those trees often have hundreds of entries, they always contain various levels of lack of organization... but as said before, next time I really must do serious work on some (real) topic, I first, to the degree of necessity of least, I do the work of shuffling around displaced items into their real places. As said before, this use of trees allows for perfect hierarchical organization where it's needed, AND for just putting things into (more or less precise) contexts, and this way, I don't feel the need for an indexing (= not tree-like) system (= where in fact, whenever you must do real work on things, those things are in no order, which deeply affects your working quality it seems to me), and at the same time, I avoid that disadvantage people say trees have when they pretend that the efforts to do the "necessary" shuffling around of items are too much for them.

Of course, those links to "real" topics can be multiple. Thus, I sometimes do "doubles" of such links. For example, that famous "car insurance". It's in fact, in my system, "oic", for "Organization - Insurances - Cars", under the tree heading "Insurances" of my topic "o", as described above. Also, it's under the heading "Cars", in the same master topic "o", but there, I formatted the link in italics; in fact, a file "oic" has its NATURAL placing under o and "i...", and its placing under "o" and then "c..." is an "additional" placing, what you'd call perhaps a "reference link".

The same with DIFFERENT master topics: A topic "aic" would have its "natural placing" under "i..." in the master file "a", but could also have an additional placing under "p..." (= any totally different heading with any meaning, let's say opening with "p") in the master topic "n", so that additional link for "aic" would be under "p..." in "n", in italics; other additional links for the same real topic would be possible in any master file.

And there you see that my system has a big disadvantage, as it is: Such additional links could only be possible in master topics, since it's only master topics that are always loaded: As soon as you try to do "links anywhere", e.g. a link for "cim" (see above) not only in "c" but also in "ci" = Comp - Info Management, every renaming of such real topics would necessitate a search for its title in "all topics" - this would cost me about 5 minutes each, so I refrain from it.

Hence the necessity of an automatically updated table in MI itself, in order to check for such links to other MI topics, and, most wanted, even to links to just ITEMS in other MI topics.

For the time being, I help myself with this: Whenever I MUST have such links in other files than master topics, I do a special link in the master topic, to that third topic in which there is such a link that risks to be orphaned soon, and I "name" (=entry line in the tree for that special link) it "also referenced in file xyz" = "see also in xyz" - it's awkward, but at least this way I can manually prevent such links from being orphaned, in case of renaming of the files in question.

It goes without saying that all this cannot be but an intermediate solution, and that indeed I finally would decide to adopt one big file, in UR, where all those problems (but within one big file only) would be avoided, by UR's perfect cloning system.

One more remark: I've got a macro to do projects where I don't want to (double-!) click on 10 files in a row

(whereas, of course, the much better solution would be to have a heading in the tree, and a special click / command to this heading would automatically open ALL SUB-items of this heading in a row; thus, the heading would be the project name, its sub-items would be the files that together constitute the project, and the special command on the heading would really OPEN the project!) :

I don't do them as links, technically, but I do an entry like "Project xyz" in one of the master topics. In the first line of the text pane of that entry = item, I then do a

"aim" "pcl" "xyp"

and so on, sometimes 20 different topics. Then my macro copies this line into the "open" line of the "open dialog (^o or whatever) - happily, neither the ".mio" parts of the filenames nor the paths are needed, and then, the project is loaded into memory, after the macro's done the necessary "Enter".

Here again my hint told long before: in the above example, it would not only be aim, pcl, xyp, but aim, pcl, xyp, and again aim, in order for the focus being set onto the FIRST "entry of the line".

My project macro shows again that an option "open files after last file" vs. "open files after current file" would be extremely helpful.

One last word, the above-mentioned encoding, with a "natural" place of a given file being shown in its name, and then, in case, additional locations where the file is also stored, can be applied to any three-dimensional file system of any kind.

And, again, for 6.0, I would really need something better in MI itself, projects cannot be managed endlessly with intermediate half-solutions. If my developments on these subjects don't encounter much interest here, as it seems to be, the question is, have almost any seriously-working information management users gone to UR, PB and other programs?

I very much hope not.

[Fred]

EDIT: My fault, the option "Automatically save web files" must be OFF, then the problem's gone. My other considerations stay valid, I think. This also affects my wish to be able to open such MI files, by SINGLE mouse clicking of the corresponding items in the tree: We must distinguish between mouse click (that should indeed be single, not double, like now), and just "selecting" the item by up and down arrow, thus, we must distinguish between "real select" and "just preselect", way of speaking. The only "preselection" should just display the item (as it indeed does now), whereas a (simple = not double, as it is now) mouse click should do the loading of the file.




I just discovered a "bug", and I hope you will not say, well, since your way of using the web links is not intended, we'll just leave it that way - again, be it a "web" link or not by intention, I couldn't do without it (and UR has such a thing also, even up to the item, not only with topics; of course, renaming problems there are as big as with MI).

Whenever I open a topic (= by ^o, be it one or be it in a row (see above)), and the last time that topic was open the current item in it was such a web link, Windows intervenes with showing that unwanted dialog: "Want you open the file or save it?" (I cite from memory.)

Since, as stated, I always open my master topics, and I've got plenty of such links in them - ideally, as deleloped, they consist only of such links, when they are duly freed from their inbox function -, the risk is rather high that one or several of my master topics will indeed be opened on such a link item, and of course, I do not want to read that Windows dialog then; could we get rid of such a behavior?

Again, it's not a "Fred's doing special things and gets worried about them" item here, but in fact, that possible "mis"-use of the web link for linking to other MI topics is one of the most important features in MI throughout, even when it's not yet possible to link to ITEMS in other MI topics for the time being, so some polishing of this tremendous function is important and urgent, for better passing of the waiting time for better solutions of the third-dimension problem in MI.

[Fred]

"Topic Color: Organge" ? Make it "Orange", please. While preferring more vivid colors (as said before), I am notwithstanding VERY pleased by your amending the tab color bug occurring when sorting tabs! This was unbearable; now it's gone: Thank you very much indeed! Same for toggle tree-text, same for "Go first/last item", and especially "Go to last viewed tab", the gone baby-blue line behind tabs, and many more. I do not want to make the impression that I only see what's NOT having been done yet!

[Fred]

And for a real bug now:

I select an item in the tree, do ^c or ^x (copy or cut, no macros concerned).

Then I select another item in the tree, and do a ^v (= paste, I verified in the key assignment table, and no macros involved).

Indeed, the item IS pasted there, BUT immediately afterwards, I get an error message:

" " is not a valid date and time

So I tried this several times, for several items at several places, and every time I got that error message, proposing to notify by web, and asking for comments to be sent with the notification.

Since cutting and pasting, = shuffling around items, is a feature we (?) use many times in a workday, it's an urgent issue, to be addressed as soon as possible, i.e. in the next release. That fellow users could not have encountered this bug, within weeks of using 5.5 - I'm without words (which rarely occurs)!

EDIT: The bug persists, independently if you paste the item into another place in the same tree or into another tree. To be frank, I also waited in doing my real work in 5.5 in order to avoid such blatant bugs, hoping for others to check them out. Since nothing came this way, I thought it was safe to do the transfer, finally, and here we are, fellow users' "All's ok." notwithstanding...

EDIT: It's even (much) worse, but being suspicious, this time I didn't do a cut, but just a copy, and voilà:

In fact, when you select several items at once, in order to cut / copy and paste, ONLY THE FIRST item will be pasted then, the following items will be lost, together with their (perhaps many) sub-items... and then, the inevitable error message (as described above) will appear.

Thus, let's face it: "Scholars" = university professors or whatever they may be, (pretend to) use 5.5 for some weeks now, without even seeing they are losing (valuable? haha in their case) data - perhaps the world is in its actual state because even the "elite" isn't but a bunch of idi... - and the taxpayer pays for it all.

Have me right: I understand there are important bugs in beta versions - but I DON'T understand highest-paid university professors who have it all right, lose data for weeks before their very eyes, without even knowing - such data seem to be worthless, so never mind.

Unfortunately, I cannot bear losing data, so I must go back to 5.0 and cannot comment further on the 5.5 beta in the meantime. Just fix it, please, send out a gamma, and I'll continue my analyzing of pre-5.5 then.

And wasps should perhaps do real work, for once, instead of being grossly, shamelessly over-paid for their worthless blah-blah.

[Fred]

I

"I have worked with the beta for the last month. In general, it works well."

This is incredible. After years of "all's ok" usage from various users, it has been I who (inadvertantly) "found a way" to lose your work, by just daring to "save" when focus is in the search field; now, after some 3 hours of trying out 5.5, I see I lose sub-items by copying / cutting then pasting items, and no reaction whatsover; year-long users as "Dr J." or "Wasp" and others (who didn't pretend I was speaking of matters I didn't know, so no use to identify / attack them, but of course, they, too, should have seen those bugs weeks before me) declare that all goes well, pretending having tried out, and so, I'm more and more feeling that perhaps I've got quite another MI than those people who have doctorates and university chairs but who cannot even see obvious things when you put their noses into them; even dogs show some reaction when you put their noses into sh** they made before... and don't tell me those fellows ain't responsible for the current state of affairs (whereas the dog sh** is their own) - such things, even in 5.5, are of course of the co-responsability of people who use a program since 1.0 or 2.0 = for years now, without never ever saying a mumbling word about 'em; for the newest bug of copying / cutting then pasting items, of course, I'm asking myself, since 5.5 doesn't seem to have addressed any issue with those commands, where in he** do this new bug come from? Ain't bugs understandable in beta versions but when in direct respect with newly rearranged components? Why bringing bugs into a program where there hasn't been done any new work that might duly have brought them in?

A question of self-sabotage, in a way? Be it as it might be: It's incredible that doctorate owners and university professors not just don't see those bugs on their own after weeks of trying out, but even DENY them when those bugs are to be seen by any one who does NOT have a weird mind. It's outright incredible, that lack of honesty. And let's face it, it's not 3 "for me it's ok" users that will make MI survive, it's the appeal (or lack of appeal) to serious users of information management software that will decide on this, so it might be said that this appearance-only "solidarity" of these dishonest MI users IS DOING HARM to MI whereas my critique - which comes late, after 5.0 only, i.e. after years and years of not having done the necessary homework - appears unfriendly (in the lack of real response and any sign of willigness to address the important issues) but in fact is perhaps more real help than the developers have had in their whole careers, since I dare to analyze the CRUCIAL issues, to the last detail, that will decide of MI's future - as anybody can see, I've been doing the homework of the developers here, for months, that they didn't do for years; following "loyal" customers' worthless advice will not get MI any new customer, neither now nor in the years to come.

II

I could easily say that "Dr. J" is ever and ever again repeating his "I need hoisting" preachure, without EVER giving just a HINT to WHY he needs it - as I have thoroughly explained here, for people who have all their stuff in one file, UR is the superior program, and for people who need to rearrange reference material in various contexts, MI is indeed not bad at all, and would even be a formidable program if some issues were addressed in a professional, not amateurish way - and then, hoisting is the least of our problems: If you follow common sense (or my hints), what would hoisting then be good for?

III

Hoisting doesn't offer any help with project management / information management; have a look at ZOOT or other contenders that ALL make available "projects", i.e. prefigured sets of files to be loaded together; MI does NOT, so my hints to this subject are more than just a personal opinion but the way for MI to get out of its amateurishness... together with a better way of making hyperlinks to files (and items) in the tree... and better cloning.

The developers would be VERY well advised to have a thorough look into UR's ability to hyperlink, in the tree of any file a, to any item (!) of any file b, AND to do it in a much less weird way than UR offers that feature.

For now, I've got about 250 MI files / "topics", and I've got some 400 or 500 hyperlinks to other files (only, since there isn't any way to address given items in those) in their trees, and each day, I add dozens of such hyperlinks; in fact, if I couldn't "mis-use" the net hyperlink feature to do this, I would have abandoned MI for some weeks now; since this "mis-using" is working well (even if it's ugly, since it imposes a special frame on you, the "hyperlink frame" or whatever you call it), I'm AT LAST and indeed able to do some project management with MI; whenever I delete, rename or even distribute a file into two or more (= so much for "hoisting", "doctor"...), I do a (painful) search over ALL files, title:TheFileInQuestion, in order to have a look at any such hyperlinks which, if I didn't do this, would be orphaned (or in the future falsely addressed by the link, in the case of separating the items of a file into several files).

If you do this, MI (but only by its "search over all files" feature) is really one of the best systems of information management you can buy at this time.

IV

But don't be fooled by this. The "search a term in the trees only and over all files" feature of MI is awkward when you have 300 files, but at least and indeed, it "replaces" an in-built MI feature where the program would do some synching / listing of such "in-system" hyperlinks (at least) in order for you having a chance to not lose order in your things just by working on them.

Just a byline here: Tomorrow or so, on bitsdujour, there's the file manager Xplorer2 50 p.c. off, some 15 dollars instead of 30 - appears to be an incredible bargain. Well, it offers "scrap panes" = virtual folders where you can indeed "put" files from other folders, by means of referencing in there to the original files; it's virtual cloning. So far so good. As stated above, such a system needs some monitoring of deleting, renaming and putting the physical file into another (physical) folder. Well, Xplorer2 indeed monitors deleting and renaming of files and readjusts the links in the virtual folders: bravo! But not good enough for me: Shuffling around files from one (sub-) directory to another will leave you with broken links in your virtual folders; it's, let's put it bluntly, the same phenomenon as with MI: As soon as the necessary encoding work risks to get complicated, the developer(s) option for "good enough quality", leaving (very) good ideas totally unfinished...

And get me right: The lack of monitoring of shifting a file to another physical directory or sub-directory is NOT of only academic interest, no: In fact, for TWENTY shifted files, I delete or rename one! The interest of such file directories lies in fact in your possibility to have MS Excel files, graphics files, MS Word files, pdf's, saved htm's, whatever, totally various files in some elaborate file system (instead of 5,000 files or more in just one directory which slows down the system), AND to GROUP them in multiple ways into "projects" or "contexts" or whatever, and this will lead you to various RE-grouping of those files... and then, you'll need that feature MISSING in Xplorer2: any dividing your 1,000 or more pdf files into more manageable file system groups will leave you with a mountain of broken links to those files in your various virtual folders.

V

You see, addressing those issues by better ways than by "search for x in the titles of all files" and then force the MI user to manually rename / readjust these (perhaps 300!!!) links (= an important legal source in 300 of our lawyer's cases...), is of the greatest importance for MI's appeal to serious users (when some falsely "loyal" MI users cannot be taken seriously anymore)...

But why then did I introduce my chapter IV by "But don't be fooled by this."? Well, UR allows for addressing ITEMS in those files, not only those files in whole. As said before, real project management would require exactly this "internal deep-linking", not only the superficial file referencing / grouping that's possible today; from the point MI (or any other program) will offer THIS feature (in a practical way, in UR it's implemented in the most concealed and awkward possible way: You cannot believe your eyes when you discover how it's realized there...) - that program will indeed be the winner that takes it all since it will be the FIRST program of its kind to offer REAL project management.

Again, why my "don't be fooled"? Because MI's ONLY lead in this respect is indeed its possibility to MANUALLY (at least) monitoring the integrity of those links after deleting, renaming, shifting, by the above-mentioned "search all files" feature... that UR has not yet... but which is on UR's list!

Thus, let's not dream: Probably, NO developer of such a program will ever give us the "necessary" automatic synching / monitoring function, so we'll have to do it manually anyway, as the best possible solution, short of allowing for broken links, and to he** with our comfort needs, let alone slick working style.

But as soon as UR will have global searching, this project management with multiple files will be possible there, as it is with MI even now... but with the difference that there, it's even more ugly (and perhaps forever) than in MI (now)... but with deep-links (impossible in MI now, and perhaps never available in MI anytime if Petko listens too eagerly to dumb voices in this forum / (false) "community")...

And now let's face it: It's ugly in MI, it's ugly in UR; as soon as I'll have the possibility to monitor my links in UR (= as soon as they will introduce global search), I'LL OPT FOR DEEP-LINKING: I need REAL project and information management, not just some simili-impersonation of it.

As said before, even the genius-work ConnectedText leaves you with broken links in these cases, so indeed, they all cook with water only, as the Germans say (= and not with wine or something better than water, they want to express)... but some of them even cook with dishwater, it seems...

VI

So I made my point clear:

A SERIOUS information manager must have, as a conditio sine qua non = as the strict minimum, global search, links to other files, and links to items in other files (both in the tree, not only in the text)... and UR will have this soon. (And a REALLY serious information manager should do the synching automatically / half-automatically (in the case of dividing a topic into several sub-topics that is).)

UR is eagerly catching up with MI in this respect (it's just the global search that they will do in some months), whereas MI is sitting on its tiny lead (= global search), without even addressing the possibility of deep links = links to ITEMS in other files... the comfort aspect being nil in both programs in this respect...

VII

And now to clones. As said before, UR's clones are the best I ever encountered (including mine, and they were way elaborate). But let's see, let's take our psychologist here, Daly. I don't know if he does analytic work, but let's assume he does. Any given item would be classified in a timeline, in a group of items spanning several weeks, several months, several years, depending on the fragmentary vs. cluster character of events in this span of the client's life. On top of this, all these items would be categorized into one or several "systematic" / real categories, depending on the recurrent themes in the patient's life experience.

I know this can be done with tags, but as said before, knowing that MI tagging features are NOT implemented the way I developed, but in a rather primitive way that will not really allow for thorough use of them, I took the decision to REFRAIN from tags (in fact, in 250 files, 10 or so contain tags now, before transferring them manually into better processing, without tags, perhaps in other programs, AS or UR, and from start on, I distributed tags freely throughout my files - one of my errors with respect to MI...), and anybody working seriously should indeed refrain from using tags in MI as long as they are done with as they currently are - again, it seems to be that old question of "good enough quality stops here" when multiplying usefulness of a feature unfortunately requests serious additional encoding work.

So it'll be done with clones. And here, let me say two things.

The GOOD THING is, in the above-mentioned psychoanalysis example, the magnificent UR cloning feature is not really necessary; even when cloning an item 5 times, into 5 different categories, it's only the item itself that is needed there, not any "later-added-on-sub-items" (that UR would process whereas MI would not), and as long as such isolated items are concerned, MI does clone them as UR does, and I discovered in my work that it's rare that I really would need the elaborate UR cloning feature; even I can mostly do with MI's "one-item-only cloning".

The BAD THING is, and I said it before, MI implemented cloning in such an incredibly incredible way that each cloning of one single item asks for real, serious, awkward work on behalf of the customer, it's sheer folly.

Again, look at UR's cloning command: You go to the item to be cloned, you do control-c. You go to the item after which you want the clone to be placed, you do control-v. That's it. That would enable Daly or any other psychotherapist to do cloning on-the-spot, in real time, when in interaction with the patient.

And now compare this real "flow" with trying to do clones in MI. Daly / our therapist would have to say, excuse me, Mr. x, for some 5 minutes, please, I need to put this issue into 5 categories, and since I do my work with a totally incredible program, I need to do manually 5 times something that will cost me about a minute...

Indeed, I've got a file with about a 1,000 items, with, at this time, from 2 to 4 tags each, and thus, I'll have to do about 3,000 clones of the items in order to get rid of the tags... and now imagine the tremendous work waiting for me if I insist to do it in (current) MI... it's outright ridiculous.

At this time, cloning in MI is so much work that anybody who really needs cloning, must use another program... when in fact, cloning, with very little encoding work, would be not perfect in MI, but perfectly usable:

a ) As in UR: control-c triggers copy AND a special function preparing the cloning; control-v in the same file finishes the cloning = inserts the clone under the then current (= other than the cloned) item, control-v in another file does a normal pasting

b ) Not as smooth for the user, but less work in encoding: control-c is always copying, control-v is always pasting; control-y (=any assignable shortkey different from control-c) prepares the cloning, control-z (= different from control-v) does nothing in any different file, but inserts a clone under the (then) current (other) item when in the same file

c ) As in b but only the first command would be different whilst control-v would paste the clone if there was the cloning command before (and if it's in the same file; if not, an error message would be handy), whereas it would do the normal pasting in any other case.

VIII

Sometimes - what do I say, in permanence these last times - I've got the impression to speak Chinese, or any other totally indecipherable language... and then, let's face it, such a display of non-understanding of 99 p.c. of what I'm saying is all the more scandalous when considering the good basics of MI: The ADDITIONAL effort to make it a really good program would NOT be tremendous, but the current state of affaires is bleak, and unnecessarily so. What a pity it would be if this persisted. There's serious work to do, but it's worth it, gosh!

[Petko]

Fred, the bug is related to the new Reminders dialog and is already fixed. The fix will be part of the next beta release, but if anybody wants to have it sooner, he can use the original beta link to download the fixed version.

[Fred]

Hi Petko,

I

That's good news. I've had frequent looks into my mail account in order to get perhaps a new download link, not knowing that you'd just replace the original beta at the original link with further ones. So I'll download again.

II

One more command, perhaps? (minor thing)

At this time, control-v pastes an item, in the tree, as a sibling of the current item, and indeed I think that's good and normal behavior. But as I explained in depth, I use a lot of "categorized in-boxes", an "a" file for all, then "b", "c", etc. for all those "ba", "bb", "cd", "ce", etc., etc., and in those in-boxes, links to those "ba", "bb", and so on are my headings, under which I put any new item, be it by distributing them from the "a" file, or from the "b" (etc.) file directly: Whenever I get a lot of new material of a certain kind, I don't put it into the "a" box, but in the relevant box, but not yet under the correct heading, but on top, and it's only afterwards I distribute the new items under those specific headings.

I insist on these descriptions since I'm certain that it's the best possible way to manage incoming information; neither putting all info into a big, big, big one-and-only inbox, and then distributing it, one by one into the right places in various specific files would be efficient work-flow, nor (and worse) putting new info directly into their right places (= which would request perhaps opening and navigating in 100 or more different files in one work session) would be a good idea; the way I've found seems thus the optimal way indeed, except for any better ideas from "fellow" users... not coming soon, I fear.

Thus, whenever I've put a first "new" item beneath such a heading yet, all further such items in this "category" will be siblings of that first sub-item of the category, and thus, control-v works fine.

But for every first such item under a heading, control-v makes it a sibling of that category that I have to indent then, in a second step; of course, I can do a macro which does a paste (= as sibling), then pauses a little bit, then indents the new item(s); as said on many other occasions, I literally HATE such lack of elegance; a smooth program should have a real command, different from "paste as sibling" (= default): "paste as sub-item".

People could assign any other shortkey to it, e.g. Alt-v, shift-control-v, or any other; I use an additional keyboard that takes key assignments / macros, and thus I have three keys there, in a row: "cut", "paste" (as sibling), "paste under" (= the above-mentioned macro); of course, in a second row, I have other commands, "outdent", "indent", in a third one and further ones, "collapse", "expand", in different flavors, etc., etc.

But then, whenever there is a way to do it "in-house", to make a command possible WITHIN MI, I have an urge to have it this way, and not being forced to make it as a macro: The result (for me) is the same, but my underlying feeling is not: I really crave for perfect software, and that means all things should possibly be done in the foremost straight way.

Thus, "paste as sibling" (control-v) and "paste as sub/child" would bring us a little bit nearer this target.

III

Re Zoot: They sell Zoot 5 for 99 dollars (and let you download a 45 days trial), but they also let you download 6 beta, as a 90 days trial. Since up to 5, items cannot be bigger than about 32 KB (!), and cannot contain rtf (but only plain text), I had never been interested in Zoot (my own software had the 32 KB limit also = which was the real reason I gave up, not having the guts to redo all my work in a real programming language, and even today, OpenScript (= Toolbook) seems to have that 32 KB limit for any item, and have a look a their price now: incredible...), but permitted rtf...).

Now, in Zoot 6, those limits are eliminated, and thus, Zoot's architecture becomes of interest. The problem is, it's totally convoluted, and tries to do a lot of work in your behalf (thus it reminds me of my behavior here...), and it's a THREE-PANE outliner!

(That's extremely rare nowadays; mine had been a multi-pane outliner but that made you choose the number of any more levels at any level: In fact, I had two different clicks provided: normal click opened the subs in the same pane, special click opened them in another pane... = sort of automatic hoisting if you want... and indeed, my main problem wasn't the hoisting, etc., but the management of all those multiple panes: to make them dockable, to make them accessible in the most easiest way even when there were 6 or more of them, with the mouse AND with the keyboard, at your discretion... so in 1998 it was rather elaborate and original software even when I wasn't able to exterminate its experimental character in the end...)

(The other extreme are those one-pane outliners, like Ecco (defunct) and NoteMap (from CaseSoft but not further developed by the legal firm LexisNexis, it seems, for years now, and it seems you can lose data with it, rather easily... - and not to be confused with NoteCase, in spite of this being the perfect name for it, given the legal context of its marketing...).)

I do NOT think that the concept of Zoot will ever really appeal to me, but technically, there seems a lot to be to learn from it.

First, it allows for doing deep links into items of other databases, from the tree (it seems; in fact, I first installed v. 5, then discovered 6 beta, installed, and GONE was v. 5, and the help file with it, whereas 6 beta does not have any help file automatically installed with it, and my searching for it has not been successful yet, even when people in the net speak of its very existence).

And second, it seems to excel (= you see I didn't understand its working yet, but it seems I won't get accustomed to it, whereas I've delved rather deep into PersonalBrain (that I'd never use for serious work, when I indeed use MI for that...)) in the constitution and managing of projects; it even allows (by option that is) for automatically (!) consigning any opened file into the currently opened project.

The thing that's awkward with those 3-pane outliners (I've seen some others in the past), in my opinion, is this:

They literally throw away the tree (= first pane) to the first level, the project level that is, where indeed a list of included files, etc. would be "sufficient"; the prominent place of the "real tree" = the main work zone in most people's workflow

(= except for those who prefer one-pane outliners: those will indeed try to do all the work in the text pane where they insist on having sort of a doubled outline, which is a mis-use of the text pane, but understandable since any legit one-pane outliner today (of my knowledge) is sub-optimal)

should indeed be reserved to the second level, the file / outline / "folders" level: It's HERE that you'll have hundreds or more of items, so it's HERE you really need to have a big frame, from top to bottom of your screen, in order to have some insight in your many, many items there, without eternal scrolling.

And now, have a look at those 3-pane outliners, like Zoot: Where I need the real tree, there's a tree, but confined to some second-place, squeezed pane, making it a pain to do real work, whilst your first-level list takes the height of the screen when in fact it would be largely sufficient to have some secondary pane for it, like the search results, favorites, history or any other - of course it should be re-sizeable by the user, in height and in width, but it should not take the place of the main tree where the real thinking work is done:

What elements from various (often bis-sized) sources are to be included in your project / case / whatever piece of work you're working on, and in what order?! THIS would be a program that works as you think, and not some PB that only pretends to work as you think.

And critics, don't tell me I'm wrong, that I'm just describing rehashed elements, when YOU'd work with ORIGINAL ones: NO element whatsoever in your thinking is "original" in this respect, EVERY such element is fired by any cluster of EXISTING elements, INTO your "project", into your thought, and thus, the real work is done indeed by the interaction of your target (= your project, your thought), and your material (=long lists, long clusters, might you be aware of them or not), and thus, your extensive clusters of basic materials must be given enough room to "breathe", to "flourish", i.e. a spacious frame in order to have a change TO GET OUT of their original frame that holds them back, and to DOCK - at the right place - onto your project / thought / case.

After several years of serious work, you'll have A LOT of such brute elements, and the difficulty is to FREE them from their various contexts, i.e. to get the idea that they might be RE-USEABLE in your project / thought. Thus, you need a spacious frame to BROWSE them, be that space in your head, in thinking, or be it on your screen, when constructing a legal case or any scientific work, business development or whatever.

In NO case, any such brute element will be truly "original", your intellectual challenge (and perhaps, achievement) will be the "original" Re-Use and Re-Clustering of those atomic elements.

Besides, language is nothing other than what I've described here, words in themselves are nothing but raw material, the intellectual performance consisting in re-clustering them from their various origins into new targets... so you see that the bright accessibility of those various word lists (in your head) permits much better choice of much better adjusted elements = words to a given context...

and this will show you, finally, that I'm right in saying, those lists of elements contained by your software must be easily accessible and be arranged in multiple, smart ways... since it's also a question of SPEED IN FINDING "the right word", the right element for your thought, for your project... since people just cannot browse for hours, even far-away lists of not-connected / not-connectable / not-useable things in order to get to their results: the browsing must be doable in a reasonable time (and efforts) frame... without having the results within those frames, people will not get a valuable result, be it "good enough quality" (according to them), or be it totally inadequate.

This is the reason you must put a lot of work into your raw materials:

in MI or any other information management program...

and in your own head. That's why in ancient times (let's say up to the seventies of the last century) smart parents saw to it that their children read a lot of good books, e.g.

If you don't respect and nurture your raw materials, your output will be negligeable.

And now have another look onto existing 3-pane outliners; there's an inherent architectural fault in them; what I'm trying here is helping to construct something better than those.

Information management is a secondary problem; output enhancement is the real objective; approaching information management to the real way of thinking might indeed enhance your thinking, and by that, propulse your output into higher spheres.

PB got into a dead end, but they make a lot of money in that niche; there's a great empty space to be taken by anybody offering better thinking (-aid) solutions than them.

[Fred]

III continued = IV

When I'm speaking of air, breathing, flourishing, I mean that your raw elements have to be accessible in the easiest way possible in order for your being able to pick them up and use them, like papers on a very big working table, like the raw elements in an INTELLIGENT mind who's able to have MORE than just 2 or 3, but 5 or perhaps 6, 7 different elements available to his internal processing machine (= your individual IQ not only has that speed characteristic, but much more, it's a "concurrent availability problem", a spacial problem, a "geographical representational" one, and even perhaps it's this dimension that then triggers speed in those geniuses' thinking, when others unsuccessfully try to go forth and back, forth and back, to ever the same different items they simply CANNOT HOLD TOGETHER at one time, as the high IQ people can, thus pathetically slowing down their thinking, and NOT even arriving at integrating those missing elements, those missing links, in the end, in spite of their (time-consuming) efforts. (Remember that NOBODY has succeeded yet in analyzing how thinking works, but be assured I've been in the vicinity of catching at least a (badly-lit) glimpse on it as any of your oh so full of themselves state-paid scientifics.)

It's for facilitating these processes that squeezing your material into tiny lists, or even worse, into highly-indented/-leveled-down lists, is as counterproductive as it gets: Your elements should be arranged in views as flat as possible! (And now compare again with PersonalBrain: har, har har! They pretend to make accessible your far-away elements, when in fact they even hide those "normally" rather near your current proceedings.) (In 1996 ff., I did my programming / software designing by learning by doing, with NO theoretical insight, but now, I'm eager to deliver the explanations for what I've done then, considering that "instinctively", I did right; see below.)

This being said, even on the project / target level, too much squeezing seems very counter-productive to me, but again, most "space" - in your head and on your screen - must be given to your materials. Thus, the upfront levels must indeed be in some "expandable" list, and why not, before your (main) text, having, let's say, a project list in the left top corner of your screen, and your main tree = raw materials tree beneath it, 3/4 of height, then the great text frame to their right, large and in height from top to bottom, then, at the right side of your screen, any other lists, be them 1, 2, 3, 4, in one row or in two rows... and those, as for the first two ones, before the text frame: MAKE THEM FREELY REARRANGEABLE, and not only by mouse resizising, but especially, by toggles / special commands for pre-figured set-ups: Give us arrays in which MI will store several different screen layouts, and give us immediate access to those layouts by just one key pressing!

E.g., those two first frames, one layout should be list 1 (= project tree) above list 2 (= materials tree), another layout should be, list 1 or list 2 has the whole height, but you toggle between them, and another one should be, they have both the whole height and are one beside the other, taking the necessary screen space (= additional width) from the text pane, and again, another toggle should restore the full text, and another system variable should "know" which list 1/2 layout to restore, the first, second or third variety of them. I.e., all those rearragements should be freely resizable and rearrangeable by mouse, etc., and then should be storeable, AND special commands should trigger toggles between ANY of those layouts, not just one toggle between just two prefigured layouts.

BTW, the "0 level", i.e. the projects list (= not list 1 which is the target list, the list of your currently-to-be-composed project = the list / tree of the elements of this project), the list / tree of many different projects (= from which you choose your lists 1 and 2), should be in some "right screen border" frame, or sometimes, even replace list 1, depending on your current work.

In this given work frame, those developments must be made step by step, on a design level, but on a technical level, there must be (sufficiently sized) arrays in which to write (and from which to read) positions, sizes, states, contents and even behaviors of frames / panes, and then, standard commands could be re-used again and again in many similar such "rearrangement" commands, without a developer having to fix the eventual functionality of his command bunch up front.

In any case, mosts could / should be displayed with rather squeezed widths, not too space-consoming thus in the end, most of the time; BTW, your brain works in the same way, just FLASHING little pieces of raw elements to you, no half-developments yet like they usually appear by displaying long item titles in length; thus, any such lists above text frames on your normal (= landscape) pc screen in information management software (be it in Zoot or in others) is not only bad design, it's much worse than that: it's throwing obstacles in your way of thinking

(and twofold: height is squeezed = not ENOUGH elements are visible concurrently, and width's ways too large = too MANY in-depth informations way too early thrown into your thinking process (remember: you cannot hold too many concurrent elements there, so their combination at any given moment is more crucial than anything: any unwanted info there takes the place of another one badly needed there!) when just the trigger (= contained in the very first words of your elements if you title them in a smart way) is to be allowed there),

and thus, whenever I see such a design, I'm put off, not hoping for any way to overcome such "limitations", such external crushing of my possible thinking efforts.

III continued = V

To make some other hints, my German "Manuscript" software down in 1998 / 1999 - or did I start it "commercially" in 1997? - used some other original ideas, original at least in the way that neither in the 12 years since, nor, and more importantly, in any year of my lifetime before, I EVER encountered them, be them applied anywhere, be them discussed / mentioned anywhere, and indeed they're worth thinking about:

a ) A lesser one (and I'm not totally sure I did not see it afterwards, but could not remember at least): Colour the background of your (list) frame in one of several standard colors, according to its current state, be it its content (category/level/etc) or its "willingness" to respond to any / special given commands (= what this or that click / key pressing will do to any entry / item in that list); if you employ "mixed" colors (= in an intelligent way, that is), you can even display TWO such "characteristics" concurrently: red for one characteristic, yellow for another one, and orange to indicate both of these are currently "activated"; green and yellow and grass-green for the combination; red, blue, or cyan for a combination of these, and other combination colors, like turquoise, poison green, even light brown... different shades of baby blue, with components of green, red, yellow..., rose... - and any time, a special command, included in the right clicks (see b here), would give a little tableau which indicates the state of affairs in case you're new to your new splendid information system... And I even experimented (but not did publish then with a combination with b here)...

b ) Even better, and I'm positive of not having seen it but in my own software then: Every line in such a list, and independently of the given width of the frame, can easily be devided in 3 click zones, for any click, simple, double, right, middle, with shift, alt, control...: First 30 p.c., last 20 p.c., remaining 50 p.c. in the midle, between 30/100 and 80/100. Of course, you can do 75 p.c., you can do 20 or 25 p.c., or whatever, but I experimented a lot with it, and most important is to have a large click zone for "normal" clicks (= the above-mentioned simple, double, shift, alt..., but "normal" in a way other programs would offer them indistinguishly for the whole line = entry), so that you can do those clicks at any time without having to bother for "rightly placing your mouse first before clicking", and thus, a zone of about 50 p.c. of the whole line length in the middle seems perfect.

Second-rate clicks (again with all the other possibilities mentioned here) would be in the (comfortable) beginning zone of each line, and thus, for some people, 20 p.c. of the line would be sufficient, or 22, or 25, or 30 p.c., but again, "second rate" is not "third rate", so it must be easily accessible and thus not only the very first 10 p.c. of each line.

Very special clicks can then be done (again with all those combinations mentioned above) in the last 20, 15, or even 12 p.c. of the line, and thus, you understand now that I didn't have just one right-click menu for my panes, I had THREE of them, and you also understand I had no real problem in not getting lost in my various panes: A normal click in zone 1 of any given list showed that element's subs (= sub-elements) in the same pane, whereas the same normal click in zone 2 showed its subs in the next pane (the pane were numbered), thereby replacing the actual content there, and the same normal click in zone 3 showed the subs in a NEW (additional) pane; in each case, some "headers" in the panes showed the parents, and so on, even, in case, their multiple parents, and of course, clicks on those headers showed those parent's lists in the same way as explained for the lists of "siblings"

- thus, if you think that I didn't have real "trees" in any of those lists, you're right, since those were cut into multiple (sub-) panes of each other (= by this design giving access to any relevant raw elements, be them as far away as they might be in some cases)... but then, I had project panes, in order to print / export, for "building up" "flat" projects, whereas my internal data management was totally three-dimensional, and at any given time, special routines (working when doing shifting / cloning commands) assured not only referential integrity (when renaming, deleting, etc.), but also non-recursiveness, so that when "building up" my projects for exporting / printing (= flattening the whole thing for two-dimensional representation), I did not encounter any recursive problems since they had never had a chance to build up in the first place.

I was able to do this by stricly distinguishing between "natural parents" = only ONE for each item, and "adoptive parents" = as many as were handy for each item.

Of course, my distribution of items into the panes being mainly just a matter of normal clicks in 3 different zones

(= on top of this, I had indeed special commands like "put this item and its subs into pane number x", thus not only displaying to further levels beneath was possible, but also jumping up some "levels", from pane 5 to pane 2, and so on: perfect control, AND a floating mind at the same time, if you want...),

I had all the other possible mouse clicks (right, middle, with shift, control, alt, shift-control, etc., etc.) left for doing special commands, like shifting, cloning, renaming, and so on, and all this in the easiest ways possible, since threefold, also for them, in the three zones.

You can of course do four zones, but except for very special needs, my 3-zone system appeared to be perfect since at NO time with it, I had to pay attention where I clicked with the mouse: zone 2, the main zone, was large enough for clicking there without care (= by clicking somewhere in the middle or right to the middle), zone 1 was large enough in order to click there carelessly, not having to bother with a "but do it right at the beginning in order for it to function right", and zone 3 was special enough in order to never be clicked inadvertantly when in fact you wanted to click in the main zone, being at the same time large enough in order to get your click there fast in any case that was your intention.

There was NO encoding difficulty for all this since I had endless tables "to handle click(x,y,z)" identifying the targets of my clicks (and, in the same way, "to handle keydown", then identifying the focus, and then only deciding on the command triggered by the (otherwise identical key pressing), and in that way, I identified the zone, by automatically maintaining corresponding system variable arrays in which the corresponding commands "read" the values for identifying the corresponding zone for each mouse click in any given frame / pane / other element, of any height / width / position; this was dire encoding work BUT IT WORKED, and in a standardized way, so that I was able to position the panes at any place, and to resize them, without those command system losing its precision; it's just a question of maintaining various system variables (and grouping them by arrays), ande then of writing and reading those numbers in various ways, referential integrity having to be maintained in it at all cost. I was able to do it, so professional developers should be able to do it.

This being said, you can easily imagine my degree of unhappiness with the most basic programming efforts encountered in any current information manager, my own having been splendidly superior in its design 12 years ago (and this with 4 light versions sold...), and knowing that programming efforts to do the same or something even better would NOT be that far out of reach for professional programmers...

(I had import / export from and to MS Word 97 only, I had a lot of contact / delegation management (but without it being group-work-ready), I had (dedicated) data fields (and many routines working with them) but not in a "column" form, I had no net connection / import whatsoever - have a look into Zoot's mail functions, I don't understand them, lacking a manual, but they seem to be splendid -, and I developed it from scratch, not knowing any other outliner; in fact, I even did not have any internet access then (and I had no idea how to implement such (further on mandatory, I very well saw this) web import functions, so I let it go... but at least, I had a chance to develop original things, instead of being guided by half-way solutions of competitors, and I took that chance and have preserved all OpenScript routines, so if anybody wants to use my ideas referred to here, I would not consider it stealing, you only would have the enemy of your life when you pretended they were yours, so everybody refrain from trying to patent my ideas in your name, but apply them freely, it would be an honour for me to see them work...)

III continued = VI

I'm not a masochist wishing to endlessly throwing perls before swine in any possible direction, but considering what I did from my own, and what crowds of professionals do less today, almost 15 years from my beginnings, in core functions, I deeply wish that somebody out there might at least see to that my ideas survive, even when I buried my hopes for making money by them long ago; it's become a question of personal honor (hence my touchiness when very-well-paid people but who ain't on my thinking level in these very special matters, when I'm not on theirs in their special fields, tell me I don't know what I'm speaking about) - and also a question of lessening the incredible loss of general benefit to thinking enhancement that occured when I "buried" my Manuscript files, not seeing my ideas resurrected by others even 15 years ago (= never?!), so I need to do a little pushing in order to avoid total loss, be it here or be it anywhere.

It's a question of applying my share to make the world a better place if you want, so you easily understand my hating of people saying (= the participle applying to the gerund, not to the noun if they don't persist) that I had nothing to give.

So let's make'em take it

P.S. "Manuscript" hadn't been a false name, it had even as many literary functions implemented (= by toggle, a "literary mode") than Scrivener has today. There's so much irony in this world: The founder of ToolBook (and then undertaker of it as a general programming language) was and is the (more or less) ousted (?) co-founder of MS, a certain Mr. Allen (no, not the GTD type)... it was the limitations and quirks of the programming language (that I can prove, TB 6.1 was NOT stable, so no chance for my program being programmed with it), not of my program, that made me abandon them (= my program as well as TB)... and as a software house, given its means, MS is the utmost undertaker of what (ubiquitous indeed) software could have done for mankind: With and due to MS, we all have lost 30 years of another level of doing "office" work (= from lowest- to highest-brow, that is)

If any software house (and that would even be MS in case of - isn't it that they have 30 lost years to catch up with what the COULD have done?) employs me for min. 5,000 euros a month (= before taxes and all, and yes, I know what UML 2 is and all that now), I'll bring my files and my loyality with me if you let me do my work for the benefit of EARTH; if not, Petko will get more of my findings if he's willing to implement some of them, and to he** with the MS's of this world.

And Happy New Year to everyone in the meantime, but I really should actively search for somebody or some (commercial) body with money that has the manpower to implement my flow of ideas if you, dear Petko, cannot assure faster sailing ahead than before my self-invited climbing on your vessel.

Perfect software is possible, Mr. Gates, even if you never had some of them made. And REAL enhancement of MI should be possible short-time, Petko, if you (let) develop it my way, for some time, promised, but you musn't consider my ideas inferior then.

Or as little Hemingway said to another Allen a lifetime ago, in one of the splendid films, Manhattan: You've got to learn to trust SOME people at least, sometime - or something like that, as usual, I cite from memory.

Gosh, Petko, I'm trying to offer you my design work for 6 months now, FOR FREE, go and do just the encoding work, you are two people, and I'll deliver you splendid design that'll make you rich in some years... (since I won't have any copyright in it)... but I'm just asking to get me a chance to get me that some CREDIT / CREDENTIALS in the eyes of IT wasps that have the power to give me that 10,000 euro-a-month-paid job in the industry I deserve.

And in 151 posts here, I've LEARNED to speak / think English. (All kinook's unimitable developer had to say a year ago, instead of considering any new idea: "English doesn't seem to be your native language?!")

Gosh, what a waste... which has to stop. Thus, I'm willing to be everyone's whore if our acted-out playings-around will be mine: YOUR satisfaction guaranteed, under that condition.

Or is the World a psychiatric ward where my ideas will die me, one day? Yesterday, on bitsdujour, Goalscape for a second time, a pretty fancy toy, but an even more short dead end than PB (Xplorer2 being there tomorrow, in case partial reference file integrity will do for you, see above) - but have a look upon their site: They're rich people in Hambourg, Germany, and world-wide, but their encoding is done in East Europe: very well done, folks!

So, Petko, if he has the manpower he pretends to have, he's not one, but two, and if I had two developers in East Europe for my necessary encoding work, even from scratch, I could produce incredible software in almost no time.

If you, Petko, leave further designing to me, you'll be three, one for free, one on Eastern Europe wages, and yourself... who'll pocket soon all financial benefits. I think that's a chance to take for some time. After all, I'M taking the corresponding chance to work for free - even if some people think that by offering my work for free, it loses all possible inherent worth.

And oh, yes, addendum ad cuspem quartum:

Any try to do implement wiki functions in MI or any other information manager is doomed: technically it's rather easy, especially when you already have implemented (as in MI) deep links to paragraphs, but as said above, THINKING requires FLASHES, BITS of other things and reordering them anew, as a first step before any further development in depth can be done (in your mind, that is, and that will consist of other flashes, and other flashes again), not losing your mind in further and further readings totally distracting you from your possible targets. Besides, the very poor global benefits of the net are due to this overall "wiki" character of its architecture, when in fact AI is criminally neglected (because of its lack of its immediate revenue stream.

I'm not really in the mood of Prof-Kuehn-Bashing again, but then, I said it before, and his blog ("takingnotesnow") proves it to any incredulous soul: His own thinkings on information management are WAY below most thinkings he cites there, whilst he's certainly not less intelligent than most of his sources (if he was, he wouldn't be a / the leading Kant expert worldwide) - so why? Well, he prefers a wiki software (CT) over any other, and I pretend that this affects his intellectual abilities (from which there persist enough anyway, be assured of that) -

In fact, I've tried to explain, in this post, this: Your perfect workspace will be a sort of a THESAURUS in which you incessantly browse, and from which you incessantly scoop ("puiser" in French) - whereas most other people seem to believe that the wiki, not the thesaurus model, was THE reflection of real thinking. Well, since it's not, I'm right in my software architectural considerations, and those in the other camp are erroneous, and here again, it's not a question of taste, it's a question of wrong and right, and I think I'm right, so they must be wrong, and this explains for me why they don't take but so few benefit from even elaborate working plans:

Sophisticating errors doesn't make them true; lesser means in a right direction will give far better results.

I need a chance to prove my theories in a working model applied to real-life affairs, which also implies connectivity, integration, group work and so on.

MI would be a base from which upon I would be willing to develop if you let me do it with you, and to he** with its looks due to all your Delphi components in it.

But then, wasn't it Borland that had Delphi once, in its prime time, and hadn't it been Borland that had bought Ashton-Tate, which for me is the greatest name in software history? (May it be defunct or not; in a way, my "work" is a dirge to / for Framework, and is it really important, kinook, that I don't know, English being a foreign language for me, if it's a dirge "to" or a dirge "for"? May it not be a 1,000 times more important that I make a dirge to / for Framework, in my development efforts, deeply bowing to their initial genius, whereas for your myriads of "normal people", Framework is dead for good, and its genius with it?)

Thus, I'm not really fond of Delphi (just compare with UR's far prettier MS components), but splendid software can be programmed with almost any language, and even I would have come near to prove it then with (even much more ugly (then) TB, given I'd have had some help from some programmers friends, which I didn't have.

Today, it's the other way round, real programmers would have a helping hand there avoiding them their design errors (when my programmer's capabilities weren't sufficient) - might they take that hand.

Or indeed, if nobody wants my real help, neither for free nor, in the case of commercial venues, for a modest wage, one day I'll have to sell my house, and have to hire some third-world programmers in order to encode, just for the pleasure to see what Framework would have been in 2015 had I been involved in its developing from the point Borland SOLD it to people who just preserved it in its state of that time if I may say so.

In those years, I spent my spare time, ALL my spare time, on developing my information manager, and thus I cannot really empathize with those people who say that software development must pay, and on short-term on top of that, for the hours spent on it: Isn't there some ART in software development also, where the (ok, never final but big-step intermediary) "end" result(s) are a mean in themselves?

Especially if there's real chance to propulse science? That cannot be done with TB 6.1 and without any marketing means, resulting in a gross of less than 200 euros for about 2 man years (or make it 1 man year and a half), but today's marketing possibilities are quite different, Delphi or ANY other programming language seems to fit better than TB 6.1, and I made some analytical progress in the meantime with respect to what I want in information technology, and WHY I want it that way and not any other, so encoding is my problem, and since there are a lot of such programs on the market out there, the real problem would be to convince one of those developers out there that my "design" know-how is better than his, in order for him to eagerly follow my path instead of treating me like a beggar who gets some little things here, some tiny bits there: for at THAT pace, I'll DIE before having gotten to any approach only of perfect software that I'm indeed able to design.

It's simple: If MI 6 goes every which way but loose in its development, that's Petko's perfect right, but it will not take it sufficiently near a real solution of the global problem, and I don't have the patience to wait forever; even competitors' (partial) successes (due to real thinking, due to "stealing" (here e.g.) or due to sheer accident) will make that too minor progressing in the right directing will in fact be DRIFTING AWAY from our common target if I may say so: producing / having / being able to use the utmost information manager.

My proposition: Follow me for some time at least in MY direction, do what I want MI to have, in the order I think it will be feasible, do "double work" for some time: You have not only my work of honor, but you've already seen by yourself that I'm not trying to manipulate anybody into giving him (= to me) what I want, but that my target is real enhancement of MI, profiting to everyone... but let's stop my having to beg for elaborate things and then "get" peanuts: I cannot bear this for much longer, and MI will not really profit by such a method consisting of, at best, integrating some minor elements of isolated ideas of mine here and there:

It's a whole system I have to "sell", a real vision. Give me a chance to offer it to you for free.

Thus, allow me a blunt question: Petko, since you're speaking of your encoder, ain't you a programmer yourself? Are you a business man having developed his ideas by his encoder, or are you technically able to program with him? Again, if you are two programmers, not just one, and if you're willing to follow some "complete" advice of mine, not just take a minor hint from me here and there, I am SURE my offerings will make your success.

Some developers out there publish intermediate versions every 2 or 3 months or so; why not doing the same with MI, charging once a year, for 6, 7, 8, etc., but holding alive a real flow of intermediate enhancements, some big, some minor, BUT ALL IN THE SAME, THE RIGHT, DIRECTION.

We both will have a lot of credentials (which I need desperately when you have the credentials you want since you have currently-sold, "working" software, not just some ephemeral remembrances of it down 15 to 12 years), you'll earn a lot more money from MI than you do now, and at any time you could say, from now on, I'll do the development on my own again.

I hope I made some people THINK about some things for some time. Anyway, you've understood me, I'm sure, anybody around here: LIST management, and the most elaborate possible one, is the KEY to information management and thinking enhancement - I bet happily my head upon it.

And now play around again with PersonalBrain, har har. (But even in this jungle (or better, its corp version), big corps desperately see lists; which shows us how important they are - or do you think big corps would spend a fortune on jungled-up lists if they got them otherwise, in a neat graphic environment? You bet not. Oh, there's obviously a position to take.)

And a last P.S.: OneNote: Tremendous features where MS was able to fall back on its endless manpower and knowlege resources. But no real architecture in all this, the perfect clutter, and not many people use it, considering it's from MS, and compare with their other, now totally ubiquitous (even more so since Oracle's half-burial of OpenOffice) offerings. Imagine what I could make out of such a program (= "having it all" except for a vision and hence a straight built-up) and relying upon only a minute, atomic fraction of this workforce and all. - Anybody having ever seen differenciating uses of mouse clicks depending on position of the mouse in the same line of a list entry or any similar use before 1999 (= provable publication date of Manuscript) is invited to enlighten us re my no-paternity of this feature.

I even would work for Oracle; plus 20 p.c. whorehouse service charge, but then, SAP would be a natural environment perhaps. Yeah, that's dreaming; MI letting me help them would be just fine.

[Fred]

Graphics

a ) You followed my advice and did away with "Milenix" in the top bar: bravo: much more elegant, and as said before, "Milenix" has the suffix "nix" which is ugly and in German outright negative, meaning "void" / "nothing", and even in English, there's the expression "nix it!" = delete it, eliminate it, do away with it, so that's a wise decision of yours!

b ) You followed my wish and did away with the tree tabs: A thousand thanks! And for users who need it: It's by option of course, like the tree line I also am happy to get rid of by option, as asked. I'm very thankful for this "neating" graphics. By the same piece of work, you did away with the ugly flashing of the "No selected items" screen caused by a flashing up of the filter view, when loading topics. Again, thank you very much, it's a relief!

c ) You did, as proposed, set down the tree's up arrow, but there's a problem. I do not want to drive you crazy here, but all the upper part of the screen has to be reviewed, it's real ugly (as it was before), so it's important to find neater solutions to all those details. Sorry, but I'm positive about the importance = appeal to new users; it's more Eighties than Nineties today, and we have to work it out then. Again, my first thread on this had not even been read by the majority of current regular community readers, but again, it's the appeal to possible NEW users that's at stakes here, so you must pay attention to MI's getting a modern and sleak look even when most existing users are not bothered by its lack of such a look.

Since there is, above the tree up arrow, that field "Tree", that you lowered up to the top of the text field, the top of the field "Documents" (and other attributes) does NOT begin with the top of the text field = it's not aligned, bt there's a millimetre for allowing for a space between the fields "Tree" and "Documents": ugly, ugly, ugly, this non-alignment! It's even more ugly than before, but that's no reason to go back to the ancient state...

d ) You did not indent the title line above the text field, when this is absolutely necessary though. As said before, just indent the whole field, not its contents, so technically it'll be easy.

e ) You did away, as requested, with the ugly baby-blue line behind the topic tabs, but it's as ugly as before, and for a reason. In fact, imagine just several short tabs above the text (but at least one of those tabs, since without tabs, indeed, the problem does NOT exist). Then, where's space, above the item's title, for more tabs, there's empty space of course, and thus, the (regular-formatted) title looks really "poor". I know there's a light grey ribbon behind the title (instead of the baby blue one: again, I'm using XP with NO blue background, but "silver"), but its shade is "too light" in direct comparison with the (a little bit lighter yet) background ribbon behind the tabs and toolbars. You could do it in exactly the same (light) shade, but that would possibly even worse since that empty space would then be more prominent yet, the title itself would appear even more tiny and "poor".

f ) Another problem with the tabs is, they are "designed" from three sides (and even from within, their color being "shaded"), but except for their bottom, where they seem to be "cut off", and by this I do NOT mean, they seem to appear out of some ribbon beneath them, but they are really cut off: it could not be more ugly than that.

g ) The tabs again, and their colors. As said before, those colors are too washed out, and more of a problem, they are not in common with the colors used within the toolbars. Let me explain. I have three toolbars in a line beneath the menus: Search field (again, it should be longer by request, for the search field containing (and displaying then) more complicated search terms than just three short words ("Search This Topic")), ThisBranch/ThisTopic/OpenTopics/AllTopics, and then the formatting toolbar, not because I need that, but because I need the search field to be open, and if it's the only (very short / much too short for me) toolbar in the whole line, the empty space above tabs and item title is even more prominent. Thus, I use these additional toolbars primarily for making graphically "bearable" all this wasted space above the item's title / the tabs, awaiting eagerly your making the search field / toolbar unbound, so that I can put it on the right side of "MyInfo" and the menu line - again, that would make for 1 cm of screen hight, and again, there are people out there using MI on their 800x600 pixels netbooks, so every height pixel counts a lot for them. See it under another angle: MI is one of those rare programs that can be used on a netbook without any problem, resources-wise, so taking 1 cm of pixel height from them is not only really unfriendly, but when they try it there, it's like a cold shower for them in discovering this waste when first they had been delighted by MI's rather tiny ressources-eating up behavior. (Long battery life will always be much more important on portable devices than processor power, and nethertheless, people would like to work on netbooks in a rather smooth way.)

Back to tab colors. If in the above-mentioned toolbars, an element is selected, like "This Topic" or the "Left Alignment" symbol in the formatting toolbar, it's highlighted with an orange background (in my system): That's not unpleasant at all, it's a rather subdued orange, not a too bright one, so it's fine for me. But now compare with tab colors immediately beneath those highlighted elements. It's weird! Even your current topic's tab is mandatorily rendered in a washed-out color, not speaking of the not-current topics' tabs!

I currently have, as said before, my "Category Topics" (= a, b, c...z) in red, and my "normal" topics (= ab, ac, ad... ba, bt, bz...), by sorting tabs, immediately after them, so it would be a (red), ac(blue), ad (blue), b (red), several bb's in blue, and so on, two or more dozens of them. It's NOT that I LIKED these colors, but I simply cannot do without them since the other colors are soooo subdued I do not even distinguish their "current topic" flavor from their "not current topic" flavor, by this having often encountered doubts "where I was" = which one was the currently selected tab!

I'm not asking for Micky Mouse colors, but just have a look at my 5 colors, "This Topic" in a warm (but not-aggressive) orange, and just beneath 2x blue (active and not active), and 2x "red" which in fact is "rose" (non-active) and purple (active). It's the only way I can distinguish my tabs, and it's weird and queer and what you want, it's more than ugly!

Those tabs colors are from a washed-out, "cold" range of colors, the selection color in the toolbars is a warm and much more bright color: It's a punch in your face!

So, the strict minimum would be to have TWO ranges of tab colors, by option, and where at least the second one would be something more bright (which is NOT "craving your eyes"!) and in line with that (pleasant, I said that) orange of the toolbars - besides, the green-backgrounded arrow to the right in the search field toolbar is in line with the orange of the other toolbars, it's another "bright" and "warm" color, as are most colors in the color palette in the formatting toolbar indeed: just make available THESE colors - but in two flavors each, for active and not-active, from this palette, instead of the current tab palette nixing any sense of color schemes whatsoever: any interior decorator doing such a mixing would be killed for doing this: it's that the tabs colors simply don't go with those, but in no way whatsoever. Again, I'm not asking for craving-your-eyes colors in that palette, but just for colors that "go with" those warm and not-washed-out colors of the toolbars. As it is, it's almost crazy in its non-alignment, but I'm repeating myself here. It's really important... (Or are your tab colors in line with Windows 7? I very much hope not, it's becoming psychedelic again, and that's 40 years behind where individuals did NOT have "personal computers" of their own...)

h ) My considerations apply to the filter view as much, but I'm specifying my findings about the tree view here. Again, the current absence of any "beauty" from the screen is as blatant as before, in spite of your efforts, so we have to amend all this; there has been no real "error" in my advice, but simply, it's done half-way only, and the intermediate result is not better than having done nothing, before. Let's try to make it better, no pun intended, and no pun accepted, for the time being.

When focus is in the text pane (or elsewhere), the tree pane starts with "Tree", in a grey-bordered field whose background has the same color as the beginning (= at the left that is, to the right it gets a little bit darker) of the title field above the text field. This is useless, worthless and distracting since it even puts the "optical focus", the "highlighting", on the tree, when there should be some "highlighting" on the title above the text - besides, I'm NOT asking for a middle-grey, not-bordered field on the title field, as appears on the "Tree" field when the tree has the focus: it's ugly and "Eighties".

i ) Under the "Tree" field, there's a "Documents" field, perhaps with other attributes' indications, like "Tags", etc. ; as said before, the seperation lines / edges between "Tree" and "Documents" is awful, but on top of that, why doing such a "Tree" and "Documents" indication when it's perfectly evident that's the tree view - and then, if people use different views, they will put ON the tabs at the bottom of the pane, so they will "know" if it's tree or filter view, even if they don't see it from other details.

The effect of these "double indications" is that the screen space where tabs, tree pane, title above text pane and text pane itself meet, is A TOTAL MESS in every respect!

Where there's the white text background of the text pane already to the right, to the left there's always the grey of the title line above the text, on the SIDE of the white text background, but there's NO grey throughout, whole pane, whole height of it (and that wouldn't be a good idea, besides), but there's chaos, chaos precisely on a spot where users almost almost lend their eyes to.

So what to do? First, get rid of the totally useless "Tree" indication. Thus, for technical reasons I clearly see, the up arrow of the tree list will again going up where it's not really beautifully placed, so your trying of following my advice, unfortunately, was following my error indeed here: sorry for this.

In fact, of course I was right to ask for the two up arrows being placed at the same height (as they are in this 5.51 beta), but then, I didn't know yet that your tree component forced you to have the "Document" and "Tags" and "Whatever" indications WITHIN any scrolling frame of this pane. To make my point more clear: A better tree component would have allowed for displaying those columns indicators not besided the up arrow (= at the same height with it) but in a "line" ABOVE it, the up arrow being placed by this at the same height as the first real "line" = item within the list space of the pane; by this, you could have put the "columns indicators" of the list ABOVE the list, on the same screen height as the title is above the text field.

So this being not possible (?), we unfortunately must place the tree's up arrow, again, besides the text title (where it doesn't really belong graphically), since that's the only way we can assure that the white backgrounds, of the tree and of the text, will start at the same screen height, and that's much more important than the positioning of the tree's up arrow.

For focus toggle between tree and text panes, I would propose this: If text pane has focus, make title above text bold; if tree has focus, make that "text title" regular, and make any "columns indicators" above the tree bold (and make them regular again when the "text title" gets bold).

But then, the bold formatting of the "column indicators" would not be too "beautiful" if there are a lot of them... and I clearly doubt you could make bold only the first one of them, the "Documents" term...

What to do? Well, we first must distinguish between "columned" trees / topics and topics not having any columns besides "Documents". As said before, from my about 250 topics, only 10 have any columns left now; for almost all of them I prefer the neatest look possible!

And then, to he** with that ugly "Documents" "indicator" - I KNOW that those are my documents! So why not have an automatic routine doing the above-mentioned displaying whenever there are OTHER attributes displayed than the attribute "document" or rather "title" called "Documents" in the tree header, and that would do something MUCH BETTER when there's a topic without columns (or without the columns displayed currently, a property stored with each topic individually)?

That header "Documents" is to be done with! And this way, our up arrow could be at the same height as the up arrow of the text pane, and above the (white) list pane, there would be NO indication whatsoever; depending on focus (in text or in tree), it would be just the "bolding" of the "text title" that would be applied or not? (And of course, the more vivid-colored background of the current line in the tree if focus is there.) Would this be possible, technically, or insists the tree component on displaying that header line, with content (= "Document") in any case? Then, would it not be possible to format those contents, at least, in the background color, so that the first tree line / item would indeed be at the height of the first text line in the text pane, white backgrounds' top and bottom being the same in the tree and the text pane? thus, there would only be the up arrow, to the left of the text title, without any other eye-wringing nuisances there...

Of course, there would ever be the possibility to have the (in case of it being too long, cut) TOPIC title above the tree, at the same height as is the item's title above the text!

And I fear that your tree component will not allow being displayed without any such "headers within", thus taking the place there where there could be another field? "Bolding" topic and item titles, depending on focus in tree vs. text, would indeed be the most elegant solution, even if the tree's up arrow cannot be put down where it should belong? Anyway, just putting a topic title field over the tree pane, would not be a solution, since the white backgrounds of tree and text panes MUST begin at the same height, and if two titles, they must be at the same height.

Following my advice as much as technically possible here, would indeed bring enhancement.

j ) And then, why doing that Eighties-style vertical border between tree and text? Just leave it in white, oh yeah! Have a look at modern software, "Less is More.", as the great designer Ludwig Mies van der Rohe knew even in the Twenties! (Oh no, don't apply this to my writings...!)

In fact, there's that very light shade of the scroll bar whenever the tree gets long and convoluted; when there isn't any scroll bar, the tree will be so neat that it's sheer shortness will separate it graphically from the text pane. Just try it, just dare it: I KNOW it will be much, much better than what we have now!

You must see that ANY design that mixes horizontal and vertical lines, is crap! (With the sole exception of Mondrian, but he KNEW why to work with so bright colors filling up the spaces between all those lines...) And thus, since we need, on top, all those various horizontally-designed elements, from menus to tab rows and titles... and even the items in the tree and the text lines in the text panes follow up this horizontal desin all screen height down - we must get RID of any vertical clutter breaking this up; that line, as bright as it may be, between tree and text pane has to be eliminated, and you'll see that there has been no functional need for it ever.

(Do NOT rapproach text and tree; even I who want to make best use of space know that there has to be some "breathing space" between those two elements indeed.)

k ) Please, as said, make an option "hide status line".

l ) Let's see what we've got after addressing these points; for the bottom of the topic tabs, I don't know yet, except for a thin and yet shadowed line there?! (2 pixels's height, 2 slightly different shades of grey... or even of blue? (no!) or blued-grey, since that's the border color "around" those tabs, except as yet for their bottom...!

m ) I know that the problem e) has not yet been resolved here. Give us an intermediary result, and I'll have new ideas about that empty space there and its possible coloring and / or filling up!

[Fred]

Tree: Text color, Text background color

You spoke of problems with the implementation of those commands; I said assigning them to any key (combination) didn't do anything.

Now I tried again.

In fact, both commands "work" now, by opening the respective color palette. Good! But then, problems begin.

Let's say you've chosen "red" for (special) items' color, and "yellow" for (special) items' background color, with the mouse; the toolbar symbols show those special colors.

Any "normal" creating of new items will not be done with these specifics, but in black, and with white background: very good, nothing else did I expect.

But let's say you want to format some item in red. You've created it, or it's even an old one. Then you trigger the key for "text color", in order to change that (default black) text color (it's exactly the same with the background command, so I leap over that's description).

The command displays the open palette. There, the special color (here: red) is selected. And now, any sensible user would do an ENTER, assuming that the selected color in the palette, red, would by this be assigned to the selected item in the tree.

But no. You do ENTER. The item color (or background) does NOT change, the palette does close (as expected)... and the color indicator (= of the closed palette, in the symbol in the toolbar) changes to... BLACK! (In both cases, even for the background color symbol, not only for the text color symbol.)

When you re-do the opening-command for the palette in question (by your key assigned to this effect), NO color in the palette is selected now (= not even the black one, that is), and in any case you must (again) select your wanted text (or background) color by hand, i.e. with the mouse.

Thus, just for opening the palette, nobody needs a key-assignable command if then he'll have to move the mouse cursor within the given palette in order to assign a (text or background) color, even for the preset standard "special" color he could much more easily obtain by just clicking with the mouse on the pre-set color symbol in the toolbar.

Thus, the two key commands should do either of these:

- as proposed before, assign the pre-selected (and being visible in the toolbar) color to the selected tree item(s) = best alternative

- OR open the palette, as they now do, but then, ENTER should not trigger the above-described bug, but just assign the pre-selected (or manually in the palette selected) color (and then pre-set it also in the toolbar symbol if your possible manual choice before pressing ENTER altered the before-preselected special color), and close the palette - this second alternative would be less comfortable than the first one, proposed by me, but would indeed open the palette for possible manual changing... but then, whenever you want to change your preset color, you need to do it with the mouse, so in those cases you could open the palette by mouse in the first place... which makes the first alternative being preferable even when considering the offerings of the second one.

As it is, those two commands stay as worthless as they were, or worse, since before, they didn't anything, whilst now, they "reset" your pre-set special colors to black if you dare to press Enter.

Thus, please have another look at this problem. In fact, keybound assigning a standard special color (or background color) to tree items, as in the first alternative, would indeed be handy. If not, at least the bug, in the second alternative, should go.

EDIT: The first and the second palettes are quite identical, except for the inscription "More Colors..." in the first one. Well, in the first palette (= text color), you'd need LESS colors than in the second one (= text background color), or at least brighter ones!

In fact, when you try to assign background colors, you'd mostly preserve the black text color, be it in the tree, in the text or even in tables (!), and thus, even if I dislike baby blue indeed, I had tried to make a light blue background in a table where I must assign several colors for identifying reasons, and I now see that even the lighter one of the only two blue color shades offered there is far too dark, not as text color, but as text background color!

Thus, we have here another misconception of wanting things "adjusted", "similar", "identical", whilst in fact, colors for text should be darker, colors for text backgrounds should be lighter... and be assorted in style = color character notwithstanding! Be it as it is, currently there's NO light blue color available in the text background colors palette, and it's not a question of preferences, it's just that users should be able to use colors as CODES, so blue must be available, if you like it or not (which is my case). BTW, there are MANY greens / turquoise there, so some of these could be replaced by blue, etc.

[Fred]

Clones

I discussed clones again in this thread, before having another look upon them in 5.51. There are quite a handful of clones commands, but cloning stays as practically impossible as it ever was.

There's a command for "copy clone". If you trigger it, your current tree item is cloned... but to the end of the tree. From then, you'd naturally try to shift it to that position in your tree you want it to be.

First try: You cut it (control-x), then you paste it where you want it to be (control-v); as we all know, by this procedure, it has lost its clone character; it's become a copy, no further synching between the two whatsoever. (We're speaking of pasting to any place in the SAME tree of course.)

Second try, but here I didn't try lately: You shuffle it around, by Alt-Arrows, thus without cutting and pasting. If my memory doesn't fail me, this WORKS, but shuffling around an item to another subtree, in a tree containing perhaps hundreds of items, just by using various (!) arrow key combinations (!), depending on the places to bypass in your way, that's awkward, lengthy and error-prone and not doable but on special occasions, for just a few needed clones. I agree that's it's perhaps a better way than the third try, but it's as off-putting as that.

Third try, you don't do a "copy clone" command, but you go to the TARGET item, and then, you do the INSERT clone command. This is really bad since it opens an additional window, with an image of your whole tree, and there, you'll have the "pleasure" to find your original item that you are willing to clone, and if you've found it finally (let's say, 1,200 items in dozens of subtree: have a nice round-trip then!), you do an Enter, and you're done...

In fact, I reviewed the cloning commands not in the hope of seeing something new there, but by fear of having overlooked something better than I had described in my posts here-above, in this thread... but no: Indeed, there does NOT seem to be any way to apply a command to an item to be cloned (as in "copy clone", but without the cloning to the end of the tree), and then to apply another command when having selected your target, "insert the aforecopied clone here", as described in my posts here-above.

Thus, unfortunately, I must renew my claim that as it is, MI's cloning feature has to be avoided; there's no way to use it in any practical way.

And this brings me back to my hope that you soon will implement cloning commands as explained by me here-above in some post before this; any "go to next/previous" clone command would THEN ONLY be of great help; today there are lost effort. Since cloning is implemented, such "clone this item" (= into memory, just like you'd copy an item into memory) and "paste clone here" commands should be possible to implement without any further effort. (And clones (and their "originals") should be distinguished by some additional symbol (like in UR, and as there, not necessarily in different ways "original" vs. "clones 1/2/3"; just make it visible an item HAS been cloned or IS a clone, both alternatives confounded.)

EDIT: I just see that there's a "cloning" symbol indeed, but it's in any given symbol in front of your item titel in the tree. As I do NOT have any symbols in my trees (nor flags, but you'll have expected that), I cannot see the clone symbol either. Thus, when perfecting clones = making them really useable in the way described above, there should be a way to have the clone symbol independently of any other symbol, OVERLAYING any other symbol that is, instead of being integrated to them, and the option "no symbols" (on which I heavily depend!) should NOT affect those special cloning symbols.