chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] cross-platform gui toolkit


From: Brandon J. Van Every
Subject: Re: [Chicken-users] cross-platform gui toolkit
Date: Wed, 07 Feb 2007 12:12:44 -0800
User-agent: Thunderbird 1.5.0.9 (Windows/20061207)

Joerg F. Wittenberger wrote:
Brandon Van Every wrote:

  
Chicken wouldn't have half the eggs it does if the non-Chicken
Scheme community had taken that position.  Fortunately for us,
they did not.
      
Which half?  My world is OpenGL and C FFIs.  I don't see any
interloper eggs helping out here.  It's one thing if your task is pure
Scheme, quite another if your task is OS interfacing.
    

Brandon, please don't take things personal.  Don't downplay others
contributions just because you don't know yet where you might need
them.
  

This conversation does remind me that I haven't properly looked about for Scheme-based OpenGL windowing toolkits.  I don't recall any from previous searches, other than SDL bindings, but it has been awhile since I looked.


So let me tell you something: a chicken specific gui toolkit, which
somehow wraps opengl and that it - that's something I don't have time
for.

Right, but that's all that 3D OpenGL game developers need.  Collaboration isn't always beneficial, especially in the abstract.  We only need to get a simple job done.  It's also a mostly Chicken-specific job, binding to low level OS interfaces.  You want to do something much more complicated and far reaching.  The complication of your job, far outweighs the resources you're offering to do the job.  So from my standpoint it is a loss.  There is no benefit in worrying about the greater Scheme community for this particular task. 

Once we have our base layer working, and it matures, then presumably people will be writing much more pure Scheme code on top of it.  Then maybe it is worth it to someone to refactor for other Schemes.  Or maybe it isn't.  There's always this question of *labor*.  Who will extend and maintain the code?  People don't just grow on trees to do all these porting and maintenance jobs.  In fact, most people don't like maintaining "other people's code."  Attracting and keeping labor is a community formation problem.  Strategically, I think Chicken is far better off trying to pull people into its fold, than trying to work with the Scheme community at large.  That may sound like a matter of religion, but Chicken is tangible.  Scheme isn't, when you're talking about OS-specific stuff.

What in 3D-land would really bind up a community?  I think a high quality 3D engine would.  I think also, such an engine would inevitably have to succeed with 1 Scheme, in this case Chicken, before even remotely considering the possibility of porting it to other Schemes.  The bar for success in a 3D engine is very, very high.  Everyone and their mother's uncle has a 3D engine out there.  What matters is if someone ships several commercial games with the engine.  As you can imagine, by that time the engine is a *big* project.  Porting it to another Scheme is a *huge* refactoring effort.  Probably unjustifiable, and probably uninteresting to most people out there.

However I've got the feeling that there where some persons, who
listened, who - at least partially - agreed with my concerns.
  

Listening and agreeing is one thing.  Hammering out workable specs that address multiple people's concerns, and actually cutting code, is quite another.  I have low expectations for you uber-GUI guys, frankly.  You're all brilliant, you've all got wonderful ideas.  But first you're going to get distracted by a lot of design stuff.  Then some people are going to drop out, because the problem isn't interesting to them anymore, it's too much work, financial priorities rear their ugly heads, the design strategy isn't meeting their goals, or whatever.  Then what you're going to actually get done, is either 1 binding to 1 extant toolkit, or 1 "from scratch" uber-simple toolkit.  You may get part of a 2nd binding done, as proof of the backend concept.  But it won't be very good because you won't have labor that's interested in doing the job.  This is the elephant in the room about deferring problems through backends: those backends will never get done.  You'll end up with 1 "de facto" backend.

Show Me The Labor.



I wish you all the success with the gui toolkit.  If you are
interested, I might take some time to review you design.  

For clarity: Thu, John, and myself are not working on the kind of GUI toolkit you're talking about.  We're not doing widgets.  We're just putting OpenGL windows up on a screen, so that game developers can get started with something productive.  We're not going to try to make events invisible to the programmer.  We will facilitate a developer who wants his own control over event loops, callbacks, and other event passing mechanisms.  Game developers usually hate it when the toolkit gets in the way of how they want to do the event handling stuff.

Ergo, there's going to be precious little design to comment on.  That's why the job is doable with 3 people.  More than doable.  Our decisions amount to, should we write this mostly from scratch, stealing platform specific snippets from CPW and/or GLFW?  Or should we bind SDL?  Or is there an OpenGL toolkit for another Scheme that we've overlooked?


Just post it
to the chicken list when you feel ready to take discuss questions.
I'll comment on if I feel it's not wasting my time.
  

I'm going to assume you meant well with that last comment.  In a similar vein, we're not worried about people's comments.  3 people is more than enough to design *and implement* such a simple project.  We'd of course welcome anyone who wants to actually bang out code.  Not all problems are design and infrastructure: we'll need demos, tutorials, and a webpage also.


Cheers,
Brandon Van Every


reply via email to

[Prev in Thread] Current Thread [Next in Thread]