[dcc2] DCC Whiteboard specification

codemstr at ptdprolog.net codemstr at ptdprolog.net
Mon May 24 15:58:23 EDT 2004


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?

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.

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

Some basic comments/suggestions:

Should the canvas always default to white? I think it would be nicer to have 
a "background color" setting. 

Some of the protocol seems inefficient. Every time a user draws, the width, 
brushcolor, and pencolor all have to be sent. Consider the scenario where 
I've decided to hand draw a 600x600 circle and fill it in by hand. This could 
require several hundred, if not thousands, of DR commands to be issued, each 
one drawing a single pixel. It seems a more efficient way is to implement 
three new commands:
WDTH width - sets the width to width
PCLR color - sets the pen color to color
BCLR color - sets the brush color to color

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. 

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.

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.

Other ideas:

These are ideas from other whiteboard applications and/or MS Paint.

Rounded rectangle. Just a regular old rectangle but with rounded edges rather 
than corners.

A polygon/filled polygon tool. Why limit to just circles and rectangles? The 
parameters would just consist of a list of the begin/end point of the edges.

Spraycan/spraypaint/airbrush. Allows you to variably fill a region with 
color. It seems to me like this would just require you to specify a circle 
(the area affected by the airbrush) and the pressure (how long the mouse was 
held), and then use a predictable number generator to pick pixels out of that 
region to color. The number of pixels to color is determined by the pressure. 
Basically, this would involve using some hash algorithm to make sure that the 
sender and receiver both pick the same pixels in that region.

Brushtypes. For things like the pen, you assume all pens are created equal. 
That's not true. For example, you can have a "round" pen, a "square" pen, 
some programs go really crazy, for example, GIMP has a "pepper" pen in which 
it draws a green pepper. I think at least some standard set of brushes needs 
to be defined. I'd suggest a round, square, fuzzy(antialiased) round, and 
possibly a calligraphy (a slanted line, / or \) brush.

The following are some things I have no idea if they'd be difficult to add or 
not, I'm no image manipulation expert, but if they could be, I think it would 
be nice.

Rotate/Scale/Shear a region. Meaning you select a region, and then you can 
rotate that region by a number of degrees, or increase it's size, or shear it 
in a particular direction.

A smudge/blur tool. Well I don't quite know how to describe this, but if 
you've worked with just about any image editting tool, you know what I mean :-
)

The image transfer stuff:
I can definately see this being useful. I know people often like to draw on 
existing pictures and such, and use little icons, but I wonder, should this 
actually be done over whiteboard? Or should it just open up a filesend? What 
I just mean is, it seems as though the way you have whiteboard implemented 
requires creating Chat and File on top of Whiteboard. 

-- codemastr





More information about the dcc2 mailing list