dellard / snoods Goto Github PK

Now that we have multiple boards per server (#8), the user interface should display the name of the board
somewhere that the user can see. The titlebar of the window makes sense.

The drawable class implements a mix of the protocol logic and the Tkinter-specific idioms of how to make buttons, canvas objects, etc. These should be split out, so if we add another graphics library it's a lot more obvious how to do it without reimplementing everything.

If there are two users editing the same whiteboard, but they have different whiteboard sizes, then it is possible for one user to place an object where the other user cannot see it.

When this happens, it would be ideal if there were some sort of indication that there are objects that are not not visible to everyone.

The current server protocol does not include any way for a client to tell it how large its screen is, so this would require a change to the protocol.

I hope there's some commonality between different kinds of drawing peripherals...

I have a small tablet and the events it generates are a little bit weird.

If the client receives a message that doesn't parse correctly, it should not crash.

It may be necessary to exit (once the server starts sending gibberish, the client might never get back in synch) but we want to do this in a controlled manner. In most cases, the client should try to restart parsing as soon as it can.

The current model is that each server hosts one whiteboard, but it could be useful to have several. This means that the client needs to tell the server which whiteboard it wants to access (and the server might need to tell the client the names of all of the whiteboards).

Let the whiteboard be whatever size the users want, even if they can only see a fraction of it on
their screen at a given moment; let the whiteboard scroll.

It's lame to have people drag around tarballs. Make it into a package that pip can handle, or something similar.

There should be commandline parameters for choosing the size of the whiteboard canvas, because some people are still stuck on small screens.

Need some images that illustrate what the control panel does.

Some people still have smaller screens than I do... and for them, the controls at the bottom
of the screen (or even the bottom of the whiteboard itself) are not visible.

By default, the client should make a whiteboard that is as big as can fit -- if we can figure out how big that is.

If the server receives a badly-formed message from a client, it should not crash nor relay the message to the other clients.

In most (maybe all) cases the server should shut down the client connection as well. If the client starts sending gibberish, it might recover, but then again it might not. Restarting is safer, and no state will be lost as long as the server survives.

Let the user save the current state of the whiteboard, and load it again later.

This may require some care to handle re-loading the same objects more than once, since objects with the given viobid will already exist and are being "modified" rather than being created.