Kizby: The First Commercial e4 Based Application
Join the DZone community and get the full member experience.Join For Free
while reading through the e4 mailing list, there was one post that caught my attention - a commercial product based on e4 called kizby. considering that e4 is still a relatively new framework, i was intrigued to find out more about why they chose e4 and whether they had any problems adopting the technology. i contacted brian de alwis, the man behind it all, to find out more.
dzone: could you introduce yourself please?
brian de alwis: i'm the founder of manumitting technologies, and currently the only full-time employee.
in terms of experience, i've been developing on eclipse for about 5 years or so, primarily developing plugins for my phd work. i was actually a fellow phd student with mik kersten (of mylyn/tasktop); we were both supervised by gail murphy. before my phd i did a master's with gregor kiczales for which i created an aop language binding for smalltalk. prior to that i worked for oti (after its acquisition by ibm) primarily on distributed systems, but also on the precursor to eclipse. more recently i worked with the hci lab at the university of saskatchewan on distributed gaming prototypes and toolkits.
dzone: what does kizby do?
brian de alwis: kizby is a project and task management tool that scales to large, complicated workloads. as its motto says, kizby aims to "rescue your task list" by combining the strengths of a project planning app for managing the big picture, a todo list for breaking down work, and a notebook for capturing everything else, such as the notes, links, files, and other specialized information associated with a project.
dzone: you chose e4 as your base technology. had you considered anything else before this?
brian de alwis:
with the big push to mobile and online webapps, i had given some serious thought to pursuing a web-based approach. although there are some amazing frameworks out there, it’s impossible to get the rich interaction of a desktop app. one of the reasons i initially came across e4 was its early hopes for single-sourcing as a desktop app and a web-app. that push was taken up more by rap.
having a cross-platform app was important: i'm now a mac guy, but i still use unix a lot. i did consider some non-java solutions, like objective-c — there are some cocoa porting libraries for windows — but it involved a lot of unknowns. and i quickly rejected a c#/.net-based approach: mono works well, but the resulting guis look terrible.
i chose e4 as it promised to move away from the eclipse rcp look-n-feel. most rcp apps *look* like rcp apps. e4's styling and pluggable rendering framework can help towards looking and feeling like a native platform app. i’d say i’ve been moderately successful: kizby kind of feels like a native mac app (which has the most stringent guidelines). i have some changes planned for e4 to improve the mac look and feel.
dzone: how easy was working with e4, given that it's still early days for the framework?
brian de alwis:
although i had a pretty strong e3.x background, i didn't have much experience with creating standalone rcp apps, and hadn’t kept on top of changes that came through in 3.4 and 3.5. i started working on kizby last year just as the e4 group was starting to push towards getting out e4 1.0. i asked questions, found and diagnosed tricky bugs, contributed patches, and since become a committer on the project.
moving to e4 is both easy and difficult.
it’s easy as most of the eclipse application services are unchanged — e4 only changes the workbench ui model.
it’s difficult as the new workbench model (called the modelled workbench) is *very* different. and unfortunately we haven't done a good job in creating and maintaining documentation.
i should also note that e4 provides a e3.x compatibility layer. if you download the eclipse sdk for 4.0 or 4.1, you're running the classic e3.x code using the compatibility layer. the layer is not intended to be bug-compatible, but the compatibility team have done an amazing job in seeking out and addressing any issues. assuming your code doesn't rely on undocumented apis, you should have very few changes required to start moving to e4.
tom schindl has also done some great investigative work to allow e4-based views and editors to work within eclipse 3.x.
dzone: did you have any major problems?
brian de alwis: the use of dependency injection to obtain services was a bit of a shock at first. but i’ve since come to love it. no more violations of the law of demeter to find the status line manager! (but there’s also no standard status line manager built into the model.) injection of preference values is so nice.
building a pure e4 app can be difficult as there are useful framework pieces in org.eclipse.ui and org.eclipse.ui.workbench that are now out of bounds for pure e4 apps. ideally these useful pieces could/should be moved into jface.
one problem for me was that it was unclear how extensive e4 was gong to change eclipse. the early planning documents talked of changing the entire world. but many of the changes were adopted by the respective teams and became part of the evolution to 3.6 and 3.7. and the e4 modelled workbench apis are now being stablized — 4.1 will lock the apis down.
most of the difficulties we’ve had in getting kizby out have *not* been related to e4-based issues. i still had to do a lot of swt tweaking and hacking; swt and jface are amazing toolkits, but scrolledcomposite is the bane of my life.
dzone: could you share an architecture overview of kizby with us?
brian de alwis: kizby is a fairly traditional database-backed client. kizby sits on a custom transactional persistence layer over top of a lucene repository. in hindsight, i perhaps should have used one of the nosql dbs, but it was fun working on it.
there is a p2-based updating system. since it's a pure e4 app, i couldn't use any of the p2 ui framework.
dzone: what are your plans for the future?
brian de alwis: we currently have two variants of kizby. we have another 2 variants planned to add additional functionality for managing resources associated with projects. we'd also look to handling the mobile aspect too.
my longer-term ambitions is for kizby to evolve from helping your rescue your task list to rescuing user-generated information. i've had several occasions recently where i've looked for but failed to find a conversation or some other content that i *know* i created somewhere, but i couldn't remember how or where the conversation was held (im, email, or google wave). we have so many venues for communication — im chats, facebook, email — now that our information is so easily lost. and with web 2.0, much of what we create content lives and dies with the hosting site. desktop-search apps like spotlight or google desktop search can't help when these conversations happen through web apps.
Opinions expressed by DZone contributors are their own.