welcome: please sign in

Upload page content

You can upload content for the page named below. If you change the page name, you can also upload content for another page. If the page name is empty, we derive the page name from the file name.

File to load page content from
Page name
Comment
What program is the main source of Conkeror's design philosophy?

location: Roadmap

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

maybe to-do

done

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.