Re: CeGui#

[Dan Moorehead]

I have added Robloach as a developer to CEGUI# to move it to the new SourceForge SVN repository for the CEGUI# project. Axiom is being migrated to the Axiom SourceForge project as well by Terry.  Najak, danno, and myself are discussing providing support for Axiom as well as Suva3D for our Visual3D Framework and the Visual3D Architect .NET development tools and we can't wait until Axiom reaches OGRE 1.0.3 state. What is the ETA for this?  Rob, we are interested in using ODE.NET, how is this progressing?

On 2/27/06, Rob Loach <r...@robloach.net> wrote:

Hello,

I've been active in the open source .NET game development community for a while
now, primarily helping out with the Tao Framework, .NET Prebuild and SDL.NET.
With the new RealmForge proposals and discussions over at the RealmForge Google
Group, things have seemingly been slowing down.

I've been talking with Terry Triplett recently and we think it's time to get
things moving.  He has moved Axiom from the RealmForge SVN to the SourceForge
project SVN ( http://sourceforge.net/projects/axiomengine ) and I think it's
time for CeGui# to make the move.  I'm completely willing to do this if you
grant me developer access on the SourceForge project page (
http://sourceforge.net/projects/ceguisharp ).  It will most definitely speed up
development and hopefully get things back on track.

If you're looking for my SourceForge username, it's "robloach".

Thanks a lot and I'll talk to you soon,

Rob Loach
http://www.robloach.net

--
Dan Moorehead
_____________________________________________
Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET (www.RealmWare3D.com )

Resume (http://realmware3d.com/Resume.pdf)
Business Card (http://realmware3d.com/BusinessCard.jpg)

[Terry L. Triplett]

Dan Moorehead wrote:
> Axiom is being migrated to the Axiom SourceForge project as well by
> Terry.

And borrillis, depending on which part of the migration process one is
thinking of. I just have more time and energy at the moment. As far as
the code repository: Done. ( Though still unofficial since we need to
workout the official cutover process. But SourceForge subversion is in
sync with the tigris tree).

> Najak, danno, and myself are discussing providing support for Axiom as
> well as Suva3D for our Visual3D Framework and the Visual3D Architect
> .NET development tools and we can't wait until Axiom reaches OGRE
> 1.0.3 state. What is the ETA for this?

Heh. This is a FLOSS, volunteer, ain't-paying-the-rent project. "When
it's done" is the only real answer. If you "can't wait", go over to
Borrillis' Axiom Roadmap, pick a section of code, roll up your sleeves
and help make it happen. :-)

[Dan Moorehead]

Haha, of course, I dont expect full-time work by any stretch of the imagination, just curious as to if anyone has an estimate or the percent completion towards the current goal of syncing up.  As for us, ideally we will eventually be able to pay the rent while working on this kind of thing ;)

On 2/27/06, Terry L. Triplett <c0d3...@gmail.com> wrote:

Dan Moorehead wrote:
> Axiom is being migrated to the Axiom SourceForge project as well by
> Terry.

And borrillis, depending on which part of the migration process one is
thinking of.  I just have more time and energy at the moment.  As far as
the code repository:  Done. ( Though still unofficial since we need to
workout the official cutover process.  But SourceForge subversion is in
sync with the tigris tree).

> Najak, danno, and myself are discussing providing support for Axiom as
> well as Suva3D for our Visual3D Framework and the Visual3D Architect
> .NET development tools and we can't wait until Axiom reaches OGRE
> 1.0.3 state. What is the ETA for this?

Heh. This is a FLOSS, volunteer, ain't-paying-the-rent project.  "When

[Rob Loach]

Hi Dan,

First of all, thanks for all the help so far. Things are slowing
coming together now. But I came into some troubles with the SVN on the
SourceForge CeGui# project though as it's not enabled. Would you mind
either giving me admin on CeGui# or enabling the SVN access yourself
and giving me SVN access?

Terry sent me his somewhat recent checkout of RealmForge's CeGui# stuff
and I've managed to adapt it to the CVS, but still need the power of
SourceForge's SVN to complete the motion.

Thanks a lot,

Rob Loach
http://www.robloach.net

[Fred Hirschfeld]

BTW, how do we gain access to the Suva3D and tools to begin ramping up for MMT?

 

---

[Dan Moorehead]

We are still working out the partnership contract, that has been delayed due to contracting work for Microsoft referrals but will hopefully resume tomorrow.  However, we are all working on a prototype of the tools, which will soon be located in our private SVN repository. We will make periodic releases in this alpha stage to get feedback early and help users get started, this will be in at least a month, but we encourage getting started with our interactive application design model early on to start building/integrating your game logic. 

You may wish to work with our Axiom + Visual3D product stack first and then replace the Axiom rendering system later with the Suva3D engine under the commercial license we are providing your team, once they release their Community Technology Preview (beta) in an estimated month or two.  Select your engine depending upon your preference and requirements, it wont make much difference in the game logic and development tools.  Like with RealmForge and RAGE the tools will support several rendering engines, however support for these engines will be developed in parallel.  Najak is specializing in the Axiom engine adapter and runtime (game) logic (Visual3D Framework), myself in the Suva3D adapter, software architecture, and data systems and component model (Visual3D Foundation), and Dannomite will be specializing in the Eclipse/Visual Studio-like workspace and game-integrated, run-time development tools (Integrated Visual Design Environment - iVDE) . Each of us has prototypes of these separate systems and will be integrating them fairly soon to evolve them together.

Resume (http://realmware3d.com/Resume.pdf )
Business Card (http://realmware3d.com/BusinessCard.jpg)

[Dan Moorehead]

Enabled Subversion for CEGUI# and gave Robl oach admin status, glad I could help.  Why did you move into CVS before going to SVN, so that could combine the development histories?  Btw, the RealmForge.Utility dependency is not an RF dependency, it should be renamed to DotNet3D, it was meant to provide a uniform set of interfaces and structs used across RF, Axiom, and CEGUI to create some consistancy and ease work for developers.  The scope of the library can be certainly reduced now that RF no longer takes part in it and I think its a good idea, to share a common base for .NET and 3D releated projects (like the DotNet3D.Math library), but it is in no way a requirement.

On 2/28/06, Rob Loach <robl...@gmail.com> wrote:

Hi Dan,

You must have missed by post.  I was having troubles getting the SVN up
because I'm only a developer on the CeGui# SourceForge project and
don't have the access to enable the SourceForge SVN service.  I was
wondering if you could either add me as an admin on CeGui#, or enable
the SVN yourself and allow SVN access on my account.  It might just be
easier to just add me as an admin, but it's completely up to you.

Progress report:  I got the RealmForge CeGui# integrated into the CVS
version, but require the SVN capabilities to finish the move.

Thanks a lot Dan, you've been really patient....

Rob Loach
http://www.robloach.net

> >  ------------------------------
> >
> > *From:* realm...@googlegroups.com [mailto:realm...@googlegroups.com] *On
> > Behalf Of *Dan Moorehead
> > *Sent:* Monday, February 27, 2006 1:48 PM
> > *To:* Rob Loach; RealmForge DevTeam
> > *Subject:* Re: CeGui#

> ------=_Part_16641_31379186.1141101854692
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> X-Google-AttachSize: 8156
>
> We are still working out the partnership contract, that has been delayed due to contracting work for Microsoft referrals but will hopefully resume tomorrow.&nbsp; However, we are all working on a prototype of the tools, which will soon be located in our private SVN repository. We will make periodic releases in this alpha stage to get feedback early and help users get started, this will be in at least a month, but we encourage getting started with our interactive application design model early on to start building/integrating your game logic.&nbsp;
> <br><br>You may wish to work with our Axiom + Visual3D product stack first and then replace the Axiom rendering system later with the Suva3D engine under the commercial license we are providing your team, once they release their Community Technology Preview (beta) in an estimated month or two.&nbsp; Select your engine depending upon your preference and requirements, it wont make much difference in the game logic and development tools.&nbsp; Like with RealmForge and RAGE the tools will support several rendering engines, however support for these engines will be developed in parallel.&nbsp; Najak is specializing in the Axiom engine adapter and runtime (game) logic (Visual3D Framework), myself in the Suva3D adapter, software architecture, and data systems and component model (Visual3D Foundation), and Dannomite will be specializing in the Eclipse/Visual Studio-like workspace and game-integrated, run-time development tools (Integrated Visual Design Environment - iVDE) . Each of us has prototypes of these separate systems and will be integrating them fairly soon to evolve them together.
> <br><br><div><span class="gmail_quote">On 2/27/06, <b class="gmail_sendername">Fred Hirschfeld</b> &lt;<a href="mailto: axeh...@comcast.net">axeh...@comcast.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <div>
>
> <p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">BTW, how do we gain access to the Suva3D
> and tools to begin ramping up for MMT?</span></font></p>
>
> <p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">&nbsp;</span></font></p>
>
> <div>
>
> <div style="text-align: center;" align="center"><font face="Times New Roman" size="3"><span style="font-size: 12pt;">
>
> <hr align="center" size="2" width="100%">
>
> </span></font></div>
>
> <p><b><font face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma; font-weight: bold;">From:</span></font></b><font face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma;"> <a href="mailto: realm...@googlegroups.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
> realm...@googlegroups.com</a> [mailto:<a href="mailto:realm...@googlegroups.com" target="_blank" onclick="return top.js.OpenExtLink (window,event,this)">realm...@googlegroups.com</a>] <b><span style="font-weight: bold;">
> On Behalf Of </span></b>Dan Moorehead<br>
> <b><span style="font-weight: bold;">Sent:</span></b> Monday, February 27, 2006
> 1:48 PM<br>
> <b><span style="font-weight: bold;">To:</span></b> Rob Loach; RealmForge DevTeam<br>
> <b><span style="font-weight: bold;">Subject:</span></b> Re: CeGui#</span></font></p>
>
> </div><div><span class="e" id="q_109aecf6a19cdee3_1">
>
> <p><font face="Times New Roman" size="3"><span style="font-size: 12pt;">&nbsp;</span></font></p>
>
> <p style="margin-bottom: 12pt;"><font face="Times New Roman" size="3"><span style="font-size: 12pt;">I have added Robloach as

> a developer to CEGUI# to move it to the new SourceForge SVN repository for the
> CEGUI# project. Axiom is being migrated to the Axiom SourceForge project as

> well by Terry.&nbsp; Najak, danno, and myself are discussing providing support

> for Axiom as well as Suva3D for our Visual3D Framework and the Visual3D
> Architect .NET development tools and we can't wait until Axiom reaches OGRE

> 1.0.3 state. What is the ETA for this?&nbsp; Rob, we are interested in using <a href=" http://ODE.NET" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ODE.NET</a>, how is this progressing?</span></font></p>
>
>
> <div>
>
> <p><span><font face="Times New Roman" size="3"><span style="font-size: 12pt;">On 2/27/06, <b><span style="font-weight: bold;">Rob
> Loach </span></b>&lt;<a href="mailto:r...@robloach.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> r...@robloach.net</a>&gt;
> wrote:</span></font></span></p>
>
> <p style="margin-bottom: 12pt;"><font face="Times New Roman" size="3"><span style="font-size: 12pt;">Hello,<br>
> <br>
> I've been active in the open source .NET game development community for a while<br>
> now, primarily helping out with the Tao Framework, .NET Prebuild and <a href=" http://SDL.NET" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">SDL.NET</a>.<br>

> With the new RealmForge proposals and discussions over at the RealmForge Google

> <br>
> Group, things have seemingly been slowing down.<br>
> <br>
> I've been talking with Terry Triplett recently and we think it's time to get<br>
> things moving.&nbsp;&nbsp;He has moved Axiom from the RealmForge SVN to the
> SourceForge<br>
> project SVN ( <a href="http://sourceforge.net/projects/axiomengine" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://sourceforge.net/projects/axiomengine</a>
> ) and I think it's<br>
> time for CeGui# to make the move.&nbsp;&nbsp;I'm completely willing to do this
> if you<br>
> grant me developer access on the SourceForge project page ( <br>
> <a href="http://sourceforge.net/projects/ceguisharp " target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://sourceforge.net/projects/ceguisharp</a>
> ).&nbsp;&nbsp;It will most definitely speed up<br>
> development and hopefully get things back on track.<br>
> <br>
> If you're looking for my SourceForge username, it's &quot;robloach&quot;. <br>
> <br>
> Thanks a lot and I'll talk to you soon,<br>
> <br>
> Rob Loach<br>
> <a href="http://www.robloach.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://www.robloach.net</a><br>
> <br>
> </span></font></p>
>
> </div>
>
> <p style="margin-bottom: 12pt;"><font face="Times New Roman" size="3"><span style="font-size: 12pt;"><br>
> <br clear="all">
> <br>
> -- <br>
> Dan Moorehead<br>
> _____________________________________________ <br>
> Sophomore in Business Administration: Entrepreneurship<br>
> University of Illinois at Urbana-Champaign<br>
> <br>
> Project Manager and Software Architect<br>
> Visual3D Architect .NET (<a href=" http://www.RealmWare3D.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.RealmWare3D.com
> </a>)<br>
> <br>
> Resume (<a href="http://realmware3d.com/Resume.pdf" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://realmware3d.com/Resume.pdf</a>)<br>
> Business Card (<a href="http://realmware3d.com/BusinessCard.jpg " target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://realm

[najak]

Our tentative plan for Visual3D is to do revamps starting with the RAGE
baseline for real-time game engine. This is the engine that
GravitySpec used for his Nada game. This will be our starting point,
with a majority of it being transformed and revamped, piece-by-piece.

Essentially, we're planning to commercialize the RAGE layer by
rewriting significant portions of it, and wrapping it with
professionalized content editing tools (Danno's domain). I'm targeting
Axiom to start with because the rendering engine design of Axiom, IMO,
is superior to that of Suva. Axiom will be the "baseline to beat", and
Suva will be the commercialized rendering engine alternative to the
FOSS Axiom offering. Hopefully, the competition will produce favorable
results on both sides.

Our marketing plan is aiming to provide free (or near free) licenses of
Visual3D for non-commercial products, and commercial licenses for
commercial products. Suva seems to be going along with this line of
thinking as well, but it's not guaranteed that they'll stick with it.
Our aim is to provide the public with an option to use Axiom, making
Suva an optional plugin. Therefore, if Suva were to retract their free
offering, Visual3D would still be usable in conjunction with Axiom, for
free (or near free) use.

I am sorry about going commercial, but it seems necessary in order to
survive and achieve the momentum necessary for making a dent in the
market. We're aiming to hit a point where a few developers can go
fulltime to make this happen, and it can't be done without a
significant revenue stream.

My role with Visual3D is focused on the real-time game engine logic,
with adapters written for both Axiom and Suva. Danno's focus is on
the Game Editor presentation layer (details to be revealed later). And
Xeonx provides the vision, leadership, connections, specs, proposals,
prototypes, designs, etc to fill in all the gaps and drive the
top-level product vision. We've each got our domains; seems like a
effective trio and will hopefully produce tangible quick results.

------- Lu4Net Update ----
I'm going to finish up my most recent revamp of Lu4Net v0.91, leaving
some stuff unfinished, but the Logging system is pristine, efficient
and usable. The App/DataModel/Gui layers of Lu4Net still need further
work - they function fine, but *I* know about the messes inside that
still need to be cleaned up. We're going to use it for Visual3D and
let product requirements drive further changes/fixes to Lu4net. I
think v0.91 will serve as a good baseline for it. With Lu4Net, I did
some personal experimenting with the VisualStudio 2005 Test Manager -
my Unit Tests currently cover almost half of the code blocks, which
helps me to maintain quality as I move forward. There are 40K lines
of source code, and 10K lines of test code, and 5K lines of comments
currently in Lu4Net. It comes packaged in 3 Core DLL's depending upon
what functionality you are interested in. v0.91 will have some
preliminary documentation, as well as a half-dozen demo projects to
show how to use it. It also comes with a ConfigTool to allow you to
dynamically hook into your own Lu4Net-based project and configure the
Loggers, Targets, Writers, Filters, and Triggers. That's the quick
low-down.

Lu4Net will remain LGPL, so if anyone is interested in using it --
there are no strings attached. I'll post the link soon for v0.91, when
it's released.

I have some ideas for how it might be beneficial for Axiom -- but
before I get ahead of myself, we're going to apply it to Visual3D as
the guinea pig. It will be especially useful when trying to debug
synchronization issues for multiplayer games. The Lu4Net.App logic
will be useful for the Game Editor, binding real-time game content data
to WinForms, but done in such a way as to minimize the performance
impact to the real-time engine logic (note: anyone who's done something
like this has probably seen that GUI-Databinding can become one of your
biggest performance killers for structures of fast changing data).
Therefore, one purpose of Lu4Net.App.UI.WinForms is to provide a way to
throttle the data binding update rates (to say 2Hz) in order nominalize
the performance impact of the data binding.

[Rob Loach]

Thanks again, Dan. I've finished moving CeGui# from the RealmForge
repository to the SourceForge project new SVN
(http://sourceforge.net/svn/?group_id=117714). I did a number of
different things to the project so far that you should be aware of:

- Updated Prebuild (now has a VS2005 batch file)
- Added in the DirectX9 renderer
- Renamed assembly from "CrayzEdsGui" or "CrayzEdsSharpGui" to
CeGuiSharp (goes along with CeGui#)
- Centralized the WidgetSets' namespace so it's under the main
assembly's namespace

Future Plans:

- Rename all other namespaces to fit under CeGuiSharp (goes along with
CeGui#)
- Get rid of Axiom dependancies (there are still loads of input-related
Axiom references)
- Move Axiom's CeGui# renderer to Axiom (once there's a build of
CeGui#)
- Move SDL.NET's CeGui# renderer to SDL.NET (once there's a build of
CeGui#)
- Complete the DirectX9 renderer with a working example
- Write a Tao.OpenGl renderer

Notes:

I think that moving the Axiom and SDL.NET renderers off of CeGui#
holdings will encourage third party renderer development. It would
also tailor renderer development on the API's side of things as opposed
to the GUI's side of things. Keeping only low-level renderers within
CeGui# (DirectX9 and Tao.OpenGl) will just show the power of the
library as well as allow others to download the official renderers for
the library directly from its website. If anyone thinks differently,
please let me know.

[Dan Moorehead]

You want to take out the existing CEGUI renders from the CEGUI SVN?

Why do you call it CeGui#?  The base product was CEGUI, the SourceForge.net project is CEGUI#, and all references I have seen to it have been CEGUI#, why not use CeguiSharp as the namespace? Why are you restyling the product name? Its not pronounced See-gui, but C-e-gui, and acronyms are represented as CamelCase when larger then two characters.

On 2/28/06, Rob Loach <robl...@gmail.com> wrote:

Thanks again, Dan.  I've finished moving CeGui# from the RealmForge
repository to the SourceForge project new SVN

(http://sourceforge.net/svn/?group_id=117714 ).  I did a number of

[Michael Cummings]

I don't have any issue with moving the renderer into the Axiom SVN. I am going to be expanding the Add-ons section to accommodate this.

 

Rob, please make sure you are coordinating with JW Sullivan as he has been updating the codebase to be inline with the original version.

 

Borrillis

 

On 2/28/06, Dan Moorehead <d...@realmware3d.com> wrote:

You want to take out the existing CEGUI renders from the CEGUI SVN?

Why do you call it CeGui#?  The base product was CEGUI, the SourceForge.net project is CEGUI#, and all references I have seen to it have been CEGUI#, why not use CeguiSharp as the namespace? Why are you restyling the product name? Its not pronounced See-gui, but C-e-gui, and acronyms are represented as CamelCase when larger then two characters.

On 2/28/06, Rob Loach <robl...@gmail.com > wrote:

Thanks again, Dan.  I've finished moving CeGui# from the RealmForge
repository to the SourceForge project new SVN

( http://sourceforge.net/svn/?group_id=117714 ).  I did a number of

Resume ( http://realmware3d.com/Resume.pdf)

[Terry L. Triplett]

Been suggesting that for the last couple of days. :-)

[Dan Moorehead]

Sounds fine to move Axiom renderer to Axiom codebase, not to "oster more engine/API support per se, as I the think more examples for implementers, the better, but because there would be a large number of dependencies for it required and needing constant updating.

--
Dan Moorehead

_____________________________________________
Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET (www.RealmWare3D.com)

Resume (http://realmware3d.com/Resume.pdf)
Business Card ( http://realmware3d.com/BusinessCard.jpg)

[JW Sullivan]

Sorry for the delay in hopping on this thread.  Thanks Rob for making the move to the SF Subversion repository.  I was hoping to have had that done a while ago, but an illness, and job interviews prevented me from doing so.  In my version of the codebase I have renamed the namespace to CEGUI as that is much easier to type and makes the project much more similar to the CEGUI project.  I have quite a few changes to start getting the project in sync with the CEGUI 0.4.1 codebase.  Most of the changes so far are non functional changes, and are just there to start getting support for the Falagard widget set definitions into the project.  I'll be comparing my codebase against what you have and getting it in the SVN depot as soon as I can, which should be this weekend.  Several of the changes in my code are also to get the demos to work with the latest version of the Axiom codebase as well.  We should get in touch so we can coordinate the work that we are doing so that we won't step on each others toes.

 

I've just been told that I'll be made a job offer today, which I am planning on accepting, so I won't have to worry about my current job situation, which will give me a bit more freedom to work on this project.  I'll be working as a build engineer at microsoft, so I'm excited about that.

 

J.W.

 

[Michael Cummings]

J.W.,

    That is awesome news, Not easy to get into MS so good luick, let us know if you do get the offer.

 

[Dan Moorehead]

Nice, thats great news.

[Offtopic] It seems that there is racial genocide occurring in games like Lineage and WoW over the estimated 1 billion dollar in-game items, real estate, and gold market. How crazy is that?
[/Offtopic]

--
Dan Moorehead
_____________________________________________
Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET (www.RealmWare3D.com)

Resume (http://realmware3d.com/Resume.pdf )

Business Card (http://realmware3d.com/BusinessCard.jpg)

[Dan Moorehead]

(The article link)

On 2/28/06, Dan Moorehead <d...@realmware3d.com> wrote:

Resume ( http://realmware3d.com/Resume.pdf )
Business Card (http://realmware3d.com/BusinessCard.jpg)

[Rob Loach]

Illness and job interviews are okay to have in my books.
Congratulations on the interviews! I'm going to be busy over the next
few days as well, but I'll try to get in as much time as possible.

If you ask me, "CEGUI" doesn't really fit in with .NET. Check out the
.NET Naming Guidelines
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp).
It also doesn't really distinguish CeGui# as seperate library then the
original CEGUI. CeGuiSharp makes the assembly unique from CEGUI's
(CeGuiSharp.dll vs CEGUI.dll). Although it is easier to type, I think
the benefits of having it distinguishable from the original library is
key for the success of the library.

Another point is that if people see "CeGuiSharp.dll" in a project,
they'll know exactly what it is. If they just see "CEGUI.dll", they'll
be led to think that it's the original library as opposed to CeGui#.
The Tao Framework uses the same naming conventions (Tao.Ode,
Tao.OpenGl, etc).

The assembly I checked into the SVN was revision 151 sent to me by
Terry as the RealmForge repository was down at the time. Taking a look
at AssemblyInfo, it seems like it's at version 0.3.0.

What are your thoughts on CeGui# having its own wiki/website? This
would really help later on when end-programmers are looking to develop
their own renderers. They could easiler look up tutorials and articles
on how to set it up. A dedicated forum would also help in centralizing
communication for both developers and users (instead of being spanned
over mailing lists, groups and the RealmForge forum). I have no
problem settings all of this up if you lack the time. They of course
would be hosted on SourceForge itself.

Thanks a lot, JW. I look forward to working with you on this....

Rob Loach
http://www.robloach.net

[Dan Moorehead]

I agree that Sharp should be in the name, however you are arbitrarily assigning case.  The acronym is CEGUI# and therefore the namespace should be CeguiSharp,  CeGui is not only harder to type but ugly and awkard and hard on the eyes.  Crazy Eddy is not one word and Gui the other.  CEGui would be more appropriate but even uglier.  I was under the impression that we had decided a while back on Cegui or CeguiSharp vs. CeGui.

On 2/28/06, Rob Loach <robl...@gmail.com> wrote:

--
Dan Moorehead
_____________________________________________
Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET (www.RealmWare3D.com)

Resume (http://realmware3d.com/Resume.pdf )

Business Card (http://realmware3d.com/BusinessCard.jpg)

[Terry L. Triplett]

Dan Moorehead wrote:
> CeGui is not only harder to type

Agree.

> but ugly and awkard and hard on the eyes.

Your opinion. Doesn't bother me so much.

> Crazy Eddy is not one word and Gui the other.

True, but GUI is a universally recognizable acronym on its own. My eyes
and fingers always want to treat it as such. SomethingGui looks more
natural to me than Somethinggui, though that seems to be partly a
function of how many characters "Something" has. Tough call, because it
will probably confuse people no matter what gets picked.

> CEGui would be more appropriate but even uglier.

Ahhh! My eyes! They burn! Take it away!

[Rob Loach]

.NET Naming Conventions state that acronyms of three or more letters
should be pascal case (Xml instead of XML) instead of all caps. More
details on the convention are available here:
http://www.irritatedvowel.com/Programming/Standards.aspx

For example: Use "HtmlWidget", "XmlReader", etc. If "RF" was the
acronym, it would be "RFSecretNamespace", not "RfSecretNamespace".

Taking this into consideration, CeGui# would be "CEGuiSharp" in the
namespace to live up to this convention. Either "CeGuiSharp" or
"CEGuiSharp" is fine with me. The main issue that I have is that
"Sharp" has to be in the namespace to distinguish it different from the
original CEGUI.

[Dan Moorehead]

Yes, that was the PascalCase convention I was referring to.  However, In the product name is CEGUI#, not CeGui sharp.  Therefore, the acronym that is longer then 2 letters should be CeguiSharp.  Yet, you are referring to the product name as CeGui# in your posts, however that is not the product name (see the SF.net site as well as the CEGUI site).  I agree Sharp should be in the name and that the .NET convention should be followed, but that means CeguiSharp as had been decided on a while back.

On 2/28/06, Rob Loach <robl...@gmail.com> wrote:

.NET Naming Conventions state that acronyms of three or more letters
should be pascal case (Xml instead of XML) instead of all caps. More
details on the convention are available here:
http://www.irritatedvowel.com/Programming/Standards.aspx

For example: Use "HtmlWidget", "XmlReader", etc. If "RF" was the
acronym, it would be "RFSecretNamespace", not "RfSecretNamespace".

Taking this into consideration, CeGui# would be "CEGuiSharp" in the
namespace to live up to this convention.  Either "CeGuiSharp" or
"CEGuiSharp" is fine with me.  The main issue that I have is that

[Rob Loach]

I guess I was looking at it like this:

Crazy Eddie's: "CE"
Graphical User Interface: "GUI"

"CE" stays as "CE" as it's only two letters long and "GUI" turns into
"Gui" as it's three letters long. Therefore, "CEGui". I've talked
with about eight different members from GameDev.net and they all said
that "CEGuiSharp" was their prefered name, even over "CeguiSharp". All
in all though, I guess it really doesn't matter that much. I have no
problems with either one (although I personally would prefer
CEGuiSharp).

When do you think the changes will be in the SVN, J.W.?

[Dan Moorehead]

However, it is not a string of multiple acronyms, and you are discussing the naming of a namespace, not the product name.  The product name, as already established with the parent project of which we are a port is precisely CEGUI#, not CEGUISharp, nor CEGui.  This is already set and the namespace should follow the project name, not its own combination/spelling/varient.  Therefore CEGUI# would be represented as CeguiSharp.  If you want to change the name of the product first from CEGUI# to CeGUI or CEGui#, then that is another issue and the two should not be confused.  However, I would advise against deviating that far from the base project's name.  The namespace should not be an arbitrary spelling/skew of the product name based upon some polling of a couple people, it should reflect the product's actual name, and the actual name is the CEGUI# acronym. Frankly, you are breaking the .NET coding style conventions with the CEGui proposal, because the acronym if CEGUI and CEGui is not a PascalCase representation of that.

On 2/28/06, Rob Loach <robl...@gmail.com> wrote:

_____________________________________________
Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET ( www.RealmWare3D.com)

[Terry L. Triplett]

I'm not quite sure why this thread made me think of this. I'm sure it
will come to me eventually. :-)

http://www.straightdope.com/classics/a940211.html

Dan Moorehead wrote:
> However, it is not a string of multiple acronyms, and you are
> discussing the naming of a namespace, not the product name. The
> product name, as already established with the parent project of which
> we are a port is precisely CEGUI#, not CEGUISharp, nor CEGui. This is
> already set and the namespace should follow the project name, not its
> own combination/spelling/varient. Therefore CEGUI# would be
> represented as CeguiSharp. If you want to change the name of the
> product first from CEGUI# to CeGUI or CEGui#, then that is another
> issue and the two should not be confused. However, I would advise
> against deviating that far from the base project's name. The
> namespace should not be an arbitrary spelling/skew of the product name
> based upon some polling of a couple people, it should reflect the
> product's actual name, and the actual name is the CEGUI# acronym.
> Frankly, you are breaking the .NET coding style conventions with the
> CEGui proposal, because the acronym if CEGUI and CEGui is not a
> PascalCase representation of that.
>

> On 2/28/06, *Rob Loach* <robl...@gmail.com

> <mailto:robl...@gmail.com>> wrote:
>
>
> I guess I was looking at it like this:
>
> Crazy Eddie's: "CE"
> Graphical User Interface: "GUI"
>
> "CE" stays as "CE" as it's only two letters long and "GUI" turns into
> "Gui" as it's three letters long. Therefore, "CEGui". I've talked
> with about eight different members from GameDev.net and they all said
> that "CEGuiSharp" was their prefered name, even over
> "CeguiSharp". All
> in all though, I guess it really doesn't matter that much. I have no
> problems with either one (although I personally would prefer
> CEGuiSharp).
>
> When do you think the changes will be in the SVN, J.W.?
>
>
> _____________________________________________
> Sophomore in Business Administration: Entrepreneurship
> University of Illinois at Urbana-Champaign
>
> Project Manager and Software Architect
> Visual3D Architect .NET ( www.RealmWare3D.com

> <http://www.RealmWare3D.com>)

[Michael Cummings]

Technically, if the product name is CEGUI#, it's not an acronym anymore, and the name space should be all uppercase. IT would be an acronym of the product name if the product name was Crazy Eddie's Graphical User Interface Sharp

On 2/28/06, Dan Moorehead <d...@realmware3d.com> wrote:

[Dan Moorehead]

The full product name is in fact Crazy Eddie's Graphical User Interface, however just like with XML, the effective product/technology it what is always considered, it is less relevant what the full name is and even in a formal document you may not find it referenced as the full title.  Therefore CEGUI is the acronym representing the product, regardless of it being more common to use them the full product name. Even if it just a random string of characters that were all caps, .NET conventions call for PascalCasing to appear more consistent within the code and easier to type as I see it.

Funny article Terry ;) Weird stuff.

On 2/28/06, Michael Cummings <cummings...@gmail.com > wrote:

--
Dan Moorehead

_____________________________________________
Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET (www.RealmWare3D.com)

Resume ( http://realmware3d.com/Resume.pdf)

Business Card (http://realmware3d.com/BusinessCard.jpg)

[najak]

I can't resist jumping into a perfectly good naming convention dispute.
:)

Try this - type all the options for namespace 10x each and time them.
For me, Cegui and CEGUI stole 1st and 2nd place, while CEGuiSharp took
last place. Just something to consider.

I agree that namespace should match the file name, but with one caveat
-- I consider the "Sharp" (or "DotNet") to be a suffix, the same as you
would consider ".dll" a suffix. Therefore, filename "CEGUI.Sharp.dll"
could translate to namespace "CEGUI" same as what JW used.

Filename: CEGUI.Sharp.dll
Namespace: CEGUI (this matches the original library)

The suffix "Sharp" serves *no* purpose in a namespace. You are doing a
.NET project, so of course your assemblies are written in a .NET
language. For namespace, the "Sharp" suffix clarifies *nothing*. It
is impossible to use the CEGUI native C++ assembly directly with .NET,
so where's the confusion?

The filename needs to differ for obvious reasons; the "Sharp" suffix to
lets you know you can use it with .NET projects directly.

My suggestion doesn't deviate from the spirit of the rule which says
"filename == namespace", if you simply consider the "Sharp.dll" as the
filename suffix. When they made this rule, I don't think they were
thinking about "what to do if you port C++ to C#". I think the naming
convention needs an amendment for these special cases. Another
blunder, IMO, is the selection of namespace "OgreDotNet" instead of
just "Ogre".

Filename: OgreDotNet.dll
Namespace: 'OgreDotNet' (could have just been "Ogre" without *any*
confusion whatsoever among .NET developers who are using it).

-------
And... just to make my point and thumb my nose at those who disagree,
the base namespace for Lu4Net is simply "Lu" (the '4Net' suffix in the
namespace offered no clarity for .NET developers using it, so I omitted
it and save you the typing).

That's my story, and I'm sticking with it.
:)

(*really* I'm okay with whatever the CEGUI worker-bees choose. I don't
mind the diversity.)

[Terry L. Triplett]

Dan Moorehead wrote:
> Funny article Terry ;) Weird stuff.
>

Cecil Adams' column used to run in the Dallas Observer, and probably in
other 'colorful' lifestyle periodicals around the country. But I was
just alluding to the modern usage of the Freudian term. The sentiment
can be summed up as "Is anal retentive hyphenated?". Maybe the name
should just be changed so we can worry about more important things. :-)***
*

[Dan Moorehead]

Good points, either Cegui or CEGUI would work for me, however the arbitrary CeGui is what doesnt gel with me. I would however suggest CEGUISharp (vs. CEGUI.Sharp) for the assembly name, suffixes can come without a period IMHO (eg Screenshot3.jpg vs Screenshot.3.jpg).

[JW Sullivan]

I think that you've all just gone over the exact same arguments that were made in the last round of namespace arguments.  The reason why I chose CEGUI over all of the other combinations was for a combination of different reasons.  For one, I do agree that the extraneous Sharp or DotNet tagged onto the end of the namespace is unnecessary since developers will already know that they are developing on the .Net platform, however, I am not against having that extra data included in the name of the assembly itself (eg CEGUI.Sharp.dll).  I don't think that CeGui or CEGui are appropriate, because the name of the product is CEGUISharp, and as such Cegui or CEGUI are more appropriate.  As for why I chose CEGUI over Cegui, I believe that it was the more popular of the two at the time I made that decision.

 

For now, the namespace change has only been made in my source base, so I would be open to changing my decision before submitting my code, however, once I submit the code with the new namespace that will be the FINAL namespace name, and there will be no changes after that point.  I don't want this discussion to keep coming up.

 

J.W.
 

[Dan Moorehead]

Great to see it as CEGUI!  I am glad that is settled and had pointed as well that this argument has been made and settled on already a while back, I just dont want to see any skewing of the namespace CeGui CEGui, etc. that does not fit the product name nor liked to see this being unnecessarily rehashed or changed by one person without us deciding upon that course.

On 2/28/06, JW Sullivan <jwa...@gmail.com> wrote:

--
Dan Moorehead
_____________________________________________

Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET (www.RealmWare3D.com)

Resume (http://realmware3d.com/Resume.pdf )
Business Card (http://realmware3d.com/BusinessCard.jpg)

[Rob Loach]

I'm glad everything is back on track and can't wait to see how things
progress.

Dan, I stated my reasons for changing it and don't regret doing so. No
one was doing anything with the library so I decided to get things
started. Stating that I "broke the .NET coding style conventions" was
a bit out of line as I clearly stated my opinions with backed up facts.
If you have a problem with my opinions, please feel free to state them
as communication is the key to a community's success. I'm not breaking
the .NET coding style by making valid proposals and helping out the
library. We're all in the same community here, we are all after the
same goal..... We have to work together.

Thanks,

Rob Loach
http://www.robloach.net

[dannomite]

Watching from the side-lines I could see where you both have valid points for your naming conventions, even where the so-called "standard" is concerned.  FxCop would be fine with both Cegui and CeGui, but probably not CEGui, so quibbling over this is a waste of time.  Bottom line is, there is no need to change it and it's just better off left the way it is.  Arguing over an acronym just gives me an embelism. ;-)

 

Rob, I think we all know you meant well, well at least I do.  It's great to see you working on Cegui/CeGui/CEGui/Yada/YaDa/YADa.  *grin*

 

-dannomite

 

[Serge Lobko-Lobanovsky aka arilou]

I second your opinion. To me, it's just a matter of personal
preference whether to type CEGUI or Cegui :-) Intellisense
will help you in either way ;-)

The only thing I wanna add is that you could have asked on the list
_before_ you "got things started" ;-) I had to prove I am skilled
enough to join in before I started to work on Axiom. So just nothing
personal - I am sure Dan intended no offence.

What makes me feel uneasy that so much discussion takes place over
such an insignificant issue as compared to discussing project features
themselves.

--
Best regards,
Serge mailto:serge.lo...@gmail.com

[Dan Moorehead]

I apologize if my statements come off as brash and blunt in nature (just check najak and danno, and he will tell you that blunt is the way we go in our personal communication ;) though may not be the best idea here).  I view CeGui as deviating from the conventions because we have considered CEGUI to be the acronym and product name, and Cegui would be the transformation of that according to the .NET conventions.  I am not accusing you of "breaking" the conventions (and I have found many cases in which convention *should* be broken, a hard-and-fast rule is hard to come by) but simply stating the perspective that your proposal *would* deviate from those conventions due to our consideration of CEGUI as the official spelling of the product name.  If you were arguing for CeGui# to become our own variant in spelling then I would see no reason that a CeGui namespace would be non-normative, however my point was that is not our selected name and context.  I am always up for communication, but was just voicing my agreement with Najak and JWace and how I don't see the logic in the segmenting the product name and acronym into two acronyms just for the purpose of namespaces. I apologize if I was unclear in my statement of this and definitely appreciate your initiative in getting the ball rolling again with CEGUI#, the SVN suggestions were great ones.

On 3/1/06, Rob Loach <robl...@gmail.com> wrote:

I'm glad everything is back on track and can't wait to see how things
progress.

Dan, I stated my reasons for changing it and don't regret doing so.  No
one was doing anything with the library so I decided to get things
started.  Stating that I "broke the .NET coding style conventions" was
a bit out of line as I clearly stated my opinions with backed up facts.
If you have a problem with my opinions, please feel free to state them
as communication is the key to a community's success.  I'm not breaking
the .NET coding style by making valid proposals and helping out the
library.  We're all in the same community here, we are all after the

[dannomite]

For the record, that should have read "Arguing over an acronym just gives me an emblem-ism. ;-)".  A lame attempt on a play with the words embolism and emblem.  Um, I'll go back to work now...

 

-dannomite

 

[Dan Moorehead]

Good point ariluo, some times its just difficult to see old threads of arguments brought up again when we are moving forward so well with Rob & Terry's SVN transitions and Borrillis's consistent management (a new thing indeed!), and the new-found communication and collaborate development (which was not really there back in the day with leed).  But then again, I should remember that not everyone was there for the WW1C (World War I of CEGUI ;), now that I think about it, we have had drawn out discussions on pretty much naming convention, it seems that constitutes (sadly) a large portion of our development communication some times.  My harsh statements were not directed at you, so much as disclaimers that I hadnt want to start this naming convention discussion and was happy in my box with CEGUI# engraved on the side of it ;) 

So now that this is settled, I would love to discuss what everyone is working on of late, status updates and the like, important things (oops, sorry Borrillis, didn't mean to step on your project management toes and steal your roll call thunder ;)

On 3/1/06, Dan Moorehead <d...@realmware3d.com> wrote:

I apologize if my statements come off as brash and blunt in nature (just check najak and danno, and he will tell you that blunt is the way we go in our personal communication ;) though may not be the best idea here).  I view CeGui as deviating from the conventions because we have considered CEGUI to be the acronym and product name, and Cegui would be the transformation of that according to the .NET conventions.  I am not accusing you of "breaking" the conventions (and I have found many cases in which convention *should* be broken, a hard-and-fast rule is hard to come by) but simply stating the perspective that your proposal *would* deviate from those conventions due to our consideration of CEGUI as the official spelling of the product name.  If you were arguing for CeGui# to become our own variant in spelling then I would see no reason that a CeGui namespace would be non-normative, however my point was that is not our selected name and context.  I am always up for communication, but was just voicing my agreement with Najak and JWace and how I don't see the logic in the segmenting the product name and acronym into two acronyms just for the purpose of namespaces. I apologize if I was unclear in my statement of this and definitely appreciate your initiative in getting the ball rolling again with CEGUI#, the SVN suggestions were great ones.

On 3/1/06, Rob Loach <robl...@gmail.com > wrote:

I'm glad everything is back on track and can't wait to see how things
progress.

Dan, I stated my reasons for changing it and don't regret doing so.  No
one was doing anything with the library so I decided to get things
started.  Stating that I "broke the .NET coding style conventions" was
a bit out of line as I clearly stated my opinions with backed up facts.
If you have a problem with my opinions, please feel free to state them
as communication is the key to a community's success.  I'm not breaking
the .NET coding style by making valid proposals and helping out the
library.  We're all in the same community here, we are all after the

same goal..... We have to work together.

Thanks,

Rob Loach
http://www.robloach.net

--
Dan Moorehead
_____________________________________________
Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET (www.RealmWare3D.com)

Resume ( http://realmware3d.com/Resume.pdf )
Business Card (http://realmware3d.com/BusinessCard.jpg)

[JW Sullivan]

My current status hasn't changed yet.  It looks like I may have some time on Thursday night to work on getting my version of CEGUI# into the SVN depot.  If not, then I'll be doing that on Saturday, so you can expect to see those changes this weekend.  Most of the new code is un-tested, however, the functionality offered by the new code is not yet accessible.  I've currently ported over about 90% of the classes and functionality in the falagard folder of the 0.4.1 release of CEGUI.

 

Rob you are correct that the current version of CEGUI# is (mostly) on par with the 0.3 of CEGUI.  There is some missing functionality, and a few less widgets, but for the most part it had all of the functionality

 

J.W.

[Terry L. Triplett]

LOL.  Good thing you posted this, because I was fighting myself about posting a spelling correction.  "You know you're anal-retentive if ..."

[Terry L. Triplett]

Serge Lobko-Lobanovsky aka arilou wrote:

The only thing I wanna add is that you could have asked on the list
_before_ you "got things started" ;-) I had to prove I am skilled
enough to join in before I started to work on Axiom. So just nothing
personal - I am sure Dan intended no offence.

  

I kind of thought that asking Dan for access to the site for the purpose of moving code over from tigris and getting things set up, then announcing some housekeeping changes and future plans qualified as that.  It's not like Rob just fell out of the sky and started changing stuff in secret.  I guess mentioning some changes after the fact pushes the envelope a bit, but nothing's irreversible, and the announcement that triggered the debate was made to the list.  Now a few more people (including me) understand the unspoken history of CEGUI#, and things will be quiet until the next unwary soul willing to step up and contribute naively wonders why things are the way they are and gets the smack-down from the project elders.  :-)

What makes me feel uneasy that so much discussion takes place over
such an insignificant issue as compared to discussing project features
themselves.
  

You should see the conversations Dan and I had about naming conventions in Tao.Ode (or should it be Tao.ODE?).  :-)  It's less significant than other things, yes (which is why I start poking fun when things go on too long), but it's like proper spelling of words - the content of an essay is more important than spelling, but we still care because poor spelling distracts.

[JW Sullivan]

I would like to thank you Rob for taking up an interest in the CEGUI# project, and taking the initiative to start things moving.  It's nice to know that people are interested in the project, and it will be nice to have someone else interested in developing the project.

 

J.W.

[Michael Cummings]

No thunder stealing here, I've been swampped at work, so I have not had much time to participate this week. However, I will make a this observation. I think this is the most I have seen of you in this group since August, I guess makeing that announcement of yours enabled you to come out of hiding? :)

Business Card ( http://realmware3d.com/BusinessCard.jpg)

[Dan Moorehead]

Haha, yes, no more secretive coding I guess you might say. But then again, as najak pointed out, what coder can resist a naming convention argument ;)

Resume ( http://realmware3d.com/Resume.pdf)
Business Card (http://realmware3d.com/BusinessCard.jpg)

[Rob Loach]

Absolutely no problem, JW. I've been extremely disappointed with the
availability of GUIs on the .NET front and a I think CeGui# is possibly
the only one with any potential at all. There is the Managed DirectX
Framework GUI, but that's extremely restricted to Managed DirectX.
Having an embeded adaptable GUI framework for .NET will really help out
the community.

What are your thoughts on CeGui# having its own website? If you lack
the time to set this up, I'd be more then willing to put up a wiki.
MediaWiki has been very effective with SDL.NET
(http://cs-sdl.sourceforge.net) as community members have begun to
write their own articles. It was really easy to get OdeDotNet
(http://odedotnet.sourceforge.net) running through the wiki as well.
Having a wiki as its website is really good for the community and will
enforce that the community stays alive. Another good example of a
community-run project that uses a wiki is NSIS
(http://nsis.sourceforge.net).

Thanks again,

Rob Loach
http://www.robloach.net

[JW Sullivan]

CEGUI# having its own website does sound like a good idea.  It sounds like you already have some ideas and experience in that area, so it would probably happen a lot faster if you can set it up.  I'll check to make sure that you have the permission to do that on the SF site.

 

J.W.

[najak]

For reference, here's a good link for your back pocket:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamespacenamingguidelines.asp

Two quotes here are:
"If your brand employs nontraditional casing, follow the casing defined
by your brand, even if it deviates from the prescribed Pascal case."
--- Translation: "CEGUI is fine according this naming convention."

and

"Finally, note that a namespace name does not have to parallel an
assembly name. For example, if you name an assembly
MyCompany.MyTechnology.dll, it does not have to contain a
MyCompany.MyTechnology namespace." -- Translation: "CEGUI.Sharp.dll is
an okay filename to use, even if 'CEGUI.Sharp' isn't your namespace."
(or whatever you name it). I've heard a lot of folks say things like
"you've got to match your root namespace to the DLL", but according to
this naming convention from msdn, that's optional.

NOTE: I'm not arguing anything here --- just posting a reference from
MSDN that supports the choices made by JW.

[JW Sullivan]

Just a heads up.  I have created the CEGUI_0_4_1 branch in the SVN depot, and will be updating it this afternoon.  I think that the work to update to CEGUI 0.4.1 should be kept in a separate branch until it becomes a bit more stable/usable at which point we can migrate it over to head.

 

J.W.

 

[JW Sullivan]

I've committed my updates to the cegui_0_4_1 branch.  This includes the namespace change to CEGUI, and all of the new classes that I've been working on to start syncing the code base with CEGUI 0.4.1.

 

This update doesn't include any updates to the Axiom rendering engine that I may have made, since right now that isn't contained in the SVN depot.  I kind of like Rob's idea of moving that renderer into the Axiom source tree, so I can work with the Axiom team to get the Axiom renderer updated eventually.

 

J.W.

 

[Arakon]

I'm mostly a lurker, but I just wanted to say that I think this has
gone on way too much.
There are pleanty of different ways of interpreting a naming convention
- and a convention
in itself is not a rule. All of the different approaches to this
naming convention is mostly
a matter of interpretation of what the different primitives in the
acronym/name are.

With the parent project being a combination of two different acronyms,
it makes the choosing
of how to interpret it rather arbitrary - and if you don't agree with
that you simply don't agree
with reality, since there is evidence that multiple people have
multiple opinions towards the
topic.

Also - this being a PORT of a different project, I think it is OK for
it to have as much in common as
possible with the parent, dispite the naming conventions of the
language it is ported to. To do
otherwise suggests the need of modifying larger portions of the
interfaces to fall in line with
"conventions".

On a side note, I dislike the user of the symbol "#" in a name. It
makes internet searches for
it a little more difficult, among other things. "Sharp" looks much
better, and is actually a searchable
term. Symbols do not belong in names.

So, that all being said, whoever is coding and maintaining it the
should choose the
namespace name. In my opinion, anyone bickering about naming
conventions is not helping, but
creating tension which only distracts from the main goal of all of this
- writing software.

Dan Moorehead wrote:
> However, it is not a string of multiple acronyms, and you are discussing the
> naming of a namespace, not the product name. The product name, as already
> established with the parent project of which we are a port is precisely
> CEGUI#, not CEGUISharp, nor CEGui. This is already set and the namespace
> should follow the project name, not its own combination/spelling/varient.
> Therefore CEGUI# would be represented as CeguiSharp. If you want to change
> the name of the product first from CEGUI# to CeGUI or CEGui#, then that is
> another issue and the two should not be confused. However, I would advise
> against deviating that far from the base project's name. The namespace
> should not be an arbitrary spelling/skew of the product name based upon some
> polling of a couple people, it should reflect the product's actual name, and

> the actual name is the CEGUI# acronym. Frankly, you are breaking the .NET

[JW Sullivan]

The namespace discussion is over :)

 

No one  had any objections to the namespace I had chosen "CEGUI", and that has now been committed to the repository, and so now that namespace name is final, and will not be changing.

 

J.W.
 

[Dan Moorehead]

Absolutely, I agree gone on long enough and thankfully was settled a bit ago ;)

--
Dan Moorehead
_____________________________________________
Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET (www.RealmWare3D.com)

Resume (http://realmware3d.com/Resume.pdf )
Business Card (http://realmware3d.com/BusinessCard.jpg)

[Terry L. Triplett]

Arakon wrote:
> I'm mostly a lurker, but I just wanted to say that I think this has
> gone on way too much.
>

LOL. So the obvious solution is to re-vitalize the discussion instead
of ignoring it so it will die. And you sucked me back in - bravo. :-)

Must. Resist. Clicking. Send. Button. No. NO!.

Just one click, that's all. No. Yes. YES! *click*.

:-)

[Michael Cummings]

| /dev/nul

[Arakon]

Terry L. Triplett wrote:
> LOL. So the obvious solution is to re-vitalize the discussion instead
> of ignoring it so it will die. And you sucked me back in - bravo. :-)
>
> Must. Resist. Clicking. Send. Button. No. NO!.
>
> Just one click, that's all. No. Yes. YES! *click*.
>
> :-)

I know.. I know .. I heavilly debated that myself before the clicking
on the reply, during typing, and clicking on send.. I hang my head in
shame.. :-)

[Dan Moorehead]

Lol, you guys sleigh me. I send so many emails these days that I just click away without reservation... but too easy to start a naming war that way!

--
Dan Moorehead
_____________________________________________
Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET (www.RealmWare3D.com)

Resume (http://realmware3d.com/Resume.pdf)

Business Card ( http://realmware3d.com/BusinessCard.jpg)

[Rob Loach]

Although I know the namespace discussion is "over" and I'd would love
to move on to more pressing issues, I just like to say that I'm in
agreement with Arakon on all topics. This is a whole different project
then CEGUI and the name should reflect that. The '#' character also
brought up some issues with the Wiki, but this isn't the point of this
post.... :-)

What I was meaning to discuss was that I just commited a number of
fixes in to the SVN to make it .NET 1.1 and Mono compatible. This
meant taking out all Generic collections and hard typing in some
specific collections and dictionaries. The only error that is brought
up by Visual Studio 2003 when compiling now has to do with one of the
XML Schemas. Changes are in the SVN.

Thanks a lot, guys. Progress is being made! Hopefully we'll beable to
move this discussion over to the forum one day.

Cheers,

Rob Loach
http://www.robloach.net

[Dan Moorehead]

Do we really want to move backwards towards .NET 1.1 support? I didnt realize that was the intended direction for CEGUI#, JWace?  Mono already has generics support even if its not fully production yet, I dont see a reason to take a step backwards for temporary support when .NET 2.0 is already prime.

[Don]

Aaack!  Rob, please don't take us back in time!

 

A whole lot of work has gone into trying to get these projects to work under .NET 2.0, including making use of generics.  Removing all that work (at all, let alone removing it without talking to anyone about it first) is an incredibly bad and disruptive idea.

 

Mono will eventually add generics.  When it does, the code will just work.  Until then, please, don't take us back in time.  It's hard enough to maintain forward progress on a project.

 

-Don

[Terry L. Triplett]

Mono already has generics, and the implementation is almost complete.  A lot of things "just work" already, and as you indicate, those that don't will eventually.  One of the talking points when moving Axiom  to .NET 2.0 was that those of us interested would contribute to Mono in those areas where the implementation was lacking. 

Don wrote:

Mono will eventually add generics.  When it does, the code will just work. 

-Don

[Dan Moorehead]

I agree, I have given you edit permission to SVN, and so far you have starting removing generic support and renaming the project without talking to anyone about it first.  As Terry had mentioned and others had mentioned before, we dont just make radical changes without discussing them first, communication not loner coding is our focus in these open-source projects. We are glad to have you contribute, but please communication your intentions before acting on them so we can all have a say in the direction of these projects.  Thanks.

--
Dan Moorehead
_____________________________________________
Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET (www.RealmWare3D.com)

Resume (http://realmware3d.com/Resume.pdf )

Business Card (http://realmware3d.com/BusinessCard.jpg)

[JW Sullivan]

My preference would be to continue moving towards .Net 2.0.

 

Does anyone know the official status of generics support in Mono?  I haven't been able to find that out.  From what I have seen, most of the other 2.0 features are now enabled by default in the Mono compiler, and the generics support is available in the gmcs compiler.  How stable is the generics support in Mono at this time?

 

Not a whole lot of work has been done to CEGUI# to start using .Net 2.0 features at this time, so for now this is not a major issue.

 

J.W.

[Rob Loach]

Considering the recent discussions and debates, I've decided it would
be best if I don't participate in the development of CEGUI#. My views
of what's best for the project don't seem to mesh well with most of
you.

My goals of the project were:
- Complete independence from Axiom and RealmForge
- Nice clean library that fits in well with the .NET Framework
- .NET 1.1, .NET 2.0 and Mono compatibility
- Speed up the development process

Although I would really love to help out with the project, whenever I
tried doing something beneficial to the project to head towards those
goals (and not permanent things for that matter), I was shot down.
It's been great trying to get this project moving and I think
everything is ready to take off now. I leave now with CEGUI#
completely on SourceForge, source moved into subversion, a new wiki
(http://ceguisharp.sourceforge.net) and a community forum
(http://ceguisharp.sourceforge.net/forum). I think this is all you
need to have a successful library. Now all you need are the developers
and the motivation.

I'll stop by now and then to see how things are going, but I won't
be touching anything anytime soon. Once things are moving, I'd be
glad to get involved again, but I don't think now is the time for me
to be involved in the development of this project.

I've had a wonderful time, gentlemen.

Sincerely,

Rob Loach
http://www.robloach.net

[Dan Moorehead]

I dont see any issue with your goals, a matter of fact, I agree with them. Mono .NET support, independence from Axiom/RF, speed up development, the works.  However, changing the name without asking anyone or regressing from Mono 2.0 support to 1.0 support is not a part of those goals and I think rightfully so.  I would like to see you continue with those goals, I just ask when you perform major changes of direction that these be discussed first, I dont think that an unreasonable request? Communication is just a function of working together with a community in open-source development, however we are quite open to incremental changes and those dont need to really be discussed other then status updates to keep everyone on the same page and not doing redundant work.  As I had said, I appreciate your *work* other then the two issues of implicit name changes and removing the latest contributions of others to generic support. 

On 3/7/06, Rob Loach <robl...@gmail.com> wrote:

Considering the recent discussions and debates, I've decided it would
be best if I don't participate in the development of CEGUI#.  My views
of what's best for the project don't seem to mesh well with most of
you.

My goals of the project were:
- Complete independence from Axiom and RealmForge
- Nice clean library that fits in well with the .NET Framework
- .NET 1.1, .NET 2.0 and Mono compatibility
- Speed up the development process

Although I would really love to help out with the project, whenever I
tried doing something beneficial to the project to head towards those
goals (and not permanent things for that matter), I was shot down.
It's been great trying to get this project moving and I think
everything is ready to take off now.  I leave now with CEGUI#
completely on SourceForge, source moved into subversion, a new wiki

( http://ceguisharp.sourceforge.net) and a community forum

(http://ceguisharp.sourceforge.net/forum).  I think this is all you
need to have a successful library.  Now all you need are the developers
and the motivation.

I'll stop by now and then to see how things are going, but I won't
be touching anything anytime soon.  Once things are moving, I'd be
glad to get involved again, but I don't think now is the time for me

Sophomore in Business Administration: Entrepreneurship
University of Illinois at Urbana-Champaign

Project Manager and Software Architect
Visual3D Architect .NET (www.RealmWare3D.com )

Resume (http://realmware3d.com/Resume.pdf)
Business Card (http://realmware3d.com/BusinessCard.jpg)