[dcc2] DCC Whiteboard specification

[Jesse McGrew]

codemstr at ptdprolog.net wrote:

>Overall, it seems nice, I just have a few comments/suggestions.
>
>Things that aren't clear to me:
>How does TXT/TXTEX handle multiline text? It seems logical that people will 
>want text areas that span multiple lines, does it ignore a \r\n if a \1 
>hasn't been encountered yet? Does it escape \r and \n?
>
>  
>

No, there is no support for multiline text. One way to add it would be 
to send a TXTEX command for each line of text. If we specified a 
standard DPI for the whiteboard, or specified the text size in pixels 
instead of points, then the sender's client could easily figure out 
where each line is supposed to be.

>How do clients decide what the canvas size will be? If I'm on an 800x600 
>resolution, and someone starts writing to (900,700) that won't show up on my 
>screen. Somehow, the two clients need to decide "the canvas is MxN." For 
>DCC2, I guess this would be handled through a negotiation token. Initiator 
>sends "canvas=900x1000" then the other client responds with a canvas <= to 
>that canvas size.
>
>  
>

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).

>In the DR command, is tooltype = 7 nonexistent, or did you forget to include 
>it in the spec?
>
>  
>

Tools 2 and 7 are nonexistent, for historical reasons. I don't think 
there's any danger in reusing them for new tools.

>Some basic comments/suggestions:
>
>Should the canvas always default to white? I think it would be nicer to have 
>a "background color" setting. 
>  
>

If two users have different default background colors, which will be 
used when the whiteboard opens?

>When the DR command is used, it uses the width, pen color, and brush color 
>that have been previously set from the issuing of the WDTH/PCLR/BCLR 
>commands. It continues to use those settings until a new command is issued 
>changing them. That can significantly reduce the network traffic caused by 
>whiteboard. 
>
>  
>

Makes sense.

>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.

>For DCC2, is the chat-over-whiteboard really necessary? I don't quite see why 
>you wouldn't just open two connections. I mean the client could be setup to 
>deal with this automatically. It just seems odd to intermix them. Otherwise, 
>why have a Chat protocol at all? Why not just have a whiteboard protocol, and 
>you just send DONT to everything. Then you pretty much have a DCC Chat. It 
>would seem to me it's better to have two seperate connections. A client could 
>be set to automatically open a DCC Chat when a whiteboard is initiated, and 
>it could even display them both in the same window, i.e. a whiteboard at the 
>top, and a small chat area at the bottom.
>
>  
>

Good point. There isn't much reason to send chat (or stamp images) over 
the same connection, other than that's how ViRC 1.x did it and therefore 
that's how I did it in ViRC 2.

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?

Here's a possible set of changes to support your suggestions:

Select pen: PEN <shape>,<size>
[shapes: 0=round, 1=square, 2= / , 3 = \ ]
[size is the width and height of a bounding box containing the pen]

Select pen color: PCLR <color>
Select brush color: BCLR <color>

Draw: DR <tooltype>,<x1>,<y1>[,<x2>,<y2>,...]
[x1 and y1 are required, but any number of other coordinate pairs may be 
given and will be ignored if the tooltype doesn't need them]

Tool types for DR/SETTOOL:
Pencil = 0
Line = 1
Rectangle = 3 (hollow), 5 (filled)
Ellipse = 4 (hollow), 6 (filled)
Eraser = 8
Flood fill = 9
[flood fill only needs one coordinate pair]
Rounded rectangle = 11 (hollow), 12 (filled)
Polygon = 13 (hollow), 14 (filled)
[polygon needs 3 or more coordinate pairs, the last of which is 
automatically connected to the first]
Blur = 15

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.

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)?

Jesse