Black&White Project
Black&White Project is a set of Kiwix tasks contracted by WMCH.
Deliverables
Kiwix for Sugar
Deliverables
- Portage of Kiwix for Sugar (100% finished, directly usable without major bug)
- Re-design of the user interface for a perfect integration and match of sugar guidelines.
- Compatibility with Sugar journal
- Documentation in the wiki of the sugar foundation
- Delivrance of an .xo file
- Integration of Kiwix as a Sugar-activity
Dates & Duration
- Start Date: September 5th
- Estimated Delivery Date: September 30th.
User Interface
Sugar is a special interface mainly used by the OLPC Project. It is designed primarily for educational purposes, targeting children with no computer experience and ranging from primary school to secondary school.
Kiwix is a complete desktop software with many features and capabilities. In order to integrate Kiwix properly within Sugar, we made the following U.I choices:
Tool Bar
The toolbar is the main out-of-context interface for the user. An icon on the toolbar is associated either to an action or displays a sub-toolbar. Those can not be chained (only one sub-toolbar level).
- Home
- Back
- Forward
- Display (quite common to display this as sub)
- Text Size Up
- Text Size Down
- Full Screen (remove toolbar completely)
- Copy
- Search in page
- Toggle bookmarks list
- Bookmark this page
- Options (drop down menu)
- Toggle Content Manager
- Open file
- Recently opened
- Random Article
- Help
- Save as...
- Purge history
- Quit
Tabs
While Sugar support tabs, we believe it's not appropriate to use them here.
Eventually decided to include them but without highlight on them.
Dropped features
The following features are not accessible from Sugar.
- Help
- About
- Report a bug
- Request a feature
- Tools/Integrity check
- Status bar
- Language switch
- Skin switch
- Select All
- Preferences? Currently it's in but I'm not sure it should.
- Full Bookmarks Manager (Simplified version exists though)
Sugar-specific features
- Bookmark list
- Journal entry for each page viewed
- Sugar activity + .xo package
- Neighborhood broadcast ???? not sure about that yet.
Screen shots
Kiwix displayed on the Sugar ring (home screen) because it's a favorite activity.
Otherwise, you need to go to the journal to launch it.
Kiwix just launched.
Back/Next and Mark page are on right of search bar to follow Surf activity convention.
Display toolbar activated. Gives access to Search in page, toggle bookmark bar, Zoom IN and Zoom OUT and Copy selection
The bookmark bar opened.
Notice that you Mark and un-mark a page by using the Star icon on top-right. If a page is marked, star goes yellow.
Bookmark list has been simplified.
Options menu gives access to all the non-direct actions possible. Maybe we can remove some items in it.
Sugarness
Bellow is a list of imaginable development regarding Sugar integration:
Item | Difficulty | Comment |
---|---|---|
Native Sugar U.I | Difficult | Requires reimplementing most U.I code (J.S) in Python.
Very unlikely that we'll properly maintain that over time. |
100% Look-alike U.I in gecko skin | Difficult | We can do something that's 70% like sugar but remaining
is very hard to achieve if possible. |
Journal Keep feature | Doable | Upon click on Keep, record the session + ability to reopen a session.
Session will contain:
|
Journal activity record | Easy | At quit, open the sugar activity entry dialog to add an entry to the journal
Journal is just a log of what users did. |
Bookmark | OK | Ability to mark pages, display a list of marked pages and click on them.
Bookmarks should persit over sessions |
See also
Compilation Farm
Setup
Researches
Our first researches were leading to Mozilla Tinderbox which seems to be the best alternative (but if you have a better idea, we are ready to discuss it):
- https://developer.mozilla.org/en/Tinderbox
- https://wiki.mozilla.org/Tinderbox:Tbox3_Setup
- http://www.johnkeiser.com/mozilla/tbox3.html
- http://jenkins-ci.org/
But, maybe BuildBot or Jenkins could also do the job!
Automatic compilation (architecture=x86)
Deliverables
- DVD launcher and installer for Windows 32/64 bits
- Kiwix for Windows 32/64 bits
- Kiwix static for GNU/Linux 32/64 bits
- Kiwix dmg for OSX 32/64 bits
- Kiwix static (portable ZIP files) for Windows, MacOSX and GNU/Linux 32/64 bits
- Debian unstable package for 32 et 64 bits in the official Debian repository
Dates & Duration
Start Date: October 3rd- Estimated Delivery Date:
October 28th.week 17 of 2012
Tasks
Windows Setup
- Document windows VM setup.
DVD launcher and installer for Windows 32/64 bits
- Windows Setup (64b)
- compilation
- Makefile
Kiwix for Windows 32/64 bits
- Windows Setup (64b)
Kiwix win32- Kiwix win64
Kiwix static for GNU/Linux 32/64 bits
Kiwix static linux32- Kiwix static linux64
- Makefile (cross compile?)
Kiwix dmg for OSX 32/64 bits
Kiwix dmg OSX 32- Kiwix XR 2.0+
- Kiwix dmg OSX 64
Kiwix static (portable ZIP files) for Windows, MacOSX and GNU/Linux 32/64 bits
- Makefile from binary dist.
Debian unstable package for 32 et 64 bits in the official Debian repository
- Fix deb
- add man pages
- follow-up upload with vasudev
- makefile kiwix-serve deb
Porting to Gecko2.0+
Current code is tied to Gecko 1.x API/ABI. As Gecko 1.9 is now getting pushed out of distributions, it is important for the sake of future maintenance that we update to Gecko2.0+
- XulRunner removed from Ubuntu 11.10+. Ubuntu decided to remove xulRunner package from its repositories. It means we will have to use Kiwix with Firefox instead of xulrunner.
- New registration API. Gecko 2+ has a new registration API with macros for backward compatibility with Gecko 1.9.
- ABI breaks every 6 weeks. Since Gecko 2.0, the binary compatibility is broken with each new major release (which happens every six weeks). It means we will have to compile a version of the components for each FF release.
- js-ctypes[1] is the recommended way. In order to avoid the burden of recompiling components for every FF release, Mozilla recommend the use of js-ctypes, a JS module which allows interaction between JS and C libraries.
- Porting our components to js-ctypes seems to be the best long-term move regarding Mozilla strategy.
- It will require a lot of work: rewrite a lot of the C++ code into JS and wrap all the C++ code into C code as js-ctypes only support C libraries calls.
- It probably makes sense to separate the low-level (C/C++) code from Mozilla in case we need to not use Gecko in the future or on another platform.
- It will probably ease a lot the compilation process on Windows as we won't need the Mozilla stuff.