Tweak Docs

[Steven W. Riggins]

Are there any more docs for tweak? For example, the docs mention
dragEnter event, but really no examples on how to use it. So I
search the code and find several uses of dragEnter, some using the
hand, some not, etc.

For tweak to be really successful and robust I think the
documentation is very important. Sure we can all look at the code,
but as we've found many times, in trying to describe your system you
often run into holes you didn't see before :)

Most importantly, good docs will keep people from asking the same
questions over and over.

So for now, are there any unfinished works just not published yet,
before I start asking questions? :)

Steve

[Andreas Raab]

Hi Steven -

As you noticed, there is little documentation about dragEnter and
friends. Not hard to write though, if we know what to write about (other
than saying "everything" ;-) So how about sending an RFD (request for
documentation) which we can file as a bug report and deal with properly?

In any case, per your request I've started a cookbook entry here:

http://tweak.impara.de/TECHNOLOGY/Cookbook/DragandDropHandling/

Cheers,
- Andreas

Post by Steven W. Riggins
Are there any more docs for tweak? For example, the docs mention
dragEnter event, but really no examples on how to use it. So I search
the code and find several uses of dragEnter, some using the hand, some
not, etc.
For tweak to be really successful and robust I think the documentation
is very important. Sure we can all look at the code, but as we've
found many times, in trying to describe your system you often run into
holes you didn't see before :)
Most importantly, good docs will keep people from asking the same
questions over and over.
So for now, are there any unfinished works just not published yet,
before I start asking questions? :)
Steve
------------------------------------------------------------------------
_______________________________________________
Tweak mailing list
http://impara.de/mailman/listinfo/tweak

[Steven Riggins]

Thanks I will do so!

For now:

1) Can we determine what is being drug over us on dragEnter? It
would determine how I decide to hilite (if at all)

2) What is the pattern for drag n drop? For example, in order for my
canAccept... method to work properly, I need to know if that player
is one of ours or not. I can't accept a normal RectanglePlayer, it
means nothing to me in the large picture of things. I need to know
if it is a Resource, or a Frame, or....... etc. What is a general
pattern for this that we can put out there so everyone uses a similar
pattern? ie you don't just send the object a message of course, that
can fail. Or do you send it a message and trap for an exception? Do
you check its class? (yuk)

Danke!

Post by Andreas Raab
As you noticed, there is little documentation about dragEnter and
friends. Not hard to write though, if we know what to write about
(other than saying "everything" ;-) So how about sending an RFD
(request for documentation) which we can file as a bug report and
deal with properly?

[Andreas Raab]

Hi Steven -

1) Can we determine what is being drug over us on dragEnter? It would
determine how I decide to hilite (if at all)

Sure - that's what "hand dragContents" tells you.

2) What is the pattern for drag n drop? For example, in order for my
canAccept... method to work properly, I need to know if that player is
one of ours or not. I can't accept a normal RectanglePlayer, it means
nothing to me in the large picture of things. I need to know if it is a
Resource, or a Frame, or....... etc. What is a general pattern for
this that we can put out there so everyone uses a similar pattern? ie
you don't just send the object a message of course, that can fail. Or
do you send it a message and trap for an exception? Do you check its
class? (yuk)

It's not clear if a one-size-fits-all solution is really what we want
here. At least personally, I'm not sure about this. We've got the
(extreme) general and common case already that there we only drop
players (which therefore need to be used to represent other
non-graphical objects like files etc.) and it seems to me that if we
build another general purpose mechanism "inside" these players we'll end
up asking "so how do we find a general purpose mechanism to identify
drag and drop inside *that* mechanism", e.g., layers inside layers.

So personally, I do consider this a somewhat application specific task
and if you want to accept drag and drop from other apps you need to know
how to figure those out (unless you just accept graphical objects).

Cheers,
- Andreas

[Bert Freudenberg]

Post by Steven Riggins
Thanks I will do so!
1) Can we determine what is being drug over us on dragEnter? It
would determine how I decide to hilite (if at all)

As per Andreas' cookbook recipe:

hand dragContents

Post by Steven Riggins
2) What is the pattern for drag n drop? For example, in order for
my canAccept... method to work properly, I need to know if that
player is one of ours or not. I can't accept a normal
RectanglePlayer, it means nothing to me in the large picture of
things. I need to know if it is a Resource, or a Frame, or.......
etc. What is a general pattern for this that we can put out there
so everyone uses a similar pattern? ie you don't just send the
object a message of course, that can fail. Or do you send it a
message and trap for an exception? Do you check its class? (yuk)

No, just ask the object. The Smalltalk pattern for this is to
implement #isMyThing in both Object and your own class(es). This is
both very readable and efficient. In general you do not want to check
the class, this counteracts polymorphism. If something chooses to
answers true to your #isMyThing query, it better should behave
according to the protocol implied by claiming to be a MyThing.

In the tile programming system (etoys) we send #isTilePlayer to
determine if we are safe to send other messages, and if so, we check
that, e.g., only statements can be dropped into a sequence.

- Bert -

[Andreas Raab]

No, just ask the object. The Smalltalk pattern for this is to implement
#isMyThing in both Object and your own class(es). This is both very
readable and efficient. In general you do not want to check the class,
this counteracts polymorphism. If something chooses to answers true to
your #isMyThing query, it better should behave according to the
protocol implied by claiming to be a MyThing.

An alternative that works very well for drag and drop of non-graphical
objects is to to use tag for the player, e.g., what you could do is
something like:

aPlayer userDataAt: #dropStuff put: <something>

BTW, userDataAt: is explicitly meant to be used by "other" objects -
it's a namespace independent from internal properties of an object
therefore you'll *never* conflict with the objects internal properties.

Then you'd test it via:

dropStuff := aPlayer userDataAt: #dropStuff.
dropStuff ifNil:[^false"not my kind of guy"].

The obvious advantage of this pattern is that you can attach any kind of
information to any kind of object. The obvious disadvantage is that it's
much harder to track than if you put this into code directly.

Cheers,
- Andreas