wiki:Videos
Last modified 16 years ago Last modified on 08/17/09 18:22:39

Weekly Meetings

ITERATION_03

ITERATION_04

ITERATION_05

ITERATION_06

ITERATION_07

ITERATION_08

ITERATION_09

ITERATION_10

ITERATION_11

Discussions

In this video are explained our goals, what we strive to achieve, our challenges and how we shall proceed in order to create a product with high quality. It is recommended everyone to be familiar with this discussion.

Detailed log of the discussion is included below. 

Topics:

= pro_lib = - designed to help people! If they are not helping, either something should be fixed or people do not understand how to use it.
 * attibute - self responsible.
 * do not care about initializing order.
 * good practices:
  * defaulty constructors.
  * avoid final properties.
  * push updates - instead of updating things manually, provide these things the ability to auto-update.
  * avoid trying to use unconventionally the pro_lib since this is error prone.
 * Property improper use cases:
  * accessing an AutoProperty WILL NOT invoke its compute() method!
  * resource properties:
   * create method should depend on NOTHING => it is invoked once and will not update things.
   * setup methods are designed to keep things synchronized for people. @Setup may be put to split setup things in different methods, so that they are updated in groups.
   * destroy methods are not working.
 * List properties.

= core_modularity =
 * extensions are now sortable by comparator.

= base_visual =
 == layout ==
 == menus ==
 * this is a new module to split the layout and menus from the main.view things.

= base_skins =
 * provides things to simplify things that are registered for a single skin => currently a map with (id, value) entries.

= global things  =
 * few people have a global vision about things.
  * people should get a better overall idea.
 * supercool model.
   * not only implement a great library but find a task to actually use it and also do that task.
    * this will improve the library.
    * things that are error prone will appear.
 * the "not my task/class" problem (people tend to do only things that are tracked and planned):
  * the code is owned by everyone!
  * fix things that need to fixed in order to implement you things, otherwise the next revision of the task will fail.
  * if the things are complicated to be fixed, ask the others, make discussions about it.

During the three days of discussions at Sheraton Hotel between Astea Team and some of our oversea partners detailed information about all aspects of the project was given.

Project overview of Sophie 2.0 by the team leader which aims to introduce the product to Robert Abbott from Shift Global.

Discussion between Robert Abbott and Astea Team on which they discussed Sophie 2.0 logo drafts and basic visual wireframes of the future product.

Discussion about Sophie 2.0 user interface and some internal aspects of the project.

Discussion between Astea team and Robert Abbott about the vision and functionality of Sophie 2 website.

Milo gives details about the modules that he refactored, and explains his vision about improvement of the code quality.

  • common concept of mvc
    • model
    • view
    • controller
  • interactions among them
  • past attempts at integrating mvc in sophie2
    • R1
      • dark ages
      • pure MVC form
      • parallel model, view, controller hierarchies
    • R2
      • ProLib
      • customized form of MVC pattern
      • nonparaller model, view, controlelr hierarchies
      • examples of bad code/design
    • R3
      • model - same as R2
      • view
        • view shouldn't modify the model directly, it should fire an event
      • controller
        • only single class
        • a set of operation
        • enum of operations
        • each operation has two methods
          • defineFilter
            • define what kind of events this operation processes
          • handleEvent
            • returns boolean
            • gets the actual event
            • try to process it, return wheter the event was processed
          • sortkey of each operation
        • event description
          • OO approach (Swing/AWT)
            • grouping of similar events
            • decomposing into class hierarchy
          • EventR3
            • contextData
              • source - (component, etc.)
              • context - (a parent view for instance)
              • tip - (a corresponding model / bad design)
              • cause - other event (EventR3, Swing event etc.)
            • target / event specific data
              • eventId
                • Ids enum
                  • @EventParams
                • Place enum
              • params
          • enum InputEventR3
            • enum InputModifier
              • CTRL down, SHIFT down.. etc.
            • ModifierSet
              • immutable set of InputModifier fields
            • example:
              • @EventParams(ModifierSet.class) 
G0gOv pR0d\/cT10nZ pR0uDLy pR3s3nTs:

================ PART 2 ================

* base.visual [interaction]
 * app structure / doc structure correspondence for visuals
 * interaction is put in skins
  * sample of what you usually put in a skin
  * sample of how you add interaction maps in a skin
  * interaction maps "string language"
  * skins are meant to be written to/read from human readable string configuration files
  * brief skin explanation
 * (input -> user events) map
[continued in PART 3]...

G0gOv pR0d\/cT10nZ pR0uDLy pR3s3nTs:

================ PART 3 ================
* base.skins 
 * brief skins content description
 * brief value lookup scheme in skin hierarchy
 * each skin is consisted of SkinParts
 * @SkinPartDef
 * SkinPropId
 * @SkinElementId

...[continued from PART 2]
 * userEvents
 * events/operations/interaction maps relation
 * SwingEventAdapter

* base.model.text
 * brief overview
 * HotText
  * list of HotUnit
 * HotPos
 * HotTextLayout
 * HotTextPane
 * HotStyleDef
 * HotStyle
 * sample use cases and solutions
  • base.persistence
    • overall description
    • current format structure
    • different formats
    • different entities
      • resourses
      • immutables
      • Pro*
    • Storage
      • like XML DOM
      • used as an internal data format
      • attributes
      • children tags
    • PersistFormat <S,T>
      • S - source type
      • T - destination type
      • converts between two types
    • general saving/loading overheads
    • SharedSaver
      • saves<T> in Storage
      • T - Page, Frame...
      • single saver for each type
      • save scenario
        • traverse everything and save it
    • SharedLoader
      • multiple loaders for different instances of each type
      • load scenario
        • create "blank" objects for each loaded entity
        • fill in dependencies between objects
    • savers/loaders and extensions/extension points
    • @Persist
      • save this as something
      • could list multiple @Persist for same field for different target formats
    • content to be persisted/not persisted
    • saving/loading immutables
    • saving/loading Pro*
  • core.modularity
    • modularization
    • modules
      • different understanding of modules, depending on context
        • classes, packages, source files, .jars, eclipse projects, maven projects, plugins, components
        • comparison
    • dependencies between modules
      • cyclic dependencies
      • target could be acyclic graph
      • sample scenario of registering a TetrisFrame
        • sample solution
        • works but could be better
    • uml notations
      • module
      • extension
      • extension point
      • TetrisFrame scenario adapter to these concepts
      • scenes examples
    • core.modularity module
      • content
        • SophieModule
        • SophieExtension <T>
        • SophieExtensionPoint <T>
      • comparison with OSGI
        • convention for such concept
        • hides OSGI complexity
        • FakeModule registry
          • can run in a fake environment
          • provides a simulation of what happens when app is deployed in an OSGI container
        • TrueModule registry
      • content
        • SophieModule
          • doStart(), doStop() - shouldn't have to be overriden
          • defineExtensions(), defineExtensionPoints() - should be overriden
        • SophieExtension <T>
          • sortKeys (not present still, will be in the future)
        • SophieExtensionPoint <T>
          • ProList of extensions, so it's tracked and easy to use
        • communication class/interface between extensions and extension points
          • extension which provides an Integer doesn't work with extension point which requires Number, should be exactly the same
        • matching extensions with extension points
          • currently each provided extension maps to each possible extension points which accepts it
    • Felix, Maven
      • terminology
      • pom.xml
      • module naming convention
      • accessibility of packages
      • embedding external modules
      • embedding vs depending
      • can have classes with the same name in different modules
        • example leading to runtime error
    • creating a module
      • use proto.project
        • remove .svn entries
      • fix pom.xml of module
      • fix pom.xml of parent module
      • documented in the wiki

(continued in PART 2...)

...(continued from PART 1)

  • the future
    • list of modules (for displaying in UI for instance)
    • mechanism of accessing resourses in the modules
  • platform structure
    • current structure (in Eclipse)
    • planned final structure
  • base.visual
    • VisualElement
      • parent
      • title
      • tooltip
    • VisualElement hierarchy
    • BaseVisualElement
      • getSkinValue()
      • computePropElement()
      • computeListProp()
      • findParent()
    • VisualProvider
    • SimpleVisualProvider
    • AutoVisualProvider
    • @VisualDef
      • could be used for multiple needs
    • @Related
      • tells the AutoVisualProvided which classes to scan for extensions to register
    • palette tracking current book example
    • short AutoProperty discussion
  • base.scenes
    • short description
    • starting and stopping needed modules
    • not enough time...
  • base.model.text
    • check the discussion from 2009-02-17, part 3, for introduction of base.model.text
    • HotStyleDef
      • push and pop
      • for example, push "bold" in some position and then pop it later
      • do not be misled - this is not like in HTML, where you can do things like (b)(i)(/b)(/i)
      • you can get the style for a given position
    • some languages are a challenge
      • example: right-to-left languages
        • some text in English, that is written left-to-right; then some text in Arabic, which is written right-to-left
        • visually this appears as: EnglishLetter1, EnglishLetter2, EnglishLetter3, ArabicLetter3, ArabicLetter2, ArabicLetter1
        • if we select last two English letters and first two Arabic (ArabicLetter1 and ArabicLetter2), the selection is visually not continuous
      • some languages are more complex - Chinese characters are traditionally arranged in vertical columns, read from top to bottom down a column, and right to left across columns
      • even more complex: what if someone mixes English, Arabic and Chinese?
      • another challenge: the baseline is not always below the characters, even in horizontally written languages
    • text replacing
      • primitive: replaceText(HotPos from, HotPos to, List<HotUnit> replacement)
        • steps:
          • fix positions
          • delete/undelete positions
          • fix styles
          • fix element nesting (begin paragraph, etc.)
          • actual replace
        • the replacement can have positions, but they can be nulls also
    • some considerations about the positions:
      • if you cut and then paste some text, the positions will remain the same
      • if you cut some text and then paste it twice, the second copy must not contain the same positions; instead, new positions should be generated
    • text layout
      • this is the hardest part
      • purpose: to find a position for each element of a text that has to be rendered in a shape
      • trees won't be used here too
      • generally the text should be displayed in a concave polygon.
        • thus some lines may be splitted in different segments (watch the video for an example)
      • sometimes we want a line to be slightly shrinked, thus not allowing a single short word on the next line
      • text layout algorithm
        • popular software uses greedy algorithm, which does not always produce good looking text; also they use plenty of if-then-else rules
        • in Sophie 2 the text layout problem will be reduced to finding a minimal path in directed acyclic graph
          • price function: badness of a layout; the algorithm has to generate a layout with minimal badness
            • for example, if a word has to be stretched two times, the badness would be high
            • another example: if a line has to shrinked slightly so the last word of the text fits on the same line, the badness would be low
          • one of the advantages using this algorithm is that finding path is well-known problem and there are many optimizations
            • we can use dynamic programming, A*, etc.
          • state (vertex in the graph)
            • each state has a range - start and end position
            • in the beginning they represent the whole text
            • after each step the start position is shifted right
            • each state can have several ancestors
              • for example, we can put a char on the current line, or we can break the line
              • for each choice the badness is calculated
          • the graph is virtual, because it is huge
          • number of states is decreased in we have breaks, for example page breaks
  • extra.pdf
    • this is related to PDF frames - the user can insert PDF content, the same way that he can insert an image
    • new module: extra.pdf
      • other layers, such as core, base and main, must not know anything about PDFs
      • if you have to modify these layers in order to integrate your extra functionality, then something is wrong in these layers
    • PdfFrameContent
    • PdfContentView, which is related to scenes
    • PdfResource extends (Book)Resource
      • may contain origin - the pdf file that is imported
      • this functionality is common for other resource, like images, audio and video, so we have to deal with this
    • Saver/Loader
    • GUI: the end user should be able to:
      • select a page
      • zoom a page and select which portion of it should be displayed (if the frame is smaller)
        • the same applies for images
  • base.scenes
    • SceneElement - base interface
      • extended by interfaces
        • ImageSceneElement
        • ShapeSceneElement
        • ContourSceneElement
        • AudioSceneElement
        • VideoSceneElement
        • CompositeSceneElement
        • SwingSceneElement
        • maybe other
      • in most cases this element is visible
      • scene - just a tree (in some cases - directed acyclic graph)
      • root element with properties and children, which also have children...
      • scene elements have no parent link
      • all coordinates in scenes are floating point numbers
      • example: page with two frames, one of them is an ImageFrame, with image, padding and border
        • in outline mode we have also margin bounds, padding bounds, middle of the border; margin is always invisible
          • we need thes in cases of transparent images
      • scene tree
        • first level: node for all frames and node for the page background (not the whole page)
        • each frame is ancestor of the frames node
        • each frame has the following children:
          • background
          • content
          • border
          • in outline mode - some other elements (ContourSceneElement)
          • the order of the children is important! It will determine the z-order - first the background is drawn, then the content, finally the border
      • properties:
        • subElements - not only for CompositeSceneElement; for example, ImageSceneElement has subelements...
        • space - transformation matrix
          • for most elements this will be the identity
          • for zoom - detect the root level and change its space, for instance scale with 0.5; only there, that's enough
          • from the root to the leaves the matrices are multiplied...
          • the coordinates are similar to CSS - (0,0) is the left-upper corner of the content; if we have a border, part of it will have negative coordinates
        • color
          • ImmColor - floating point Alpha-RGB; default - 1,1,1,1 (white)
          • can be fill color for a shape, can be color of contour, etc.
        • effects
          • for example - shadows
          • currently there are no effects
        • controller - not discussed, will be changed, for interaction?
        • clip() - for example, we have a big image element and we want to show only part of it; define clipping shape
      • scene elements has no names
    • ImageSceneElement has a reference to ImmImage
    • scene element implementation: override some methods:
      • setupElements() { subElements().clear(); add.... }
      • setupStatic() - for example - color
      • setupDynamic() - things that you expect to change; for example, color().set(isSelected ? HALF_BLUE : WHITE)
      • This is just a convention, but it is a good idea to separate things into different setup methods
    • currently there is one implementation - main.scene.simple
      • SceneVisualElement
      • SimpleSceneVisual
      • quite short implementation
      • implementation helpers - base.scene.model
    • visible area != responce area
  • changes (discussion in Bulgarian)
    • r2 = r1.getSpace().getRevision(13) - returns a new resource with new id, parent=null?
    • currently redo=register, but that's not good
    • History
    • Change
    • skip changes...
    • ChangeServer, LocalChangeServer
    • UndoManager
      • undo(resource)
      • redo
      • getUndoDescription
      • getRedoDescription