Rename project, libMissile?

[mikke89]

As suggested by @barroto in #2, this fork of libRocket is now quite distinct from the original project. A rename of this work then seems natural.

Some things that me may consider with this change:

• Update the original documentation with the new changes
• Rename the namespace from Rocket to.. Missile?
• A new logo?
• Updated templates?

What do you think? These are just ideas I'm throwing out there, any ideas you may have are very welcome.

I'm not sure how the original documentation was built, but you seem able to assist here, @barroto?

[barotto]

I think I can assist with the docs, somewhat...

I've converted the original libRocket docs from html to markdown using Jekyll, so that GitHub Pages could auto-compile them from source.
https://help.github.com/en/articles/setting-up-your-github-pages-site-locally-with-jekyll

But I'm not an expert of Jekyll, quite the contrary...

[mikke89]

That would be great. I have no experience with it either. Do you think it's best to fork your repo and rename it or start over with a new repo?

[barotto]

I think you should fork and then rename once you've decided the final project name.
I've recently updated the documentation adding all the images so I think it's now complete and a good starting point.

[mikke89]

Great work! I've got it up and working now:

https://mikke89.github.io/libMissileDoc/

If you'd like to assist in documentation, I can add you as a collaborator. I think I'm going ahead with libMissile, it's a natural extension of rocket (a guided rocket). Although perhaps it sounds a bit too military for a gui library? Any other suggestions? libFire?

[mikke89]

The change has started! How do you like the new logo? :)

[barotto]

So you decided for libMissile?
Because after you pointed out it sounded a bit aggressive, I came up with another idea.

Bear with me:
libRocket -> libTorpedo (the weapon but also the fish, genus of rays) -> libRay

libRay can be interpreted in many ways like:

• geometry: half of a line proceeding from an initial point
• optics: an idealized narrow beam of light
• quantum theory: an equivalence class of state-vectors representing the same state
• fish: the common name for Batoidea, a superorder of cartilaginous fishes
• and many musicians and fictional characters

Pros:

• name is short, so the namespace is short as well (ray::)
• you can keep "rml" and "rccs"
• "ray" seems appropriate for computer graphics related stuff
• sounds non aggressive

Cons:

• name is short, so higher risk of name clashing
• someone could think it's a ray-tracing lib

Btw, what time zone do you live in?

[mikke89]

I guess I was a bit... trigger happy on that decision. ;)

Now I want libRay in my life! I also did like the tag line I came up with, it will be a tough loss. Plus we need a new logo already! But I like your thinking here. Interesting how it went from outer space to subsea space so fast. I'm also thinking ray tracing, but we could use the fish as a logo and everyone will understand!

Let me have one more day to think it over :)

[mikke89]

I also like that it still makes sense then to call it rml and rcss. You have me nearly there now.

[mikke89]

Ray fish with laser eyes! That's got to be our logo. Okay I'm convinced now. It's decided!

[barotto]

Take your time! ;)

[viciious]

Imo you got a bit too carried away with these poetic names as none of them actually reflects the purpose of the project :P How about plain and simple Rmlui or libRmlui instead?

Just my 2 cents.

[barotto]

I'm personally not fond of un-pronounceable acronyms. Btw, not even libRocket reflects the pourpose of the lib. How about libRayUI ?

[mikke89]

I think you're right I got carried away :P
Maybe just RayUI?

[barotto]

On second thought, rmlui is not bad.
Some variations to consider:

• libRay
• libRayUI
• RayUI
• RMLui
• libRMLui
• RmlUI
• libRmlUI

All start with "R" so "rml" and "rcss" are preserved.

[mikke89]

Okay, I'm leaning against RmlUi now. Lowercase i because it looks weird with the lUI in many fonts.

[mikke89]

I went ahead with this, and I'm quite satisfied with the change. :) Thanks to both of you for the proposal and suggestions!

I think I'm leaving the namespace as is, at least for now. Time better spent at all the other things.

[viciious]

Shouldn't the include path be updated to reflect the name change too: Include/Rocket -> Include/RmlUi?

[mikke89]

Yeah, do you think we should? I guess, to be consistent, we should also change the namespace away from Rocket as well then?

So, what should we pick? Probably one of these:

RmlUi::Core::Element
Rmlui::Core::Element
Rml::Core::Element
rmlui::core::Element
rml::core::Element

I would find it a bit awkward to write RmlUi often, my favorite right now is Rml.

[barotto]

The include path should definitely change to RmlUi as well as the version number which, given the disruptive changes from Rocket, should be a 2.x

For the namespace, I'm personally a fan of lowercased short names, so just rml would be nice.
But everything else would still be upper camel case, so I guess the most consistent would be RmlUi and the most practical Rml.

(I'm also a fan of snake case... how about changing everything to lower? ... lol jk)

[mikke89]

Right, I'll make master 2.0 then, and performance will be 3.0.

Hah, yeah, everything in snake_case would be nice, but not going to happen :P
I think the best consistency/practical tradeoff is Rml then.

[mikke89]

Okay, it is done! Puh.
I may seriously regret not waiting until the performance branch is merged, because that will be painful now.

There may possibly be some issues introduced here, although everything seems to be building and working properly from my testing. Please let me know if you have any problems :)