acarrillo / scribble Goto Github PK

A collaborative Google Drawing-style sketching program in C

License: GNU General Public License v3.0

C 100.00%

scribble's Introduction

      ____      _ _     _     _
 ___ / ___|_ __(_) |__ | |__ | | ___
/ __| |   | '__| | '_ \| '_ \| |/ _ \
\__ \ |___| |  | | |_) | |_) | |  __/
|___/\____|_|  |_|_.__/|_.__/|_|\___|
                                     The smart doodler

------------------------------------------------------
by Alejandro Carrillo, Doron Shapiro, and Vincent Zhen
------------------------------------------------------

Members:
	Alejandro Carrillo
	Doron Shapiro
	Vincent Zhen


HOW TO USE:
    Install the 'libsdl-devel' package.  Depending on your platform, package names will vary, but you will need the "dev" version of the package to compile sCribble.

    Then, to build, run:
        $ make

	To start a doodle, run "./sCribble".  To collaborate on an existing doodle, run "./sCribble XXX.XXX.XXX.XXX", where XXX.XXX.XXX.XXX is the IP address of the host.

    For example, to run two canvases on the same computer, do the following:

    TERMINAL WINDOW A
        $ ./sCribble
    TERMINAL WINDOW B
        $ ./sCribble 127.0.0.1

	We used SDL for our project. This includes SDL_image (for image blitting), SDL_ttf (for text) and SDL (for the rest of it).

    To clean up the build files:
        $ make clean && make cleanS

Files in sCribble repository:
      font
	      blackWolf.ttf
      gfx
	      color_line.bmp
      src
	      server
	          listener.c
	          listener.h
	          server.c
	          server.h
	          subserver.c
	          subserver.h
	      client.c
	      client.h
	      defs.h
	      file.c
	      file.h
	      graphics.c
	      graphics.h
	      init.c
	      init.h
	      input.c
	      input.h
	      main.c
	      main.h
      .gitignore
      DESIGN
      README
      TODO
      BUGS
      Makefile

NOTES:
    The full commit history of this project can be found at http://github.com/acarrillo/Cribble

scribble's People

Contributors

Stargazers

Watchers

Forkers

vzeddie

scribble's Issues

DESIGN document

I'm finishing it up for the final commit.

Server does not always clean up shared memory

The main server process should call cleanup() before it exits to ensure that shared memory is freed. SIGSEGV and SIGINT, at the very least, should have handlers that call this function.

Implementation postponed, as signal handlers interfere with debugger functionality.

This is mostly a reminder to myself, but also a heads up to @acarrillo .
main.c currently holds the code that will probably morph into the "canvas" thread, but it should probably hold the primary process for the program. I'm writing the main function for that now in mainApp.c, as I don't want to start messing up working code tonight, but we'll have to do the switcheroo at some point.

"Listener" server prints garbage instead of listening for connections

Line 64 of src/server/listener.c:
socket_client = accept(socket_id, (struct sockaddr *)&server, &l);

This line should block until a new connection is made by a client over socket socket_id.
Currently, it indefinitely prints a random character/set of characters (often `) to the terminal.
When a client does try to connect, this it is not acknowledged (accept does not stop blocking/printing).

Server sometimes does not clean up after ^C sent

If running sCribble causes the following error, the server does not kill its subservers and its children persist as orphans: Could not initialize SDL: No available video device,

After drawing with rapid motions using pen tool, window mysteriously disappears

The program then has to be force quit, as ^C's do not kill it...

Clunky line drawing

Line drawing is clunky:

Only works for a certain range "negative" slopes
Lines are oddly formed, resulting in variable widths

I am still working on improving the line drawing. Line drawing does have an effect on the pen tool, as scattered dots are connected by lines, so when the line drawing works, so will the pen tool.

Ideas and implementations of new drawing tools

I managed to make a sort of "butterfly" tool. It symmetrically draws (line of symmetry is diagonal NW - SE).

ADD:

if (mouse.ycor >= 0) {
/* TODO: Scale up from simple pen tool */
drawFilledRect(mouse.ycor-(tool_width/2), mouse.xcor-(tool_width/2), tool_width, tool_width, 0, 255, 255);
}

into graphics.c after line 56.

But it's not very effective considering that there are some issues with the screen disappearing.

⌘-Q does not quit in OSX

Running Lion, I have to close the window with the mouse or control-c in terminal to end sCribble.

Not high priority to fix.

GUI

I guess I'll try to build the GUI. Does anyone have any recommendations or ideas about how I am to go through with this? I was thinking about making a separate screen that will house the color palette but I can't seem to create a 2nd screen. I thought about making some buttons on the bottom. I think that would be the best idea but I don't think I will be able to make it complex (many colors). Maybe only red, blue and green. I don't know.

@acarrillo : I would like to know how to change the pen's color. It seems that even though I hardcode 250,0,0 as RGB values in graphics.c, it will not change the color. (I tried changing the RGB values in the updateScreen() function replacing 0,0,0)

Server Implementation

Mostly notes to myself for tomorrow after debugging the server today:

Here is the final behavior that we need from the server:

Clients connect and are "remembered" by the server
Clients constantly send data up to the server
The server send all of the data it receives to all of the clients (in a uniform order)

So basically, we're creating a broadcast server.
Right now, when each new client joins, it receives a socket file descriptor in the server. The current plan is for the server to constantly loop through its list of socket descriptors, and if any have written a data struct, to loop through the list to broadcast it out. The possible issue here is that a client could write multiple data structs before the server has looped around to reading it, and we don't have a clear way of dealing with that. (Just to confirm, can you write to a socket that hasn't been read yet?)
For now, I think we can hope that that issue won't come up. If it does, we may have to create subservers that constantly read the client sockets and queue up their requests to send to the main server.

Project is dependent on resources; should be independent

Unless anyone disagrees, it would be convenient if our project was locally sustainable, such that DW (or ourselves) could compile our project without having SDL universally installed on his machine. This would be convenient for us when working on different machines at school where not all software is installed as well.