Messages - peter.s [ switch to compact view ]

Pages: prev1 ... 7 8 9 10 11 [12] 13 14 15 16 17 ... 24next
Greetings, donleone.

Wow! If ever some application had some ace ambassador, that was RN getting you as its spokesman! Of course, I'm musing about how you got together all this info, with no forum and a very low-key helpfile (to say the least); if by chance you're the developer himself, well, kudos, you defend your program brilliantly, and, very obviously, you are right to do so, since from your explanations, it's much, much better than it appears.

Thank you so much for your multiple (and obviously very needed) clarifications, and I fully acknowledge, from what you say, that the tagging limitations do not appear to be of relevance anymore, since more than 500 identical tabs would to be cut into several "siblings tags" anyway. I uphold my observation that the tag gui is catastrophic, though, not only visually, but from the "how to search for tag combos" pov, too; I deduct from what you explain that the tag feature does NOT have some specific search in-built, but that, if several items are tagged "tag_a" and "tag_b", you simply do a regular quick search for "tag_a tag_b", like for would do for every search term present in the text.

Thank you so much for your explanations on the "pages" concept, so "pages" is simply a synonym for "tree", several such trees, each with its specific tree format, being possible in ONE db file; in fact, that reminds me not only my developments of "several trees in one db" in the outlinerswforum over there, some months ago (and the big difference of RN trees vs. the concept I explained there, see below), but especially, several both UR and MI users asking for different sub-tree FORMATS within the same db = very big tree, in their respective outlining applic; doing several trees within the same db instead obviously is a viable and much more elegant solution to this appearantly rather common prob.

Now I understand better why RN, which (as I see now) belongs to the "big shots" in its category, has no clones yet, since in the db structure you describe, clones would be more difficult to implement than in the traditional "1 tree - 1 db" setup, and that seems to be the difference between RN today and my developments over there:

If I understand well what you say, one item, in RN of today, can be in one tree, but not in several trees (yet), no more than it can be placed in different sub-trees of the same tree (of course, since that would be cloning), and thus, whilst several trees are possible, in RN, within the same db, it is not possible (yet) to create "contextual variants" (or whatever you might call those structures), i.e. to have items in more than one context, and by this building independent data repositories but accessing (and then SELECTING and REGROUPING) already-available "raw" data.

( cf. my thread here )

So what we have got, is:

- UR and MI (and others) which offer clones (i.e. multiple instances of (= internally references to) an identical item, and which is a "big step in the right direction"

- RN which offers multiple trees within the same db,

and it hits everyone in the eye that the perfect outliner would combine these two features (and it is evident that you need complete cloning first to realize this, i.e. any clone must "update" any possible children/grandchildren which may be added either anywhere, or, even more elaborate but perfect = the ultimate solution, which might have been added in some "source", some "primal" tree, but not, or just by way of dialogs popping up (= not by general option once and for all!), within trees that should be considered not as "partial descendants" from the original ones, but as "partial siblings"; here again, my example of legal dispositions, in some "source", and then different "cases" where you will need diffent subsets of these dispositions only; technically, such subsets could be realized the following way, even "cross-wise", replicating from one such "sibling tree" to another one:

Any cloning does a "complete cloning", i.e. sets a value in the respective dataset to any new descendants being replicated "here" (i.e. any clone would have its own settings), but then, those specific clone settings, individual for every one clone, would maintain additional "deletion" info, causing that any "add-on", elsewhere, of that replicated sub-structure, to an item here in THIS instance of that sub-structure, will NOT be added here, IF the sub-parent item in question has been deleted here OR has been "marked as sterile" (while having been left there to contain alternative descendants): Thus, "updating" of any clone wherever would be automatic, but would encounter individual barriers in each replication, and this "infertile items" would not only not be updated for new descendants added elsewhere, but their own descendants would not be replicated in the "sibling" replicating structures:

Thus, an ideal cloning concept would clone "over" different trees, AND allow for these clones becoming perfectly individualized over time (as would do primitive copies), AND get "allowed updates" (= context changes, item add-ons, item deletes), but just within the limits individually set: Just imagine "identical" twin siblings which are then heavily changed, "individualized" by their respective lifes and in different towns, even countries, and new family contexts, but which often attend the same familiy meetings (and get identical new info there, often replacing old info instead), but which often one sibling wants to incorporate into his knowledge, whilst the other sibling refuses such "new info", be them add-ons, be them corrections, and having "voids", "blank spaces" in his mind instead, or having new info of his own (instead, or additionally), but which he won't share with his sibling, and even if they grow very much apart, there is always the possibility that one day, they both get their respective share of the inheritance of their parents when those die - ok, in my IM concept they wouldn't die, in normal circumstances, but up to then, the above allegory is quite faithful, and even for the "death"/deletion of "original parents", some "taking over" proceedings should be implemented (and processed from within dialog windows, individually).

Sorry for diverting, but as we see, RN is just short of becoming something really great, at the condition that further development will be based upon its current strengths, so some guidance could not do any harm. ;-)

As for the multiple tagging features in RN, as said I don't grasp them yet at this moment, and some better help file descriptions, AND some remodeling of the taggingrelated part of the gui would both be more than welcome. ;-)

Hi TaoPhoenix,

He knows about it, and you're right, if there is one very responsive outliner developer, it's Petko, so this will probably be amended. I should have added that the cloning command in MI had been implemented some years ago and was really abysmal at first (= MUCH work to clone something), but then had been changed to somewhat as good as in UR, creating a clone is much smoother now.

And of course, "singulary clones" (without children, and which presumably will get no children even afterwards) in MI are perfectly viable even now, e.g. if you have got legal dispositions, one by one, or grouped into one item, within the context of the corresponding law, and then cloned into some "case" you're working on.

And yes, there are no clones in Maple; re Maple: As said, it's db-based, but it's lightweight, and as in any "text-based" outliner, it will feel natural to multiply outlines/files, whilst maintaining hundreds of such files in UR, e.g., would feel "inappropriate", would at least go a contrario the "spirit" of that program. And then, for maintenance of such multiple outlines in multiple files, the special trans-file search feature in Maple is something extraordinary, which I would like to see elsewhere, too (= in a program WITH tree formatting, and WITH Boolean search that is). Technically, you can do the same with MI, and which HAS got, as said, both these features I miss in Maple, and that's another reason why I think MI is leader of the pack, currently (and in light of respective development paces, this position is unlikely to change).

I warmly recommend Paul's blog, for more than decent (and current) specific info on specific outliners:


Since the public viewing of the Snowden affair is 1 year old, there are some articles in the press, on Snowden, but also on Turing and encryption/decryption, and I stumbled on this one (in German):

I never understood the Enigma, especially since every "explanation" about it you can find in the web, either is written by experts for experts, or by non-experts who don't understand the Enigma themselves, and the link above falls into the second category, but some comments there rise some interesting points.

It seems Turing began his decryption work on the Enigma after one functional Enigma machine fell into British hands.

It seems the "code for the day" was communicated using the previous code.

It seems some primary code needed for the real encryption, then to be made by the machine, with the help of the "code for the day", was a stable arrangement of the abc chars, and the British tried myriads of possible sequences for this, e.g. qwerty, and so on, but the Germans, "incredibly", just used "abcde", and it seems the mathematician Marian Rejewski did find out this, not Turing, and the commenter in the above link who brings this info into the discussion, muses that Rejewski had worked in Göttingen, Germany, beforehand, so had some first-hand info on German psychology / way of thinking, which enabled him to take into consideration the Germans might do it in the utmost basic, primitive way, a possibility excluded by Brits just admiring the machine but without intimate knowledge of German "national character" - I very much like this observation.

(EDIT: And of course, this over-emphasizing/relying upon the over-obvious resp. the "really-too-easy" reminds us of that E.A. Poe short story...)

It seems the breakthrough was then made by Turing's reflection that by the way the machine obviously worked, on a physical level - direct current was sent thru the rolls in one direction, then in the other direction - no character (a...z, etc.) could be replaced by itself, this drastically reducing the machine's encryption possibilities / possible permutations; in fact, the cited article is primarily about this phenomenon of "Selbst-Bewichtelung", no English translation found, just this transcription, "Players who receive their own gift in 2/3 of all secret Santa games."

Some commenter over there claims the biggest U.S. employer for mathematicians is the NSA - very funny and very convincing, even while no proof is given.


I, just some days ago, had mused about specific file formats countering effective encryption. Let's say you use MS Word files, or some other file formats where quite lengthy passages are, more or less identical, but highly standardized at the very least, for every one of your encrypted files, AND the decryptor knows (or can safely assume, from the presence of these applications on your system, or simply by the ubiquity of some applications, like MS Word, and its rather few "replacements", ditto for spreadsheets, etc.) which (few) applications you will have used to produce the encrypted data:

Then, this might drastically reduce the theoretical power of your specific encryption, since the decryptor (assuming even he doesn't have a way (which might exist, without us being aware of such possibilities) to determine where one of your file ends, and the next one begins, which would further cut the possible permutations into a mere fraction of their theoretical potential-by-strong-password) would try to decrypt those "standard passages" first, and even allowing for your individual data within these "standard passages", intimately knowing the "format" of the latter, incl. possible lengths of different such individual data in-between, and once these "file headers" are decrypted, your key will be known.

This would mean that usage of any application not producing just naked ansi files, but putting "processing data", "meta data" into the file, too, should be prohibited if you really want your data safe (= necessary but not sufficient condition)...

(As the title indicates, this does not treat the maths program.)

Maple Prof. is an interesting piece of sw, but my experience (checked with the developer) is somewhat mixed. Since there is no review yet, some info should help.

It's a regular 2-pane outliner, but db-based; this is worth mentioning, since from its regular behaviour, you would think it's text-based; for example, better db-based outliners like MI and UR store pics within the text content in a light format where jpg remains jpg (= even when you don't import the jpg as an item on its own), whilst "bad" outliners (like AO, Maple, Jot+ and others) blow those jpg's up into a format that for a 30k jpg imported into the text, 1 million bytes may have been added to your file.

Outliners (= tree-formed data repositories) often are very helpful on the road, with perhaps a tiny screen. Thus, I never understood why most outliners which have search hit lists, do these in an additional pane, since if you have 3 panes at the same time, tree, content and search results, on a 12- or 14-inch screen, you will not see much of any of them.

Now Maple uses, as search results pane, the tree pane, or more precisely, you can switch back and forth between hits and tree in that pane (different viewers), and this seems perfectly logical since either you browse the tree, or the search results, by you scarcely ever will need both at the same time.

Also, you can do regular search (over tree and content), or then, in tree only; this seems mandatory, but some outliners don't offer this way of searching.

Very unfortunately, though, Maple does not offer Boolean search, no AND, OR, or NOT, which means that any search will be primitive "phrase search" (which is a very good thing if it comes besides Boolean search, but which is unbearable when it's the only search you get); of course, presenting a hit table, but no Boolean search, is quite an incongruity, but the developer says Boolean search will be implemented in the future, but without giving a road map.

Sideline: From my memory, the corporation behind Maple (they do some other sw's, too, but for Maple, there is slow but steady development, whilst for AO, e.g., development is almost inexistent, and Jot+ is defunct or rather can be bought in its ancient state from multiple years ago; none of these sw's have a forum) seemed to be from Spain (which is quite exceptional), but the current stuff seems to be from Russia (which is quite regular); I don't know if I'm mistaken, or if they have been bought, or whatever.

Also, very unfortunately, formatting of tree entries (bolding, italicising, underlining, coloring, background color, etc.) is NOT possible with Maple, and it will NOT be implemented, which seems to indicate they chose a bad tree component and are not willing to replace it; of course, you have the usual icons instead, but from my (very extensive) experience, icons could never ever replace tree formatting; in fact, for me that's the ultimate deal breaker.

Now the outstanding Maple feature, which is why I took the effort to write this review:

The only (?) big shot "search over several files" outliner is currently MI, but Maple Prof. has got a similar feature. Now, if you need trans-file search, for outliner files, your best bet is some tool like "File Locator" (The internal text search functions of both XY and SC file managers do it, too, but don't find all occurences, as hopefully FL does, and, interesting, they overlook the same occurrences, which are listed in FL (free).)

Whenever you search in outliner files with such a tool (most indexing search tools refuse to index outliner files to begin with), you will (hopefully, see before) at least see where to look further then, but no exterior tool will get you to the right item there, of course, and this makes the tremendous interest of such in internal trans-file search tool: When you click on a hit there, the proper item will be shown.

Since Maple Prof. has got such an exception feature (as said, together with MI), it deserves its own review, after all, even in the absence of tree formatting and Boolean search. Let me put this straight: Permanent absence of tree formatting makes me discard this program which otherwise has lots of potential, even if I would like it to implement Boolean search immediately, not some day in the future, and I would even be willing to live with the rather bad rtf editor which blows up imported/inserted pics.

Or in other words, the day Maple would replace their substandard tree component, I would switch over to Maple.

Now some brief words on that age-old competition UR-MI.

MI development is much more "developed" than UR's is, and the key misses are:

- UR has no global replace, and the developer is unwilling to implement it (this is the deal breaker for me, since trying to replace some term in 20 or 50 items, by external macro, is crazy and unreliable)
- UR has no trans-file search, but then, you use both programs more or less as "global data repositories", i.e. few people will create multiple files in any of them, so this is less important

- MI (of which the cloning feature development is much more recent than in UR) has always a missing detail in its cloning function which makes it almost unusable: Whenever you add child items (or grandchildren and such) to a cloned (parent) item, this is then absent from the descendants of the clone. Now there are very few instances where this absence would be welcome indeed, but in most practical uses, this totally awful:

Not only for "one subject in different contexts in general", but especially in the "ToDo" part of your big tree: This absence makes it impossible to put some subject into the ToDo list, and then to work upon that subject from the ToDo list; instead, you will need to CROSS-REFERENCE the subject in the ToDo list, i.e. to jump to the "natural" (and unique) context, and to work from there then.

On the other hand, MI's developer could work on this, and then, his program would undoubtedly be the far better program, at least speaking of Prof. version in both instances, since only MI Prof. has the global replace feature (which everybody will need in the end, even if he thinks he can do without, that's blatant wishful thinking), and which UR presumably will never get.

(I'm repeating myself here: In UR, tree formatting is possible with a trick... whilst in MI, it's available straight on.)

Thus, with a little more development, MI will be number one (or, if you're willing to cross-reference instead of cloning), it beats UR even today).

And yes, Maple competitors should adopt Maple's hit table, in the frame of the tree, at least by option.

Thanks, rjbull, for the link to, some instructive content, even if it's been a LONG while I've seen some other site as ugly: straight from 1983, or so it seems to me.

He's got some page "Programmable keyboards" over there, too, with "Using AHK instead of a prog. kb" - well, you know, I think by now, that it's "Using AKS ON a prog. kb", of course, i.e. just assigning weird key combis on the prog. kb, and then intercepting those impossible key combis by ahk, to do the real scripting.

Tuxman, your Germanese, "As a German, the centricism isn't too bad for me." is awful, Germans to this ALL THE TIME. I'm no teacher, can't give the right terms to it, but let me explain: "As a xyz" is subject 1; then, "the centricism" (or whatever) is subject 2, and the verb, here "isn't", depends on subject 2, whilst the "As a" for subject 1 unsuccessfully tries to make it depend from subject 1. As they say, Goethe's spirit would rotate in his sepulchre, had it knowledge of such ways of speaking. Thus, every German out there/here, please, say, "For me/him/whomever as a xyz" (by this, transposing subject 1 into accustive, by this breaking up the link with the verb), if really you can't do without the "as a" structure which is of utmost ugliness anyway.

As for SC: NO English-language forum, just in German; NO English-language help file, just in German; no help worth to speak of in the Forum, even in German, just Germans musing abing absence of features, and the developer not deigning to intervene/clarify/inform, except for very rare occasions. Additional prob: In order to "find" something either in the help file or the forum, you must know the German term first, and be assured they just don't use simple translations but have their own, very special SC terminology for many common English terms... (And you should be able to read German to begin with, of course.)

Comes with several add-ins, e.g. a text search function, similar to the one in XY (and neither better nor worse, neither slower nor faster than there; I own both and compared extensively), or a synch tool (which is really bad), and, of course, bulk renaming as any paid file manager offers to some degree (see below).

"Every other file manager is just a sub-set of those three." Innuendo, this is simply not true, Besides, whenever I see a FAR screenshot (as in the linked softpanorama), I feel an urge to scream out loud (Wanna buy my NC, Dos or Win, anyone, btw? = rhetoric question).

Of course, TC is very powerful, but 2 things:

- My ways of doing an AHK tutorial may be debatable, and yes, it was a "work in the make", and I should have it revised, and edited; cut up into several posts, it's become a mess. But then, I tried at least (and am not too motivated to do the necessary work on it, by lack of feedback, i.e. no AHK noob to ask about details, so what!), and any TC "expert" would be free to do something similar (cf. the post above, about the need to search it all together, over numerous hours of hard work, from dozens of forum entries), in order to make TC more "accessible", both from a technical pov and from a gui pov (yes, the step from bold to regular font is known by now, but that's not enough, as we all know).

- But that is not done, and this brings me to a second observation: My tries with the forum were that the developer doesn't take part in it, except some possible exceptions, and if you explain another one of the innumarable weirdnesses of TC and ask for an option to have it another, more "normal" way, TC experts will explain, with lots of goodwill (cf. DO forum, where you will be attacked instead), "why" it is as it is, and only that way, and most of the time, these explanations are quite weird on their own, whilst the developer just has it his way, no any other. Thus, the form of discussion is much more pleasant in TC, than in DO forum, but you quickly get the impression that nothing really will ever change though, and version history (8 now) proves that your impression is right. Also, explanations about "how to" are sparse, and (as said above by Innuendo), are both fractionized and aleatoric... and, my impression, TC experts on that forum like it a lot like that.

Thus, TC expertise has become their hobby, and just as I don't count my spare time spent with AHK, they do similar with TC - of course, people who preserve a minimum of objectivity would argue that time spent with a scripting (or programming) language might be time which, at least in perspective, is spent to some reasonable goal, whilst for file managers, it should be "want to do something? here it is, immediate availabality, so that it won't make you lose time unnecessarily": A file manager should be a readily-available instrument for special tasks, not your new folly.

The same applies to other file managers, to a degree, and certainly to DO where "spending time with my preferred file manager DO" has become a hobby on its own for quite some people, whilst the intuitiveness is often absent; on the other hand, DO's got one of the very best help files out there, which helps a lot for lots (if not all) of things.

But at the end of the day, whilst most daily functionality is perfectly done by FC or such, and whilst XY (today on bits, 50% if you havn't got it yet) certainly has got the most pleasant photo viewer functionality of the immediate competition:

As soon as you get to some special needs, you try your 5 or 8 file commanders, 1 by 1, and then you risk to do it by hand. Last weekend, e.g., I needed to rename JUST the FIRST term of a bunch of folders from upper- to lowercase (whilst the rest of those names would have to be left unchanged). So I spent more than 2 hours with my numerous file managers, and tried to apply, where it DID apply, my knowledge about several regex replace flavors, to no avail whatsoever, and finally, in XY, it did it manually, but renaming in the XY rename list, which at least spared me multiple F2, Return, F2...

Every file manager does it its own way, deep down to regex replace in file names, and the respective help files are far from being up to par, and you end up thinking that you search, and try, in vain, because the relevant special functionality simply isn't there.

A last word on SC (I'm repeating myself here, but it's important, and, ok, I didn't try the last versions of it): If you want quick access to a subfolder (beginning with "ac"), you enter "ac": So far, so ubiquitous. But then, in order to display that subfolder, you press enter TWO times, not once (or you opt for (the totally awful) "NC mode"), and quite frankly, that drives me crazy, since it forces you to always reflect on "in which file manager / program am I? 1 enter, or 2 enter? So many people in their forum criticised this crazy behaviour, and the developer didn't lend them his ear, over many years (as said, perhaps it's set now, but I'm not sure at all about this).

I like XY, for photos. For everything else, I use FC. And to finish: I suspect SC people to not being able to write in English, and that would then of course hold them back over there, in that depressing but German-speaking forum.

Pages: prev1 ... 7 8 9 10 11 [12] 13 14 15 16 17 ... 24next
Go to full version