CHS: New Formatting Dialog

[mouser]

I have concluded that it would be best to reorganize the modify/formatting dialog, to move from an all-on-one-page view, to a tabbed view.

Old dialog:
[attach]

[superticker]

I think you need something in the middle. The new design has too many tabs, but the old design doesn't have enough. Maybe create just three tabs where related items are grouped together.

This also brings up another issue. If the changes you want to make require operations on two different tabs, does that now mean you have define (and execute) two separate PreFormat definitions to get all these changes?

[mouser]

Yeah i can combine some of the sparse tabs.

A saved preset saves/applies ALL formatting on all tabs.

[superticker]

A saved preset saves/applies ALL formatting on all tabs.

I have an operational question. How can you make creating/using presets intuitive if saving a preset means saving across multiple tabs? In my mind, this design is counter intuitive. (I wonder if Steve Jobs would approve?)

Maybe you could group all the formatting operations that are commonly done together on a single tab. If that's done, then this issue is moot. This also means minimizing the number of tabs in the UI design.

[cranioscopical]

mouser,

I can see your reasoning but I have to agree that the new layout that you showed above seems counter-intuitive. On the existing panel, I can use your cleverness to create some useful items in a trice (only a little slower than a bice but certainly faster than a vice). By the time I stumbled through the new layout I'd have forgotten what I was trying to do. I have found it useful to see all of the options in one place. Keeping together as many items as possible would be an advantage, as seen from my purely selfish perspective.

[rjbull]

As in tranglos' thread Is this a worthwhile idea for a program?, my "problem" with this dialog isn't the BRU-like density of the dialog itself, which after all works for BRU, but its location.  You have to pick a clip and activate Modify Format/Case to get to it.  In particular, the User Tools menu is an item under it, so that's one more layer to negotiate.  I originally thought that it should be accessed from the main Configuration dialog.

One more request, though not strictly relevant here.  At present User Tools expect tools that read from a file, write to a file.  Please would you consider adding the alternative of sending the clip to a utility that expects input from STDIN, and receiving the modified text back from STDOUT?  That would suit lots of Unixish utilities.  However, I'm given to understand that redirection and pipes are far harder in late-model Windows than they were in DOS.

@cranioscopical: what's faster than vice?  Have you ever been to Las Vegas?

[cranioscopical]

what's faster than vice?

If you're into Devil worship, I'd say sin apses. Now you mention it, not so different from those one might find in LV cathedrals of ...

[mouser]

In particular, the User Tools menu is an item under it, so that's one more layer to negotiate.

rjbull,
i'm doing away with the UserTools menu completely.   Now if you want to use a user tool, you simply configure it as part of a saved preset, which can be combined with all or no other formatting operations.  this is a key change.


as for using stdin and stdout as input and output, yes i could probably add that.

[mouser]

I have found it useful to see all of the options in one place. Keeping together as many items as possible would be an advantage, as seen from my purely selfish perspective.

i can try to combine more per page.  as you can see from my first post i am inclined to agree that the new tabbed method is going to make it somewhat more cumbersome to do quick stuff.  it just wasn't sustainable -- i was quickly running out of space and adding things became a question of where to put it..  the new approach removes that constraint which is the important thing.

so i don't think there is any going back from this new tabbed approach -- but i can try to reduce the number of tabs.

[cranioscopical]

i don't think there is any going back from this new tabbed approach

Fairy Nuff. I can see that it opens the door to further enhancements. 

[mouser]

Following the discussion on this thread, the way custom user tools/scripts are interfaced with CHS has now changed.

In the past, you configured a custom user tool from a special menu in the formatting dialog, and then triggered it manually when you wanted to apply it.

Now, this is done through just another tab on the modification dialog.  That is, you can configure a tool/script to run either before or after any other formatting operations, and then you would SAVE the formatting modifications "preset" to be applied when you want.

Then you can run the custom user tool/script *just like any other saved modifications preset) on any selected text by triggering the preset formatting settings that you previously saved, either from the quick paste menu or the main window modification menu.

I will be making a screencast movie demonstrating the process soon.

If anyone wants to help test the new version send me a message.

[mouser]

If anyone wants to try it i've uploaded to:
http://www.donationcoder.com/Software/Mouser/clipboardhelpandspell/downloads/alpha/ClipboardHelpAndSpellSetup.exe

I've also included 2 sample commandline tools (one exe, one perl), that you can configure your formatting presets to use.  (I actually included one included formatting preset which you can load from the Presets menu that will trigger the exe tool).

Note: The custom tool feature is an advanced thing and may not be easy to understand.  I will upload a screencast video this week that should make it easier to understand.

[cranioscopical]

The Preset Hotkey Trigger doesn't want to take Ctrl+Q (which was set in the previous version).
Can someone else see if that's so?

[mouser]

it may be refusing to release ctrl+Q that it allocated earlier to another (or the same?) preset.  If so, that's a bug.

To test: if you are in notepad, select some text and hit Ctrl+Q, does anything happen?

[rjbull]

Now if you want to use a user tool, you simply configure it as part of a saved preset, which can be combined with all or no other formatting operations.  this is a key change.n and stdout as input and output, yes i could probably add that.

OK, I can't immediately picture what that will mean, but (eventually) I'll take a look at it.

[cranioscopical]

To test: if you are in notepad, select some text and hit Ctrl+Q, does anything happen?

Entirely my fault, same as usual. 

[cranioscopical]

chs_sampletool.exe wants a .dll that I don't appear to have. The Perl script does its best but is thwarted by the fact that I haven't Perl installed 
As far as I can see, though, the mechanisms work as intended — FWTW. Items set that don't call those tools work fine, as with the old, single panel.

It must be my setup. I just set the external tool to be an editor and the editor is looking in the wrong place for the file.
[attachthumb]

[mouser]

• 1. I'm repackaging with a sample tool that doesn't need visual studio runtime dlls, so that should solve that problem.
• 2. As you noted, the perl sample tool will only run if you have perl installed and configured on your pc; that is as designed.  One could build the perl sample into an exe but the point was simply to let you test running a perl script directly IFF you have perl installed.
• 3. As for using an editor.. it's failing because you are passing in both the input and the output file, and the output file doesn't exist yet.  However, i will modify the way tools work so that you can actually use it with a tool that reads and writes to the same temp file, the way an editor would.  That will let you use it in the way you are trying.

[mouser]

I've uploaded a new version that will also work with tools that write out the changes to the input file.

You can test this by downloading new version and then setting the tool to: notepad.exe

But if you do, make sure you change the argument string to just "%infile%" (instead of "%infile%" "%outfile%").

[cranioscopical]

it's failing because you are passing in both the input and the output file

[cranioscopical]

I've uploaded a new version that will also work with tools that write out the changes to the input file  ... make sure you change the argument string to just "%infile%" (instead of "%infile%" "%outfile%").

That works very nicely and hands stuff out for processing by an editor that has many years' worth of Rexx macros built into it.

[mouser]

I've uploaded a new screencast video here: http://www.donationcoder.com/forum/index.php?topic=28311.0

[rjbull]

That works very nicely and hands stuff out for processing by an editor that has many years' worth of Rexx macros built into it.

I'm not sure I follow you.  I thought the point of this kind of tool was to avoid using the editor itself, while gaining extra benefit from scripts already written for it.  That is, instead of loading your editor, you'd run your scripts with a free-standing REXX interpreter via CHS.  Is that what you meant?

In my case, I have, or rather had at work, a myriad AWK scripts plus a much smaller number of SED scripts.  As first written under DOS or for use in a DOS box, these were run from the command line using redirection and sometimes pipes because that's how you did it in those days, and seems to be the standard Unix method for running Unixish tools.  Often they were wrapped in batch files.  More recently I configured certain scripts as user tools in editors like TED Notepad, Notetab Pro (NTP), and HippoEDIT.  NTP can even keep the scripts inside its own clipbook (macro) libraries.  The editors all send a marked block of text to the script, receive the transformed text back, and over-write the original marked block.  This works by STDIN/STDOUT without temporary files (or at least without them being visible to the operator).  I see that mouser's example PERL script is specifically written to use files as IO rather than STDIN/STDOUT.  I'd rather avoid having to change my scripts that currently work by STDIN/STDOUT, which is why I'd like to have STDIN/STDOUT offered as an alternative method.

[mouser]

I'd rather avoid having to change my scripts that currently work by STDIN/STDOUT, which is why I'd like to have STDIN/STDOUT offered as an alternative method.

i will add this option soon (if you promise to use it!)

[rjbull]

Thanks, mouser.
[Edit 2011-10-13, 20:32]
Just noticed your edit! 
Well, I'm not working, so I don't have as much need as formerly, but maybe I'll try and find something to use it with 
[/Edit]