Introduction
Screenshots
Mailing Lists and IRC
Alternative Browsers
Special Thanks
FAQ
Understanding Mnemonic
TODO list and ideas
Bug Reports
Download binaries
Platforms
Compiling Mnemonic
Other useful software
Core
Message modules
Library modules
Object modules
Coding Guidelines
Browse Source
Using CVS
Website questions to:
webmaster@mnemonic.org
Mnemonic questions to:
disc@mnemonic.org
| |
Have interesting ideas yourself? Let us know. Send mail to disc@mnemonic.org.
TODO list (well-defined projects)
|
These are the projects that we know have to be worked on some day.
Contact one of the mailing lists if you
feel like implementing one of these. A rough estimate of the
difficulty of each project is given.
- Cookie handling (moderate)
- Cookies should be parsed, and the client should pop up windows
to ask whether cookies should be accepted. A module to store
cookies and or accept/reject automatically should be written.
- HTTP header information window (moderate)
- It would be useful to have an information window that shows
all header information that was retrieved from the server (eg.
server name, date, expiration date etc.). A combination of a new
message type being emitted by the http module and some code in
the client module could achieve this.
- Cache installation documentation (easy)
- As we will not write our own disk cache software but instead
rely on eg. WWWOFFLE to be installed, it is probably useful if
setup of that cache software is described in a user-friendly
way. Links to .deb and .rpm packages should be collected too.
- Text-based interface (difficult)
- As the layout library API has more or less been frozen, it
may be interesting to write an ncurses-based client module to
show off modularity. There is some demo code already in the
lib-curseslayout module.
- Handle animated GIF and other multi-image formats (moderate)
- The lib-rasterimage library already reads animated GIF files, but
lib-gtklayout will have to be extended for periodic redraw.
One could of course argue that this is all evil and should be
banned from the web anyway...
- External helper module (easy to moderate)
- There is already some code in oil-helpers to spawn helper
programs for specific mime types that are not supported natively.
This will have to be finished (the message code is mostly there
already). Should probably be using the `run-mailcap' script as found
in the `mime-support' Debian package.
Brain dump (not so well-defined projects)
|
This section lists ideas that have come up on the mnemonic mailing
lists but did not immediately turn into well-defined concepts or
actual source code. They may range from very simple things to
pathetic day dreams. It's just a collection of random thoughts,
really.
- Info about HTML errors (moderate)
-
I had a thought. We should have an option in the preferences to turn
on debugging. I mean none of the browser except lynx supports HTML
debugging. This is one reason why there are so many bad pages. If
netscape said "Hey your code is not valid at line ... because ... not
allowed..." there would be fewer badly written pages. (Wouldn't be
surprised if my pages are invalid)
I think therefore that if we just made human readable debugging and
put them in a page so the user could read, they could alter their HTML
code. Otherwise they just look at the screen and say hey it worked!
- Mac port (long and difficult)
- Mac folks seem to be very unsatisfied with Mozilla, mostly
because of the UI issues. Therefore, if we're ever going to
port Mnemonic to a non-Unix platform, MacOS should be the
place to start.
- Secure HTTP (moderate to difficult): Steven
- I guess it's clear we need this at some point. Should of course
be based on an existing library.
- Alpha channel blending code (easy to moderate): Max
- To handle transparency and true alpha blending in
lib-(gtk)layout, we need support in lib-rasterimage for it.
This simply means being able to combine a given color with
an image with alpha channel, or to combine two images. Can
be written and tested independent of the other parts of mnemonic.
Technical issues and cleanup
|
- Parser modules cleanup
- The XML and CSS parsers should
move to lib-dom as to make that library useful outside of mnemonic
as well.
- Elimination of int8_t and bounds checking
- There are still a few places where we use int8_t and so on
instead of something bigger. If we keep them, we should check for overflows.
- TCP error code propagation
- The msg_network_status message can contain progress update info
as well fatal error codes. Most of the former are mnemonic status
types (`looking up', `connecting') but the errors are mostly copies
of errno.h. Remove the duplication of code for the latter.
- Library separation on the website
- It may be worthwhile to make separate pages for all the libraries
which do not show the mnemonic framework so prominently. It is probably
not very productive to also remove all dependence on the mnemonic-core
module, but it should be more clear from the web pages that all
lib modules only depend on mnemonic-core and can be used separately.
Note that we could market mnemonic-core as an alternative to the bulky
and C++ unfriendly libtool.
- OIL framework module
- Creation of an OIL module is rather complicated. Much work is
duplicated (eg. thread startup/shutdown, listening to stop messages,
thread-safe memory management and so on). Put this in a separate
base module. As a result, all current OILs will become very small.
Think of a better way to organise them.
|