Horde3D

Interesting reading about OpenGL rendering of GUIs although it is Qt specific.
http://labs.trolltech.com/blogs/2010/01 ... ce-opengl/

Maybe someone has the time to create a GUI integration of Qt Widgets into Horde3D as a separate more heavy dependency project

All GUI elements already use Horde3D materials for rendering, no part of the pipeline is bypassed.

About that Qt blog post: Currently I only support rectangles anyways, more still needs more time

Thanks for creating the hg repositories.


I fully agree here, community (or third party) extensions like yours are a key factor to the overall popularity of horde, especially since our philosophy is to keep the core small (well, for good reasons).

I don't see how DLL plugins would bring any advantage for keeping compatibility since they would also have to use internal functions and get broken when those are refactored. But a distributed structure as you propose might really help a bit since it would encourage community contributions. Git would definitely not be an option because of the bad Windows support but Mercurial looks quite promising. I will discuss the pros and cons in more detail with Volker once we find some time.

Sure, sure. The thing with DLL plugins is that they are easier to use if there is no good infrastructure to easily integrate plugins directly into a horde3d tree (while keeping that tree up to date), that's why it is either of the two solutions, DLL plugins or a distributed vcs like hg. Of course I totally understand your arguments and support in-tree plugins this way. DLL plugins only were a quick idea on my side, no need to think too much about it.

EDIT:


Edit boxes working.

I have linked to this thread from our slightly polished Extensions wiki page. For later, a dedicated page would of course be a good starting point for users

BTW, phoenix, we have slightly changed the extension interface (it is more straightforward now using an interface instead of function pointers), so a small adaption will be required for your extension.

I've finally updated my Horde3D repositories, they now build up on svn r209 (http://bitbucket.org/mgottschlag/horde3dext/changesets/)

It was dead easy to merge the changes btw - you really should think about switching ;D

I will today write a Wiki entry if I find the time, there won't be any code updates this week probably as I am currently working on the project I am needing this for. The GUI definately will see updates as soon as it is integrated though.

I experimented a bit with hg recently and although I was quite enthusiastic at first, it turned out that it is not as powerful as I would have hoped. What we would really need is good support for cherry picking, that is pulling in just a few specific change sets from different repositories. I think this is not supported well by hg. There seem to be a few extensions which improve the support for cherry picking but the question is how well they integrate with tortoiseHG. I did not spend too much time with it, so if I miss something let me know. Other from that, as it seems to be easy to integrate from svn to hg, is there really the need to switch the official repository?


That would be great!

Just after your question found that TortoiseHG has great support for the transplant extension. Works just as good as it used to with git, right click on what you want to rebase on your current revision and click on transplant to local.
(Works with changeset ranges as well)


It's not *necessary*, and it never was, it just makes things much easier, especially if others send patches back (e.g. I really like to have authorship saved together with the patches, sth the current setup will never allow).

EDIT:
Added a small wiki page after quite some fighting with the Wiki markup. Plz someone upload the last screenshot here as a thumbnail "H3DGUI.jpg" (or .png even, I don't care).

We always mention the contributer of a patch, usually by adding (thanks to name) at the end of the commit message. So it should be clear who has contributed what.

Which usually is some nickname which doesn't really tell anything. And tools like svn blame?

Just works better with git/hg.

The hg names will probably often not be full names as well. And I'm quite sure Volker will mention your full name when integrating a patch if you ask for that.
More substantial contributions will be listed on the website and in a readme file. If for any reason someone should have the feeling that his contribution is not attributed enough, contact Volker or me and we will definitely try to sort the concerns out. Anyway, I understand your point that having the real author information is useful.

Small update: List boxes!

http://imagebin.ca/view/obw89q.html

(Okay, still really simple -.-)