[dcc2] DCC Whiteboard specification

[codemastr]

> The canvas starts out at a default size, and grows automatically as
> drawing commands are received. It would be good to have some kind of
> limit, though; you don't want to resize the canvas to 1 terapixel
> whenever you receive a drawing command at (1000000,1000000).

Well I guess what I was referring to is, how is the default size chosen?

>
> >In the DR command, is tooltype = 7 nonexistent, or did you forget to
include
> >it in the spec?
> >
> If two users have different default background colors, which will be
> used when the whiteboard opens?

I guess I worded it wrong. I meant, in the DCC draw negotiation, you have
like "BGColor=FF0000" I didn't mean to use the Windows background color as
the default. Just that, the two users should be allowed to choose a
background color to use.

> >I'm not so sure I like the "arrow" tooltype. My problem with this is, if
> >that's added, you can be sure people can suggest several hundreds of
other
> >things. "What about word bubble/thought bubbles?", etc. Meaning, an arrow
is
> >simply a line with three other lines at the end forming a triangle and
then
> >filled in. Is that something that is really necessary to do for the user?
And
> >if it is, you can be sure other things similar will be suggested. What I
> >personally think is, this is a client-side feature, not a protocol
feature.
> >Since it can be accomplished as an aggregate of other tools, why not
simply
> >do that? ViRC could still have an arrow tool, you'd just send a DR for a
> >line, and a DR for a filled polygon.
> >
> That's true. You wouldn't be able to use SETTOOL with it, but I don't
> know if that'd matter after all.
Hmm that's true... But since SETTOOL isn't implemented in ViRC, that
shouldn't inconvenience any of your users, should it? I realize trying to
remove anything could cause problems because your users may have already
become accustomed to having it. But along the lines of SETTOOL, how would
that exactly work? I see why it would be useful, but say you do SETTOOL 1
(line). What stops me from then just sending back SETTOOL 0 (pen) so that I
can do whatever I want?

> We'll need a way to do a DCC2 handshake through the whiteboard
> connection, and also a file format to use for stamp images. I'm hesitant
> to pick a format that requires a big library, like JPEG or PNG,
> considering the previous debate over XML... on the other hand, what
> system without a JPEG or PNG library would even be able to support
> whiteboard?

Well, Dan Smith suggested having DCC2 negotiation through DCC Chat, I don't
see why we couldn't also include the same negotiation through Whiteboard.
Especially since your whiteboard spec uses CTCP, it seems again we could
introduce a DCC2 command. But, of course, we're going to have the same
request vs reply issues we have with chat. For the file formats, maybe the
best way to do this is through negotiations as well? I would say the default
is BMP. BMP is a really simple format, so even if the OS doesn't support it,
a BMP library shouldn't be too big, and even writing your own should only
take a few hours. Obviously Windows has BMP support built right in, so for
Win client developers, this would probably be the easiest. Does anyone know
if Linux has BMP support by default? I assume GDK supports it. Anyway
though, I was thinking something like FType="bmp,jpg,gif,png" to signal
"these are the formats I support." Then the other client returns its list
(either a list equal to, or a subset of, the first list) and then those
formats are supported. One thing I was wondering though, should the
whiteboard session "freeze" while the transfer is in progress?

> Here's a possible set of changes to support your suggestions:
[...]

Pencil only needs one coord pair as well, doesn't it? Otherwise, it looks
good. Also, I thought of possibly another tool, maybe a way to draw an arc?
The current spec doesn't seem to have anyway to allow the user to draw a
curve other than doing it by hand. Or by drawing an ellipse and then erasing
parts (and that isn't good if you are drawing on top of something since the
whiteboard isn't layered). But, of course, drawing an arc will have the same
kind of issue you mentioned with spray can, you need to specify more than
just an x,y. You would probably do it similar to your ellipse method, give a
rectangle and inscribe an ellipse in it, and then draw the portion of that
ellipse given by the specified angles. But that requires 2 coord pairs, and
2 angles.

> Rotating, shearing, and scaling sound like something that could be done
> by using MAKEIMG and extending STAMP to include the rotation, scale, and
> shear factors. I believe rotation can be expressed in terms of
> horizontal and vertical shear... but I'm not sure exactly how; I'm not
> much of an image expert either.

Yeah that sounds like a good way to do it. The biggest problem with these
features, in my mind, is the fact that you want to ensure that it looks the
same on both the sender and receiver's screens. So that means, you can't
simply call StretchDIBits on Windows, because that might use a very
different algorithm than say, GDK would on Linux. So it would mean we'd have
to find some open specification for an algorithm that can be implemented on
any OS.

> I'm not sure where the best place would be to put the spray can, since
> it needs a size and a pressure... a new drawing command? A new pen style
> (extending the PEN command to include style, size, and pressure)?

Well, the thing with the pressure is, the way most drawing programs work is,
the pressure is determined by how long you are holding the mouse button down
for, not by selecting a setting from a list. So it would mean, a PEN would
be sent before each DR when using a spray can tool. Is there any reason why
a pressure can't just be tacked on to the end of the DR command when the
spray can tool is used?

One last thing, I love the idea of using numbers for the tools and such,
since it makes parsing the commands faster, and less info to transmit, and
for a realtime drawing protocol, that's pretty useful. But, when I suggested
such things for the negotiation protocol, people said they wanted the
transmission to be human readable. So I wonder if similar concerns will be
raised here...

-- codemastr