GSoC 2015 with FOSSASIA – Mid-term report

TL;DR No Chicken Little, the sky is not falling.

Well. I’ve been selected for GSoC under organization FOSSASIA and I am working on the project sTeam Collaboration platform, mentored by awesome guys Martin and Aruna.

It is mid term already and as planned I am half way through the project. If you haven’t seen my past blogposts, go check them out to get clear idea of the project.sTeam is a document based collaboration platform. There is already an existing web interface for the platform. Interestingly REST APIs are being developed for the same and we planned to rewrite the web interface with AngularJS and make calls to the REST APIs.

Technology stack

  • bower for easy management of external modules. There are a lot of sub modules which are to be loaded and are not part of the angular itself. Though, some of the modules are bloated. The unnecessary files will be removed by using bower prune task with gulp.
  • angular-ui-router for handling deep nested routes. Interesting thing is, angular-ui-router works on state based concept and is very handy to maintain and route to certain state.
  • angular-ui-bootstrap gives us easy to use, clean and responsive UI blocks.
  • angular-local-storage We use it for saving the user’s login credentials and are sent to the API with every REST based call. This would be changed in future and session maintenace should be developed.
  • textAngular is lightweight and two way bound WYSIWYG Text Editor for handling plain text files. It can also handle source code, markdown, etc ..
  • ng-audio and ng-video for viewing audio and video files respectively.


  • login and workarea are two base templates. And the router loads one of these based on the login credential value stored in local storage.
  • With workarea as base template, at this level, two nested views. Groups, which displays the groups which the user is part of and Private, where the user’s private documents are displayed.
  • The options view has various options like, permission management for the current level, copy, link, etc.. and also create room and document modals.
  • comments view fetches the comments for the current path. It is hidden if no permission to comment.


  • loginCtrl for passing the credentials to the API, authenticate and parellely store them in localStorage. And all the other calls will use the stored value along with its payload. You know, REST is stateless! Session management is scoped to the API and is planned for future.
  • handler has functions for CRUD operations on the API. The functions do GET, PUT, POST, DELETE, .. on the passed paramater (which is the path to the room/document) and will return the value.
  • router handles the routes. It has base states with views loaded into each states with its own templates and controllers.
  • The run methods load are used for state change control.
  • workareaCtrl handles the scope for options loading and current level display in breadcrumb.
  • workspaceCtrl fetches and controls the main workspace which has the rooms, documents and containers displayed.
  • config has the hostname where the sTeam is deployed and change here is reflected systemwide for easy deployment.

Road ahead

  • Depending on the type (room/document), the appropriate view should be loaded and when document, the viewer/editor wrt to the mime type should be loaded. Follow the issue here –
  • Implement search, document/room sorting based on Author, Title, document type and date.
  • Setup right sidebar which lists all the rooms (for easy navigation).
  • Settings popup for changes to attributes of the objects.
  • Automate tasks with certain gulp modules – gulp-angular-templatecache, gult-concat, gult-lint, gulp-uglify, ..
  • Write unit tests with mocha and chai.
  • Tidy up and add more documentation, which is already being done here –

Apart, we do scrum meet everyday. Check out the logs –

Currently, node-static module is used to serve the app and our development server is hosted in azure –

Note: The project is heavily under development and things might break.

Sign-up API is not implemented yet. Find some of the working screenshots below


Private workarea


Create room

Create document

Future plans

The REST APIs are under development and a lot of features are yet to be developed. I have a brief listing of the yet to be developed APIs and the list grows eventually as we figure out something is missing.

Thats all for now. Will get back soon!

searchQuick Apprise: THREE #GoogleSummerOfCode #FOSSASIA


The intended “searchQuick” (sQuick) is an application to enable a user to search a set of books or texts, like an encyclopedia, or some other topical book collection offline built in the open source platform Pharo 4.0.


After the GUI was designed with minimal features, the next task was to develop the cardinal search function.

Indubitably, a well-run search application/engine requires indexing.

Search Application/Engine Indexing basically collects, parses and stores data to facilitate fast and accurate information retrieval.

That being, the index for sQuick was built using the Dictionary data structure in Pharo which works like HashTable of other programming languages/platforms.

index := Dictionary new.

Pharo describes a Dictionary as: “I represent a set of elements that can be viewed from one of the two perspectives: a set of associations, or a container of values that are extremely named where the name can be any object that responds to =. The external name is referred to as the key. I inherit many operations from the Set. “

The contents of the text files present in the current Pharo image were split at whitespaces and added to the index along with the corresponding file title.

tokens := ‘ ‘ split: aDocument contents.

The method #indexFiles was used to iterate over all the text files in the current Pharo image to index all the files before the searching begins.


Dictionary Entries after File Content Indexing

The #queryString method has been temporarily build using #includesSubstring which matches the user input string with all the entries of the index and gives the result in an array form with #tally output as the number of search results.

Various test methods are now built to inspect the functioning of the methods designed. Continuous debugging is being done to check out and remove errors, if any 😉


  • Improve the indexing technique
  • Explore methods to quicken the search functionality
  • Integrate the search routine with the GUI already built
  • Design more test cases to develop a bug-free application

Stay tuned for more…
Post any queries , will be happy to help 🙂

TicTacToe Tutorial #FunWithPharo

reposted from

This tutorial has been included as a chapter in  Fun With Pharo!

Tic-tac-toe (or Noughts and crosses, Xs and Os) is a paper-and-pencil game for two players, X and O, who take turns marking the spaces in a 3×3 grid. The player who succeeds in placing three respective marks in a horizontal, vertical, or diagonal row wins the game.

Because of the simplicity of Tic-tac-toe, it is often used as a pedagogical tool for teaching the concepts of good sportsmanship and the branch of artificial intelligence that deals with the searching of game trees. It is straightforward to write a computer program to play Tic-tac-toe perfectly, to enumerate the 765 essentially different positions (the state space complexity), or the 26,830 possible games up to rotations and reflections (the game tree complexity) on this space.


So , here we make a Pharo version of this well-known game by using Morph. This post provides a step-by-step approach on how to go about building this simple application.


A game package will be built having 3 subclasses :

  • TicTacToe
  • TicTacToeCell
  • TicTacToeModel

Initially , we have created TicTacToe a subclass of the Object class. The subclasses we will make will be combined in the package game as mentioned in the category: parameter.

Object subclass: #TicTacToe
instanceVariableNames: 'container model'
classVariableNames: ''
poolDictionaries: ''
category: 'game'

A category name is not required in order for the class to work, but you will not be able to access the class to make changes or to look at existing code unless you provide a category name. (The category name used can be a new category name or the name of an existing category.)

The poolDictionaries: parameter is seldom used and will not be discussed here, and the category: parameter specifies the category under which this class will be grouped in the system browser.

As we know, a class encapsulates data values and methods, and every object contains a set of the data values and can receive any of the methods as a message. The data values in each object are specified by providing a set of names of variables whose values will be an object’s internal data values. Each object has its own set of these values, and the set of data values for an object represents the object’s state (or value). The variables that contain the data values of an object are called the instance variables for the object, and the instanceVariableNames: parameter is a list of names, separated by blanks, for the instance variables. In the above code snippet , we have declared container and model as two instanceVariables.

The classVariableNames: parameter lists the identifiers that are the names of variables shared by the class and all of its objects. That is, there is only one set of these, and they are used by the class and all of its objects. Class variables (so called because they belong to the class, of which there is only one, rather than to the objects that are instances of the class) are rarely needed.

An example of a class variable that could be useful is in a case where we wanted a unique “serial number” to be assigned to each instance of the class as it is created. The variable containing the next available (or last used) serial number would appropriately be a class variable, and each time a new instance (object) is created the serial number would be recorded as an instance variable value in the object and the serial number in the class variable would be incremented. Thus, each object can be serially numbered as it is created (without using one of those nasty global variables!).

After executing the code above, class TicTacToe will exist. However, it will have no methods other than those that are inherited from class Object. To make it useful, we must add the methods that are needed for our implementation.

Adding methods to classes :

The subClasses interact by passing messages through objects only.

container := Morph new 
              layoutPolicy: TableLayout new; 
              color: Color transparent.
model := TicTacToeModel new:3.
self addRows.
self addControls.

The notation TicTacToe>>#initialize means that we have a method named initialize in the subclass TicTacToe.

In the initialize: method above , we have a container which is the instance of the class Morph (Morphic is the name given to Pharo’s graphical interface. ). We define the various attributes of the container such as layoutPolicy: and color:. model is another instance of the class TicTacToeModel which we will be creating further in this example.

self refers to the receiver of the message. It is usually used within a method to send additional messages to the receiver. self is frequently used when it is desired to pass the sender object (self), as a message argument, to a receiver who requires knowledege of the sender or who will in some way manipulate the sender.

In short, self refers to the object itself that defines the method.

| rowMorph aCell rowCol |
1 to:3 do:[ :row |
rowMorph := Morph new layoutPolicy: RowLayout new.
1 to: 3 do: [ :col |
aCell := TicTacToeCell new.
aCell setModel: (model) row: row col: col.
rowMorph addMorph: aCell.
container addMorph: rowMorph.

The method addRows (the name is self explanatory) is used to add rows in the Tic Tac Toe grid. It declares temporary (local) variables rowMorph , aCell and rowCol which can’t be used beyond this method.

1 to:3 do:[ :row |

rowMorph := Morph new layoutPolicy: RowLayout new.

1 to: 3 do: [ :col |

aCell := TicTacToeCell new.

aCell setModel: (model) row: row col: col.

rowMorph addMorph: aCell.


The above code snippet works as a nested loop that runs thrice for each three rows to create a 3X3 grid as per requirement.

| rowMorph newGameButton exitGameButton |
rowMorph := Morph new 
             layoutPolicy: RowLayout new; 
             color: Color transparent.
newGameButton := self createCtrlLabelled: 'New'    onClickExecutes: [self restart].
exitGameButton := self createCtrlLabelled: 'Exit'  onClickExecutes: [container delete].
rowMorph addMorph: exitGameButton.
rowMorph addMorph: newGameButton.
container addMorph: rowMorph.

This method adds controls to the game. The local variables are : rowMorph , newGameButton and exitGameButton.

rowMorph defines an instance of the class Morph which would be the placeholder for the two control buttons located at the top. The two control buttons are defined as New using the variable new GameButton which on click would restart the game , and Exit using the exitGameButton which on click would close the game. The buttons are created using a method createCtrlLabelled which we define next.

rowMorph addMorph: newGameButton adds the button to the Morph instance created earlier.

TicTacToe>>#createCtrlLabelled: aString onClickExecutes: aBlock
| aCtrlButton |
aCtrlButton := SimpleButtonMorph new label: aString.
aCtrlButton color: (Color black alpha: 0.2).
aCtrlButton extent: 120@50.
aCtrlButton on: #click send: #value to: aBlock.

TicTacToe>>#createCtrlLabelled: aString onClickExecutes: aBlock method makes a simple button using Morph adds label and control to it.

container openInWindow.

The open method defines as to how the game/TicTacToe class would open. Here we have defined it to open in a dialog box.

container delete.
Smalltalk garbageCollect.
TicTacToe new open.

It closes the game and calls for Garbage Collection (Garbage Collection (GC) is a form of automatic memory management. It finds data objects in a program that cannot be accessed in the future and reclaims the resources used by those objects.)

SimpleButtonMorph subclass: #TicTacToeCell
instanceVariableNames: 'parentModel rowNum colNum'
classVariableNames: ''
poolDictionaries: ''
category: 'game'

Here a subclass TicTacToeCell is defind in the SimpleButtonMorph class with parentModel , rowNum and colNum as the instance variables. This class defines the button for each cell of the grid.

super initialize.
self label: ''.
self extent: 80@80.
self color: Color yellow .
self on: #click send: #value to: (self onClickExecutionBlock).

This initialize method initialises the button size as 80X80 and gives it the color: yellow. An ‘onClick’ control is given to the button which then calls the onClickExecutionBlock method present in the same class.

TicTacToeCell>>#setModel: ticTacToeModel row: aRow col: aCol
parentModel := ticTacToeModel.
rowNum := aRow.
colNum := aCol.

The setModel: row: col: takes three arguments ticTacToeModel , aRow and aCol. The parentModel is assigned ticTacToeModel , roNum becomes the value of aRow and similiarly colNum has the value aCol.

(self label size) == 0
self label: (parentModel updateAtRow: rowNum 
                Col: colNum).
parentModel checkWinCondition.
self extent: 80@80.

This method defines what should happen when each cell in the grid is clicked. At every click , the label of the cell is changed to X or O depending upon whose turn it is , the row numbers and coloumn numbers are updated in the parentModel and win condition is checked by calling the checkWinCondition method of the class TicTacToeModel defined next.

Matrix subclass: #TicTacToeModel
instanceVariableNames: 'filledCellCount currentFill winner'
classVariableNames: ''
poolDictionaries: ''
category: 'game'

A subclass TicTacToeModel is defined in the Matrix class with filledCellCount , currentFill and winner as the instance variables.

super initialize.
filledCellCount := 0.
currentFill := nil.
winner := nil.

This initialize methods defines that initially no cell in the grid is filled and there is no winner as of now.

TicTacToeModel>>#updateAtRow: r Col: c
currentFill == nil
ifTrue:[ currentFill := 'X'. ]
currentFill == 'X'
ifTrue: [ currentFill := 'O'. ]
ifFalse: [ currentFill := 'X'. ]
self at: r at: c put: currentFill.
filledCellCount := filledCellCount + 1.

The updateRowAt: Col: method takes two arguments r and c used to update the currentFill and filledCellCount variables.

filledCellCount >= 5 "for optimization. Win can occur minimum at 5th turn"
ifTrue: [
Transcript show: 'Yes'.
1 to: 3 do: [:idx |
self checkWinConditionInRow: idx.
self checkWinConditionInColumn: idx.
self checkWinConditionInDiagonals.
checkWinConditionInRow: rowNum
winner isNil
ifTrue: [
set := (self atRow: rowNum) asSet.
self checkWinConditionInSet: set

The method checkWinCondition is self explanatory. It is used to check if we have a winner or not at every move.

TicTacToeModel>>#checkWinConditionInColumn: colNum
winner isNil
ifTrue: [
set := (self atColumn: colNum) asSet.
self checkWinConditionInSet: set.
|set1 set2 |
winner isNil
ifTrue: [
set1 := (self diagonal) asSet.
set2 := Set newFrom: {(self at: 1 at: 3). (self at: 2 at: 2). (self at: 3 at: 1)} asOrderedCollection.
self checkWinConditionInSet: set1.
self checkWinConditionInSet: set2.
TicTacToeModel>>#checkWinConditionInSet: aSet
aSet size == 1
ifTrue: [
(aSet includes: 'X')
ifTrue: [
        winner := 'P1'. 
        Transcript open. 
        Transcript show: 'Player 1 is the winner!!'.

(aSet includes: 'O')

ifTrue: [
        winner := 'P2'.  
        Transcript open. 
        Transcript show: 'Player 2 is the winner!!'.


Now , we have made the game. To open the game , simply execute the following in the playground/workspace.

TicTacToe new open.

The messages : ‘Yes’ , ‘Player x is the winner’ will be displayed in the Transcript.

PS – This was just the basic implementation. I plan to improvise it further with graphics and other functionality/features.

Do like the post if it was helpful.
For any queries/suggestions please comment below.

Thank You

searchQuick Apprise: TWO #GoogleSummerOfCode #FOSSASIA


The intended “searchQuick” (sQuick) is an application to enable a user to search a set of books or texts, like an encyclopedia, or some other topical book collection offline built in the open source platform Pharo 4.0.


After building various mock-ups for a user friendly graphical interface for the application, the rudimentary features which would be present in the first release were finalized.

The chief features would include :

  • Search for word(s)
  • Browse files in the current image
  • Help or Tutorial
  • About section
  • Feedback or Suggestion Aid
  • Explore the code ( Cardinally Open Source 😉 )

Main Screen (copy)


At this moment, the most viable options available (apart from the use of GTSpotter, Rubric or Bloc suggested by developers on the forum and #pharo IRC) include:

  • The use of Spec to build the UI which provides a comparatively easier option to implement Button Click Actions, User Input Search String Retrieval etc. But the graphical interface designed by placing the widgets is not a very fancy one and dependent on the current theme of the image.
  • The Morphic GUI gives the application a very pretty look in comparison, however the user input search string retrieval method is not a straight-forward one and is under construction.

After considering various pros and cons, the suitable alternative is considered to be the one made with Morph as it gives a refreshing look to the application.


  • Completion of GUI development
  • Commencement of Index build

Stay tuned for more…
Post any queries , will be happy to help 🙂

Starting with Smalltalk, Pharo and Spec

reposted from

Hi !

It’s been a few weeks since I started with Smalltalk, Pharo and Spec. Under the guidance of Mr. Martin Bähr, Mr. Sean DeNigris and people from the #pharo community (@thierry, @kilon, @maxleske) I have been able to learn Pharo in a systematic way. I have implemented the knowledge gained by building a few simple desktop applications using the resources available online.

This post intends to clear all your doubt regarding the basic definitions of Smalltalk, Pharo and Spec.


Smalltalk is an object-oriented, dynamically typed, reflective programming language. It was designed and created in part for educational use, more so for constructionist learning. The language was first generally released as Smalltalk-80.

A Smalltalk environment is its own little world, designed around a conception of a computer with a minimal operating system and populated with living objects. A Smalltalk implementation is composed of an image (binary code), a major source file and a ‘changes’ file. The image is called Virtual Image (VI) because is independent form the platform you use for running Smalltalk. Smalltalk systems store the entire program state (including both Class and non-Class objects) in an image file. The image can then be loaded by the Smalltalk virtual machine to restore a Smalltalk-like system to a prior state.

As Sean DeNigris wrote to me: You may not realize it, but you have opened a portal to some of the greatest minds in the history of our industry. You have in your hands, not a programming language, but a live, dynamic, turtles-all-the-way-down environment designed to provide ‘support for the creative spirit in everyone’. More practically, Smalltalk is a programming tool that allows productivity unimaginable in most systems. And, if you put in enough time and effort to actually think in it, it will help you program better in any language you use.” ; Smalltalk is more dynamic and powerful than what one can think of.

Pharo is an open source implementation of the programming language and environment Smalltalk. Pharo is not Smalltalk. Pharo is Smalltalk-inspired.

Pharo offers strong live programming features such as immediate object manipulation, live update, and hot recompilation. Live programming environment is in the heart of the system. Pharo also supports advanced web development with frameworks such as Seaside and more recently Tide.

The official Pharo website defines it as: Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback (think IDE and OS rolled into one).

Pharo relies on a virtual machine that is written almost entirely in Smalltalk itself.

Spec is a simple framework for describing User Interface (UI) for Pharo Smalltalk. It takes a model and a layout description, runs it through an interpreter and a UI is produced as a result. All the widget implemented this can then immediately be reused as any other widget.

It also allows the separation of concerns between the different parts of the user interface as expressed in the MVP pattern. Spec emphasis the reuse of the widgets as well as their customization.

I hope now you have got the classifications of Smalltalk , Pharo , Spec all cleared up which remains a basic doubt in every beginners mind.


Visit the official Pharo website’s download tab to get the desired version of Pharo for the corresponding OS.

For a step by step tutorial describing various ways to install Pharo in your system visit the ‘Installing Pharo in many flavors’ blog written in a very systematic manner by Guille Polito.

Follow the steps as given in Spec Documentation to install Spec in a Pharo Image.


Visit to get more resources to study from.


PS  –  Watch out this blog for tutorials to build basic desktop applications in Pharo.

Do like the post if it was helpful.
For any queries/suggestions please comment below.

Thank You

searchQuick Apprise: ONE #GoogleSummerOfCode #FOSSASIA


The intended “searchQuick” (sQuick) is an application to enable a user to search a set of books or texts, like an encyclopedia, or some other topical book collection offline built in the open source platform Pharo 4.0.


In the inceptive coding period of this project development the tasks achieved are as:

    • Designing the basic graphical user interface using Morphs in Pharo 4.0. The morphs elements utilized to make the interface elements included:
      – TextMorph for labels etc.
      – PluggableTextMorph to display the contents of the file
      – ImageMorph for background, header GIFs etc.
      – TextMorphForEditView to enter the search string.
      – SimpleButtonMorphs for creating buttons whose click will perform the desired action.
      – MenuMorph , MenuItemMorph to make the list of files available as ‘Browse’ menu.
      – DropListMorph to make a drop down list menu for the selection of languages.
    • Loading the files in the current Pharo image and making methods/classes that would directly access those files from the image and display their names as a menu list
    • Making a Metacello Configuration of the project for easy project loading in Pharo.
    • For further ease, the project configuration was directly added to the Meta Repo of Pharo 4.0 at and now the project can be directly loaded through Configuration Browser in Pharo 4.0

                  World > Tools > Configuration Browser > sQuick(jigyasa)

    • Removing the cache of the instance of the MainInterface so as to allow the users to open up many search/content windows simultaneously
    • Making of a content window that would display the file name and the file content when the file name is clicked from the ‘Browse Files‘ menu
    • Designing mock-ups for the UI for an enhanced user interface which include the latest search engine feel



  • Augmenting the UI for a pleasant user experience
  • Initiate working on the search tool / indexer build.

Stay tuned for more…
Post any queries , will be happy to help 🙂

[Second Draft] Designing a document based collaboration interface

.. this post is the continuation of my first draft which you could find it here – I would ask you to go through the first draft before proceeding here, because here I’ve explained only the wireframes which are modified/tweaked, based on the comments on the first draft. This post is structured as /me resolving the comments on my first draft, with the new wireframes and explaining the reasons for modification.

Rooms could be nested

#1 : We could not enforce a topic/subtopic structure because rooms can be deeply nested. Topics and subtopics are all rooms. The users are free to organize the rooms as they wish. They could be topics, they could be something else. At every level, there may be documents and more rooms.

=> Removed topic/subtopic structure. As the rooms are completely nested, a room could contain any number of sub-rooms. Rooms and documents are analogous to folders and files. But wait, there are containers which are multi-part documents. To get the clear idea of what we mean by containers- refer to the discussion we had IRC log –

Shared and Private workarea

#2: The basic elements in sTeam are users, groups, rooms and documents. Each group has a workarea connected to it, and each user has a private workroom. Each user is a member of at least one group. So when a user enters the server, there are at least two rooms: the users private workarea, and the workarea of the group, that the user is a member of.

=> Workarea implemented. Under shared workarea, the user will get list of all rooms and documents which he got access to. Under private workarea he would get list of his private documents and rooms, which when shared will move to the shared workarea.

Shared Workarea

Shared Workarea - admin

Private Workarea

Private Workarea -admin

If you notice, you could create a room or document only in your private workarea. When you change permissions for a room/document in your private workarea, it would be pushed to shared workarea automatically.

Permissions are inherited

If a room has rw permissions, then everything inside the room also has rw permissions.

Room view – Level two

Room View - Level two

Notice the settings icon? Except for the first level, (levels are tracked by the level/stage bar) a user could change room/document attributes with the help ofsettings icon which pops up a window with following options.

Settings pop

The settings option appears only in the levels inner to level 1, because obviously, if the user is in the first level, he is not into any room.

#3: The user can move from room to room. The server keeps track of where the user is, and actions taken (such as creating a document) are relative to the users location. Users can pick up documents (the document is moved from the room, to the user itself), move to another room and drop the documents there.

=> When a document is selected, the copy and paste buttons (look at the above wireframe. buttons next to sort options) are activated. Clicking copy would copy the selected document, and allows you to paste it in any room (where you got access to) until the end of the session. Navigation between rooms could be done by clicking << button. It would popup the navigation sidebar on the right.

Sidebar Right

Also, if you wish to join any room, use the search bar. It would fetch you the list of rooms. Some rooms will not allow you to access the documents. Click on the user request icon next to room name, which would notify the room admin. When he gives you access, the room/document would be displayed in your shared workarea.

Search Results view

Search Results

Permission table

#4: A user should be able to insert objects without read and write permissions. One example where this is needed is to send your homework to your teacher. You get permission to insert into the teachers room, but once it’s in there, you can’t read it or write it anymore. It allows far more fine grained permissions than a unix system.

=> A permission button has been added to the ‘onClick of a Room’ view which will be available for the room admin and you.

In room view - Admin

For an admin, the permission table pop-up would look like the below wireframe (which is self-explanatory)

Permission table popup

Minor tweaks

Room sidebar removed

The room attached sidebar options has been moved to the settings popup. A detailed view of a room in any level would look like,

Room Detailed

Document View

In document level view, the following options are added,

  • Workarea bar
  • Delete document option (If access permits)
  • Permissions button

Document View

Guest view

A guest (who is not logged in) could view the rooms/documents. The view for a guest would look like,

Guest room view

PS: No changes have been made to Create room and Create document pop-ups.

Let me know what you think!

[First Draft] Designing a document based collaboration interface

This post is about my way of approach to develop User Interface for a document based collaboration platform. The Ideation is based on Martin’s thoughts, which you can find it here – . I would ask you to read the post and be back here.

The structure lives and evolves. and so do the documents. – Martin

Alright, You’re back! The primary goal was not to develop a separate admin panel. Rather the interface adds up extra admin options based on the permissions given to the logged-in user (Maybe, admin).

When I say admin, it means the authorized user who has Read/Write permissions and guest stands for non-authorized user who has only Read permissions.

As quoted, everything here would be documents, of any type (images, plain text, source code, ..) They should be structured into hierarchies. The admin/authorized user should be able to add new room, able to sort by Title/Author/Date, able to Re-arrange the documents, implemented as drag and drop.

![Home Admin && User ](

Each room should have

  • Topic
  • Description
  • Keywords

and good to have various other attributes which might explain the room well. The admin has a sidebar which options to perform CRUD (Create/Read/Update/Delete) operations on a room. The sidebar is hidden for guest user. The wireframe below is detailed/zoomed view of a room in the above image.

![Room – Detailed View Admin](

Creating a room asks for Room specific information. If you look at the wireframe below, they are self-explanatory. Permission would be set at this level whether it could be Shared/Private.

Create room

On click of a Room/Topic opens up the sub-topics under the room. The listing could be sorted and searched. Communication, being one of the major element for collaboration would be of comments. The admin gets to moderate (Approve/Delete) the comments. At this level, the comments are room-specific.

![onClick of Room Admin](

You should have noted the >> on the right. It opens up a sidebar with Room/Topic listing which then nests into Sub-topic listing. These are the doors which helps the user for hassle-free navigation between rooms.

Sidebar navigation - Right

The sub-topic ( as same as Topic) has description, keywords and various other attributes. The sidebar of options and Add Sub-topic for admins to perform CRUD operations on them. The Sub-topic sidebar would be hidden for guest user.

Sub-topic Detailed View

Considering the hierarchy as a tree, the leaf node be the document. A document could be of any type,

  • markup-text (markdown, html, others)
  • xml, json, csv
  • source-code
  • image
  • audio
  • video
  • binary
  • object (instance of a script)

Displaying the content of a document in the browser would be based on the type of the document. Anything text based, images and videos are displayed. For other binary files or objects, only metadata is displayed (owner, date of creation etc). And binaries would have a download link. Comments at this level is document specific.

At any level, one should be able to navigate to any room/topic (or) sub-topic with the help of the right sidebar drawer.

The admin has the following options for each document,

  • Link
  • Copy
  • Edit
  • Curate (based on document type)

.. whereas guest would have everything else other than Edit.

Link icon pops up a list of Rooms (where the present logged in user has access to) which on click results in adding a link of the document to the respective room. Edit icon opens up the editor only if the document type is of something which could be edited in a browser. A complete document could also be deleted. The interesting part is to distinguish the documents based on the document-type, visually. TheCurate icon pops up the list of documents in the specific room which are of the same document type as the currently viewed one.

Document View - Admin

A document would be displayed like the below wireframe for a guest user.

![Document View User](

Creating a document asks for document specific information and feature for uploading the document. I assumed MIME-Type would be automatically detected. Else, an option could be added. Permission could also be set at document level.

Create Document

With that said, if you have any suggestions (or) if I’m missing something here, please start the discussion below. Note that these are bare minimum wireframes and therefore would be slightly modified during implementation.

UPDATE: Uh oh! I missed containers. Expect a bit of restructure in my next draft.


Google Reunion in Silicon Valley with FOSSASIA

Being at the get together of more than 500 mentors and students of over 200 projects from 50 countries at the 10th anniversary of Google Summer of Code and join the celebrations at the Reunion 2014 is an amazing experience. It was the first time that Google brought together such a large number of contributors in Silicon Valley for a fantastic Unconference, a great day out at the “Great America” and a Gala at the San Jose Tech Museum with Linus Torvalds and a catering with an outstanding American Fusion cuisine.

Google Mentor Summit Tshirts

Yes, 10 years! Google Summer of Code is the only program of a company supporting hundreds of Open Source projects for many years and bringing them together with students from around the world. The magnitude of this support shows the real commitment of Google to Free and Open Source Software and I would like to thank everyone involved including Carol Smith, Cat Allman and Stephanie Taylor, and all the other fantastic people at the Open Source office supporting us.

The idea of free sharing and collaboration across borders has always inspired me. And I could not be happier to enter the conference room in San Jose – full of creators, developers, contributors of many amazing Open Source projects such as Mozilla, KDE, Python, Haiku, Blender, GNU, Debian, Inkscape and many more.

Google Reunion 2014 in San Jose with FOSSASIA

In previous years, the program brought together mentors of each active organization, but for this years celebration Google also flew in mentors of former years and even some students of the program. As an organizer of our annual FOSSASIA event I know what a challenge it can be to bring in a few dozen speakers from different parts of the world, but flying in 500 Open Source contributors from around the world is a logistic masterpiece. Organizing this event takes a huge amount effort and resources. Two thumbs up for the organizing team, they did an amazing job. I am grateful to be among the participants.

Great Day Out at the Great America

Every year the Mentor Summit spreads out in two days filled with interesting unconference sessions, lighting talks, and plenty of spaces for group discussing and code sprints. This time Carol and the team went an extra mile to surprise participants with an additional day-out at the Great America Theme Park (exclusively for us!). Believe it or not the majority of my lovely geek friends apparently have never been to an amusement park in their lives. We had such a great morning and afternoon there. I am sure some of us will never forget that very first roller coaster ride. It is great that Google makes this experience possible for mentors and appreciates their contributions.

Google Reunion 2014 in San Jose / Mentor Summit USA

Gala at the Tech Museum San Jose with Linus Torvalds

Another of the highlights of this year was the Gala at the Tech Museum in San Jose. Everyone dressed up in beautiful garments. It was fun to see all the developers who kind of always wear black shirts suddenly dressed up. And, on top of organizing everything the team also arranged a meetup with a star of the Free and Open Source community: Linus Torvalds joined us as a special guest. Of course Linus was everyones hero. And I was thrilled to meet him and Dirk Hohndel just before their talk. Sincerely thanks to Cat Allman for introducing him. I took the chance to invite them to our next FOSSASIA in Singapore, which will take place from March 13-15, 2015.

Linus Torvalds FOSSASIA Meetup at Google Reunion with Hong Phuc Dang, Dirk Hohndel, Mario Behling

After the interesting talks about the history of Linux, Open Source at Google and future projects, we experienced the interactive exhibits at the Tech Museum and enjoyed more of the yummy food. Coming from Asia, experiencing the food in the US is always very special for me. Especially in Silicon Valley and San Francisco I love the Fusion food, the blend of Western food and Asian cuisine. On the night of the party, the Google team really did arrange a fantastic catering with very friendly caterers, who knew a lot about all the different ingredients. I learned from Stephanie that this was one of the best catering companies and that they came all the way from San Francisco. It was truly special indeed.

Participants at the Reunion

Personally I was so excited to meet with the developer team of Processing at the Google Reunion. Processing is one of my favorite software applications. One team member – Andres Colubri from Argentina – told me he finally met his friend and co-developer whom he worked together with during the last 7 years but never got a chance to meet.

Some voices of participants of this years summit: Doris Lee, a first year GSoC from Taiwan said: ”The program is a great way to practice and apply what I have learned in programming. I took computer science at UC Berkeley but I never had the feeling I get the right assignments to work on. I enjoyed so much to work with GSoC program which gives me a chance to improve my coding skill, to learn how to use Git, Python and much more.”

Google Mentor Summit FOSSASIA, Hong Phuc Dang, Doris Lee

Adnan Zahid – 2nd year GSoC student also commented: “It is good that Google created the program for public benefits and I wish this program can be extended not only during summer but throughout the entire year. My suggestion is to create cooperation between Open Source projects and universities so that the schools constantly receive assignments and then distribute them to students”

Hamish Bowman from OSGeo said: “We are participating at GSoC for many years and I am happy to see new and old faces at the Reunion. For me the mentor summit is a chance to meet developers from projects, that we are using and working together with. Many of them, we would not be able to meet some anywhere else. After a long time, I had the chance to talk again with Mario Behling who is working with lots of projects and founded Lubuntu. It was great to see Mario’s excitement when I showed him our OSGeo Live distro which we build on top of Lubuntu.”

Google Reunion Hamish Bowman and Mario Behling Lubuntu Founder

I also spoke with one of the most senior mentors – Kevin Krammer from KDE, it was Kevin’s 10th time mentoring. He said: “This is a fantastic thing. I appreciate the opportunity to be mentor. I think we had very good students who have helped KDE a lot during the past few years. GSoC gives us the possibility to experiment new things for which we normally do not have enough resources and this is a great training opportunity as well.”


The closure Q&A session marked another year of GSoC was over. We are all looking forward to another 10, 20, 30 …years to come. Once again congratulations to GSoC 10th Anniversary!



Google Melange

GSoC Ideas 2014

FOSSASIA aims to participate in the Google Summer of Code 2014. We are working together with a number of Open Source developers in the region and function as an umbrella for different projects. If FOSSASIA gets accepted, you will find more information about the application procedure for students on this page.

The ideas list below gets updated continuously as students also submit ideas in the process. So, please check back again later. If you have your own idea or small project, please apply for FOSSASIA on the Google Summer of Code website!

If you have questions or feedback, please write to us on the mailing list:

We have four areas for our GSoC projects 2014:


Open Design Projects, Garments, Knitting


Develop 2D Body Measurement App

The goal of this project is to provide users with an Android app that assists them in measuring their body data for generating customized patterns. The measurements are taken according to standardized measure points which are usually used by tailors. The student needs to propose a design and step by step guide to collect the measurements of the user. The data will be saved to the app or as a file, with additional options to export data as a Google spreadsheet and submit data to a web service.

A draft of a file format has been developed. A sample part below:


Project: Valentina Patternmaking Project


Skill Level: Medium

Usefull skills: Android development, UI design, Java, formats, CSS, Phonegap or other framework

Mentors: Mario Behling [], Hong Phuc Dang



Develop a GUI for the Adafruit Knitting Machine Project

The goal of this student project is to facilitate the production process with the Brother KH-930e Knitting Machine, that can be controlled by Open Source software as below. Parts of the process require commandline experience and Python knowledge. In order to enable more knitting enthusiasts to use Open Source knitting machines, we hope to find a student that takes on the challenge and comes up with ideas to make this process easier. Below a video of the current work process and step by step descriptions.


Disk Drive/Computer Connection Notes

The external floppy drive for this machine was the same as a Tandy PDD1 (Portable Disk Drive 1). This drive is connected using a serial port. There is documentation on the internet about how to connect these drives to computers, but the connector pinout on the knitting machine is different than the drive, and I didn’t find that documentation to be helpful. I was able to figure out the connector pinout by examining the knitting machine PCB.

Knitting Machine/Computer Connection Notes

The knitting machine drive connection uses CMOS voltage levels, not RS-232. Here is the pinout of the drive connector on the knitting machine:

      |   |
|   |   |   |   |
| 7 | 5 | 3 | 1 |
|   |   |   |   |
| 8 | 6 | 4 | 2 |

The pin numbering is shown as they are labeled on the knitting machine PCB, and does not agree with other documents I found on the web.

Connector Pinout
Pin Signal I/O Notes
1 Ground    
2   Out Tied to 5, Pulled up through 1K resistor
3 CTS? In (Tie to pin 2)
4 No Connection    
5   Out Tied to 2, Pulled up through 1K resistor
6 RXD In  
7 TXD Out  
8 RTS? Out Follows state of Pin 3 (buffered)

Methods of connecting the knitting machine to a computer

Using a FTDI serial adapter cable (RECOMMENDED)

Using an FTDI adapter is the best way to assure that you are interfacing with the machine using the same signal voltages as the original external floppy drives. This is documented on this wiki page, which will someday be merged with this one.MProg only runs under windows.

Using a USB serial adapter WITH flow control

This is a method I have used extensively with one model of knitting machine, but I no longer recommend it. Although it does not require any additional hardware like a FTDI adapter, this method does not present the exact same voltage levels to the knitting machine as the external drives which were designed to work with the machine. Although I have not had any reports of problems, it is possible that this method could stress the knitting machine input circuitry, and therefore I think it is safest not to use it.

Cable connections with flow control
Knitter 9 pin connector
1 5
6 3
7 2
8 4

Using a USB serial adapter WITHOUT flow control

I have pulled pin 3 high, and am not using flow control in my software. I have not had problems with data loss while sending to the knitting machine, and the machine I am using is fast enough to always keep up with data received from the knitting machine. The data rate is 9600 bps, and the largest amount of data sent at once is 1024 bytes. Here is the cable I am using to connect the knitter with a USB 9 pin serial port:

Cable connections without flow control
Knitter 9 pin connector
1 5
2 tie to 3  
6 3
7 2

Software Interface Information

There are a number of documents on the web about the Tandy PDD1 and the serial API for it, Most of them are incomplete. The knitter places the drive into a mode called “FDC emulation Mode”, which allows access to raw sectors. This document is the most complete documentation I was able to find: Media:Tandy-Disk-Reference.pdf

External Disk Drive Emulator

I have written software that emulates the external disk. It runs under Linux and keeps the data as files on the linux file system. This allows knitting designs to be saved and restored using the emulation computer. I am using these files to reverse-engineer the knitting machine file format. The emulator is written in Python, and released under the GPL. It has been tested most extensively under Ubuntu Linux. I have reports that it does not work on windows due to problems with the serial library. It has been successfully run under OSX. If you have any information to add about platforms that it does or doesn’t work on, let me know and I will update this informationI am happy to work with people who are trying to use the emulator with different models of knitting machine, and hoep to improve compatibility with other machines. The source code is available in the git repository listed above. Software for manipulating Brother data file: I have begun a python class which will provide an API to the brother data files. Source code is in the git repo. Knitting Machine File Format: A lot of the file format is now understood. Documentation is in the git repo.Work on this continues.This work was greatly helped by prior work performed by John R. Hogerhuis and posted on the kminternals yahoo group.



BL5 Brotherlink 5 serial or USB cable Brotherlink information

Yahoo group dedicated to hacking brother machines

Brother Liberation Front is working on open source interfaces

Info and protocols for the FB-100 interface

KE-100 motor drive (not sure that this is the right model drive for the KH-930E)



More info:

Skill Level: Medium to High

Useful skills: Python, Knitting Patterns, Image design

Mentor: Mentors to be announced



Create search functions and import pattern functions for Valentina

Valentina is a development project to edit pattern files for garments and textiles. The goal of the student project is to implement a method to choose additional design items, e.g. different collar styles, and to add them into a pattern during development.  In addition, the user should have the capability to organize their created patterns into categories, and conduct searches of patterns based on this organization. 

The student would develop user functions to add search tags to patterns, search for patterns, and select patterns from search results to load into the currently open pattern.

Background: One of the main ideas of Valentina is to enable users to create custom sized patterns based on applying an individual’s measurement data to pattern formulas, independent of industry sizing standards. Similar industry software packages include Assyst (, Lektra (, Grafis (, plus others. Grafis in particular enables users to generate patterns based on formulas derived from pattern descriptions from standard books (e.g. books published by Mueller und Sohn.) Currently available industry software, however, does not aim at the DIY/maker or SME markets.

Project: Valentina Patternmaking Project


Skill Level: Medium

Usefull skills: Vector graphics, C++, Qt5, basic knowledge of garment patterns, basic knowledge of generating patterns from formulas

Mentors: Hong Phuc Dang to be announced



Port Valentina to different platforms, build packages and refactor code

Currently the installation process of Valentina is only semi-automatic on Linux and Windows. For MacOSX there is no port yet available. The goal of this project is to automate the build process for the major operating systems. Create a standard workflow for Windows .exe builds, create a MacOSX port and provide packages for the major Linux distributions. The challenge of this project is to work with a number of projects and partners. For example, it is possible to create .deb packages for Debian. In order to get the package accepted in the Debian repository, it is necessary to get approval of established Debian developers who verify that the package build was done according to best practices. Similar procedures are required for other distributions. The second part of this project is to refactor code and replace deprecated code including if constructions with switch. Please see below.

Many if constructions replace with switch.



For example:

QStringList arcs;
<< VToolArc::ToolType << VNodeArc::ToolType;

case 0:
// parse arc tag

case 1;
// parse node arc tag

// print warning


Mailing List:!forum/valentina-project-list

Skill Level: Medium

Usefull skills: C++, Qt , Windows exe build, MacOSX, Linux packaging

Mentors: to be announced



Add Design items and Measurement Tables for Patternshare

Patternshare is a development project of a web application to edit pattern files for garments and textiles. The goal of the student project is to implement the choice of additional design items, e.g. different collar styles, and to add them to the patterns. Patternshare users should be able to generate non-custom sizes on the fly and add their own measurements table in the app. Another required feature is to add specific design items or changes, e.g. starting from size 36 up to 42. In order to establish a suitable way to allow the sharing of patterns in an industry quality, patternshare needs to support these features and be able to import and export CAD files.

Background: One of the main ideas of patternshare is to offer a web service that enables people to edit patterns independently from standard sizes. Similar industry software packages including Assyst (, Lektra (, Grafis ( and other exist. Grafis in particular seems to generate patterns in the same way, that we do it in patternshare – based on formulars which are defined from pattern descriptions from standard books. Many standards defined in books from Mueller und Sohn for example. The current players do not aim at the maker and SME market.



Skill Level: Medium

Usefull skills: Implementation of Mathematical Algorithms, Javascript, Fabric,js, Rafael.js, HTML, vector graphics

Mentors: Hong Phuc Dang to be announced

Web and Mobile Development

Implement Post to Github in NGO photo app and develop a Jekyll/Markdown Website

The goal of this GsoC project is to develop functions, that allow users of the phimpme photo app to upload images to their gallery that uses Jekyll, Javascript and Markdown. The most well-known one sites using these technologies are github pages. The phimpme photo app connects to “any social service” and Open Source CMS. It was developed for development projects in South East Asia and Open Sourced recently. Phimpme is a beautiful photo app that already works with any web systems based on Drupal, Joomla and WordPress. Android and iOS versions exist.


Skill Level: Medium

Useful skills: Web Api, Android Development, HTML, Jekyll, Markdown, Knowledge of CMS

Mentor: Hon Nguyen [Vanhonit], Mentor 2 to be announced



Anonymous mode and autosharing for phimpme Android app

Implement an anonymous photo sharing mode with auto-connect options to nearby phone , computers and wifi nodes with public sharing capability. Bluetooth connectivity was already implemented in the app to support this future feature. The implementation of Wi-Fi direct would require to change the minimum required version for Android to version 4.1 (Jellybean). Some functions and libraries that are required for this project are already implemented partly for other services. The goal of this project is also to use existing libraries and extend or change them where necessary to keep the code base clean and small. To make full use of an anonymous sharing mode as many systems as possible should be supported, e.g. shared folders on PCs, public ftp and other phones. The requirements include that sharing works without an Internet connection (local networks without Internet and other devices are available to connect). At the beginning of the project we require the student to define a list of features he/she plans to develop during GSoC and a timeline.


Skill Level: Medium to High

Useful skills: Nearfield Communication, Wifi, Wi-Fi Direct, Bluetooth, ftp, avahi, Android Development, Java

Mentor: Mario Behling [], Andre Rebentisch []


Network and Mesh Technologies


Develop Web Interface Administration tool for large numbers of Nodes (routers) for OpenWrt based on kalua

Kalua is a hardware-independent OpenWRT-extension (using busybox-ash as main-language) for setting up, monitore and manage many, large wifi-mesh-networks for different locations including billing, captive portal / splash screen / weblogin, accounting, data retention and layer7/8-QoS. OpenWrt is a widely used Linux distribution for embedded devices and specifically routers. Large networks consist of hundreds and even thousand of nodes. Administration of routers, e.g. ESSID setting is a long process.

The goal of the project is to develop a new web interface to show the status of routers and enable mass administration of devices.

configure the builtin-packages

# the fast and easy automatic way:
kalua/openwrt-build/ set_build standard
make defconfig

# the way to understand what you are doing here:
make kernel_menuconfig      # will safe in 'build_dir/linux-${platform}/linux-${kernelversion}/.config'

    General setup ---> [*] Support for paging of anonymous memory (swap)
    Device Drivers ---> Staging drivers ---> [*] Compressed RAM block device support

make menuconfig         # will safe in '.config'

    Global build settings ---> [*] Compile the kernel with symbol table information

    Base system ---> busybox ---> Linux System Utilities ---> [*] mkswap
                                  [*] swaponoff
    Base system ---> [ ] firewall

    Network ---> Firewall ---> [*] iptables ---> [*] iptables-mod-ipopt
                             [*] iptables-mod-nat-extra

    Network ---> Routing and Redirection ---> [*] ip
    Network ---> Routing and Redirection ---> [*] olsrd ---> [*] olsrd-mod-arprefresh
                                 [*] olsrd-mod-jsoninfo
                                 [*] olsrd-mod-nameservice
                                 [*] olsrd-mod-txtinfo
                                 [*] olsrd-mod-watchdog
    Network ---> Web Servers/Proxies ---> [*] uhttpd
                          [*] uhttpd-mod-tls
                          [*] Build with debug messages

    Network ---> [*] ethtool    # if needed, e.g. 'Dell Truemobile 2300'
    Network ---> [*] mii-tool   # if needed, e.g. 'Ubiquiti Bullet M5'
    Network ---> [*] netperf
    Network ---> [*] ulogd ---> [*] ulogd-mod-extra     # if data retention needed

    Utilities ---> [*] px5g
               [*] rbcfg    # if needed, e.g. 'Linksys WRT54G/GS/GL'
  • usage
    • login via ssh
    • prepare the router by calling firmwarewget_prepare_for_lowmem_devices
    • fetch/copy firmware image to /tmp/fw
    • call firmwareburn

Useful Skills: Linux development, OpenWrt, Embedded devices, Web UI design, Gimp, Inkscape, Lua, Scripting

Skill Level: High


Mentor: Bastian Bittorf [], Mentor 2 – to be announced


Peer to Peer Technologies and Cryptography


OpenCoin Digital Cash App

OpenCoin is a true digital cash system, similar to the former DigiCash/eCash based on tokens and providing real anonymity. A prototype wallet app is already available and has been written in JavaScript. Project scope is to implement a mature wallet with additional features (e.g. p2p transactions, encrypted wallet, QR codes), better look and feel and plattform independent (e.g. C, JavaScript+PhoneGap) Make yourself familiar with the OpenCoin protocol Agree the feature set Develop and test the wallet

Project: ,

Skill Level: Medium

Usefull skills: Scala programming language, Twitter’s Finagle server, SBT build tool, Optional: Eclipse IDE is recommended, Optional: Coins are stored in a SQL database via squeryl library

Getting Started:

* Make yourself familiar with the OpenCoin protocol

* Agree the feature set

* Develop and test the wallet

Mentors: Jan Suhr [], Joerg Baach []