Weekly reports for thesis DPPXVII
pre
weeks (1.2 - 12.2.10)
- getting to know Saros
- Eclipse and Plug-in background (reviewed)
- the videos, theses from C.Jacob, M.Rintsch and S.Ziller
- Code view
- event flow
- understanding code rules and conventions
- applied patterns
- Threading
- Jupiter and synchronization
- background to whiteboards
- checking existing whitboards (Groupboard, Coccinella, ReLaTe + see beyond)
- drawing, writing and mindmaps
- how to implement a whiteboard
- understanding Xpairtise and SWT example whiteboard
- SVG
- how to integrate it
- Saros' activity structure
- whiteboard implementation structure
- knowledge (overview)
- Test-first and test-driven development
- UX-Design, prototyping and iterative programming/testing
week (15.2 - 19.2.10)
- SVG as proper internal representation
- informing about libraries Batik and SVG Salamander
- read documentation of Batik and its uses (i.e. GMF)
- writing code snippets
- finishing a pencil whiteboard as Eclipse View using Batik (no Saros yet)
- first plan for diploma timetable
weekly reports
week 1 (4 days) (22.02.-26.02)
Activities
- Release manager
- prepare presentation
- understanding Batik and SVG
- how far is standardization respective SVG + XMPP
- general planning of the thesis
Literature
Problems
week 2 (actually 2 days, however, a lot of work at home) (01.03.-05.03)
Activities
- understanding Batik
- proper usage of UpdateManager and SVGGraphics2D
- distinguish between different possibilities to draw
- create DOM elements our own
- usage of SVGGraphicsD2
- usage of SVGShape
- batiks basic features: zoom, scroll and rotate
- add a vertical SWT Toolbar to snippet
- fixing bug #2958625
- learn about Saros invitation structure
- fixing user feedback when peer cancels
Literature
- Batik documentation
- SWT documentation
- finally after asking to many questions Eclipse Jobs API
Problems
- ill, much worse (wisdom tooth)
- fighting with SWT layouts
week 3 (5 days) (08.03.-12.03)
Activities
- add Tools structure to snippet
- support of batik's built-in zoom and pan
- Performance testing with batik
- Usage of SVGGraphics2D, SVGShape or manual creation of XML Elements
- Reason for AWT-Event-Queue delay (too many straight lines while using the pencil)
- try out to draw pencil on Graphics object first, to XML on mouse release only
- Shared XML Editing (SXE) as most supported SVG + XMPP approach
- protoXEP only; but experimentally used by the IMs Gajim, Psi and Miranda (obsolete)
- search mailing lists to follow the acutal state of standardization and known issues
- jabber Standards, proto-xep, Shared Editing and Gajim develop
Literature
week 4 (3 days) (15.03.-19.03)
Activities
- add IActivity and Saros manager infrastructure for distributed whiteboarding
- distributed editing works!
- contact initiators of Shared XML Editing protoXEP
- Joonas Govenius is not working on it anymore
- in his opinion SXE might be a little bit too verbose
- no response from Peter Saint-Andre yet
- current implementations like psi and gajim differ somehow
- try to contact psi's and gajim's developers list (no response yet)
- how to synchronize SWT scrollbars with batik
Literature
- batik, SWT and Saros documentation
Problems
- wisdom tooth extraction
- surprised how verbose it is to add an IActivity
- it does not seem to be easily possible to uncouple the whiteboard from Saros
weeks 5-9 (22.03.-21.04)
- virus, probably mononucleosis
weeks 9-10 (6 days) (22.04.-30.04)
- reintroduction to my work, catching up with current state of Saros
- Responses for SXE
- Psi uses an outdated version (no jingle for session negotiation)
- no time/interest to improve this
- that's why incompatible with Gajim which uses latest version
- found a new contact who tries to improve SXE and who would be interested to try check compatibility
- SXE not complete for our purpose yet (selection, blocking etc. messages)
- trying to fix batik rendering problems, especially while resizing
- even the simplest whiteboard has these problems. Response from batik mailing list: these are SWT Swing integration issues and they cannot help
- entering deep to batik rendering leads only to underlaying rendering engines:
- with Direct3D rendering cheesy and doubled painting occures, unusable
- with openGL the picture shakes verically while resizing
- in both cases batik rendering might get stucked while resizing, workarounds lead to ugly rendering/flickering and perform very bad
- no response yet form the gef-batik project
- start work on networklayer to change Socks5 as first choice and add IBB fallback
- studying Hennings smackx extension (good work!
Problems
- still not completely recovered
weeks 11 (6 days) (02.05.-07.05)
- still no responses for batik problems or SXE improvement and implementation
- GEF (Graphical Editing Framework)
- reintroducing myself to GEF (used to work with it)
- creating a simple whiteboard view, figure based, however, rectangular selection of freeform shapes
- GEF is the better solution, offers command stack, properties management, selection, doesn't have the problems of SWT integration. Batik offers a lot but difficult to use within eclipse (a bit hacky).
- Main problem: proper free-hand drawing
- introducing to Eclipse Sketch project (free-hand drawing pattern regocnition)
- published 28.04. only, would be a nice extension for any whiteboard for programmers
- Batik
- contacted Gerrit who used to work with GEF and batik and created the SVG composition eclipse plugin
- http://developer.berlios.de/projects/svgcompost
- batik rendering on graphical contexts (using GMF adapter), above transparent rectangular GEF figures (bounds)
- no freeform shapes, no drawing, a littly bit buggy
- advises to use GEF for batik because of GEF's editing modell
- Problem: DOM API is unhandy as modell in MVC pattern
- in the first moment SVG and batik is deferred
- if time, investigating to use DOM as GEFs modell representation
- waiting for answers for SXE improvement
- ECF
- I got familiar with the container and provider concept, some tutorial
- offers a kind of multi-IM integrated in eclipse
- views extendible by additional features
- XMPP support (without jingle)
- for jingle there exists a provider as part of a VoIP provider (GSoC project)
- MUC support
- it wouldn't take too much effort to write own providers for jingle, SOCKS5 and IBB
- However, XMPPConnection in Saros has more than 80 references, needs more investigation to estimate the effort if we ever want to switch to ECF
- networt refactoring
- introducing to Saros network layer
- adapting SOCKS5 and IBB to Transport-Conneciton concept
- helping Henning to find deadlock cause in IBB
Literature
- ECF documentation, GEF documentation and tutorials, smacks API
weeks 12 (3 days) (10.05.-14.05)
- debugging and refactoring the network layer
- improve smacks API changes (what is missing?)
- transport hierarchy
- getting SOCKS5 to work with IBB fallback
- study synchronization and take care of properly releasing resources
- improving mediated SOCKS5 connections if server only allows unidirectional connections
- wrapping two unidirectional connections in a bidirectional one if necessary
Literature
- smacks documentation, OpenFire documentation
- XEP 65 SOCKS5
- XEP 47 IBB
Problems
- ejabberd, saros-con.imp.fu-berlin.de, was configured wrong
- getting to know the APIs and network layer
- i.e. how to configure OpenFire or smacks properly
weeks 13 (5 days) (17.05.-21.05)
- refactoring Networklayer
- testing and fixing SOCKS5
- updating preference page to new network layer implementation
- deeper understanding of SOCKS5 mechanics and distinguishing necessary preferences
- applying preferences on reconnect
- change DataTransferManager to enable "force file transfer by chat"
Problems
- understanding static SMACK behavior
- deeper understanding of SOCKS5 mechanics lead to some doubled work
weeks 14 (5 days) (24.05.-28.05)
- finishing to implement preference page and preference mechanics
- some more refactoring and renaming in the network layer to avoid confusion
- removing unused classes and obsolete methods
- change to always try to establish a direct SOCKS5 connection
- establishing a connection from both side and discard one (if not needed for wrapping)
- testing
- find problems when using IBB
- dispose bytestreams in DISCONNECTING state
- studying proper locking of observer editor (Bug 2971277)
- drag and drop
- copy and paste
- possible solutions:
- deactivate these commands (does not work, get reset)
- disable the editor (does not work, gets reset)
- writing to eclipse platform mailing list, responses are pending
Problems
- reimplementing done work because of late understanding of the best practice respective SMACK
- editor preferences get reset without obvious reason
- we are locking the editor just by intercepting keys
Literature
- SWT, eclipse documentation and newsletter
weeks 15 (5 days) (31.05.-04.06)
- more work and tests with the network layer
- added simultaneous connection establishment from both sides to quickly achieve a working (direct) connection although establishing from one side only wouldn't work
- completing documentation and debug output
- GEF
- solution for continuous freehand drawing
- studying Sketch API again
- no option for us: painting on GC would get painted over by concurrent edits
- writing to GEF newsletter
- Studying GEFs code there results a proper solution: usage of feedback layer
- hacking existing code lead to a working result
- a proper implementation consists of adding specialized tool, edit policy, request and command classes for continuous drawing
- we might distribute this to GEF and Sketch afterward to achieve better compatibility
- testing for concurrency
- concurrent creation of new figures seems to work without graphical problems
- pending: concurrent modifications and consideration of proper lock-mechanisms
Literature
- learning more about Java concurrency for proper simultaneous connection establishment
- GEF code and API
- GEF newsletter
- Sketch API code
weeks 16 (6 days) (07.06.-12.06)
- improving network layer again
- catching exceptions if one connection establishment does not work, the other one can be used
- testing and trying to find out reasons for Ubuntu invitation delay and missing direct SOCKS5 connections
- considering model representation (this and next week):
- preliminary: stay SVG conform, for saving, loading sake and to develop a protocol for distributed XML editing
- Using prebuilt library classes and generate DOM only for saving
- SWT and draw2d
- hide concrete shape in drawing method, platform dependent (no independent XML editing protocol)
- AWT shapes
- platform independent representation and easier than DOM
- batik could be used to generate SVG from AWT shapes
- unfortunately AWT shapes do not maintain hierarchies
- however, transforming shapes to SVG and back didn't result very efficient
- custom implementation
- still the SVG has to be mapped and generated
- just to export to SVG, GMF and batik could be used, no loading
- reinventing the wheel
- Using DOM
- platform independent representation
- model might kept independent form concrete DOM implementation
- mapping
- searching a working SVG DTD
- using JAXB to generate JAVA classes
- very verbose, less flexible than plain DOM
- shared SVG editing only instead of shared XML editing
- plain DOM
- any XML will do it
- flexible
- best standardization approach might be to use DOM Level 2 Event Model
- generate infrastructure using model-based software engineering
- details:
- generating a Ecore Model from SVG DTD
- using openArchitectureWare to generate infrastructure
- only editor and mapping between draw2d figures has to be implemented
- all advantages of plain DOM
- reduces the effort to implement the verbose GEF infrastructure
- easier to stay SVG compatible (hierarchy is given by Ecore Model)
Literature
Problems
- Understanding complex DOM API
- finding an error free SVG DTD
weeks 17 (5 days) (14.06.-18.06)
- considering model representation (continue)
- creating working GEF prototype without distribution
- postponing concrete model representation
- still need to know more about DOM, XML-Java Mapping and code generation, especially the DOM Event Model
- model prototype to evaluate different approaches:
- wrapping the DOM in Java beans using property supports and listeners
- implementing GEF infrastructure, copy, paste, undo and redo
- not yet working completely
- adding rectangle tool
- implementing freehand drawing tool, edit policy, commands
- presenting current state
Literature
weeks 18 (3 days) (21.06.-23.06)
- Fixing GEF editor and implementing left over work
- copy, paste, undo and redo works as well as zoom
- start to add collaborative working feature to model
Problems
- using GEF editor infrastructure in ViewPart
- i.e. static zoom combo box, retarget actions, toolbar and selection issues
weeks 19 (3 days) (30.06.-02.07)
- GEF editor
- fixing pencil tool feedback with zoom and scroll,
- documenting, restructuring
- fixing network bugs:
- 3023491
- 3020135
- 3023695
- 3023576
- Stacktrace when establishing SOCKS5 bytestream connection
Problems
- 2 days sick, furthermore flatemate moved out from one day to another, had to buy new fritch and washer
weeks 20 (6 days) (04.07.-09.07)
- GEF Editor
- finish collaborative work model prototype
- adding ellipse tool, default sizes on drag'n'drop, pencil drop added (for convenience)
- cleaning whiteboard project
- removing tryouts and unused libraries like batik
- Testing
- fixing several small issues when working distributed
- cycling events
- doubled creation
- fix for getElementById() issues
- reducing the amount of events fired
- Studying DOM Level 2 event model
- a proper collaborative XML editing framework and communication protocol should be based on this event model
- offers standard naming for DOM mutation
- also selection and focus events
- preferable to SXE approach
Literature
Problems
- Several DOM API issues like getElementById() in Java that doesn't always work like expected
- interaction between undo, model and commands i.e. delete, undo, redo (mixed up order, pending) that doesn't allow using GEF API classes