CS 4773 Object Oriented Systems, Spring 2005 Project Designs, Part 1
Part 1 of the project design links
- Groups 1 and 2: GUI
The following comments refer to Presentation 1:
- I decided to combine the UserInput and UserOutput intefaces into a single
UserInterface interface.
- The GUI implements UserInterface and has no public methods other than
those in UserInterface.
- I don't understand the purpose of any of the public mothods listed
other than reDisplay().
- The ErrorHandler is responsible for displaying errors, not the GUI
- The Inspector is responsible for doing the inspecting
- The UserInterface will have a method:
public void setChangedAll(Session s) which is probably what
reDisplay was supposed to do.
- It will (for efficiency) also have methods:
public void setChangedCursorPosition(Session s)
public void setChangedCurrentLine(Session s)
etc.
- The GUI will not be the main class, the Editor will be.
- The GUI will implement UserInterface, not instantiate it.
- The only interaction between the GUI and the Inspector will be that
the GUI will have a mechanism (e.g. a button) that will cause
Editor.showInspector() to be called.
- Each session will have exactly one UserInterface and each UserInterface
will have 0 or more sessions.
- See the file UserInterface for the public methods.
The following comments refer to Presentation 2:
- The GUI does not have to have an Inspector
- I don't understand the purpose of NextCommand
- It is true that the GUI will need to maintain a history of user input
- It is not clear what a history of user output would mean
- Inspector: methods listed are OK, but we may want to change the names
to have a consistant naming convention for use by the Inspector.
The Editor will provide the method for displaying the Inspector
- General comments about groups 3 and 4:
It was probably a mistake to separate these into command and keyboard
classisfications.
Think of these as two gourps that will implement the execution of commands.
The needed commands will be divided between the two groups.
Here are some categories of commands:
- cursor movement
- character insert and replace
- line (or block) movement (up and down)
- select, cut, and paste
- search/replace
- input/output
-
Group 3: command mode
- Only one group will be responsible for the Commands class.
This could be any one of groups 3, 4, or 5.
We will have to decide this soon.
The EditorSession will instantiate a CommandDecoder which in turn
will instantiate Commands.
- You need to specifically indicate which Session methods you need,
e.g.
public int getCursorPosition();
public int getCursorLine();
public void setCursorPosition(int pos);
public void setCursorLine(int line);
public String getLine(int n);
public void replaceLine(int n, String s);
etc.
-
Group 4: keyboard commands
- The Commands class will contain static constants for each of the
commands. All of these will be upper case starting with C_.
- Some of the commands listed should have arguments such as:
public boolean executeCursorDown(int n) to
move the cursor down n lines.
- You should not have commands like the ones listed under category 2.
At what point would such a command be executed?
Think carefully about how this would work.
You might want to have:
public void insertAtEndOfCurrentLine(byte b)
- Group 5: CommandThread and CommandDecoder
- There is not enough information here.
- The session will create and start the command thread for that session.
- The CommandThread will manage a queue of RawCommands,
taking things out of the queue and executing them.
- The method processCmd(RawCommand cmd) will be called
public void insertCommandInQueue(RawCommand cmd).
- The method processCmd(String s) will be called
public void decodeCommand(String s) and will insert
the corresponding RawCommand in the queue.
- The CommandThread will be in one of the states: running, ready, or
paused. Running means it is executing commands. Read means the
queue is empty. Paused means it is temporarily suspended and
cannot execute commands.
- The CommandThread will have public methods:
public int getState();
public void pause();
public void resume();
public int getQueueSize();
public void emptyQueues();
public String getHistory(); (for the Inspector)
-
Group 6: Inspector and Error Handler
- You need to prioritize the list of what you need, start with at most
one item for each group.
- I like the idea of a popup error alert, but there also needs to be a
way of providing messages that are more informatory, such as when
a search fails or the cursor cannot move down past the end of the file.
Perhaps you want to privde a panel that the GUI can place in an
appropriate place.
-
Group 7: EditorFile and EditingSession
- The EditingSession will create a CommandThread, but the CommandThread
will need to know the session:
public CommandThread(EditingSession session);
- As indicated above, the EditingSession will not create the GUI.
Since each EditingSession will have exactly one UserInterface, the
UserInterface will be passed to the session in its constructor:
public EditingSession(String localName, UserInterface interface);
- There will only be one Inspector, not one for each EditorFile.
The editor will create the Inspector.
- You did not list any of the public methods of the EditingSession
such as those to get or set cursor postion, get the number of lines
in the file, replace a line, etc.
You should do this ASAP.
- Each editing session needs to have a unique ID.
- More later ...