Editor Refactoring

Everything about the development of Urho3D.

Re: Editor Refactoring

PostPosted by rasteron » 13 Dec 2016, 00:09

You can check out aster's 2D Particle Editor here: https://github.com/aster2013/ParticleEditor2D

uses Qt4 and I would assume you're going to use Qt5, but still this is a good reference to start with.
User avatar
rasteron
Have many posts
Have many posts
 
Posts: 437
Joined: 07 Mar 2014, 07:46
Location: web

Re: Editor Refactoring

PostPosted by TheSHEEEP » 13 Dec 2016, 06:55

cadaver wrote:I believe to have commented this before, but it doesn't hurt to reiterate.

If the editor is a separate project, using Qt fits very well. You'd only need solid setup instructions per platform, and the user could build or download Qt themselves and just ensure it's available for the project's CMake. Very likely you'd only ever use Qt + editor on desktops in that case.

As part of Urho repo or build itself, we have quite strong principles of automatic dependency build (and even including them in the source repo, since everything used so far is small). There Qt doesn't fit that well, or would require much more ninja magic.

Fully agree, Qt does not really fit with the dependencies so far. And it shouldn't, IMO. I don't think the editor should necessarily be built when you build Urho3D.
What I would probably do (and I don't say that I will, because I honestly do not have the time, this is just my developer experience speaking) is to create a separate repo just for the editor. The project structure I'd do as a Qt project (no CMake at all, since it is not required in this case and Qt is cross-platform already and free). Inside that project I would link against Urho3D, which would have to be put into a specific sub-directory of the project (so the user would have to put the binaries there himself, or it could be automated to a degree, even by Qt itself).
That would mean a complete and clean separation between Urho3D and its editor. So the editor would "just" be an application using Urho3D that happens to be using Qt.

Eugene wrote:- Harder to use with executable project

Not sure what you mean with that.
Do you mean the ability to have an editor built-in with every project that uses Urho3D? I don't think that would be a good idea. Such a built-in editor could never be as powerful as an "external" one. I think there is no example of a well-done built-in editor that comes with an engine, but there are countless examples of truly great external editors (just look at Starcraft 2 or Warcraft 3).

Eugene wrote:- Separate repo is worse than builtin

How so?
I would even say it is an important separation to make as they are simply different projects where only one depends on the other.
Urho3D could be developed mostly ignorant of its own editor, which IMO is a boon as it allows more focused development. And the editor could be developed "ignorant" of Urho3D's development (other than adjusting to eventual breaking changes).
User avatar
TheSHEEEP
Have some posts
Have some posts
 
Posts: 27
Joined: 21 Jul 2016, 09:07
Location: Finland

Re: Editor Refactoring

PostPosted by Eugene » 13 Dec 2016, 08:45

Not sure what you mean with that.

Exactly that you said.

How so?

Huh. I mean, from the developer's point of view separate repo is more clean way..
But it would be harder for newcomers to build Editor...
User avatar
Eugene
Some active
Some active
 
Posts: 62
Joined: 06 Jun 2016, 06:30
Location: Russia

Re: Editor Refactoring

PostPosted by Victor » 13 Dec 2016, 16:13

One purpose I feel the editor solves very well, for me at least, is how to use Urho's UI to do various things. It's essentially an advanced example. One thing to keep in mind as well, is that someone will have to maintain the editor for a very long time if you switch to Qt. I believe using Urho's UI makes this task (maintenance) a bit easier.

I do, however, think the editor in C++, rather than AngelScript, is a great idea. At the end of the day however, I see cadaver as being the person who would have to shoulder the burden of maintaining the editor, so it should be done in a way that would make that burden lighter for him.

My proposal, is to take more of a plugin approach; where most features/extensions of the editor is built as a linked lib or script (giving both possible choices on how to create a new feature). This way, a really cool feature by some random person can be versioned, and when it's not supported anymore it won't take down the entire editor. This may make the burden on cadaver (and not just cadaver but any main maintainers of Urho) lighter.
User avatar
Victor
Have some posts
Have some posts
 
Posts: 48
Joined: 11 May 2016, 14:22

Re: Editor Refactoring

PostPosted by Eugene » 13 Dec 2016, 16:51

IMO plugins is the most important thing that our Editor needs.

it should be done in a way that would make that burden lighter for him.

Unfortunatelly, it's pretty hard to simplify current AS Editor AND reuse the same code in Qt Editor because editor is mostly UI and we can't re-use code for UI.
User avatar
Eugene
Some active
Some active
 
Posts: 62
Joined: 06 Jun 2016, 06:30
Location: Russia

Re: Editor Refactoring

PostPosted by TheSHEEEP » 14 Dec 2016, 06:50

Victor wrote:One purpose I feel the editor solves very well, for me at least, is how to use Urho's UI to do various things. It's essentially an advanced example.

That's true. And I like the UI as it enables a user to get started rather quickly.
It's big downside is scope, though. It can't (and IMO wasn't designed to) and shouldn't compete with top-notch UIs out there, like Scaleform/Noesis/CEGUI*/etc. (I'll be using libcef personally).
For example, if you need a UI that scales perfectly with resolution, you'll have to look at alternatives. Which is pretty much mandatory IMO for non-mobile games if you don't want to subject users to weird scaling issues.

Victor wrote:At the end of the day however, I see cadaver as being the person who would have to shoulder the burden of maintaining the editor, so it should be done in a way that would make that burden lighter for him.

I'm not fully convinced of that. I mean, most of my experience in open source development comes from Ogre, but there different people were responsible for different aspects.
And since cadaver has developed such a great tool and is no doubt the driving force here so far, I would love him to be able to focus on the core of Urho3D. Which I do not consider the editor to be a part of.
For me, an editor would be a perfect project if another person wanted to contribute to Urho3D in a more long-time fashion :)

Which is why I wouldn't do any major changes to the editor, actually, before someone doesn't say "Yup, I'll do this!".
I'd love to do it, I know Qt rather well and like working with it. And it would also be a perfect way of getting to know Urho3D better before starting with my project (which will begin in ~1.5 years).
But I just don't have the time for such a commitment :(



*admittedly, calling CEGUI top-notch is a bit of a stretch.
Last edited by TheSHEEEP on 14 Dec 2016, 11:15, edited 1 time in total.
User avatar
TheSHEEEP
Have some posts
Have some posts
 
Posts: 27
Joined: 21 Jul 2016, 09:07
Location: Finland

Re: Editor Refactoring

PostPosted by Victor » 14 Dec 2016, 09:51

TheSHEEEP wrote:That's true. And I like the UI as it enables a user to get started rather quickly.
It's big downside is scope, though. It can't (and IMO wasn't designed to) and shouldn't compete with top-notch UIs out there, like Scaleform/Noesis/CEGUI*/etc. (I'll be using libcef personally).
For example, if you need a UI that scales perfectly with resolution, you'll have to look at alternatives.


I can agree with this, and you're right.

One other concern, I think, would be licensing. Perhaps someone wants to deploy their game with a modified version of the editor. How would Qt effect this? Would they have to rewrite their own editor to remove all of the Qt elements. Would wxWidgets be any better? And does statically linking your library effect this process as well with Qt (or wxWidgets)?
User avatar
Victor
Have some posts
Have some posts
 
Posts: 48
Joined: 11 May 2016, 14:22

Re: Editor Refactoring

PostPosted by TheSHEEEP » 14 Dec 2016, 11:08

Qt comes in both GPL (which I'd never choose, and there is no reason to) and LGPL (which is the one you can use for open-source and closed source/commercial both).

I am not a lawyer, but the general consensus for LGPL is that as long as you link dynamically, don't modify the source code, don't rename the lib files, put the license somewhere* and (some say this is mandatory, most say it isn't) make the source code of the LGPL-licensed software (so not your software) available somewhere, you are fine.
It really is not much to do and almost every software that does anything with audio/video manipulation does that for FFmpeg, for example.
Besides, this wouldn't even affect the editor in Urho3D since that would be open source anyway.

wxWidgets has some very weird kind of custom license, which seems to be a more permissive variant of LGPL allowing you to modify its source code as well.
But I see no reason to use wxWidgets. It isn't exactly lightweight, either and not as versatile as Qt. And it doesn't have an editor that could rival Qt Creator even nearly.
I tried working with wxWidgets before, more than once. But it always ended with hitting some brick wall that doesn't exist in Qt...

The only reason not to use Qt would be if someone wanted to have everything (including Qt) statically linked for the editor.
But why would anyone want that? To hide from other programmers that he did not write an entire interface library for every platform himself? :D

*You know, those "license" buttons in software that nobody really clicks on? Like that ;)
User avatar
TheSHEEEP
Have some posts
Have some posts
 
Posts: 27
Joined: 21 Jul 2016, 09:07
Location: Finland

Re: Editor Refactoring

PostPosted by Victor » 14 Dec 2016, 15:05

TheSHEEEP wrote:To hide from other programmers that he did not write an entire interface library for every platform himself? :D


So far, Urho has done so well with choosing libraries that are great for other people/companies. I work on a lot of projects that are NDA-bound, and license is a real concern. Like you said yourself, they would never choose GPL... I've also had a friend ask me to recommend a game engine her team could use, (she works at IBM in the R&D dept... they do crazy things heh). I recommended Urho because of the license and the light-weight nature of it.

Now, I'm honestly not sure of the "correct" direction for the editor. Maybe this will just be a community thing and not part of the official Urho repo; but if the editor were to change (officially), I believe careful thought would need to be taken. Any direction would have long-term consequences to the future of Urho (I hope I'm not being too dramatic).

I just want to make sure all of the questions and concerns, especially the long-term consequences, have been considered.
User avatar
Victor
Have some posts
Have some posts
 
Posts: 48
Joined: 11 May 2016, 14:22

Re: Editor Refactoring

PostPosted by TheSHEEEP » 16 Dec 2016, 06:15

Well, the truth is that many people are afraid of LGPL for no real reason. All it requires you to do is acknowledge the tools/libs you are using.
You don't have to share your own code at all.
You can still be secretive and earn money ;)
I don't think that is too much to ask, not from anyone, NDA or not.

And I especially don't think open source software should try to specifically cater to closed-source needs.

But yes, as said before, I think the editor (if being rewritten in whatever way) should be its own, separate project.
But the current one should probably stay as a good example for the UI.
User avatar
TheSHEEEP
Have some posts
Have some posts
 
Posts: 27
Joined: 21 Jul 2016, 09:07
Location: Finland

PreviousNext

Return to Developer Talk

Who is online

Users browsing this forum: No registered users and 0 guests

cron