Re: [AD] [Win] Proposal

[Elias Pschernig <elias@xxxxxxxxxx>]

On Sun, 2007-01-21 at 23:22 +0100, Evert Glebbeek wrote:

> I've done the advertisement (on ACC) following a release once or twice, and 
> usually enough people are willing or interested in helping. The problem 
> is, they want something concrete to do then and there, which requires a 
> lengthy explanation of Allegro's internals and what needs to be done, 
> which someone has to write, which takes up a lot of time, which ends up 
> not being done.

Yes, mokkan in #allegro offered to help just before, but I wasn't aware
of any tasks to suggest. In fact, I'm myself not really sure where the
xdummy branch is heading (besides the fact my work in it progress really
slow right now).

> Ideally, the wiki should contain enough information to get people started; 
> I'll be the first to admit that I don't use the wiki that often (not sure 
> if I even registered an account there), so I don't know how well it could 
> serve that role right now.

The wiki has been having a lot of technical problems from the beginning,
unfortunately. At least now we'll soon have a working mediawiki at
least.

> I propose the following: we document on the wiki what has been done for 
> Allegro's internals (for the 4.3 branch) so that new people can join in 
> there easily. At the same time, we set a number of goals we want to meet 
> for 4.3.1, and set ourselves a deadline. We can start the work and sync 
> the Windows port until someone steps forward and declares a willingness to 
> start to actively develop the Windows port.
> 
> So this actually leads me to the following questions:
> 1) How well are the (proposed, new) internals documented at the moment?

Nothing is really "final" final I'd say, but if someone implements e.g.
Bob's display API or Angelo's config files, then I'm sure those will be
used - at the most they need some API adjustements, like e.g. the state
based stuff you mention below.

> 2) Who is doing what and what has been done? I think Elias forked off a 
> branch to play with the display drivers a bit (the actual drivers, not 
> starting with the API sitting on the old drivers as I did), what is the 
> status of this? (I assume I don't need to repeat that I don't personally 
> like a state-based API, but that's for another discussion).

Yes, my idea was to get some template how to do a driver internally,
mainly following the format Peter has set forth. Right now things are
more messy, e.g. struct members are named wrong, and I need to yet add
natural docs comments for internal stuff, and over all first finish it
to the state I want. (And yes, it's another discussion, and I still
would prefer having the current display match 1:1 the way the current
OpenGL context works, as I think it makes code much clearer.)

> I think Chris 
> did some more work on the audio part of it, what's the status of this?
> 3) What goals do we set for 4.3.1? I think a working grahhics system, even 
> if it only works through X11 or OpenGL is ok to start with, more can be 
> added in later, and I personally think we can make API changes along the 
> 4.3 branch to the new API; it's in a state of flux anyway (but this is a 
> debatable standpoint).

I think we definitly should allow API changes. Only the first post 4.3
version (personally I think this should be 5.0.0 as opposed to 4.4, as
it won't have much in common with the 3.x and 4.x Allegro outside the
compatibility layer) should be set in stone again.

> 4) What target release date should we set for 4.3.1? I feel it should not 
> be too distant, but not too soon either (we need time to get work done, or 
> in my case get back into doing work on Allegro on a regular basis). What 
> about April/May? That's about six months after 4.3.0, which seems 
> reasonable.

Depends how much work will be done. I must admit, I'm not sure how much
improvements are in since 4.3.0. There's the new mouse API and partly
naturaldocs docs.. but what e.g. about Windows and Mac OSX, do they
currently work?

> Once 2) and 3) are clear, I think we can do as you suggest and actively 
> recruit people to work on the Windows side of things. Probably an extra 
> MacOS X developer/tester will be good too, but I suspect MacOS X to be 
> more likely to play nice with a basically UNIX+OpenGL based library than 
> Windows does.

Yes, I think once we have each API part working on at least one
platform, like say display with X11+GLX and sound un Mac OSX, it will be
easy to give out tasks (port blah to another platform).

-- 
Elias Pschernig