Hi, the license is a temporary choice. I wish to release it under a permissive license in the future, I'd just like to secure a tiny bit of funding before that !
Just a note that if you accept any merge from anyone else, when changing the licence, you'll have to have their consent to change the license as well. Sounds like it might be a difficult thing to switch, depending on how many contributors you'll have when wanting to switch.
Is that true though? I thought all third party contributed changes are licensed separately, with the contributor still having all rights, unless they explicitly say otherwise.
IANAL: My understanding is the same as @halfastack's.
> I thought all third party contributed changes are licensed separately, with the contributor still having all rights, unless they explicitly say otherwise.
That's true, but it prevents the project owner from changing the license unless either the contributed code's license is compatible with the new license, or all contributors consent to the license change. That is, going from MIT to GPL is fine, but GPL to MIT is not.
Projects concerned with this frequently require contributors to sign a CLA (Contributor License Agreement) where the contributor gives permission for the project to use the contributions and relicense them in the future. E.g., Ubuntu [1].
I don't think that's quite accurate either. Although you can include MIT-licensed code in a project that is, as a whole, licensed under the GPL, you still must include the original license and copyright, rather than "going from MIT to GPL."
For example, if you have an MIT-licensed project and I contribute to it, my MIT-licensed contribution will remain MIT-licensed, regardless of what you do in the future. If you change your project license to GPLv3, and later can prove that someone used my code from your project after downloading your project's source, I do not think you will be able to successfully hold them to the GPLv3 and force them to release the source of their derivative work.
My understanding is a bit different, but also not a lawyer.
> going from MIT to GPL is fine, but GPL to MIT is not
AFAIK both are _not_ fine, eapecially because the licenses are totally incompatible.
When you publish a patch under a certain license (that of the project at the moment of the contribution), you _only_ allow using your code under that license. This is why dual licensing is a thing.
Except when you sign a CLA - mostly used by companies to gain copyright over your work. In that case the company can do whatever they want - even charge you later to use your own code.
> AFAIK both are _not_ fine, eapecially because the licenses are totally incompatible.
MIT licensed code can be relicensed under GPL with or without modification to the code. It is only the other way around that won’t work. The reason for this are the specific demands made in each license.
> The MIT license is also compatible with many copyleft licenses, such as the GNU General Public License (GPL); MIT licensed software can be integrated into GPL software, but not the other way around
IANAL.
Personally I encourage people to prefer the ISC/BSD/MIT family of license over GPL, but anyone that is set on using a GPL license is within their rights to do so for code derviative of said licenses (and several others as listed in the above linked list of GPL compatible licenses).
Possibly true... but wehther it can be done without modification to the code is a separate issue from whether a license change can be made without the consent of all contributors.
What I am saying is that anyone can take MIT licensed code and re-release it as GPL licensed code. That includes anyone of the author without consent from the other authors, or even someone who was not an original author. Specifically because such a change does not violate the terms of the MIT license. Whereas for going the other direction; GPL -> MIT you need consent from all authors (either directly or via a CLA that permits such a change of license).
License your work under GPL3 and if someone want to uses your engine in a proprietary game, then you can sell him your game engine under a permissive license. Just be sure that the other contributor are okay with it.
It's thin in the way that all the goodies are in separate modules that you don't have to use, and also in the way that it still runs in the browser with all these goodies.
For those that might remember a UI library called kiui that I shared a few years ago: it is the UI module inside mud (and is still usable independently).
It has also been completely revamped, and now follows an immediate/declarative paradigm that makes it much more straightforward to use, while still being entirely stylable and auto-layout.
The rest are new components I developed and refined in the mean time!
I'm interested to know more about your plans for a declarative model.
I think many things in kiUi, especially the layout and style, can be seen as declarative, in a way.
But the individual widgets and interaction between them are not. And I'm curious as to how it could be different.
Also you want to collaborate on something or just discuss, I'm interested.
After spending quite some time writing UI, I believe doing it in either XML or HTML is just pure madness.
UI is a very complex structure with complex wiring and interactions between components, and so it is very prone to human error. To represent such a complex system in anything else than a statically typed language like C++ is, to me, incredibly counter-productive.
You may like to write them in XML, but I want to write them in code and I wrote kiUi just for that. It's more concise, less error prone.
More essentially, I think it comes from a "fallacy" or "false dream" that a designer could design a reactive UI in XML or HTML without knowing anything about code.
The back of the coin, is that to code a real UI you need both HTML and javascript, or XML and another language.
XML and HTML are just here for the layout.
But kiUi takes a rather different approach at layout, which is that you may not even need to specify layout in the first place. It's done for you already, but, the designer can still tweak it if needed.
So, kiUi inverted relationship of the primacy of layout over the rest. In kiUi the primacy is to the native code, and to the logical elements (the widgets).
I think that things like React, and React-Native show the opposite is true... composition of UI elements that are meant to be rendered in relative terms doesn't tend to work out well when you are trying to use absolute measurements in something like C++ with lower-level constructs.
The fact that it is XML is more convention in this case... even with React, it's translated to coded controls via strict rules.. and is relatively easy to manage and reason with.
You are somewhat right in that HTML and CSS heavily inspired what kiUi became.
But there are two major concerns that are not adressed by your solution :
- Embedding a whole browser in your app just to display a few widgets is not my definition of "lightweight"
- Often coding UI in native code (C++) makes a lot more sense, integrate with exiting code in a much cleaner way
Game developpers would much less tend to build their own libraries from scratch, if there was at least one that satisfied all of these 'basic' requirements : lightweight, skinnable, auto-layout
I agree, embedding a browser doesn't seem lightweight at all. What it does give, however, is a common and comprehensive framework for laying out and styling your UI elements. Every web developer can now be a game UI designer.
Some of the benefits I see with HTML+CSS(+JS) based UI:
* Comprehensive feature set
* Easy prototyping
* Easy modding
* No recompilation required
* Web full of documentation & examples
* Common skill for developers/designers
The main disadvantage is probably the performance hit of having a full-blown browser engine in your game, but it seems to work OK for AAA games. I believe Anno 2070 uses Awesomium for some of its content: http://www.posidyn.com/games/anno2070/anno2070-09.jpg
Thank you. As to the draw calls, NanoVG draws everything directly each frame so this is constant whether or not you are updating. As to the overhead, not too long ago everything was updated each frame regardless of whether it was modified or not, and performance was fine. Worse than it is now, but okay. So I guess it could handle it.
But then again, that's only the default renderer. You can always roll your own and plug it in, kiUi has been designed to permit that.
Gotcha. I ask because, on my machine, kiUi takes 8-9ms every frame regardless of what I'm doing (e.g., typing, dragging windows, resizing things). If I'm trying to maintain 60 FPS with Emscripten, 8-9ms is a significant portion of my 16.7ms frame budget.
statico: you can load a different TTF with ImGui, it doesn't have to be monospaced and they can be smooth. The perf differences are due to designing the library with performances as a major pillar, lots of things are optimised. A visual redesign is planned but it'll take a bit of time to get it done to keep the perf up.
If you want to strip it down, you can start by not compiling all the widgets you don't need as there are quite a lot of them. The renderer (glfw, NanoVG) takes about half of the dll size (~500kb) on windows.
Framerates are much better in the non-web version somehow: I suspect some unnecessary texture sampling ops are to blame, but I need to investigate.
Resizing the window to a smaller helps greatly improve the framerate, which tends to show that the bottleneck is in the fragment shaders.