|
|
Post by Robert on Mar 19, 2023 14:35:25 GMT -5
In the course of testing the new beta with scroll bars, I happened to notice some of my files in FM that didn't have line counts. The usual way to get the line count is to issue an L or LL line command. But, that does a complete recount of every file in the range, even ones that already have a count. If you had a lot of files in the range, it could take a good while to recount them all.
I was about to suggest a new FM line command of U to mean "update line count" which would only be applied to files without an existing count.
But, I found that U is a one-letter name for "PURGE". This seems kind of odd to me. How many people are going to think to use U to mean PURGE? It is very counter-intuitive.
By contrast, everyone knows the FM and edit command of D for delete. It's not clear to me why we need two completely different command names to accomplish exactly the same thing.
My suggestion is this:
1. Remove PURGE and all abbreviations for it from FM. That leaves D alone to mean delete.
2. Reword the confirmation message to say "OK to Delete?" instead of "OK to Purge?"
|
|
|
|
Post by George on Mar 21, 2023 8:12:30 GMT -5
Robert: PURGE ignores the "Delete to Recycle Bin" and always does a permanent delete.
Even then, I agree that PURGE is really pretty useless.
George
|
|
|
|
Post by Robert on Mar 24, 2023 13:13:29 GMT -5
I have to agree - a notable event in itself, seeing that I am the one that told you years ago to distinguish Delete from Purge. Now years later, the feature I myself talked you into, I can barely remember. Sigh.
Since you seem to agree that Purge is an issue, I have a suggestion that should help, and shouldn't be too hard to do. This is a revision of the points above.
1. Remove PURGE and all abbreviations for it from FM. That leaves D alone to mean delete. It also frees the FM line command of U for future purposes (which I will get into on a future day).
2. Remove "[x]" Delete to Recycle Bin" checkbox from the General Options GUI.
3. As far as I can remember, we have always had a "delete confirmation" message. That would continue. However, I believe its wording AND functionality should be changed a little.
Right now, this box says,
SPFLite Recycle/Purge
OK to Purge: C:\path\file.ext
[ Yes ] [ No ]
I believe it should look more like this:
File Delete Confirmation
Choose DELETE OPTION for C:\path\file.ext
[ Delete permanently ] [ Recycle ] [ Cancel ]
This way, it's no longer necessary to set (or, REMEMBER) what the checkbox is set to in the General Options GUI. You can decide at delete time what to do. And, since you ALREADY had to make a decision at delete time, this add no additional burden. The only user impact is the former Y/N reply gets changed. To me, that is OK, because the "Yes" reply has been ambiguous, like "OK, tell me again what YES means?" Now, there is NO ambiguity, because the user says exactly what THEY mean, right when it needs to be specified.
Thoughts?
|
|
|
|
Post by George on Mar 25, 2023 8:37:46 GMT -5
Going to have to add stuff to my custom MSGBOX function to handle custom Button text. Better to do it there than having to make up custom dialogs for stuff like this. Makes it easier next time.
George
|
|
|
|
Post by Robert on Mar 25, 2023 9:11:39 GMT -5
I had a thought I wanted to share. This is an OPTIONAL part, but you might be interested.
On my cel phone, when I copy some files (usually music or lyrics text), the Windows Phone Link causes a message to come up: It shows the kind of Delete/Cancel type thing we have been talking about, plus one more.
It says in effect, "Do you want to take the same action for the remainder of the files? Y/N"
Think about what happens when I put D on 10 lines, or if I used a D/ on the FM screen. I will get the delete confirmation message 10 (or more) times, which I then must ANSWER 10 (or more) times.
Wouldn't it be nice if there were a checkbox on the confirmation popup that said, "[ ] take the same action for all remaining files?"
You would always show the checkbox empty, so they'd have to specifically check it to opt-out of the constant delete confirmation messages.
I suppose you could even "confirm" the confirmation opt-out checkbox, but even I would hesitate to go that far.
That's the idea.
|
|
|
|
Post by George on Mar 25, 2023 12:55:32 GMT -5
Robert: I think not. I'm trying to avoid having to create custom dialogs, and adding a tick-box is a custom thing. I'd like to keep it as a MSGBOX type, with custom button text, and more than 3 buttons is simply confusing.
George
|
|
|
|
Post by George on Mar 26, 2023 12:39:26 GMT -5
Robert: How about:  George |
|
|
|
Post by Robert on Mar 26, 2023 13:04:33 GMT -5
That is a nice dialog. It adds new functionality, avoids use of a checkbox and is quite readable. It also identifies the state data, something I would not have thought of.
However, it still uses the "purge" terminology. If you maintain the Delete vs. Purge concept, then that is sort of a "fourth" variable, which would have been represented by a checkbox.
Maybe the issue is just one of terminology. What does "purge" mean, anyway? Does it mean delete? Or, delete in case some GUI checkbox is enabled? Or recycle? I think part of the problem is the vagueness of "purge". I don't really like that word.
Suppose we looked at it differently. Instead of "removing" the Purge command, how about renaming it to RC for "recycle"? RC is not a command name in current use (and it allows for block mode as RCC).
Then, take your popup above, and everywhere it says "Purge" replace that with "Recycle" or "Move to Recycle Bin".
Finally, make a similar popup for Delete, which then will ONLY use the word "delete" and NOT "purge".
That fully covers all the possible use cases, eliminates the confusion of "purge" and gives users the ALL option, without requiring a checkbox either in the Options GUI or in the popup.
And, it still leaves "U" available for a new command.
|
|
|
|
Post by Robert on Mar 26, 2023 13:24:00 GMT -5
Hmm ... just wondering ...
If I have a file with state information, and ask SPFLite to recycle the file, what happens to the state data?
You just delete it, right? You don't move the state data to the Windows Recycle Bin, do you?
After all, Windows knows nothing about SPFLite, and couldn't possibly know what state file to restore if it even the capability to do it, which it doesn't. Even if a user were to figure out which state file to pick (a neat trick in itself), what would be the consequences to the integrity of the state system? Seems like "instant state corruption" to me.
I don't recall reading anything in the Help discussing this situation. In any event, if you are doing a Delete, mentioning the state file makes some sense. For Recycle, I don't think there is any need, because (unless I am mistaken), a Recycle operation necessitates actual deletion of the state.
I am very interested in hearing what you have to say about this scenario.
|
|
|
|
Post by George on Mar 27, 2023 8:24:12 GMT -5
Robert: I don't like keeping two different commands to perform a delete, just one with the "Delete to Recycle Bin" option is sufficient. I can certainly alter messages to reploace Purge with Permanently Delete (or whatever)
And displaying the State filename was always supposed to be there, except for a lurking bug I corrected.
As to STATE: Delete will also delete the State data, both are handled the same way based on the delete option.
If you want to restore fully, you'd have to restore both the file AND its associated STATE file. If you don't restore the STATE, then you get no message, you just don't get any state data restored.
George
|
|
|
|
Post by mueh on Mar 28, 2023 7:40:38 GMT -5
George: V3.0.23086
If D U and D are set as line cmd's the files are deleted with action of last cmd .
DEBUG log "which msg" and Prompt action is the same for the 2 file names .
Thanks
|
|
|
|
Post by George on Mar 28, 2023 8:59:12 GMT -5
MUEH: Ack! Too many revisions of the same few code lines. Corrected.
George
|
|
|
|
Post by Robert on Mar 28, 2023 12:34:34 GMT -5
I have to temper my objections here, since you did in fact do mostly what I asked, and after a few bug fixes it seems to work. I don't want to seem ungrateful.
However, I could still wish the form were a little different.
I can, up to a point, see using D U to unconditionally delete a file. But, if I want to unconditionally delete files from one point to the end of the list, I have to say,
D/ U
Do you honestly believe that this is a "good" way to type an FM line command? Doesn't it seem that having U as an "operand" that is separate from the D/ part is an awkward way to do it?
Allow me to suggest an alternative that won't break things. Suppose we adopted a "naming convention" - and that's ALL it would be - that FM line commands having some kind of "extension" had names that ended in an "X". So, instead of D and L having a U "operand", you have the command DX and LX as "extended" versions of D and L. The "extended" feature is that they are "unconditional". (This wouldn't interfere with the X/XX command, since it doesn't need to be extended in any way that I can think of.)
That way, you would have "D" and "DX" commands like this:
D
Dn
D/
D\
DD
DX
DXn
DX/
DX\
DXX
Same with L and LX.
Don't you think that looks better and makes more sense than D/ U etc. ?
|
|
|
|
Post by George on Mar 28, 2023 13:20:33 GMT -5
Robert: Of all the FM Line commands, there are currently 13 commands (a total of 40 variations of them) that accept, or require an operand, separated by a space. You have simply ignored all the long version aliases of the commands.
So a line command operand is not some new coding idea being introduced just now, we've had them for years. Do we now go back through all these and start adding an X suffix to all these?
As to not 'breaking things'. The U operands were added without breaking things, they utilized the pre-existing support for operands.
If the current style supports E3 .TXT to open 3 lines in Edit using Profile TXT, what on earth is wrong with D3 U to permanently delete 3 lines?
You want to add a bunch of new commands, modify the parser, add stubs for the .X command versions to setup for the extended version, and then pass control to the old non-X version. This may not be 'breaking things', but right now it would be a totally un-needed effort, all in aid of making it suit your sensibilities for how line commands should 'look'. Even though everything is working right now.
If what you really want is to step back and re-evaluate and re-design the whole FM Line command structure, then do so and propose a detailed design for it. What you have here simply asks for more bolt on kludges to an area that is already overburdened with ad-hoc, quick and dirty additions.
You're asking for a make-work project that buys nothing other than introducing yet another coding scheme for line commands that you think 'looks better'.
George
|
|
|
|
Post by Robert on Mar 29, 2023 12:47:00 GMT -5
George, I know that discussing, much less arguing, points like this is hopeless, but from what you wrote it's like we are on different planets. Our perceptions are just SO far off.
13 commands that accept operands? I only counted 10 of them as documented, and 6 of those are merely the .profile type - a thing I despise and never use. (That's why I proposed EFT, if you recall.) I absolutely NEVER use .profile operands and NEVER have. Any argument you might make that counts these falls on (my) deaf ears.
You've had command operands for "years"? The "?" operand on BACKUP and the cmd operand on W have existed for lest than one year - the W command in its current form has only been around for a few months. The other two are of no consequence IMHO. That eliminates almost all of the examples you are using to support your argument. Your complaint here is little more than an exaggeration and a non sequitur.
Then you come with this absurd statement, "Do we now go back through all these and start adding an X suffix to all these?" This remark is so utterly ridiculous it is taking all of my restraint not to respond with the deepest depths of profanity. Let's just say I am highly offended by this. Must you ALWAYS respond with such ridiculous extremes to try to show me up, when I NEVER ASK FOR SUCH A THING ??
I wanted a "BUNCH" of new commands? I count 2: DX and LX. Where is the rest of this "bunch" you are claiming?
"If the current style supports E3 .TXT to open 3 lines in Edit using Profile TXT, what on earth is wrong with D3 U to permanently delete 3 lines?" What's wrong with it? Everything. (I am tempted to say, what's wrong with it is that it sucks, but that is beside the point.) Where do I even start?
If you like, go take a poll. How many people actually **USE** profile overrides like this? How many times do YOU override a profile name when editing? I would bet real money that the answer is somewhere between zero and never. If you think this trumped up example is going to convince it, well, it just ain't.
"I want to modify the parser." Please. I withdrew that after you whined so much. I went out of my way to say that the "X" was a naming convention ONLY. I have to say it: SHEESH. Either you can whine about the # flag requiring a change to the parser, OR you can whine about an X naming convention - BUT NOT BOTH. Make up your *** mind. It's one or the other.
*I* want you to write "stubs" for 'extensions' to two functions? It would take vast effort for me to care less HOW you implement it. What is it to ME whether you create "stubs" or just take 15 lines of code and clone it with a different function name and change two lines.
So how do you end all this? If I don't agree with you, then I "must" (in your eyes) want things like this
"re-evaluate and re-design the whole FM Line command structure:
"asking for a make-work project" (two commands are a "project"?)
I am "asking for more bolt on kludges"? (Again, two commands are a kludge?)
The command handler is "an area that is already overburdened with ad-hoc, quick and dirty additions". Whose fault is that? Who wrote them? I initially proposed the # flag as something that might give an easier way to add extensions in the future, but you totally rejected the idea, because "ad-hoc, quick and dirty additions" are much easier, which is why you always choose that route first.
Seriously? George, either you can (hypocritically, I might add) complain about "ad-hoc, quick and dirty additions" that provide no *future* system design benefits, OR you can complain about making a (MINOR!) parser change that would have the side benefit of giving you a new "tool" you could apply to future modifications.
AGAIN, YOU CAN'T HAVE IT BOTH WAYS.
What I find the most galling is your remarks that doing things differently "would be a totally un-needed effort, all in aid of making it suit your sensibilities for how line commands should 'look'. Even though everything is working right now" and is just "asking for a make-work project that buys nothing".
So, now that you have forced this awkward design down our throats, we're stuck with it, because you went behind our backs and implemented it without discussing it with anyone, and changing (the 20 lines of code?) at this point is useless make-work. Does that pretty much cover it?
Really? You have the nerve to attack me and attack my "sensibilities" - when those "sensibilities" are the very things that brought these command enhancements into existence? If you find my "sensibilities" so **** objectionable, why didn't you reject them out of hand in the first place?
While you're at it, go through the Help doc, and yank out every command and feature in SPFLite that originated from my "sensibilities" over the last 15 years?
If you are going to consistent your attacks and condemnation of me, by all means get started and revert SPFLite to what it was 15 years ago before I guided you to help make it better.
I just so sick of your ridiculous, extremist over-reactions. Can't you EVER discuss things normally without descending into that morass?
Discussions on software design ought to resemble a meeting of engineers respectfully speaking in low undertones in a library. Instead, you give me something that's more a tirade of propaganda. After all the things I have contributed, you have nothing but contempt and disrespect for me. Do I really deserve this?
You want to know why we've had so many issues over the years? This is YOUR FAULT.
|
|
