Messages - peter.s [ switch to compact view ]

Pages: prev1 ... 8 9 10 11 12 [13] 14 15 16 17 18 ... 24next
I trialled several of those.
First try free Mouse without borders (MS Garage).
If it's not up to your expectations, try paid ShareMouse (Bartels; I can confirm it sets the standards here)

This being said, all such sw implies your pc's being connected, by network?
Or is there sw where there is no network connection, but some more "primitive" connection, perhaps even without the usual clipboard sharing (cs)?
Ok, cs is very helpful I agree, but...

These sw's (except for my asking if there might be alternative ones, doing it in another, more basic connection) prevent you from having a set-up in which NOT all your pc's  are connected to the web.

Hence my reminding you of the good old hardware kvm's, with physical relays; I suppose there is no way to access your private data on pc 2, from some web actor accessing pc 1?
And if you consider such a physical thing, let me tell you, before you buy, that those 30-40$ devices, often functionally identical to the 120$-and-up devices (speaking of 2-pc sets here, multi-pc sets can cost hundreds of dollars), have cheap relays which will quickly make you fear about the life time of the device in question, upon every switch.

Thus, there are several aspects to bear in mind, BEFORE deciding on your respective multi-pc set-up. Perhaps it's not that bad an idea to have 1 extra pc for the web, and then several pc's (if you really need them, concurrently), within a cable (not: air) network, with the (excellent) Bartels sw, not connected to other devices which might give web access.

Any multi-pc setup brings security considerations with it, and not even mentioning those doesn't seem that prof.

"Especially when somebody else is picking up your distribution expenses."

Ok, since this "old" thread has been revived anyway, let me give my 2c to this aspect. Most developers would be happy to have "distribution expenses" caused by heavy downloads from their own page; today's schemes are such that for most developers, 1,000 downloads or more per months would not only be included within their hosting, but would be considered peanuts by their respective hosters, which means by such download traffic, they would not be forces into another, more expensive contract.

Now, whenever you see some sw on a site like cnet (e.g. because the term "review" redirected you there, which is not a bad thing since as said, many reviews there are quite informative), what do you do then? Download from cnet, and have trouble, or go to Softonic and have as much trouble (alcool: bad), or to Softpedia, and presumable have no troube? (wikipedia: good - that's how I ensure for myself to not mix bad and good up).

No, your natural way of doings things is to search for the homepage of the developer, and to try to download from there. Now you could say that with unknown developers, that's a much greater risk that downloading the same free or trial program from e.g. Soft(wiki)pedia, since them do some scanning, but at the end the day, nobody except for the developers knows what his program will do, behind the scenes, when you run it, so you either trust him or not?

But then, in light of the above, such direct download should be possible in most instances, and when not, for some financial reason behind (really big download, really lots of downloads every month), it's the developer, on his homepage, who should you redirect to the download "provider", it should be up to the (honest) developer to redirect you to some honest download where NO crap, viruses, whatever will be added, i.e. as long as (e.g.) Softpedia is "safe", why a developer should not redirect you to that site, and to the download link over there?

Problems start from 2 bad ways of doing things:

- Your downloading from "anywhere", from "where it's available", without thinking

- Much worse even (and you should think twice then about the developer: is he really so naïve, or is he not entirely honest?): The download redirect link from the developer's page brings you to cnet, Softonic, et al.

This rule, download from the developer resp. following his redirect link to a trustworthy download site, should apply except for defunct sw (where there is not any developer's site anymore), and those are rare; most often, you get crapware by not following the above rule, by not thinking about it.

And yes, whenever some program is unknown to me, and its developer, too, I try to gather some "reviews", some shared experience with that program from different sources. Which means we're not 15 years old anymore, we should be beyond "sw collecting". When in doubt, be sure you'll be able to live without it.

My 2c.

Great db Foundation
Indexing of various file formats for linked files: Your list is quite impressive, and over at outlinersw pdf linking/indexing was mentioned a lot as for RN being really good in.
So not the slightest criticism of mine here, just two reminders:
- This excellent linked-files M of RN should be another (good) reason to not import external files, thus blowing up the db
- Linking a max of external files into an outliner invariably produces de-synch very quickly, since you do part of your file M within the file manager (in which you have available all files and their structure "live"), and part in your outliner (where you have a subset of which you never really know how much it is in synch, or not in synch anymore, with the corresponding set in the file system, re renames, moves (and perhaps even copies), and then also and first of all, completeness of sub set; for me, that's the principal reason for which my concepts have shifted to "integration of an outliner into file-system-based PM/file M", instead of desparately trying to do PM within any outliner, only to never get by re numerous "file system replication faults" within the outliner. In other words, a combination of both, db-based outliner, and file manager, is overdue, but any such combination should preserve the life character of its file system representation.

As said, I did not grasp how to search for tag combinations, but the special tagging features you list are quite impressive (tag icons, plus item icons? well, that's too much fuss for me, I like it neat, but then, automatic grouping according to their respective source tree/subtree(?), this should be of high value indeed; type-matches I didn't understand; tag list vs. tag-search, and by tree: if ever I understand how it's done, I'd probably very warmly recommend RN for this reason alone)

Folder tags
Above in weaknesses you describe that folder tags are NOT automatically updated when items are moved, here you seem to say the contrary, or then I simply misunderstood what you said above I suppose? Again, the help file is a nightmare, and especially for these (brilliant?) tag features, it would have helped for the developer to explain in a way that more people easily grasped how to apply them.

Multi-line entries in the tree
I have to admit I did not discover this feature before, and it's very rare, and should be extremely useful; I missed it a lot in ANY of my outliners I ever used, so it's a good thing to tell people it's there. (As above: Most tree components do not allow for multiple-lines entries, so when this feature isn't there, don't count on it to get it ever; Rael seems to have made a good choice in choosing his components!)

Is there, as you say, and it's a very important feature for anybody who puts lots of items in one tree (Which, as explained, I don't do anymore.) Btw, nowadays, most db-driven outliners have got hoisting now, by peer pressure: It's considered more or less considered standard=mandatory nowadays. (Sideline: It's ironic that 2 panes (which are also available here (in Prof.)), and which are much more easy to implement, are much rarer than hoisting, whilst asked for almost even more!)

ABC-sorting of tree?
Wait a moment here? If it really was non-destructive sorting, this would be sensational, but I didn't find that feature anywhere: In every which outliner you try (and many of them offer this feature), automatic sorting of the tree, or of subtrees (sibling sort), is destructive, and I just rechecked RN: sort is destructive, as usual, i.e. there is NO alternative view in which the items would be sorted, and from which then you could revert back to the original tree/subtree. (The "real thing" would be easy to implement, though, but no outliner developer ever did it, from what I know.)

Coloring/formatting of items in the tree
In fact, that is standard (and it's very annoying to encounter an outliner that doesn't allow for it, e.g. Maple, or then Ultra Recall (but which offers a trick to do that at least... but which I never got aware of but after my having left UR, and by Paul's blog), but you say, it's rare (and available in RN) that the title can be formatted, whilst other columns in the tree will be left out of formatting. In fact, I don't know? I should open MyInfo with several columns, then try... In fact, I don't believe in tree columns in outliners anymore, it makes your data (as a whole at least, more or less) un-export (same problem with extensive use of clones), and if you really need columns, you will quickly discover (I cannot speak for RN here, but for several competitors) that the outliner's functionality with regards to its tree columns is very sub-standard (compared to db's, to Excel...), so column use in outliners might become a very frustrating experience, and most of the time, you'll be much better served with tags, or then with simili-tags, i.e. £a:500, £e:1,3, etc., i.e. encoded, simulated "fields" in the text of your items. Of course, if those columns permit numeric fields, and then search for field xyz < 500, and field abc > 15, THAT indeed would be of real use. (As said, I didn't trial RN for such functionality.)

Tree position not only to the left, and individual setting for any tree
Well, I have never been tempted to put the tree anywhere else, but "be able again, to set that option individually for any of the tab/page’s trees" intrigues me!
So a tab/file is a "page"; as said, such very particular vocabulary doesn't make any sense, but one file/tab/page with several trees? What are we speaking about here? Or do you simply mean hoisting, several hoisted sub-trees in different panes, anywhere on the screen? But that again would have been "tabs", so contradiction with your "tab/file/page" vs. "several trees". (Or did you want to say "each tab/tree/page/file" (and not: "each tab/page's trees") can have its individual setting for where the tree pane is to be positioned"?)
I'm not criticising a possible minute fuzziness in expression in a very long (and excellent) text, I just want to grasp a possible, sensational detail you seem to describe and which I might have overlooked?

"without having to actually open any one of them"
I'm perfectly d'accord with you that real info in the file name very much helps in browsing which item(s) you should finally look into (instead of having so many of them opened in vain).

As you say, it's a rare and useful feature, and locking the top row is even rarer and so useful! And I have a correction to make: Above, I had spoken of a spreadheet feature within regular content panes, i.e. embedded in rtf text, like in text processors. Whilst RN comes with a special, additional pane format which is especially for spreadsheets (and only for spreadheets), and where your expectations re inbuilt functionality are of course much more developed as with the above described minimal table of just 10x10 cells.
Of course, the question remains if it's really useful to have such an alternative, more or less "full-grown" spreadsheet application, within your outliner, instead of Excel/standard spreadsheets integrated into your outliner; most outliners don't offer such integration at all, indeed, and as for Ultra Recall, many users are very unhappy with Excel integration, via the MS internet browser it seems?, in that competitor.
But that would just be another argument for my concept, described here and in the other thread, re live integration of external files into your projects, instead of doing some "half-baken" additional spreadsheet within an outliner, "half-baken" meaning "lesser than Excel, so that if Excel had been better integrated into your outliner, you would have preferred the latter".
Sideline: You mention even Memomaster here; very few people know that program which unfortunately does not offer clones, and some other important features, but which is, in the field of "network integration", or, "as groupware", far more developed as any other outliner I ever encountered, and which for this reason is currently the only outliner that has made its entry into the corporate market.

Some weeks ago, on bitsdujour, re The Journal, I said,
"Mike, +1!

Of course, the real question is if you rely on various encryptions built into different applications, or if you buy one encryption program, e.g. "Steganos Safe", and which will encrypt some folder/drive, and in which you then store various folders with multiple files from multiple sources, which is the approach I adopted.

Both approaches have their respective advantages: It's handy to be able to encrypt some parts of a bigger outliner structure, working in the outliner, but then, the problem with this approach is that anyway, you will need some encrypted container, too, for all those files that ain't handled by a specific encryption-able application, so the container is there, anyway, and then, why not use it for everything you want to be encrypted?

Once it's opened, everything work smoothly, once you put your ordinary files into your regular folder, your files-to-be-encrypted into the container... and then, .lnk files pointing to those... into your regular folder!

That way, your applications "think" you've got all your stuff together, and access all files in the regular way, without disturbing your "user experience", but in fact, sensitive files are hidden from your wife, or your boss, or perhaps even your Government.

This "replacing the actual files, in the regular folder (structure), by .lnk files pointing to some encrypted container", is a very good means of encrypting everything you want, from all programs, AND avoiding multiple encryption engines, multiple passwords, etc.

Of course, you need quick means to create (and correctly name) the .lnk file, but with a macro, you can even replace the original file, in the original (unencrypted) folder by the .lnk file, and move the original file into the encrypted container. All this works fine in everyday life once it's set up.

And then, the question remains what backdoors might be implemented in such containers, for the Government... ;-) (but neither for spouse nor for the boss)"

So much for "full encryption of the whole db", but I acknowledge that a manager "on the road" would very much like to have the full db encrypted, and without thinking about it.

But here again, I'm intrigued by your mentioning special RN terms, by saying "and finally, the integrated so called “page transfer” AND “floating tree” feature, that both allow one to transfer
in & out items on either a per tab/page basis (page transfer) or an individual per folder notes section basis (floating tree)
from & to another notebook (actually up to & from 3 others open simultaneously)" -
So now we've got "notebooks" here, different from files/db's, different from "pages"... - well, that's not a really neat concept I dare say, and of course, I don't understand what this "page transfer" here would mean:
Are we really speaking of several independent trees in one db, and a "notebook" would be a db? And how differe "pages" and "trees"? Above, "pages" were different from items, though...
I'm lost! (Ok, you say it further down, "pages" are trees, as I had suspected, but then, this paragraph here gets even more impenetrable.)

"ability to merge multiple notes into a single output file"
No criticism here, just let me say that any outliner which does not permit this, would be totally unacceptable.
Sideline: As described in my coding thread, you need this feature to bring your code (i.e. split up into multiple items of various "indentation" (in fact hierarchical) levels) into compiler-readable format; hence the need (but no problem) to "outcomment" your tree entries (the entries, not the respective contents). Now, Ultra Recall offers a very special thing where all your item contents, i.e. without the titles, are shuffled into one target item (from which you can export of course), so this would mean, in theory, an even more elegant tree, since you don't have to outcomments its entries in UR. Now the irony: As said elsewhere, UR is one of those rare outliners which are totally unsuited for programming, since it lacks "global replace" (and even "replace everywhere in this sub-tree"), with a developer who's unwilling to implement that almost ubiquitous feature. (Nothing to do with RN, hence "sideline", but it's noteworthy. As for RN, as you say here, it produces a single output file with which then you can feed your compiler!)

Custom shortcuts for every command you'll ever need
Very handy, and as we've seen above, thanks to Scott, Rael even did the "extra mile" here, thinking about tricks his competitors didn't think of (and which even I, snooping around for such "extras" though, didn't grasp).
Just let me repeat what I said above: It's by thoroughly checking the virtually endless key assignment table that you will discover multiple strengths and unknown features of RN, and which you will not become acquainted with just by browsing the menu.

"is yet so slow of being rid of some of its still existing usability-bugs"
Nothing to add here, it's WEIRD that a program that good in many respects does such ugly things like filling up its history with endless lists of unwanted transit items, and more, and is riddled by a help file which literally hides its multiple strengths (sophisticated tagging details; let's abstract from the obviously substandard internal tag M by which with 1,000 tags, you can bring down this program).

As you see, I didn't want to lessen the importance of your fine review, I just wanted to put those features into a more general perspective, in order to value them by competition and what's possible in general. And it's evident Rael should do some long-overdue homework, and his offering could quickly become number one among current offerings.


After writing the above post, it occurs to me that my first post here was too abstract and not helpful enough.

Why do I muse about first part of a routine, and second part, and then the interconnexions of both? (Have a short look into the first post here if you begin reading down here though.)

Because good programming style is to abstract, to combine, AND to stay easily readable (i.e. a little bit the contrary of what I do in my writings here).

Let's have some real-life examples.

You do a typical, noob AHK script. There's a trap. You'll probable use the construct

#IfWinActive, some program
then all your key bindings there
#IfWinActive, some other program
then all your key bindings for that other program

and so on.


In many cases, you'll have similar routines, triggered from within different scopes. Ok, you could do triggers pointing to routines, but even then, even for the trigger scriptlets, lots of similarities would be spread all over the place, instead of being held together, i.e. you'll need to send (sometimes, multiple) attributes (unfortunately, necessarily by variables, in AHK, and this means that if you have ONE key assigment in the form

if ( winactive("abc") or winactive("def") ... )
else if (winactive ... etc.
else if ...

and then trigger ONE routine, or just a few routines, for similar tasks, you'll get much neater code, here where in most cases, most attributes will be identical (except for the variable indicating from which applic that other routine was triggered), and also "on target", i.e. for those routines which then handle lots of similar functionality, with just some little differentiation depending on the trigger source.

After this intro into "Key, then scope, instead of the other way round, for AHK", i.e. the real-life example for the trigger, let's have a second real-life example, for the trigger-and-target this time.

Let's imagine you do your own little file manager, for PM and such, with 6 or more panes (as they are in some ready-made file managers available out there). Trigger would be selection and then Return, or Click or Double click, in those 6 panes or so; let's imagine such selection, in some panes/list fields, would trigger external display, whilst other such selections would simply change the content in neighbouring/subordinate list fields.

So what will you do? Do like an AHK noob on his first day, and do 100 scriptlets, all VERY similar to each other? I hope not!

Instead, you will gather all those different trigger situations in part 2 of your routine (part 1 containing variable declarations and such stuff); if this kind of trigger in that pane number, your little program should do this or that suite of commands; you assign variables which are then checked for in part 3 of your routine.

There (again, this is a real-life example for what I exposed in post 1 above), you'll do a second if, if else, if else... (or condition / when / when... (not possible in AHK) structure, and indeed, as explained above, this second (part 3) if structure is NOT identical or quasi-identical with the similar conditional structure in part 2 above.

Since, as explained, those triggers are very similar, but there could be several groups of commands; of course, instead of having just one part 3 of the routine, you will instead call external routines, "sub-routines" from there, either if those "executive" routines are rather long on their own (but as explained in my previous post, why not do a a 10- or 12-pages routines, as long as those pages are clearly distinct?!), or if you trigger routines which must also be accessible from other triggers (= keys or routines).

In that second case, there is no choice, and you'll do them as separatine routines of course (and there are cases where first you do that "routine" as page 7 of 12 first, within such a bigger routine, and it'll be after writing this routine that it will occur to you that page 7 should be accessible from elsewhere, too, and then you simply cut off that page to an external subroutine; in this case you'll check for the variables that will be declared in that new external subroutine, in order to get that all the necessary information from its trigger routine of which it was once just one part; i.e., as said above, fractionizing multiplies headers (which can become rather extensive), and if you don't need access to some routine part from the outside, doint it all in one big routine helps with minimizing unnecessary headers).

Back to our tripart routine: Now, in part 3, you check for every variable you will have created/set up in part 2, and here, the similarities between different blocks could be totally different from similarities in part 2: Just some examples, different file formats, different target panes, and as said before, even, instead of showing files, just listing files.

Here in part 3, you'll group again, according to such similarities, but the items in your conditional structure will probably be in a totally different order from the one they, or similar ones, were in part 1. And of course, you will spread up your blocks into different pages here, and this could even determine the order in which you put your blocks, i.e. why not do if var1 = 3 or 4 or 8, else if var1 = 1 or 2 or 5, else if var1 = 6, else if var1 = 7, etc. -

just because those 3 and 4 and 8 are quite similar and easy and can be treated all together on page 3, whilst variants 2 and 5 will be treated on page 4, together again, whilst 6 and 7 each will nead, separately, one page of their own; if afterwards, you'll see that 6 needs its own subroutine, you will not leave the call for that subroutine, alone, on page 8 or so, but you'll do the else if var1 = 6 on page 3, before the "longer" code blocks.

Sideline: It's always a good idea to discard simple things as soon as possible. E.g., I never write, if x ... then 10 lines, else, return, but I always write if x = 0 (or input = zero or something), return, and then, without else, without indentation, the main structure:

if a = 1
   10 lines here, all indented


if a = 0 ; even if it's very improbable
here 10 lines of main code (no braces, no indentation)

Accordingly, I check as early as possible for values that would invalidate other structures, so as to not even run parts of those structures, to then be aborted anyway.

Now a sideline: You could do this tripartite 1-2-3 for heading, set-up, execution, with goto's instead of variables, or at least you could replace lots of variables by such goto's.

As said before, don't be afraid of goto's, if their targets are on top of above-described pages 5, 6, 7, no problem whatsoever: Goto's don't make your code spaghetti code PER SE, and functionally, there is no big difference between target-pointer-variables and goto's - except that in my multiple-spreading variable-if-structures, I don't need then further goto's in order to leap over following blocks, whilst in a goto structure, you will need to pay attention to do that, in order to get OUT of your goto target, since if you do not pay that attention, any goto will continue then with the following goto, and so on, and in 99 p.c. of the cases, that's presumably not what you intended it to do (and which an if-else if structure does not)! So, pointer variables are both much more flexible (ok, that could become a trap, your, by laziness, interweaving several if structures...), and neater.

And, of course, most programming languages have abolished goto's, which would become an obstacle when translating to code in some other language. Obviously, those same extremists that abolished goto's, did NOT find a way yet to abolish pointer variables, i.e. can't stop you from (mis)using integer or yes/no/true/false variables as pointers being even better goto's than original goto's ever were.

Use such pointer variables to structure your code, and it will become easy to write for any beginner, and will be perfectly readable/neat, maintanable, etc. It's a good way to code, and that's why it was worth it to better explain it to you than in post 1 here.


What about my question at the end of my previous post? Is there any editor where you could suppress search hit lines containing search term 1, which are NOT followed by hit lines containing search term 2? There are many occasions where such an editor would become more than helpful...

(As said before, rtf formatting of your code is so extremely useful that I would not switch from outliner to editor, for writing code, but many people will not switch from editor to outliner, but would switch to a really better editor than their current one, and this feature would make all the difference, as explained above.)

On outlinersw, I was censored and threatened to be thrown out, for being too harsh with RN. As we all can see, and in the absence of a RN forum, its developer (who, as said, does not ignore this thread) does not see any necessity to express his views/intentions re his program which e.g. by its more than amateurish history function is almost unusable.

Folder Tags
Without contradicting you (and without having trialled this feature), I think that additionally, the behavior you describe, or at least a similar one, could be of big benefit.
In fact, RN does not have clones, so when you move an item which automatically got the corresponding folder tag when it was created, that item, by this "ancient" folder tag, has got some info of its "origins", or of its original/alternative context; of course, this should be made evident in some way, e.g. by adding a "From " to that original tag.
So what you describe is just by sloppy programming, but something in that line, and better thought-out, would be welcome indeed.

Go previous in same file, not working trans-files
As said, the (intra-file) history is unusable, so I've got some doubts about "Previous/Next" here, too.
History-for-files is easily done by external macro, for RN files, and for every other file.
The intra-file history should work, since for external macros, it's often impossible to replace the missing/unusable internal function.
Of course, it would be even better if there were several histories, one overall, one for each file, for the items visited there... and, most important, some history where your key pressing only would enter item (and which would englobe every file of course), in order to put just those items in which you'll need to visit again soon... and then, that list field should be done in 2 columns (or 3 if you like to indicate the corresponding source file, too): the very first column being for a number: You press 3, and the program shows item 3 in that particular list: THAT's user-centered gui creation...

Selective bolding of PARTS of table entries
The same problem persists with trees in outliners, why? Because almost all tree components do simply not allow for special formatting of just one word of entries there, it's, for any formatting, all or nothing. Similar for spreadsheets, Excel being an exceptions (and I know of one tree component that permits that, too). So I suppose that the table functionality of the rtf field component used in RN does not permit it, and which such limitations of the respective component, both developer and user will then have to live (until the developer throws out the component) - cf. abysmal Ultra Recall's MS rtf component...

Necessary scrolling in tables
As before, but I could imagine the developer could spice it up, i.e. add the functionality missing from the original component as it's delivered. This being said, I more and more believe that big tables should not be done in an outliner, but in Excel or similar, and that PM/project files gathering should be done from a higher level (see my thread on that, derived from this one), than from the ordinary outliner tree. So in my concept, tables in outliners are good for 10 rows x 10 columns, not for anything much more, idem with other add-ins.

Missing tagging scalability
Very interesting, thank you! This is a typical program's fault you'll never get to know just by trialling, and slow-down and crashing even in the 3-digit range is more than a pity!
I'm not sure if I should follow your try to see it from the bright side: I always whined (even here) about the unmanagability of endless tag lists, but then, the user should have the freedom to apply several tags to any item, even if that means a 6-digit number of tags; that's why I complained about the weirdness of the tagging function in RN to begin with, in my outlinersw post on that matter and here, e.g. not grasping how I'm deemed to quickly and easily do a) tag combinations and b) manage multiple tag sub-categories. Of course if even some hundred tags make this program unreliable, well, no need to discuss better tag M for thousands of tags...

From your "page" I see that RN, just like MyInfo, thinks it advisable to introduce weird non-standard denominations. Of course, a tree with its contents should be called a file if that's its technical organization (as it is, in both programs), and an item should be called an item; to call a tree/file a "page" is outright ridiculous (of course, I'm not criticising you who just wanted to be faithful to the particular vocabulary), but objectively, it's nuts to call it this. (And in South Africa, they speak English, which is not the case for Bulgaria, so here it's not a possible case of bad translation to which then the developer stuck for reminiscence reasons.)

So much for the "Still bad"; I'll look again into your incredibly rich and informative post in some days; if more posts where like yours here, this forum's usefulness would be multiplied.

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