|
|
Discussion:
- AToM3 Demo:
I demonstrated to Professor Vangheluwe what I have implemented so far. I've
added a new checkbox to the Options dialog in which the user can enable freedrawing in
AToM3. If freedrawing is enabled, you can draw ink using the mouse left-button.
On the other hand gestures are drawn using the mouse's right button. So far, I implemented two
types of gestures: Scrolling Gesture, and Selecting Gesture.
- A Scrolling gesture is semi-line stroke in which the user indicates the scrolling
direction. The user can scroll to the right, to the left, up, and down. Currently, there
is a bug that causes the x and y values to be wrong after scrolling. I check whether a
stroke is a line or not by comparing the first point, the middle point, and the last point.
If the three points have the same x value (+/- 10) then this is a vertical line. Similarly,
if the three points have the same y value (+/- 10) then this is a horizontal line.
- A Select gesture is a semi-circle stroke in which any object contained by this semi-circle becomes
selected. Right now, I'm still having trouble selecting ink-strokes. However, objects that were
added using the toolbar bottons are getting selected correctly. To check whether a
stroke is a semi-circle or not, I compare the first and last 10 points of the stroke. If
the begining and the end of the stroke are close enough to each other, then this gesture
is recognized and handeled. (This idea of checking the distance between the begining and
the end of the stroke was taken from
SATIN's implementation)
- Code Convention:
I suggested establishing a MSDL Coding Convention. Right
now the coding style is left up to each individual and this could create inconsistency in the
code. As the group is growing, this problem will grow if we don't enforce a coding convention.
I particurlarly find this problem annoying when there is no clear explanation of methods'
parameters and return types. Professor Vangheluwe thinks that our code is more like a prototype so we should
not worry too much about this, but at the same time he agreed that we should at least try to stick
to the Style Guide for Python Code
(specially for documenting methods!) He asked me to read this style guide and possibly give
a presentation about it in one of our MSDL Friday meetings.
- Extract Reusable Components:
I also suggested re-architecturing our code in a way that
we have reusable components which are application-independent. This could be beneficial for
future applications. Right now the main class "ATOM3" subclasses from Tkinter's Frame class and
then it adds all those great functionalities. I was thinking of having a class called
"Application" (that is a subclass of Tkinter's Frame) in which we'll have useful
functionalities like freedrawing capability, show/hide grid, etc). Then we subclass AToM3 from
that generic class and add all the AToM3-dependent functionalities.
Professor Vangheluwe said he's always in favor of modularity and not subclassing! We should not be thinking
object-oriented but we should think model-based. But my argument here is that we still don't
have a good formalism for modelling GUIs, and that's when we got into next point's discussion.
- GUI-specific Visual Modelling:
Professor Vangheluwe explained to me what
Shengjie has been working on. Professor Vangheluwe's idea for a GUI-specific visual modelling formalism can
be shown by his drawing below:
Then this single component can be combined with other components to form a more complex component.
You can think of the above component as an atomic DEVS and the more complex component as a
coupled DEVS.
Shengjie is taking care of building a library for GUI's widgets (the top-left corner in the
above drawing). As a proof of concept, she's also working on building a prototype of this
idea. After she's done with her work we can move into building a visual formalism environment
and its transformation rules. We also need to implement a complex GUI application using our
proposed formalism to show its applicability and then write a paper about this new
GUI-specific formalism.
- Course Selection (Fall 2005):
I registered for
COMP 533
and COMP 623. But Professor Vangheluwe told
me that Professor Kienzle might require
COMP 667 and not COMP 533 for the comprehensive exam. We need to confirm with Professor
Kienzle about that.
Action Items:
- Bug fixing:
- When scrolling the x and y coordinates get messed up! Denis said he might know what's going on.
- The select gesture doesn't select ink strokes.
- Code Convention:
Need to read the Style Guide for Python Code,
summerize it, and prepare a presentation to be given in one of our MSDL Meetings.
- Pattern Recognition Engines:
As explained in my COMP 762's report, I need
to explore different alternatives to Rubine's recognizer.
- GUI-specific Visual Modelling:
The goal now is to try to expand Shengjie's work to
implement the above explained GUI-Specific formalism and try to publish a paper in
CHI 2006 about it.
- Course Selection (Fall 2005):
Need to confirm with Professor Kienzle on whether I
need COMP 667 or COMP 533 for my comprehensive exam.
|