Messages - peter.s [ switch to compact view ]

Pages: prev1 ... 14 15 16 17 18 [19] 20 21 22 23 24next
Well, posting general considerations in a DO fanboy thread was naïve, since it could only be met there with admirers' blah-blah, not addressing the underlying conceptional considerations. So I take the liberty to open a new thread for those, be there some arguments to come or not.

Unchanged, that other post:

Features, not benefits

Andus is right, and I want to spit in the soup anyway, or so it might seem to some.

- Update scheme: I think 2007, 2011, 2014 (full 3 years between 2011 and 2014) is acceptable. It's just that people buying on bits (or worse, paying full price whenever the current major version has been on the market for some time then) are a little bit fuc**** up, since asking price is high, update price is high, accordingly, and on bits (that's my impression at least), this prog tends to be offered whenever next major update, without being imminent, is not THAT far away: was it spring / early summer 2013, last time, i.e. 2/3 into the "life span" of the then current major release? And this means, if you want to profit from this prog, release of a major update is the time the buy (full price, unfortunately, but full price for 3 years' it being up-to-date is better than paying half-price or more just for 10 months, right?).

- Scriptability: Well, that's been offered before, and also from XY, SC and some others. As I said before, I don't see the real value in a given file commander's scriptability, since I've got an AHK macro system which gives me access to almost any "command" I am in need, or just in want, of, from ANY file manager today, and also (here I have got some more work to do, though), from "anywhere where it applies", i.e. it's possible to access the respective file M functions from within another applic, from within there would be an "interest" of having access to the respective file M function, i.e. without switching to your file manager, and then triggering the relevant commands from within there.

So this is a common prob of all those scriptable file managers: Finally, they let you do lots of elaborate macroing, but from within that given file M, and I prefer it light, smooth: Why would I have to bother with a file manager, or worse, with a specific file manager, when I can do the work in a much more elegant way? (= Any file manager is an additional access gui to what you want to do, under the hood, so being able to have it done under the hood, without getting by a file manager for that specific task that arises within your REAL task, the one you are doing in your main prog at that time, IS a much more elegant way to do things, with no file manager coming into your way.)

And as said, I do such things from ANY file manager even today, so for me, even FC XE does not have any limitation, e.g. compared with X2 (I don't own DO but don't see any additional functionality in there): from both (and several others), I trigger the same AHK commands, instead of relying upon what one file manager might be able to do, and another, not.

- As said before, there is additional functionality both with XY and with DO, for pic browsing, and I use XY extensively for this, but at the end of the day, hadn't I my license to it, I'd do it with XN or other freeware, and Fast Picture Viewer is also there, as the superior prog to anything else (I've been extensively using the free version for years, because the version has been 1.95 for years now (or so it seems to me), and I'd be happy to buy 2.0 (but would have been extremely unhappy to buy 1.95, just some months before 2.0 came out. In other words, the developer will have prevented many prospects from buying, by having upheld his 1.95 version number for years or so now, and I very much hope this will change soon, i.e. he will bring out 2.0, finally.)

I also said this before, general preview, both with XY and DO (i.e. not only for pics), seems to be superior to their competition, but then, in order to be fully functional (and unparalleled), DO's preview pane has to be spiced up with an external add-in that costs (if I remember well) 40 euro, i.e. some 55 dollar. Also, and even if you're willing to pay for that upgrade, too, you'll realize that most of those additional formats you just bought are legacy formats, often from the VERY early days of personal computing...

So here is a viable concept but which lacks in realization quality for today's needs - many current file formats you would be eager to have preview access to in your file manager, are simply not available here (and I don't have the impression that there is much development going on on that subject, either).

- Also, in both DO and X2 (not XY, as before: they have their own, proprietary format for that, and in TC, it's even more weird, with their maintaining the venerable descript.ion format), the ADS-NTFS-format meta data concept (which has been dumped by MS) has been upheld (and probably, it's even fully interchangeable from X2 to DO and vice versa, but that's not for sure in every possible circumstances), but both are unwilling to discuss specifics: Whilst XY just isn't helpful, DO's lapdogs, in their usual style, even become rude when some paying user (not me) dares to bring up the subject. So, at the end of the day, it's more than doubtful that ADS file attributes could ever be an argument pro DO or pro X2, since you will never know what are their respective intentions with that, let alone those of MS.

- I said this before: File managers like XY, X2, DO, SC, etc. try to justify their price by integrating some additional functionality into them, e.g. batch rename, file search, and even some file synch, duplicate search, etc.: As said before, most of the time, there are (even free) tools available that do this even better (= with more options to choose from, e.g., i.e. more fine-tuning allowed), and so what really remains from this, is their argument that it's more convenient to have it all in one applic. Well, I don't share this pov, for a double reason: I prefer having the very best tool available for any given task, not some tool from the file manager but which more or less limits what I want to achieve; and even those tools "integrated" into those file managers are often just triggered by the file manager in question, appearing then in their own, additional window, which means they are not as fully integrated into the file manager as they try to make you believe, and then, if there is no full integration anyway, why not trigger, by a shortkey, the additional tool of your choice to do the work in question? Here, the promised convenience seems to lie in the fact that most users don't have immediate access to anything, by simple shortcut and/or custom menus (AHK again), but would have to fiddle with opening those additional tools, instead of them being instantly available. So, for me, this argument of "convenience of having all (???) needed tools in one tool box" falls flat, all the more so since, again, at least in some cases, non-file-manager-dependant tools of the same kind are MUCH more sophisticated than the (more or less) "integrated" ones.

- So, from my pov, it's just looks, and yes, DO's pretty, and from that, perhaps it's not that bad an idea to buy DO 11 LITE on bits when it reappears there, since that would add another file manager to your collection that might be a pleasant-looking replacement for FC XE (or anything else), for triggering your AHK commands from there, like you would do it from any other such file manager. Just don't expect file managers to be "complete" in any way, since even the most expensive ones are just compromises for anything they do. I did buy that bunch of file managers over the time for lack of understanding then that even by being willing to buy them "all", and at any price, I would NOT get real good stuff, and not even by combining their respective highlights, by switching between them. And in conclusion, I seriously think that expecially fervent DO advocates did not yet see this evidence:

You will have to build up your own toolbox; by waiting for some perfect toolbox, comprising it all, and delivered to you, at any price you're willing to pay, you'll just grow old - and that includes DO, notwithstanding their snooty pretending otherwise.

And now some additional remarks, re that 1001st DO thread:

"just a pint of beer frequently cost >= $15 USD"

As we all know, Norway (the country of the poster of that "argument"), as well as Switzerland, has highly inflated prices, AND highly inflated wages, so almost ANY price will be considered "cheap", in direct comparison with local prices, and with local wages, in those countries (and in Oil countries: Kuweit, etc.). BUT THAT IS NOT THE POINT. The point is, what does a 100 bucks sw does MORE for you, than, say, a 0 bucks sw? I.e. it's all about comparing apples with apples, not with the purse of your Lady.

"Auto filters on folders?  That's just plain cool."

Of course it is, but then, again, this automatic filtering of files should be accessible from within your main application, automatically presenting you a dataset reflecting what you're doing in your real work environment: Any file commander is just INTERFERING, badly or slightly, but interfering, with that "natural workflow" which in most cases, today, has NOT yet been realized for most people.

Of course, for people JUST doing file M, the "mileage" varies, but for most of us, a file manager is something that gives us access to some "material TO" our real work, and for this task, today's file manager do NOT "deliver", or in a way no manager who's in optimization of business processes, could ever find even reasonably satisfying. (Developers are more or less aware of the fact, so they invent "virtual folders/collections/whatever", but they lack the imagination to do this in any real useful way.)


We've got a similar prob with MS Excel, which is misused by legions of managers for "data crunching", "data analysis", as a data BASE, and so on, more appropriate sw not being (financially, organizationally or intellectually) available (for most people), à la différence près que in file M, there does not even exist such an ideal solution... because here, the ideal solution would be complete integration of all relevant file M functionality into what you're REALLY DOING. And it seems that this paradigm is more than most people's minds can cope with, conceptually, hence the blatant absence of relevant solutions.

Thus, DO might be "best" or "among the best ones" within very low confines, within a real flat world.

"Code Browser" (freeware) has some good explanations on different folding paradigms.

But I doubt ANY editor is perfect for managing text snippets (and even for coding) since they all seem to present that common prob that you have not only to code / mark up the folding point (begin=not hidden title of the hidden text part), but also the end point of that hidden structure, again and again, and it does NOT seem to be possible in any of them to define ANY "begin new part (hidden except for its title line)" code (= begin), as the END of the previous hidden structure, so there is a lot of (imo) unnecessary "hide mark-up" to do here.

On the other hand, most 2-pane outliners perfectly export to plain-text .txt files, so why not manage your code within such an outliner and have the exported text file compiled then; this makes available rtf formatting within the "work copy" of your code, which I find extremely helpful.

All the more so with text notes: Almost any dedicated 2-pane outliner does the M of text notes in a perfect way; why bother with the very limited capabilities of editors (folding or not) instead?

Of course, a 1-pane outliner would often be the worst solution: It lacks many capabilities of editors, and it doesn't offer the clarity of a 2-pane outliner either (which will become very important if you have hundreds or thousands of such items (or folded text bodies within your .txt file).

Again, a capable pc can export thousands of items of a 2-pane outliner into the corresponding .txt files within a second, and with a macro, you can automate this transition from outlining to file-for-compilation (which is not even necessary for text notes, compared with source code), so why clinging to bad editor solutions when there are better, i.e. more appropriate ones?

This being said, I'd be interested in knowing a folding editor in which you would just do some special char before title lines, and which would then fold anything else (folding editor, I said, i.e. not speaking of KEdit and such here, bec there is a prob with those whenever you then want to see the text underneath such a title line, and just that part).

More info would be more than welcome.

General Software Discussion / Re: Are Tables Required Or Not?
« on: February 27, 2014, 02:33 PM »
"After reading superboyac's excellent treatise on "information collectors""

Could you share the link please?

"how does one handle the data normally contained in tables"

Well, that would depend both on the origin of the data you normally would have put into the table, and on the USE you ideally would have made of that data (if it were stored in a table) - from that point on valid advice would be possible, not without that knowledge.

I'll give two examples:

- some IMS come with "columns"; unfortunately, it's a trap to put data into those "columns" = item attributes, in most cases, bec such data will not be exportable ever after, or with difficulty

- if you don't need "live", frequent writing access to your data, why not link an item containing a .jpg of the table, to the original table? (of course, broken links probs could then occur, without proper planning: If you don't have hundreds of such external tables, putting them all together in just one directory would be preferable to splicing them up into numerous folders-by-context (= you would organize context within your IMS, not try to double it within the file system, for these)) (also, for memory/fast display reasons, is Excel mandatory, in such a coupling, e.g. for need of elaborate data processing, or is it simply a set of un-touched values, where tiny MS Works or other simple spreadsheets could be linked instead? There might be free offerings for very simple tables) (Also, a short macro could automatically load the respective original file, whenever you then display such a "special" item, even for frequent writing access, if needed; in such cases, even the copying of the "pic" of the table into the item would be counterproductive, since most of the time, the pic would be out of sync (or synching would be too much fuss) - here, just the item's title, in the tree, could contain the link, which would omit the intermediate step of first going to the content field of the item, then to trigger the link only)

As said, it all depends on the origin (and extent) of the data, and your typical access to it; just for reading of seldomly changed data, a pic of the original file, plus the link to it, would be best.


Quite naturally, I'm very interested in this type of projects. Unfortunately, your,

"Most who use English, do it unsuccessfully."

applies to yourself, and for a native speaking English writer, that's hard to beat.

Perhaps you should not write in 5 languages but in 3 only, like I do? It's all about preserving that at least your native language continues to sound right. (For the really gifted, even 10 tongues might not be a prob, but that's not us, obviously.)

Just my 2 cents.


As for AHK's ListView, there are some alternatives available within the AHK framework, written by excellent programmers. But then, I don't see the necessity for any list views here, it would all be about text processing by replace functions, and for this, heavy duty, AHK is not ideal to begin with. And then, translation tools have been on the market for a very long time now, and with astonishing little success, results-wise: So, before speaking of most income being given to charity, and before some programmer willing to script the needed function set for free, there should be some evidence why, all the more so with very little scripting work said to be necessary, the product would be able to surpass what sw houses with sometimes big manpower have tried to succeed in, more or less in vain.

Just my 2 cents, again.

Pages: prev1 ... 14 15 16 17 18 [19] 20 21 22 23 24next
Go to full version