[Roadster] state of the roadster

Knight Walker kwalker at kobran.org
Thu Jul 6 13:17:20 PDT 2006


On Thu, 2006-07-06 at 08:04 -0300, Ian McIntosh wrote:
> First, personal: I am still in South America, but perhaps more settled
> now.  I would very much like to continue working on Roadster.

I'm glad to hear this, as I've seen many projects die when the
maintainer moves on or disappears.

> Up until this point, Roadster has had only a few people working on it.
> If Roadster is going to be a success, it'll take many more people
> contributing.

I'm all for allowing other people to contribute.  How do you propose to
go about it?

> So, this is a call for help!  This mailing list has 70+ subscribers now,
> and I'm hoping there are some people here who want to get involved.

I'm willing to help, but my coding skills are rusty, and I never really
learned interrupt-driven GUI programming, though I've taken a couple of
stabs at it.  Thus far all I've done is setup a cfg directory and
settings file for Roadster that lets me use an external MySQL database
(in hopes of integrating it in with stuff like Kismet) and falls back to
the embedded DB.  If you like, I can make a patch and e-mail it to you
and/or the list (I use Monotone as my VCS, and I can have it generate
one).

> In addition to bringing more people in, I'd like to reduce the scope of
> the project for version 1.0.

I'm all for getting something usable out, even if it's not v1.0.  There
are a lot of people out there that aren't programmers, but can beta
test, write docs, and even help with the mailing list.

> Version 1.0 feature proposal
> ============================
> 1) move map data loading (and rendering?) functionality to an external
> library (libroadster?)

Moving data retrieval and processing to an external library would be a
good idea, but I'm not sure about rendering.  From some of the other
projects I've worked on, it's useful to break up a program's
functionality along specific capabilities and put those into libraries.
What I mean is something along the lines of using a library
(libroadster) to load and correlate the data, retrieve and store
waypoints, and possibly something to talk to the GPS receiver; a
back-end if you will.  That frees up the programmer to use their own GUI
toolkit for the front end, allowing better integration to an embedded
environment (Opie uses QtEmbedded, GPE uses GTK+, Enlightenment uses the
EFL, others may use something else, and they generally are locked into
that particular toolkit).

> 2) external library will use a better (faster/smaller) data format (no
> more MySQL GIS) stored in a SQLite database

I'm interested in hearing how this would work.  I'm all for a
faster/smaller data format, but as I mentioned earlier, I would also
like to be able to integrate with other systems running on the same or
networked hardware.  Possibly some database abstraction layer that can
use either?

> 3) ability to zoom from street level to state/country level *quickly*
> (which probably means storing data at several levels-of-detail)

I'm also interested in hearing ideas for how this could be implemented,
particularly in light of "faster/smaller".

> 4) a new GUI in a high level language (C#, Ruby, Python?) with only
> basic map navigation functionality (mouse drag, edge scroll, zoom
> buttons, zoom rect tool, history back/forward buttons)

If we do have most of the functionality of Roadster in a library
(Especially if we can keep the dependencies of that library down), this
should be pretty easy (In comparison).  Depending on how it gets
written, this could make the GUI very customizable via plugins, scripts
or something similar.  I know some of the things you've posted about MS
Streets and Trips wish lists has given me quite a few ideas, but a lot
of my ideas wouldn't work so well for someone running it on a machine
with a lower-resolution screen (My target screen is about 800x480).

> I see this as a solid base for more advanced functionality, and we can
> decide later where it should be added (in the application, in the
> library, or as an application plugin).

Or as an external application that only needs specific functionality
from the library (e.g. a special RSS reader that updates my list of
friends' POI, or something that fetches weather/traffic information).

I'm all for getting the core functionality built and working and adding
on to it after we get the base stabilized/usable.

-KW



More information about the roadster mailing list