Re: [AD] [Win] Proposal

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


--- Andrei Ellman <ae-a-alleg@xxxxxxxxxx> escreveu:

> Thomas Fjellstrom wrote:
> > On Sunday 21 January 2007 3:22 pm, 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.
> > 
> > To be honest, I was more talking about advertising for another
> admin, someone 
> > who's willing to get down and dirty and learn where allegro, and
> where its 
> > going. Someone who isn't afraid to help push allegro forward, and
> help design 
> > with regards to windows.
> > 
> > The three main platforms are different enough that they will have
> to assert 
> > some significant pressure on the overall design and layout of
> allegro, and 
> > without a Windows Allegro Guru (not just a dev) (hmm, WAG the dog?
> :D), I 
> > don't see that happening. Of course we'll want some plain old win
> devs as 
> > well, but a WAG will imo, be absolutely necessary.
> 
> 
> I think that one thing that is putting new people off of working on
> Allegro is that the sourcecode is not as elegant as it could be. By
> that, I mean that there are very few code-comments and the variables
> are
> poorly named.
> 

I agree that it is poor commented and the variables are poorly named.
However, i think that this is not the cause of the little people
fenomena. The causes of that fenomena are:

1. The allegro source is hard to follow, frequently you end in
pointer-to-functions inside vtables which you have no idea where it is
be implemented. That is not a issue about renaming variables or write
comments, it is the allegro structure.

2. Allegro isn't very known out there. Maybe we need some advertisement
about allegro itself, not just for developers.

> Some time ago, a project to refactor the Allegro source was proposed
> (
> http://www.allegro.cc/forums/thread/587133 ). I think that getting
> someone (or a group of people) to beautify the Allegro source would
> be
> an opportunity for them to learn about the internals of Allegro.

That is utopic and very unlikely to work, beautifying the code is not a
trivial task. Renaming identifiers is not so simple because it may
cause API/ABI issues and may introduce bugs in the code. And
beautifying it involves not only name changing, but probably much
structural changes. It's important to note that C is ugly by nature and
all the portability and performance things makes it even uglier.

> Ideally, the beautifying would be done by someone with good knowledge
> of
> DirectX and Windows programming. By the time they've finished, they
> should have enough knowledge to figure out for thmselves what needs
> to
> be done (although it would help if they could see a list of
> outstanding
> bugs and the proposals for the new API).

The bug list is a good idea. Allegro has one, but it is far superficial
and incomplete, and is updated very rarely. If we see a bug list in
very fine granularity, it is easier to set goals and distribute tasks.

> 
> The refactoring could be done by several people. The advantage is
> that 
> that way, it will be done quicker, and several people (who hopefully
> are 
> also knowledgable at Windows programming) will have knowledge of 
> Allegro's internals, but the disadvantage is that the knowledge will
> be 
> too diluted and this may lead to the people not knowing enough about
> the 
> internals.
> 

Utopic and unreal. The knowledge is diluted by nature, and nobody will
become an Allegro guru from the day to the night. To someone become a
guru at least an year is needed, except if we could take someone to
work exclusively on allegro, forgetting about friends, girlfriends,
business, bills and every other thing in his/her life. However that is
really really very unlikely.

> Another idea is to post a list of outstanding WinAlleg bugs. Anyone 
> wanting to become a Windows Allegro guru could make a start by 
> attempting to fix the bugs and in the process, learning about the 
> internals of Allegro.
> 

Don't need to be a guru. Just post a reliable, detailed and up-to-date
list somewhere everyone looks and you will start to see patches around.

> Also, bearing in mind that a lot of people who use Allegro are trying
> to 
> get into the games-industry, one idea would be for one of the
> existing 
> Allegro Gurus to offer to give someone a reference if they become a 
> Windows Allegro Guru. Being one of the lead developpers of a thriving
> 
> gaming-library used by thousands would look good on someone's Resume 
> (CV).

Unreal, utopic and unlikely.

> The only problem is that once they get their dream-job, they
> will 
> have very little time to continue to work on Allegro, and we'll be
> back 
> at square one again.

E.G: Shawn Hargreaves.

> Allegro is developped purely as a hobby. Many hardcore hobbyist
> programmers tend to use Linux. People who develop software for
> Windows 
> tend to be more pragmatic - that is, they focus more on the projects 
> themselves rather than hacking the libraries. The more likely they
> are 
> to want to be interested in developing Allegro, the more likely they
> are 
> to switch to Linux. On the other hand, a lot of professional
> programmers 
> code for Windows. If we could convince one of these to work on
> Allegro 
> in their spare time, we'd have someone who is very experienced with
> the 
> Windows platform.
> 

Eventually one or other appears. In the past we had some WAGs arounds.
But if you get that list of detailed bugs, mortal people will
eventually reach there.

> 
> AE.
> 

Victor Williams Stafusa da Silva

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/