1.0

Since the UI Redesign (described below 2.0) has had some nontrivial problems come to light, and is further from realization than we originally expected, we've decided to work toward a 1.0 release, which will consist of important incremental improvements to the current master branch (conkeror 0.9.3). Additionally, since we have these two divergent branches of conkeror (master and decoupling), we've decided to switch to a traditional versioning scheme to help users and developers know at a glance what is going on with the project and how the different branches relate to each other. Master branch goes from version 0.9.3 to 1.0pre, and decoupling branch becomes 2.0pre. Following the traditional sequence, after pre comes alpha, then beta, then release candidates, and then a release. We will not necessarily go through all of these steps between prealpha and release, but will use them as necessary. It is my hope that adopting this versioning system will clear up all the confusion that surrounds Conkeror's versioning.

Another thing we will do is work toward having a Conkeror 1.0 manual. This will be an undertaking partly in reorganizing the Conkeror wiki, partly in adding documentation for things that have been overlooked in the past. Conkeror 1.0 will have its own section of the website so that Conkeror 2.0 can have its own. Not mixing the two manuals will greatly simplify documentation.

What's next is to decide what features we are targetting to finish before the 1.0 release. Here is the list, which will no doubt evolve as we go along during the prealpha period:

to-do

• does Info.plist need to be changed to support using Conkeror as a default browser on OS X?
• fix js warnings with XULRunner 9
• README file
• investigate direct management of startup-cache
• fix 'unfocus' when focused element has been hidden or removed from DOM
• refactor completers to be objects instead of functions
• make browser_object_top_frame and use it by default for view-source
• fix javascript: urls... they shouldn't become the url of the buffer

maybe to-do

• merge/redesign tab-bar and new-tabs (issue62)
• fix external edit when other commands called in same window (issue224)
• robust UI for unit testing
• run external commands with non-latin characters (issue222, issue292)
• transition away from conkeror-spawn-helper in cases where mozilla provides an alternative
• fix file-name completion (automatic use of "/" as separator) (issue77)
• fix browser_object_frames 0 when page is not yet loaded (issue281)
• content-policy: dynamic registration of content-policy component
• browser object corner cases (issue375)
• maybe remove 'save-page' (issue314)
• input system handle keyup and keydown wisely (issue159)
• redesign theme system (issue386)

done

• fix breakage in evaluate (issue360)

• try to fix 'JavaScript Warning: "reference to undefined property this.treeBoxObject.view"' (issue364)

• either fix youtube-mode or remove it
  • fixed
• fix the missing-scrollbar-in-first-buffer bug (issue351)
• redesign page-modes to be granularized instead of monolithic
• merge buffer-ordering
• "up" command should trim #fragment as one of its steps. (issue275)
• remove in_module (issue308)
• toString methods for important datatypes
• inline minibuffer url-panel (issue343)

2.0: UI Redesign

Conkeror 2.0 is planned to be a major rewrite of many parts of the program, including the way the GUI works. Work has begun, but it is a considerable way away from being usable for everyday web browsing. As this branch revisits many fundamental points of Conkeror's design, RC scripts from the current stable version of Conkeror will not be compatible with it. Because the branch entails big changes to so many parts of the program, we're also doing a lot of smaller changes as well, which in theory could be done in master branch, but this way we avoid writing them twice. When it stabilizes, it will therefore be a big step forward on many fronts, and users will only need to rewrite their RC once, rather than in stages. Some of the main features of the branch are listed below.

decoupling

The signal feature of the so-called "ui redesign" is buffer/window decoupling. Buffers will no longer be stuck in particular windows, but will be movable from one window to another. In fact, even the word "buffer" means something slightly different in the new branch. The buffer datatype is a container of state which can be displayed (attached) to a View in the GUI. The term is expanded, too, even minibuffers are a kind of buffer now.

layout, a.k.a. window splitting

The experimental branch contains a new module, layout, which is a datatype that arranges browsers and other GUI elements inside of a window.

contextualize minibuffer and input

Currently there is one minibuffer per window. This presents a problem as conkeror's ui becomes more flexible, if commands can run in other contexts and alter, move, or destroy buffers (or other stateful objects) being used by a minibuffer, conkeror's behavior is unpredictable. we considered globalizing the minibuffer and the input handler so that only one sequence could happen at a time, but actually it is preferable to keep the current flexibility of multiple minibuffers, but contextualize them. this means that a given input sequence, and minibuffer-state-stack, could be associated with a particular context, like a buffer, and have a lock on that context so that if anything else tried to modify it, the other command would either fail or gracefully override.

contextualize input system

Commands can be called from different contexts, on different targets. Commands can be called from windows (conkeror windows and potentially other kinds as well), command-line remoting, and on OS X, the menu system. Details to be worked out about coordinating these contexts. See above, "contexualize minibuffer and input".

context system

The current stable version of Conkeror has a great keymap system, which can accomodate a lot of flexibility in determining which keys are available for any given GUI configuration/focus. We expand on this, and generalize it, to make a new context system, where not only key bindings, but also commands and other things can be made available in the UI depending on the current focus.

define_command

Commands are no longer defined by interactive but by a new form called define_command, which differs substantially from the old one, and offers much more flexibility and expressive power in the UI.

internationalization

Help strings, prompts, and docstrings can all be internationalized. Docstrings bear some discussion. By design, they are inline in the source, in English as a form of code literacy. That will not be changed. However, docstrings in other languages can be stored in locale files, and help buffers can display the user's preferred language.

logging system

Not totally sure about this one yet, but the idea is to replace direct calls to dumpln and minibuffer.message, etc, with calls to a new function "log", which takes a log route, a message, and optional additional information. Log routes can be configured to send different kinds of information to specific targets. A *Messages* buffer may be part of this project.

redesign command line handling

A new command line handling system which accomodates calling commands in particular buffers, and loading urls in particular windows. Depends on contextualized input system.