draw/paint tools in standalone ?

[Richard Gaskin]

Erik Hansen wrote:
> 
> --- Dan Shafer <revolutionary.dan at gmail.com>
> wrote:
> 
>> Actually, I suspect that for your app to
>> contain drawing tools, it's
>> going to have to create a palette of its own
>> and manage the process
>> inside your application. The Rev IDE tools only
>> operate within the IDE
>> as far as I know.
> 
> has this been done?
> is there a plugin for sale?

Once upon a time I started down the road of making a universal drawing 
tool palette, but in the real world I've found that each app requires 
something a little different, so I'm not sure it can usefully be done as 
a one-size-fits-all.   And then there's the question of how to handle 
the other properties (line size, fill/back color/pattern, etc.) -- in 
the same palette a la FileMaker, or in a separate palette that eats up a 
ton of screen space a la Flash.  Decisions, decisions....

Fortunately it's not too difficult to slap one together from scratch 
when you need it; mildly tedious if you do it more than once, but if you 
make enough of them it becomes second nature after a while.

There have been only three things that were tricky for me to get my head 
around first time out:

1. The various graphic primitives are governed by the style property, 
while everything else is governed by the tool global property (pointer 
tool, graphic tool, etc.).  So while you "set the tool to pointer" to 
engage the pointer tool, for graphics you first "set the style of the 
templateGraphic to <style>", and then "choose graphic tool".


2. Since palettes are not in the message path for things outside of 
their own stack, it can be helpful to have the palette insert a 
frontScript to trap the newTool message so it can update its UI whenever 
the current tool mode changes.  While this isn't so important as long as 
your palette is the only way to change tools, it can be handy for 
working with other tools, or even within the IDE, so that its UI will 
always accurately reflect the current tool.

If you'll have more than 10 tools with frontscripts active in your app, 
given the limit on the number of frontScripts your app can have at 
runtime you may want to set up a dispatcher like the one Rev uses for 
plugins.  I don't see much sense in setting up redundant messages just 
for plugins, since those only run in the IDE where there is no limit to 
the number of frontscripts.  But for handling lots of tools in a 
standalone it can be helpful.


3. Neither the Rev nor the MC IDE pass all mouse messages when the 
pointer tool is active.  This is reasonable, given that you'd rarely 
want to take the same action on a mouseUp with the pointer tool as you 
would with the browse tool.  But it does make it impossible to 
adequately test some things in a custom drawing environment without 
first removing the IDE frontScripts that handle those messages -- not 
for the faint of heart.

SuperCard provides an a solution to this with a parallel set of messages 
exclusively for use with the pointer tool.  So instead of "mousedown" 
and "mouseUp" as you get with the browse tool, with the pointer tool 
active in SC you get "pointerDown" and "pointerUp".

That's been requested in 
<http://support.runrev.com/bugdatabase/show_bug.cgi?id=2606>.

In the meantime, you can make a plugin to help during development which 
removes and re-inserts Rev's frontscripts as needed if you need to work 
with mouse messages while the pointer tool is active.



And those issues don't include the other two caveats of working with the 
pointer tool that I alluded to earlier in my references to BZ#s 623 and 624.

BZ#624 is simply a request to subclass the object handle management to 
allow more conventional behavior for line objects, and to allow 
interactive resizing of polygon points.  SuperCard, RADBuilder, and OMO 
did this, and it would be nice if Rev went along with the convention 
long established by those other xTalks (not to mention MacDraw, 
Omnigraffle, Word, and most other programs that provide the same graphic 
primitives).

BZ#623 is a request to outdo SuperCard in one area where SC really 
shines right now, and has for years:  In SC the tool is a property of 
the window, not global as in HC and Rev.  This lets you establish one 
stack as a canvas, and all other stacks retain their browse tool mode.

If you set the style of all other windows to either palette or modeless 
you can work around that, but sometimes that's not so simple to do if 
you need to update your menus or other UI elements based on the 
frontmost window, since the topstack will return the first stack of the 
lowest mode, which may or may not be the one in front.  Not impossible, 
just more tedious than having window-specific tool modes.

BZ#623 takes this SC convention one step further, requesting that groups 
have their own tool mode.  This would allow something that can't be done 
in SC at all:  have your tool palette embedded as a toolbar right in the 
document window, as in FileMaker Pro or MacDraw.  There are usability 
arguments going each way, some for palettes and some for an embedded 
toolbar, but regardless of what may be theoretically "best" it'd be nice 
to have the option.  You can do it today with very careful use of the 
cantSelect property but it's a lot of work to do it that way, and 
riddled with pitfalls.

Ah, but how nice it would be to simply say:

   set the tool of grp "Canvas" to pointer




PS - a modest rant about "compatibility" notes in the docs:

The docs note the syntax for the tool property as:

   set the tool [of stack] to toolName

Older versions of the MetaCard docs noted that that the option of 
specifying a stack was added "for compatibility with SuperCard".

Unfortunately neither is accurate.

While it's true that using the optional stack specifier doesn't bring 
the engine crashing to its knees, neither does it do what one would 
expect, namely setting the tool mode of only the specified stack, which 
is what happens in SuperCard.

Instead, what happens is merely the same as "choose <tool>", making the 
specified tool globally active for all toplevel windows.

That's so not what happens in SuperCard that I would be reluctant to 
call it compatible.  The absence of a script error is not the same as 
compatibility, and in this case it may be a greater disservice than 
simply flagging any such imported syntax as an error that needs to be 
addressed.  Chances are you'll want to redesign any imported SuperCard 
drawing stuff to accommodate this significant difference, but without a 
script error you're left to wonder why it doesn't work as described.

That's "compatibility" in the same way that FEMA provides "emergency 
management". :)

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com