Up to date support for bmax :)

[TheoLogic]

You have QT, WxWidgets (which I prefer over QT), ... but that doesn't make C++ the best idea for UI. C++ has not been designed for event based UI development where other languages have. I used to do all my UI in WxWidgets (and Rick, this has an editor, generating clean C++ code), but have moved to .NET. These days you're app is not only the UI, but you want to sync with a server, extensive build-in help, ... and even with a C++ library this is still a pain in the bum.

[Rick]

These days you're app is not only the UI, but you want to sync with a server

 

Well, that completely depends on the app. A good number of apps don't sync with any server.

 

C++ has not been designed for event based UI development where other languages have.

 

You are right. C++ was designed to be very flexible and fast so you can design an event based system in it that acts just like .NET's. I've done it myself. I still think there is room for improvement in C++ for GUI's, but it's all there.

 

I like .NET as much as the next guy, but C++ can do basically the same thing minus reflection. .NET just bundles it all nicely.

[Canardia]

Event based UI is just one way to do an UI, and often more complex and memory consuming. I prefer a simple UI with a clean Update() and Draw() method, and so that I can check in code in what state specific menu elements are. For example I want to be able to say: if menu["options"].item["dof"] then menu["options"].item["fsaa"]=0. That would need much more code as event driven version, and more code is bad.

[TheoLogic]

Event based UI is just one way to do an UI, and often more complex and memory consuming. I prefer a simple UI with a clean Update() and Draw() method, and so that I can check in code in what state specific menu elements are. For example I want to be able to say: if menu["options"].item["dof"] then menu["options"].item["fsaa"]=0. That would need much more code as event driven version, and more code is bad.

 

You say something contradictory. Your suggestion is more code and more code is bad? I think you mixed up or I don't get it .

But if you're talking about a loop, I don't think that's a very good idea for UI. You're saying you prefer an update() to check your objects state, but that doesn't really makes sense. You can check your elements by their name: m_buttonToDoSomeAwesomeMagic->isEnabled() ...

[Canardia]

There is no "an" word in the sentence, so it means just the opposite as you understood.

You need an Update() method for menu items which change automatically.

[Rick]

You need an Update() method for menu items which change automatically.

 

No you don't. You catch that change in the event handler. You don't want a loop you want event driven. You don't want to go back to the Win32 API days. That's horrifying.

[Josh]

I don't know yet if I will add a BMX subforum. Since the BMX API is just the C API, there's not going to be a lot of BMX-specific issues like in LE2. It would be good to put any BMX-specific issues in a forum on blitzmax.com, if BRL allows it, because otherwise there isn't going to be an active discussion there. Having an active discussion on blitzmax.com is good because that will attract more blitzmax programmers. I've tried for a long time to think of a way to get them over here, and it's very hard because the only remaining customers there have brand loyalty like crazy, and generally aren't interested in anything that doesn't have the word "blitz" in the title. An active subforum on blitzmax.com is a way to make LE semi-official for BMX, without stepping on Mark's toes or asking him to get involved in distributing LE3 licenses.

 

As for the editor, I don't know what else I would use, because nothing else has a cross-platform native API, and it's like talking to a wall when I point this out to C# and C++ programmers. Eventually I would like to have our own version of MaxGUI written in C++, so it can be used with whatever language.

[TheoLogic]

No you don't. You catch that change in the event handler. You don't want a loop you want event driven. You don't want to go back to the Win32 API days. That's horrifying.

 

Exactly, you're going to loop yourself... What do you do when something changed? Call an event . Event based development is loop based in the background. Don't go an reinvent the wheel!

 

Josh, you could just use Java. Java is one of those languages that have been build for UI's...

[Josh]

Java doesn't have a cross-platform native GUI.

[TheoLogic]

Java is not native, that all...

[Rick]

http://www.wxwidgets.org/

 

"Unlike other cross-platform toolkits, wxWidgets gives its applications a truly native look and feel because it uses the platform's native API rather than emulating the GUI"

 

The downside being you would have to recompile on the specific platform.

[Canardia]

I don't like native GUIs, most OS GUIs look horrible, and I rather want some cool UI like in 3DSMax, Blender, Crysis or Delta Force.

 

No 3DSMax artist has complained that 3DSMax doesn't look so horrible like Windows XP, 7 or OSX, and I think for them the GUI look, feel and functionality is quite important since they use it for living.

 

And what would happen if the user (like hardcore users do), use a custom GUI in their OS, perhaps even a custom GUI engine, like most Windows skins do?

Would LE3 then be able to use that also, or would it fall back to some horrible looking GUI which the user never wants to see again?

 

So, if you are going to use native GUI for LE3, make sure there is also an option to use LE3's custom GUI and/or make LE3 skinnable via some XML file.

[Brent Taylor]

Josh, if you want a native GUI, you're pretty much stuck with wxWidgets if you want it cross platform. That said, using C++ for GUI development of any kind is a pain in the rear. Might I suggest Python with wxPython (a nice wxWidgets lib for Python)? You can create native style executables with py2exe, py2app and freeze under Linux. Just about all of my cross platform GUI apps have been developed this way and it's trivial to do.

 

*Just to be clear, I'm not suggesting you write the editor NOW. Just in the future if you do decide to write the editor in another language due to blitz no longer being supported.

[Rick]

That said, using C++ for GUI development of any kind is a pain in the rear.

 

Only because nobody has created a good API and IDE for that purpose. If someone would basically duplicate .NET but in C++ and the IDE would be the same then it would be no different. For GUI apps the IDE plays a massive role in how successful the API is. .NET wouldn't be as popular for GUI apps if it didn't have the IDE doing the heavy lifting for us. I mean why would it since something like C# is so close to C++. You can't tell me the small differences between the 2 languages (not frameworks, but languages) makes all the difference.

 

I'm going to have to get into Win 32 API programming again and make a C++ wrapper and IDE or something for people to see that the language has little to do with how "easy" writing a GUI app is. It's more about the framework and how it's setup.

[Brent Taylor]

Only because nobody has created a good API and IDE for that purpose. If someone would basically duplicate .NET but in C++ and the IDE would be the same then it would be no different. For GUI apps the IDE plays a massive role in how successful the API is. .NET wouldn't be as popular for GUI apps if it didn't have the IDE doing the heavy lifting for us. I mean why would it since something like C# is so close to C++. You can't tell me the small differences between the 2 languages (not frameworks, but languages) makes all the difference.

 

I'm going to have to get into Win 32 API programming again and make a C++ wrapper and IDE or something for people to see that the language has little to do with how "easy" writing a GUI app is. It's more about the framework and how it's setup.

 

You seem to be unaware that Visual Studio comes with an identical form designer for C++ as the .NET languages. It's not free as it's only in one of the paid VS packages. It works just as well as the C# and other .NET form designers. Coding for it however is still a very painful experience. C++, when used properly, is still a monstrous beast. If you honestly think the differences between C++ and C# are inconsequential, I'm afraid I'm left to believe you've never really used C++ for anything beyond the basics.

 

It's not that writing GUI's in C++ is difficult exactly. It's the fact that most things in C++, when done properly tend to be far more complicated than their .NET (or language of choice) implementations. In the end designing a GUI application (which in general does NOT have to be fast) in C++ is going to result in more dev time, more bugs and more code. Where's the advantage?

[Canardia]

.NET is nothing else than a well maintained collection of open source libraries. If someone would compile such a set of libraries for C++, it would be just the same, or even better since .NET lacks a lot of features you will need sometime, and then it's hard to find such libraries for C#.

 

It's the freedom of choice what makes this difficult in C++. In .NET there is no such freedom, but the libraries are dictated to you and you have no other choice, and this has of course also it's bad sides.

 

If someone tries to dictate you what libraries to use in C++, he will only get flamed

But of course you can still do it, and it's then a freedom of choice if people use it or not. Most won't, as they don't see that kind of .NET ideology as beneficial.

[Rick]

The ideology of most c++ library writers is why most view c++ as a pain to write a gui with. It doesn't have to be that way though. I'm going to create a very small c++ wrapper around the win 32 api that just handles the main window and buttons and make it event oriented and follow .net specs as close as I can.

 

You seem to be unaware that Visual Studio comes with an identical form designer for C++ as the .NET languages

 

If you are talking about either MFC or C++ CLR then both of those are a complete joke. MFC is just ugly and macro driven when it doesn't need to be and C++ CLR is a frankenstein of a beast. Weren't they even discontinuing that soon anyway? It's not even "real" C++.

 

If you honestly think the differences between C++ and C# are inconsequential, I'm afraid I'm left to believe you've never really used C++ for anything beyond the basics.

 

Show me the major differences in language and not framework that C++ can't do/simulate. Things like reflection is not the language itself but the framework. C++ has void* to simulate dynamic, I can simulate properties in C++ just like in C#, etc etc. At the core the biggest differences are at the framework level.

 

It's the fact that most things in C++, when done properly tend to be far more complicated than their .NET (or language of choice) implementations

 

That's what libraries are for. They are meant to hide the complexity and give the user (the programmer in this case) a nice clean and easy to use interface. This is the problem with most C++ library writers especially in the open source world.

 

I'll do my demo and see what I can come up with. I'll compare it to a C# example of the same nature and see what the difference truly is. Note the C# glue code that the editor creates will be include as well since that's what you'd have to do without an IDE. Most people would hate C# just as much for GUI programming as C++ without VS because it does so so much for the programmer.

 

 

Let's consider this test a proof of concept.

[Brent Taylor]

If you are talking about either MFC or C++ CLR then both of those are a complete joke. MFC is just ugly and macro driven when it doesn't need to be and C++ CLR is a frankenstein of a beast. Weren't they even discontinuing that soon anyway? It's not even "real" C++.

I'm talking about MFC. Yes, I don't like MFC either. There is also QT Creator (for QT) and wxGlade (for wxWidgets). They certainly make the job easier, even more so with QT (wxWidgets still being my favorite however. I hate qmake). It's still nowhere as easy as .NET with Winforms or WPF. Or Python with wxWidgets (and it's an almost identical library) or just about any managed language with a GUI library. The framework/standard library that ships with a language and the fundamental paradigms used in any language make a huge impact on ease and speed of development. Currently, C++ has the short end of the stick in that regard.

 

 

Show me the major differences in language and not framework that C++ can't do/simulate. Things like reflection is not the language itself but the framework. C++ has void* to simulate dynamic, I can simulate properties in C++ just like in C#, etc etc. At the core the biggest differences are at the framework level.

There is a significant difference between "provided out of the box" and "you can do that, but you have to make it". Reflection, properties, garbage collection and just about everything else are all possible to set up in C++. In general they are not trivial to create (some are however, easier than others). Are you seriously suggesting that you'd have shorter or easier development given that this is true? Yes, you could make a library for C++ that makes GUI development easy. That's theoretical. The library does not currently exist, and that is what matters. When you've created such a library, by all means lets revisit this.

 

That's what libraries are for. They are meant to hide the complexity and give the user (the programmer in this case) a nice clean and easy to use interface. This is the problem with most C++ library writers especially in the open source world.

 

I'll do my demo and see what I can come up with. I'll compare it to a C# example of the same nature and see what the difference truly is. Note the C# glue code that the editor creates will be include as well since that's what you'd have to do without an IDE. Most people would had C# just as much for GUI programming as C++ without VS because it does so so much for the programmer.

Unless you intend to create a framework that rivals the .NET, Python, Ruby or <managed language of choice> standard libs/frameworks, it's still not going to be as easy or bug free. Again, the standard library and paradigms used in a language greatly effect ease of use and development time. In addition, you're talking about a theoretic GUI library, a library I might add, that is designed for a specific task. Just the GUI.

 

----

 

Don't get me wrong, I'm not saying don't use C++. It's a perfectly viable tool for any number of tasks. GUI dev just normally is not one of them as there are far better options.

[Josh]

http://www.wxwidgets.org/

 

"Unlike other cross-platform toolkits, wxWidgets gives its applications a truly native look and feel because it uses the platform's native API rather than emulating the GUI"

 

The downside being you would have to recompile on the specific platform.

That's a complete lie. If wxWidgets used the native GUI, wxWidgets applications would be unrecognizable as being such. wxWidgets applications are easily recognizable and full of bugs.

 

This is why I say it's like talking to a wall whenever I bring this up. I just mention it, and everyone has to post a wall of text defending their favorite language.

[Rick]

The framework/standard library that ships with a language and the fundamental paradigms used in any language make a huge impact on ease and speed of development. Currently, C++ has the short end of the stick in that regard.

 

I'm not arguing with you there, but there is a big difference between a framework/api and the language itself. C++ has just chosen to not be that specific but libraries can be made to make a framework (not built in by any means) just as good as the built in frameworks.

 

Also, C++ didn't get the short end of the stick, they picked that end. They want users to make those libraries using C++. I get it. I hate open source **** too. Combining 20 different libraries and having to compile each one is not something I like to do, but that's just old school mentality with C++ people. As .NET programmers over the years venture into C++ land they will eventually bring over the ideals.

 

Are you seriously suggesting that you'd have shorter or easier development given that this is true? Yes, you could make a library for C++ that makes GUI development easy. That's theoretical. The library does not currently exist, and that is what matters. When you've created such a library, by all means lets revisit this.

 

I think we are on the same page. The point I'm trying to make is that C++ currently isn't thought of as a GUI language because the implementations (and there really aren't all that many) are not that good. Instead of trying to copy proven frameworks (like .NET) they go off on their own and try to do some crazy stuff. Most also don't use the native GUI elements which like Josh points out is kind of annoying. There just hasn't been a good library created for C++ for GUI programming but it's more than capable of doing it. GC btw would be debatable if it's a good thing or not I'd say.

 

 

If wxWidgets used the native GUI, wxWidgets applications would be unrecognizable as being such. wxWidgets applications are easily recognizable and full of bugs.

 

Do you have examples of this? Just curious as I'd like to check some out.

 

 

This is why I say it's like talking to a wall whenever I bring this up. I just mention it, and everyone has to post a wall of text defending their favorite language.

 

We are trying to help. You admitted yourself you are using a dead language for your editor. Is that really a long term solution? 5 years, 10 years, 15 years down the line? I'm defending C++ because I know it can do it, but personally I think you should have used mono. .NET isn't dead and will be around for a long time to come and it has amazing support. It's only growing but you picked a dead language because you know it better at this point in your life just like you picked it when you made previous of versions of LE, but look at LE 3 now.

 

 

BTW can you believe MFC. I have a hard time believing MS tried to pass that off as anything but a POS.

[Brent Taylor]

That's a complete lie. If wxWidgets used the native GUI, wxWidgets applications would be unrecognizable as being such. wxWidgets applications are easily recognizable and full of bugs.

 

This is why I say it's like talking to a wall whenever I bring this up. I just mention it, and everyone has to post a wall of text defending their favorite language.

 

Err...Josh, I've done *dev work on wxWidgets. It's using the native GUI lib on the system. As far as being "full of bugs", I'd like to see a source for that. No software is bug free mind you, but don't confuse bugs with the toolkit, and bugs in an individual program. High Priority wxWidget bug list.

 

I've no idea where you get the idea that wxWidgets applications are "instantly recognizable". As mentioned, it uses the native windowing kit of the system.

 

*By dev work, I mean I've poked around in the source and have made a couple of changes. Nothing official. But it is definitely using the native windowing kit on the system.

[Brent Taylor]

BTW can you believe MFC. I have a hard time believing MS tried to pass that off as anything but a POS.

 

MFC is a perfect example of the engineering at Microsoft back in the day. Overall, the concepts and paradigms in MFC are very well engineered. They then took those concepts and paradigms and took them entirely too far. And then created an even worse implementation.

 

It's one of the reason I like wxWidgets. It uses the same concepts and paradigms, but scales them back to an appropriate level and keeps a nice, clean and usable implementation.

[Josh]

It's similar to Windows, but you're blind if you think this is the standard Windows GUI:

 

 

Code::Blocks gas a lot of redraw bugs when the panels are resized. You'll get a big chunk of the window grayed out because it didn't redraw right.

 

On top of that, wxWidgets has the absolute worst command design possible. Every single widget you create is its own class! It's ridiculous.

[Rick]

Actually the "default" Windows GUI is ugly. .NET adds some visual pleasantries with visual styles.

 

Honestly I'm not a fan of that in wxWidgets either.

[macklebee]

anyways....

 

personally would like to see a bmax forum... i see no reasoning for there to be a separation. Everyone will be using the same dll so the excuse not to provide one since its using the same dll is kind of a moot point. If this is the reasoning then why have separate forums for any of the other languages? just have one big general Programming forum....