[Conkeror] conkeror roadmap

[John J Foerch]

Hi everybody,

I'm writing to update everybody in the wider conkeror community about
the direction of the conkeror project, and recent and future changes.

* the repository

You may know about the `conkeror-xr' branch of the CVS repository. It
contains a version of conkeror that runs on the XULRunner platform
instead of as a firefox extension. As of yesterday (oct 16, 2007),
this is now the official development version, and it is in CVS
trunk. Development of conkeror as a firefox extension is abandoned,
but the code is still available in the CVS branch, `conkeror-ext'.

CVS trunk contains a relatively stable conkeror for xulrunner, but I
emphasize that it is still in a state of flux, and we have a long way
to go for the first release of conkeror as a xulrunner app.

CVS will also have a branch called `experimental' that will be used
for collaborating on bleeding edge code. Particularly drastic changes
to the program will be developed in `experimental' until deemed
correct and stable. We will endeavor to keep CVS trunk as stable as
possible.

* the wiki

The wiki will also be reorganized to reflect the new direction of the
project. The main content will be about the new conkeror, and a
section called ConkerorExt will be created to hold old content that
no longer applies to the xulrunner version.

That summarizes the state of the public repository and the wiki--now
on to the future of the program itself.

* redesign

Conkeror has always been essentially a `chrome application'. By that
term, I mean that all of the functionality of the program exists and
runs within the scope of the browser-frame's chrome. Each frame
(`window' in window-manager terminology) essentially has a separate
instance of conkeror running, with state completely independent of any
other frame. This design has several disadvantages. Your `conkerorrc'
script is run for each frame, not for the entire program. If you bind
a key in one frame, other frames would not be informed of that
binding. Likewise for any task where you would like to share state
between frames--conkeror does not provide an easy way to do it.

To overcome these limitations, we introduced an `application scope'
object. A reference to this object is defined in each frame as the
variable `conkeror'. The version of conkeror in CVS trunk has this
feature. Gradually, we are moving more and more functionality out of
chrome scope, and into application scope. Eventually, frames will do
very little work of their own. Most computation will take place in the
global application scope.

As you may well imagine, such a drastic redesign of the program at
such a fundametal level breaks a lot of code. This is is what the CVS
branch `experimental' is for. It will make it easier for us to
collaborate on changes that may temporarily break the program, but
without breaking CVS trunk.

* major features

Any program that sets emacs as its role model has big shoes to
fill. We have ambitious goals to turn conkeror into a truly powerful
browsing platform that provides emacs-like flexability to the realm of
the GUI web browser. This means conkeror has to be well-designed and
consistent from top to bottom, so complex features can be implemented
as abstractions from simpler features.

    * context menu

You may not have noticed the recent introduction of the context
menu. It is not (yet) enabled by default. A low level context module
handles collecting information about a DOM node to determine
operations relevant to its context. Then a higher level provides the
side-effects of the GUI popup. The intention with this division of
work is that other context interfaces can be written in the future
that do not depend on the mouse.

    * numbering

Numbered links will be replaced by a general purpose numbering module,
for numbering any grouping of element types you want.

    * special buffers

We want to have special buffers in conkeror for things like a download
manager, web history, messages, buffer list, and so on. There will be
an organized strategy for working with special buffers so they are
logically distinct from browser buffers.

    * window splitting

It would be great to have window splitting back, but don't get your
hopes up too high. I'm investigating the feasibility of this feature.

    * test suite

Conkeror will have a suite of unit tests and integration tests to help
control the complexity and give developers more confidence by
providing quick feedback about what is broken when we make changes to
the program. We have /a lot/ of tests to write.

Any questions?

signed,

John Foerch (RetroJ)