Home » Discussion forums » OpenTK » Development
Inertia's picture

Split OpenTK.Utilities from core

Posted Saturday, 21 February, 2009 - 14:29 by Inertia in

OpenTK.Utilities (TKU) was/is holding back release of the core library. The core does not rely on TKU's existance and the split would also result in meaningful version numbers which reflect the status of the libraries better. Due to independent release from each other, updates can occur according by namespace. For example: the core will not receive many more modifications after the GL 3.0 bindings are cleaned and merged, TKU will grow differently.

The question is how to proceed with TKU. One way is to follow OOGL's path and provide your own license conditions and repository for each project, the other way is to create a second repository with free write access and agree to a license.

‹ Bad texture matrix in TextPrinter Texture Compression - PixelInternalFormat ›

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Re: split Utilities from core

Posted Tuesday, 24 February, 2009 - 16:30 by the Fiddler

Splitting OpenTK.Utilities will certainly allow for more frequent OpenTK releases (e.g. no more blocking Mac OS X support for fonts), but I don't think that's the main advantage:

Interested developers will now be able to directly contribute to the toolkit.

With this in mind, I propose creating a searchable database of independent projects: add your own project and other developers will be able to download and use it. Even better, you will be able to use the integrated bug tracker and manage releases within opentk.com, if you wish so.

The database doesn't have to target developers, either. End-user applications, such as games and tools could also be hosted.

I believe this approach is better than a centralized OpenTK.Utilities library for three reasons:

  1. It's efficient: No need to wait for some central entity to review and accept your code. No danger of your code being lost in the forums (as has happened more than once). Do you have a great idea or a useful piece of code? Polish it up and release it.
  2. It's flexible. A centralized library comes with many restrictions: no duplicate functionality, no platform-specific functionality, code must work regardless of GL version. No such restrictions in independent projects.
  3. It's lighter. A single library means that you'll have to drag in everything and the kitchen sink - even if you only need the sink.

This idea has been implemented successfully in drupal.org (Drupal is the CMS used by opentk.com), where the core library provides everything you need and independent "modules" provide more advanced or specialized functionality. Judging from drupal.org, the biggest issues are incompatibilities (where project A conflicts with project B, so you can't use them together) and abandoned projects. I don't expect the first to be a problem in our case (no databases, query rewrites and PHP to worry about!) and the latter is a danger inherent to all software development.

Questions:

  1. Which approach do you prefer: a big, monolithic "utilities" library, or many smaller ones?
  2. Do you have code that you could contribute to the project database? (Could be an end-user application, a small library / utility or even a tutorial).
  3. To what extent would you like to host the relevant project on opentk.com:
    1. Just information, screenshots and a link to your homepage?
    2. Actual downloads?
    3. Bug tracking?
    4. Hosting the source code itself?
  4. What kind of project categories can you think of? Right now, we have "core", "utilities" and "applications", which are then subdivided in "games", "tools / editors" and "tutorials".
JTalton's picture

Re: Split OpenTK.Utilities from core

Posted Tuesday, 24 February, 2009 - 20:01 by JTalton

For Golem3D, I would love to have a development blog hosted on the OpenTK site with screen shots and project summary. A blog is better than forums since every new entry can have it's own set of comments. I have a domain for Golem3D already and would keep the downloads and non-development information there. Bug tracking might be a good thing to have when I get to that point.

the Fiddler's picture

Re: Split OpenTK.Utilities from core

Posted Tuesday, 24 February, 2009 - 20:07 by the Fiddler

Blogs - interesting idea, they are very easy to setup, too.

mooglegiant's picture

Re: Split OpenTK.Utilities from core

Posted Tuesday, 14 April, 2009 - 16:50 by mooglegiant

Core and Utilities should be two separate libraries. I do however think that GameWindow needs to be moved out of the core and done a little differently. It would be helpful if it was more of a static class or something. I'm only saying this because it makes it hard to write like an 'engine' when it still has to rely a lot on the core.

I don't know if you've seen the SDL.Net thing library in C#, but it's must more friendly for wrapping functions into an 'engine'.