Thinking about LDCad 2.0 and open sourcing it

[Roland Melkert]

Hi all,

Currently I haven't much time to work on LDCad 1.6 but I can't help thinking about the next next version which might be 2.0.

This would also be the perfect moment to go open source.

I consider switching to JAVA or PYTHON but I think both are too slow and JAVA is also a bit messy imho.

So it probably be C++(11) again. If so it will reuse large chunks of the current 1.6 code but in a reworked state.

If I go open source I would also need to select a License (I would like to keep it non commercial only)., this is the thing I'm looking up to the most so if anyone has some pointers on that

Also I'm wondering if there are people who would be interested to help development by taking up e.g. the mac version dependencies etc.

One major improvement planned would be the rendering of the gui (I want to go full OpenGL with this, even for dialogs) and I also want it be multilingual.

An actual usable 2.0 will probably take more then a year to make after actually starting it, so I might do a parallel 1.7

Any thoughts / feedback on this?

[Merlijn Wissink]

I can't really give you any recommendation on which license to use and not really on which language to use either.

At my current 'opleiding' (for some reason I can't find the right English word), we get Java (I would've gotten C++ if I chose another direction). I personally don't like it that much, desktop apps often feel slow when made with Java. I think the major advantage of Java is that it runs on a billion different devices and operation systems. However, nowadays more and more languages and frameworks have multi-device support. Take a look at this google trends chart...

I would love to help (although not with the Mac side, I don’t have a Mac), but I’m probably not that helpful. I only know the bare basics of C++ and just a ‘medium’ amount of Java and Python. I’m sure there are other people willing to help with a lot more knowledge than I have (yet).

I do understand though, that you might be a bit hesitant to go open-source. It’s your own ‘little’ hobby-project you’ve been working on for years, and suddenly everyone can access and modify it. I can see that might feel weird. Just do whatever you think is best, after all, it’s (still) your own work.

Btw, why do you actually want to use OpenGL fort he GUI and not something more… native (a framework or API or whatever that’s made to create a GUI)?

[Milan Vančura]

Hello Roland.

I'm in the last phase of the exhibition preparations (read: panic ) but this is so good message I must reply, at least shortly:

of course I help you with Linux version(s), we can use Build Service as for other packages and it may become the official part of OpenSUSE Factory (at least) and contain packages for other distros as well. I help you to setup proper build dependencies etc. and maintain it.

about the license: please check the list and rules for Linux distros so you don't fall into problems at the beginning, for example: openSUSE packaging guidelines, Debian packaging guidelines.

about the language: JAVA is "a legal hell". It was always a pain and now, after Oracle bought Sun company, it's a hell. I strongly recommend to ignore it. Python is slow but I've seen several desktop applications having time-critical parts in C or C++ and GUI layer written in python. Which is easy and readable and contains many modules of graphical/GUI libraries. Might be an option for you, too.

At all: I've always had a dream of having the complete Ldraw application chain on Linux, for free: the editor, LPub and what's needed in between (like renders). Even it takes some time, I'm ready to help. And/or ask my friends in Linux community to help us.

[Willy Tschager]

Hi all,

If I go open source I would also need to select a License (I would like to keep it non commercial only)., this is the thing I'm looking up to the most so if anyone has some pointers on that

Roland,

you surely know that LDraw ships with Creative Commons licences (the Library as well as the AIOI):

https://creativecommons.org/

you might have a look at their:

http://creativecommons.org/licenses/by-nc-sa/4.0/

Also I'm wondering if there are people who would be interested to help development by taking up e.g. the mac version dependencies etc.

One major improvement planned would be the rendering of the gui (I want to go full OpenGL with this, even for dialogs) and I also want it be multilingual.

An actual usable 2.0 will probably take more then a year to make after actually starting it, so I might do a parallel 1.7

I cannot help out on the C++ but I would love if the GUI would feel a bit more "windowish" with proper menus and if I could get rif off the floating menu pop-ups. I could help on designing more icons however ;-)

w.

[Roland Melkert]

At my current 'opleiding' (for some reason I can't find the right English word)

You're right I can't think of something ether its ether a superset (education) or a subset (course)

Btw, why do you actually want to use OpenGL fort he GUI and not something more… native (a framework or API or whatever that’s made to create a GUI)?

1.x does use a framework (wxWidgets) but I try to minimize dependencies on it because even with 1.0 I wanted it to be full screen OpenGL at some point. Modal dialogs are currently in the way of that.

Also part of the whole hobby (for me) is to write things I don't get to do during normal work projects. And writing a gui library is something I always wanted to do.

[Roland Melkert]

about the license: please check the list and rules for Linux distros so you don't fall into problems at the beginning, for example: openSUSE packaging guidelines, Debian packaging guidelines.

I'll have to get into that at some point, thanks for the links.

about the language: JAVA is "a legal hell". It was always a pain and now, after Oracle bought Sun company, it's a hell. I strongly recommend to ignore it. Python is slow but I've seen several desktop applications having time-critical parts in C or C++ and GUI layer written in python. Which is easy and readable and contains many modules of graphical/GUI libraries. Might be an option for you, too.

Yes but even without the legal stuff Java has some very strange ways of doing certain 'normal' things imho.

Python caught my interest as it might be good for my normal day job too. Also blender uses it, so it must do something well.

[Roland Melkert]

you surely know that LDraw ships with Creative Commons licences (the Library as well as the AIOI):

Yes the non commercial version of it did catch my eye but like Millan wrote I have to look into the Linux distro rules to see if it's compatible if I ever want LDCad to be an official package.

I cannot help out on the C++ but I would love if the GUI would feel a bit more "windowish" with proper menus and if I could get rif off the floating menu pop-ups. I could help on designing more icons however ;-)

Might be but 'normal' gui's are so boring I might setup some way to have alternative gui's though.

[Jason Smith]

I also think 2.0 would be an excellent time to refresh the GUI, make it a bit more boring if you will   . In a perfect world I would love to see it look like a pro graphics app such as Aperture, Lightroom, Autocad, Final Cut etc. This is an excellent app and it deserves the attention of an excellent GUI that attracts users. 

I vote against Java, I've had a lot of bad luck with it on Ubuntu and windows. My vote however doesn't count because I don't know how to program so I have no idea what's involved with either. 

There are some super talented people I'm sure who would love to help you. Seems as though there's at least one application a year that someone works hard on that eventually sinks in the deep abyss of unfinished or unaccepted applications. If those people could help you instead, LDCad could become a serious powerhouse, not that it isn't already.

[Travis Cobbs]

On the open source thing, I'll start by saying that, obviously, LDView is open source. So I'm obviously fine with open source. And it has worked for LDView, although it hasn't been a huge win. The Qt version (for Linux) was maintained by Peter Bartfai. (I say "was" because I can't in good conscience claim that LDView is an active project. Sure, I hope to eventually get another official non-Beta release out, but I have been saying that, literally, for years.) Aside from Peter's very welcome contribution, there have been other, smaller contributions from others. But other than Peter maintaining the Qt version, there haven't been any other developers that are part of the project (with read/write access to the source repository). And the fact that nobody has asked to take over and continue development makes it clear that I can't really claim that it being open source was a clear victory.

However, that never bothered me. I didn't open source it with the hopes that a bunch of developers would become active developers. I open sourced it because I knew it had the potential to be helpful, and I didn't see any clear down-side for me. So what I'm saying is, don't expect a bunch of people to jump on-board and help out. It could happen, but I think it's unlikely.

Switching to language choice. If you really plan to implement the whole GUI in OpenGL, then I feel your best bet would be to use C++ (11 or later) as the language, for a number of reasons:

• It's extremely well-supported on just about any platform you're likely to want to release on, plus more. Certainly on Windows, Mac, Linux, Android and iOS. There are free compilers on all those platforms, as well as professional versions of Visual Studio and Intel compilers on Windows.
  
• It's fast and low-memory by design (although of course it's possible to do things wrong and write slow, bloated C++).
  
• As long as you use C++11 or later, it gives you the infrastructure needed to write good code without being in constant danger of shooting yourself in the foot. (That was a lot harder to do in C++ prior to C++11.) Search "C++ core guidelines" for more on this; there are tools to help. If you haven't kept up with C++ developments, you may be surprised to hear that there is a whole way of thinking that says that, for example, new and delete should never appear in application code.
  
• If there is any "native" language for using OpenGL, it's probably C, and C++ can call C natively.
  

Having said all of the above, there are plenty of ways to shoot yourself in the foot with C++. It's just that since C++11 was released, it's a lot easier to write code that won't do that. It does require learning, but my personal opinion is that it's well worth it.

I have never been a Java fan. I used it at work many years ago and didn't like it then, and nothing I've seen since then has made me change my mind in any way (although I am aware that it has improved a lot). And, quite frankly, I have a seriously low opinion of Oracle. The fact that you have to uncheck a check box every time you update Java on your computer to avoid crapware is, quite frankly, preposterous. I make sure never to have Java installed on any computers where it's not absolutely necessary, and I would have to desperately want a program in order to convince me to install Java just to run the program. And that's not even mentioning the whole Oracle/Google trial thing; the fact is that I don't trust Oracle as a company. (Just search for "oracle protection racket" if you want to know why.)

With LDView, the Windows version is native Win32, the Mac version is native Cocoa, and the Linux version is native Qt. Of course, that means that I had to write the interface twice, and someone else had to write it once. (I mentioned above that Peter maintains the Qt code.) But a majority of all LDView code is cross-platform C++ (written before C++11 was available, so not at all what "modern" C++ would look like).

You wouldn't have that problem with an OpenGL-based interface. Obviously there would be some platform specific code for window setup and input handling, but I would expect it to be fairly small. So the thing you gain with Java (cross-platform support) doesn't seem like it should be worth much. And you lose a lot. (Just look at all the problems people here on this forum have running Java-based tools.)

Note: I'm not in any way trying to say that people should avoid Java when writing LDraw tools. It's my understanding that Java is the primary language used for teaching computer science, and using what you're familiar with is good. And having a program be truly cross-platform is also good. But it doesn't sound like you're an experienced Java developer, and the cross-platform nature of Java isn't going to buy you much.

[Travis Cobbs]

At my current 'opleiding' (for some reason I can't find the right English word)

You're right I can't think of something ether its ether a superset (education) or a subset (course)

Since I don't know what opleiding means, I can't be sure, but based on context, I suspect the English word you're looking for is curriculum.

[Milan Vančura]

With LDView, the Windows version is native Win32, the Mac version is native Cocoa, and the Linux version is native Qt. Of course, that means that I had to write the interface twice, and someone else had to write it once. (I mentioned above that Peter maintains the Qt code.) But a majority of all LDView code is cross-platform C++ (written before C++11 was available, so not at all what "modern" C++ would look like).

I do not know what was the (historical) reason for this with LDView but one of the biggest advantages of Qt is that it is really multiplatform. Not only Linux/Windows/Mac but also iPad or Android. So for new projects, there is no need to write GUI three times.
In fact, if Roland didn't want to implement his own GUI library, I'd strongly recommend Qt (even I am really not a KDE fan!). Just being pragmatic: there is a lot of work done - it's a C++ library with both its own scripting language and python bindings. It's mutiplatform and developed for many years, stable. And, even I do not know it to work with, I am able to read the others' Qt code and fix some bugs there. What shows the code is relatively easy to read. And, also, it allows the application to look natural on all platforms and supports multilingual applications with Unicode very well. So my opinion is it might make sense for Roland to use it and concentrate on direct openGL usage for time-critical issues like fast model rendering. But it's up to Roland.

[Travis Cobbs]

With LDView, the Windows version is native Win32, the Mac version is native Cocoa, and the Linux version is native Qt. Of course, that means that I had to write the interface twice, and someone else had to write it once. (I mentioned above that Peter maintains the Qt code.) But a majority of all LDView code is cross-platform C++ (written before C++11 was available, so not at all what "modern" C++ would look like).

I do not know what was the (historical) reason for this with LDView but one of the biggest advantages of Qt is that it is really multiplatform. Not only Linux/Windows/Mac but also iPad or Android. So for new projects, there is no need to write GUI three times.
In fact, if Roland didn't want to implement his own GUI library, I'd strongly recommend Qt (even I am really not a KDE fan!). Just being pragmatic: there is a lot of work done - it's a C++ library with both its own scripting language and python bindings. It's mutiplatform and developed for many years, stable. And, even I do not know it to work with, I am able to read the others' Qt code and fix some bugs there. What shows the code is relatively easy to read. And, also, it allows the application to look natural on all platforms and supports multilingual applications with Unicode very well. So my opinion is it might make sense for Roland to use it and concentrate on direct openGL usage for time-critical issues like fast model rendering. But it's up to Roland.

I don't know how Qt is now, but historically, it was very much a second-class citizen on Mac and Windows. Sure, it worked, but you could always tell that such apps weren't truly native. Such basic things as file open and save dialogs didn't use the system-standard ones, leading to user frustration, and every time a new OS came out with any kind of different look and feel, Qt apps were stuck with something that mostly had the old look and feel, but was never quite right in the little details.

Now, I'm not saying that Qt apps are bad, but it bothered me enough to have native Mac and Windows versions. Look at how Export and Save Snapshot are even now in the Qt version of LDView. Instead of having the options right there in the dialog where they belong, the options are separate. It could well be that this could be fixed now, but it was a problem when those were initially implemented. (Note: I think support for native open/save dialogs was added to Qt, but that support didn't include the ability to customize such dialogs. So once they fixed the first problem, you were left with the second problem if you needed customized versions of those dialogs.)

Now, I realize that Qt by its very nature can't be expected to provide hooks into all the latest and greatest native functionality provided by each OS that it supports, but the fact is that true native apps can almost always be made to have a more standard-seeming (and I would argue better) UI.

There were historically license issues with Qt also. I think the free version required any apps that used it to be GPL. I think they fixed that (although LDView is GPL, so it's not an issue for LDView). I haven't personally looked at Qt in years, so it could well be that modern Qt is fine, and solves the problems. But since I'm pretty sure that part of the Qt design is that Qt itself draws the widgets, I don't see how it can ever be a perfect match on all platforms. Mind you, what it does provide is good enough to produce good apps; it's just that they'll likely always feel just a bit off to people using Mac and Windows.

[Roland Melkert]

I choose wxWidgets over Qt because of the license as I wanted to statically link into a single executable (it's my Delphi background leaking through )

Also I only use a limited amount of stuff from wxWidgets (mainly zip, png and filemonitoring), and none of the supporting stuff like strings, lists etc as I like to write those myself as part of the hobby aspect of LDCad.

I do believe wxWidgets delivers truly native dialogs though, including the file browser one on Windows.

I won't expect people to jump on and start coding as understanding 155 thousands lines including many custom utility classes might be a bit  time consuming

The main thing I hope to get from Open Sourcing is a broader range of supported os's as people can compile it themselves if none of the pre-compiled versions suit their needs.

[Orion Pobursky]

My problem with Qt is its not native but lookalike. wxWidgets is the only widely used cross-platform library that uses native control bindings

[Milan Vančura]

I choose wxWidgets over Qt because ...

OK. My message was: there is at least one way how to make the application multiplatform using C++ and, optionally, some scripting language like python. The proof is by example (Qt) but I stopped there - I did not look for more examples because the statement was already proven

[Roland Melkert]

If I go open source I would also need to select a License (I would like to keep it non commercial only)., this is the thing I'm looking up to the most so if anyone has some pointers on that

Ok I did some reading and realized I can't call it Open Source with the 'non commercial' limitation in place, so I might have to drop that.

Although I really don't want people making money on LDraw based things without giving something back or having put in some considerable additional work themselves.

Anyone know how to address this issue?

In the meantime I'm thinking GPLv3 so at least modifications etc are forced to remain free/open.

But I must confess all this makes me hesitate a bit

ps: I do realize I'm not working on some sort of groundbreaking multi billion euro project here but it's my pet project after all

[Darren Carlson]

If I go open source I would also need to select a License (I would like to keep it non commercial only)., this is the thing I'm looking up to the most so if anyone has some pointers on that

Ok I did some reading and realized I can't call it Open Source with the 'non commercial' limitation in place, so I might have to drop that.

Although I really don't want people making money on LDraw based things without giving something back or having put in some considerable additional work themselves.

Anyone know how to address this issue?

In the meantime I'm thinking GPLv3 so at least modifications etc are forced to remain free/open.

But I must confess all this makes me hesitate a bit

ps: I do realize I'm not working on some sort of groundbreaking multi billion euro project here but it's my pet project after all

Although I manage a bunch of developers on a daily basis, I don't actually code myself. Other than teaching myself the conceptual basis of most of the languages my teams code in so that I can speak intelligently to them about how they do things.

I'm a business guy at heart and your postscript is what prompted me to reply.

Consider carefully what you do. This isn't a multi-billion euro project, but, with LDD support being dropped by Lego themselves, there is going to be a growing demand for other design software. They haven't update the parts library in LDD in ages and it's only going to get worse there.

My brief foray into LDraw design/editing tools let me to recognize that for the beginner, LDCad is by far the most friendly. If you added an option to drop a virtual baseplate into the design window, it would look and feel even more like LDD. But that's an aside.

My point is that I suspect over time you're going to see a considerable increase in the usage of your tool. Moving it to open source without clearly restricting commercial use and/or benefit could definitely result in some 'enterprising' individual to scoop up all your hard work and make dollars off of it in the manner that Redhat did with Linux. 

There is going to be a growing need for an LDD replacement and someone is going to fill it. I'd love for it to be this tool which I think is the best of the bunch available.

[Merlijn Wissink]

What you're saying about LDD is not 100% true.

There is no official confirmation about whether LDD is going to stop or not. Quite recently, a rumor appeared that a Lego customer service person said they were going to stop LDD, but later on a message from Lego came stating that it wasn't true. I can't remember it exactly, but it went something like that.

Quite recently (a few months ago) there was even a big parts update for LDD. That being said, it sure looks like Lego's LDD support is going downhill (or maybe the LDD team is getting smaller). Nobody knows if they'll continue like this, stop it somewhere in the future or even come with a complete new replacement product. For now it's just uncertain.

Whatever the outcome is, I just keep using LDraw and mainly LDCad 

[Darren Carlson]

What you're saying about LDD is not 100% true.

There is no official confirmation about whether LDD is going to stop or not. Quite recently, a rumor appeared that a Lego customer service person said they were going to stop LDD, but later on a message from Lego came stating that it wasn't true. I can't remember it exactly, but it went something like that.

Quite recently (a few months ago) there was even a big parts update for LDD. That being said, it sure looks like Lego's LDD support is going downhill (or maybe the LDD team is getting smaller). Nobody knows if they'll continue like this, stop it somewhere in the future or even come with a complete new replacement product. For now it's just uncertain.

Whatever the outcome is, I just keep using LDraw and mainly LDCad 

Fair enough. Guess we find out over time. But I know this....
If I keep using LDCad and LDraw, the community will continue updating the parts library.

[Roland Melkert]

What you're saying about LDD is not 100% true.

There is no official confirmation about whether LDD is going to stop or not. Quite recently, a rumor appeared that a Lego customer service person said they were going to stop LDD, but later on a message from Lego came stating that it wasn't true. I can't remember it exactly, but it went something like that.

Quite recently (a few months ago) there was even a big parts update for LDD. That being said, it sure looks like Lego's LDD support is going downhill (or maybe the LDD team is getting smaller). Nobody knows if they'll continue like this, stop it somewhere in the future or even come with a complete new replacement product. For now it's just uncertain.

Whatever the outcome is, I just keep using LDraw and mainly LDCad 

I don't think LEGO is going to completely abandon LDD any time soon, it's currently just low prio.

[Roland Melkert]

My point is that I suspect over time you're going to see a considerable increase in the usage of your tool. Moving it to open source without clearly restricting commercial use and/or benefit could definitely result in some 'enterprising' individual to scoop up all your hard work and make dollars off of it in the manner that Redhat did with Linux. 

There is going to be a growing need for an LDD replacement and someone is going to fill it. I'd love for it to be this tool which I think is the best of the bunch available.

I don't think something that dramatic will happen as LDraw is a very small community.

As for LDD I did notice an increase in traffic of LDCad downloads around the time LDD's future was very unclear but nothing my basic hosting package couldn't handle.

Also LDD/LDraw people seem to be very set in their ways so a editor switch usually takes a very big push to happen

[Darren Carlson]

My point is that I suspect over time you're going to see a considerable increase in the usage of your tool. Moving it to open source without clearly restricting commercial use and/or benefit could definitely result in some 'enterprising' individual to scoop up all your hard work and make dollars off of it in the manner that Redhat did with Linux. 

There is going to be a growing need for an LDD replacement and someone is going to fill it. I'd love for it to be this tool which I think is the best of the bunch available.

I don't think something that dramatic will happen as LDraw is a very small community.

As for LDD I did notice an increase in traffic of LDCad downloads around the time LDD's future was very unclear but nothing my basic hosting package couldn't handle.

Also LDD/LDraw people seem to be very set in their ways so a editor switch usually takes a very big push to happen

I'd agree. There are a lot of people using LDD simply because it's very very similar to building with bricks in the real world. That does present some design limitations but personally I find that interface kind of frustrating because it's designed to be so 'easy' for a beginner. Oh well. Each to their own.