Up to date support for bmax :)

[cassius]

I agree with macklebee, and thanks mack for getting back on subject.

[Rick]

just have one big general Programming forum....

 

I agree with this. If every command will be identical no matter what language then it doesn't make much sense to separate out the forums by language.

[macklebee]

I agree with macklebee, and thanks mack for getting back on subject.

 

well considering the topic was support for bmax for LE3 and requesting a subforum, I really don't understand why anyone that doesn't use bmax feels the need to make a case against it or even comment on this subject.

[Rick]

well considering the topic was support for bmax for LE3 and requesting a subforum, I really don't understand why anyone that doesn't use bmax feels the need to make a case against it or even comment on this subject.

 

Didn't we just come to an agreement of not having a subforum and just having a programming forum? That was BMax and non BMax people coming together right there! What a beautiful thing.

[macklebee]

did we? I think you are mistaking sarcasm concerning the reasoning of not providing a bmax subforum when other languages have one as an agreement to remove all the subforums. The point was the argument against it made no sense since all the languages will be using the same dll.

[Rick]

I think you are mistaking sarcasm concerning the reasoning of not providing a bmax subforum

 

Oh, I guess being the internet and all sarcasm doesn't come across to well

 

 

The point was the argument against it made no sense since all the languages will be using the same dll.

 

Combining them all to just a Programming forum seems ok since all commands are exactly the same. Let's unite the programmers instead of divide them. Also we have Java & Python & who knows what other language ports the community will come up with and Josh doesn't create forums for those. We have a .NET forum which is about as supported as our Java port yet .NET has a forum. I mean it all doesn't really make sense.

 

It's kind of like this thread http://www.leadwerks.com/werkspace/topic/3384-camera-going-thru-walls/page__pid__30954#entry30954

 

You point him to a C++ example, I explain in English and yet he posted it on the BMax forum. It's all just programming.

[Brent Taylor]

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.

*sigh* I'm not blind and I've worked with the code base. However, you're confusing custom drawn widgets with native controls. Code Blocks is using a lot of custom widgets as do most applications. As you're very much aware (having created them yourself for the LE3 editor) most GUI toolkits allow for custom widgets. wxWidgets (and GDI under windows, as that is what is being used internally) of course also allows this functionality.

 

It's really pointless to argue this. wxWidgets is under the MIT license, feel free to check out the source. I have.

 

----

 

You don't have to like wxWidgets. I honestly don't care what you use, as long as you're productive in it. That said, don't spread FUD either.

[Josh]

If it's using GDI to draw custom widgets, then how can that be considered the standard GUI? By that definition anything is the standard GUI, as long as it's drawn on a Windows window with GDI.

[Rick]

I think he's saying some of the controls are custom because out of the box MS doesn't have them in their default GUI. The common things like a button and the like would be using the default Windows button. There wouldn't be much point in making your own button since MS has one already for you, BUT if you wanted a button to do something MS's buttons doesn't that's where they are making their own.

[Brent Taylor]

I think he's saying some of the controls are custom because out of the box MS doesn't have them in their default GUI. The common things like a button and the like would be using the default Windows button. There wouldn't be much point in making your own button since MS has one already for you, BUT if you wanted a button to do something MS's buttons doesn't that's where they are making their own.

 

That pretty much covers it, yes. Precisely like the Treeview control that Josh has created for LE3's editor. It's a custom widget.

 

Keep in mind Josh, QT and most other GUI toolkits don't use GDI or native widgets. They have their own rendering routines. They don't have access to ANY of the standard controls in any OS (with the exception of Nokia's OS's, where QT _IS_ the native GUI toolkit).

 

The base wxWidgets toolkit only provides widgets native to the OS (with a few exceptions*) and does use GDI's native controls (proof). Most applications written with wxWidgets just use the standard widgets, or modify their functionality. Much like how you're building the LE3 Editor. You could create custom widgets for everything to give visual flare if you wanted. But you're sane and don't do so. You create custom widgets only when you need functionality that isn't provided.

 

It's precisely the way MaxGUI works actually. Under windows it's a wrapper around GDI as well (proof). When the native toolkit doesn't provide functionality you need, you create a custom widget. It's not terribly complicated concept. The creators of Code Blocks and Audacity however, for whatever reason, decided to create completely custom drawn widgets for a lot of their application. Do I agree with their decision? Heck no. Is it a problem with the GUI library used? Not in the slightest.

 

When you write an application in wxWidgets, it will look different on every OS purely because it will use the native windowing API's for the system. GDI on Windows, GTK under linux (which doesn't HAVE a native GUI library) and I believe it's using Cocoa under OS X.

 

*Exceptions being like MDI under OS X and Linux. MDI is a windows paradigm, and while the controls are "supported" under other OS's, they're converted by the runtime to native tabbed interfaces and the like. There are only a couple of controls that do things like that, and they are well documented.

 

----

 

As I said though, use what makes you the most productive. The only reason I would bother switching to something other than Blitz for writing the editor would be my concern of Blitz applications no longer working on future versions of OS X. I expect Blitz and MaxGUI will continue to work on Windows and Linux for quite some time.

 

----

 

If it's using GDI to draw custom widgets, then how can that be considered the standard GUI? By that definition anything is the standard GUI, as long as it's drawn on a Windows window with GDI.

 

That's not what I said. I was pointing out that those two applications are using custom widgets. wxWidgets by itself does not. In precisely the same way that MaxGUI provides native widgets. Both however give you the option of creating custom widgets, if those provided by the system to not offer the functionality needed by your application.

[Rick]

In case Josh didn't want to go digging in your proof. Inside Control.cpp in the MSWCreateControl method:

 

m_hWnd = (WXHWND)::CreateWindowEx
                      (
                       exstyle,            // extended style
                       classname,          // the kind of control to create
                       label.wx_str(),     // the window name
                       style,              // the window style
                       x, y, w, h,         // the window position and size
                       GetHwndOf(GetParent()),         // parent
                       (HMENU)wxUIntToPtr(GetId()),    // child id
                       wxGetInstance(),    // app instance
                       NULL                // creation parameters
                      );

 

Native Windows creation of controls.

 

In all honesty though I think a good number of other libraries that don't use Native GUI elements do so because all systems are different and getting things to look and feel just the way you want on all systems can be a pain. You've seen that pain between ATI and nVidia with your engine. Now your editor will experience that with 3 systems instead of 2 like your engine. Like Brent mentioned some concepts are system specific so you have to do the lowest common denominator with your controls which can hurt the design.

[Josh]

As a side note, I thought it was a "plus" to advertise an engine that supports so many languages, and it's understood that you could only "officially" support so many, but since you're using BMax for the editor, that tells me it's officially supported. Whether it's admitted openly or not, the editor keeps up with the engine, and therefore the "BMax include file" would be consistently kept up-to-date. Unless you eventually have plans to rewrite the editor in another language, like C++ or C#? If so, wouldn't that also mean that support for BlitzMax is no longer "officially" supported?

Getting back on-topic, I don't see myself switching the editor over to C# or C++ at any time in the future. There's no compelling reason to. We'll hope future versions of all supported operating systems remain backwards compatible as long as possible, which I think should be good for another ten years.

 

Yes, you are right that the majority of projects of interest come from the BlitzMax coders.

[Paul Thomas]

Thanks for answering and clarifying, Josh.

[TheoLogic]

@Paul Thomas: In my opinion it's not a plus that an engine supports so many languages. For me this reflects some kind of amateurism, because this gives me the idea that there is no clear goal or target... But that's just my personal opinion.

But anyhow, I think there will be a time where the editor should be rewritten. I would prepare to this change, especially with a version change in mind. But Josh's decision .

[Marleys Ghost]

In my opinion it's not a plus that an engine supports so many languages. For me this reflects some kind of amateurism

 

Fully agree, after all accessibility is such a massive negative point for any product </sarcasm>

 

 

I would prepare to this change, especially with a version change in mind. But Josh's decision .

 

I for one have just finished preparing, I posted there was not really a big incentive for this BMaxer to upgrade, and from reading how this thread progressed, that opinion has not changed. Seems it's the usual C(++)ulprits arguing about whats best not only for LE but for everyone one else, whilst at the same time unable to agree amongst themselves what that is, which arises as they are basically arguing whats best for them personally and stuff everyone else. There is an old saying about too many C(++)hefs spoiling the soup. As the forecast is that at some point time will have to be devoted to learning/using an alternative language, the choice for me will be, after weighing up the pros and cons, a proprietary scripting language, it will save on headaches later.

[Rick]

As the forecast is that at some point time will have to be devoted to learning/using an alternative language, the choice for me will be, after weighing up the pros and cons, a proprietary scripting language, it will save on headaches later.

 

Sounds like we're going to need another forum

[Marleys Ghost]

Sounds like we're going to need another forum

 

 

What for?

[Rick]

It was a joke that brought the original request for a forum for a language (BMax), which by the sounds of it you are going to create your own, full circle. haha, wink wink, poke poke

[Marleys Ghost]

which by the sounds of it you are going to create your own

 

 

no, learn/use ... not create, the clues are all there.

[TheoLogic]

Fully agree, after all accessibility is such a massive negative point for any product </sarcasm>

 

Please don't overblow my words, I can't really appreciate people putting words in my mouth.

So do you believe cheap software that has 101 features? In my experience everything has been blown up, and almost nothing works... If I see LeadWerks officially supporting a whole range of programming languages, I'm not convinced this will magically work.

 

I for one have just finished preparing, I posted there was not really a big incentive for this BMaxer to upgrade, and from reading how this thread progressed, that opinion has not changed. Seems it's the usual C(++)ulprits arguing about whats best not only for LE but for everyone one else, whilst at the same time unable to agree amongst themselves what that is, which arises as they are basically arguing whats best for them personally and stuff everyone else. There is an old saying about too many C(++)hefs spoiling the soup. As the forecast is that at some point time will have to be devoted to learning/using an alternative language, the choice for me will be, after weighing up the pros and cons, a proprietary scripting language, it will save on headaches later.

 

You are very, but then very cocky. This is an open discussion, and just because you don't like it, blame the C++ devs! We state that this could be an option, or that could be better. Go ahead and stay in your comfort zone. You want to weight to pros and cons, do it in group, we are open to suggestions. Weighting against yourself is gonna end up with what you like the most.

 

Sorry for this...

[Rick]

I guess my detective skills are lacking since Lua isn't a proprietary scripting language (and hence wouldn't fit into your description of using a proprietary scripting language) and it's the only scripting language officially supported by LE so switching to any other scripting language wouldn't be much different than using BMax in the first place with LE3.

 

You are very, but then very cocky

 

Have you met Marley?

[TheoLogic]

Have you met Marley?

 

No I have not . I'm not in a good mood, sorry about that... I sometimes get tired of people bashing C++ devs (even if they use other languages and scripting where needed). I'm proud of C++, one of the old school languages still evolving!

[Marleys Ghost]

You are very, but then very cocky. This is an open discussion, and just because you don't like it, blame the C++ devs! We state that this could be an option, or that could be better. Go ahead and stay in your comfort zone. You want to weight to pros and cons, do it in group, we are open to suggestions. Weighting against yourself is gonna end up with what you like the most.

 

Sorry for this...

 

Actually it was a thread about "Up to date support for bmax" , which was then hijacked by C++ devs all arguing about what was best from thier own POV's whilst remaining decidedly off topic, I called it like I saw it, maybe I hit a nerve or two? but the fact remains none of what was being bickered about amongst yourselves mattered one jot to myself, only what the topic was actually about, nothing more nothing less. I believe I have my answer, from the relevant information buried in the Cacophony of irrelevant noise. The weighing up of all pros and cons, for me, was beyond the limited remit of this simple topic title, although it was the catalyst for having to do so, it did not require it to be done in a group that much is certain.

 

I guess my detective skills are lacking since Lua isn't a proprietary scripting language (and hence wouldn't fit into your description of using a proprietary scripting language) and it's the only scripting language officially supported by LE

 

 

As I said, the clues are all there.

[TheoLogic]

Agreed, we're moving of topic .

Answer could be simple: If Josh has the time and the will to keep them updated: "Be my guest..."

[Rick]

I think our group talk brought josh out to speak more about the topic, helping you come to your coclusion. Otherwise you would have just gotten the vague song and dance

 

You're welcome jk