Thinking about LDCad 2.0 and open sourcing it


RE: Thinking about LDCad 2.0 and open sourcing it
#9
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.
Reply
« Next Oldest | Next Newest »



Messages In This Thread
RE: Thinking about LDCad 2.0 and open sourcing it - by Travis Cobbs - 2016-05-31, 5:20

Forum Jump:


Users browsing this thread: 1 Guest(s)