Gui Mod ?

Is it true they are going to make a non gui window system for blitzmax and if your not happy would you like a window gui system to be made ?

Making a non-native GUI system would be suicide. I doubt they are that stupid...

It say's here thay are using FLTK for the gui - http://www.blitzmax.com/Community/posts.php?topic=42033

sounds like a Blitz+ mod is in the works too.

Explain.

Yeh, please exsplain, how would it be suicide, it would mean intergrity could be kept across platforms?

BUt I might be wrong?

It would be fine and even preferable for in-game interfaces. Apps on the other hand need to be written in their native OS interface. Otherwise they just look hokey.

But for games... FLTK looks more than adequate.

I think you misunderstand me. If BRL rolls their own GUI solution and we're expected to use that instead of the native controls in whatever OS we're running on, that's suicide. If they use something like wxWindows or FLTK, that's fine.

I don't want to explain further as it should be clearly obvious why using non-standard UI controls would be a mistake.

Heh, FLTK would not be fine, it is the Linux solution even though the module does run on windows and mac but looks totally awful compared to native XP/AQUA widgets.

Oh, I wasn't familiar with FLTK, sorry. wxWindows then. Whatever gets used MUST use native widgets. That's my point...

I think if they were to make a gui system then make 1 for each platform using each of the platforms gui systems not someother gui system

For in-game gui's though a single (skinnable maybe?) gui system would be preferable. Then you could ensure consistency across platforms.

But for desktop apps... definitely native.

yes that is right for a game gui system i would prefer a customized gui system but for apps say for instance i want to make a eg. map editor or something i would rather use windows gui system

The coolest solution would be if mark made a command/type set and then implemented it using all three native guis. It could even be possible to have some "core" code that is universal among the 3 guis (like, event handling systems, abstract types declaring main types). In each of the much larger, platform specific parts, the methods are defined, event calls are setup, and the variables are set. Since Oses will most likely have very diffferently sized components, we will need ways to know how big various parts of a component are, or how large the font is. If we want to make cross platform apps we will have to pay attention to these properties and use them in figuring out the layout of our windows. Examples of a possible class:

'Core File

?Win32
Import "Win32.bmx"
?
?Mac
Import "Mac.bmx"
?
?Linux
Import "Linux.bmx"
?

Type Point
 Const YRef_Up=0
 Const YRef_Mid=1
 Const YRef_Bottom=2
 Const XRef_Left=0
 Const XRef_Mid=3
 Const XRef_Right=6
 Field X,Y
 Field FromRef,ToRef 'FromRef is which area of the parent the origin is.
                     'When FromRef is different from 0, the coordinate system changes.
                     'In TopRight, +X is left, in BottomLeft, +Y is up, In BottomLeft, +X is left, +Y is up.
EndType

Type Size
 Field W,H
EndType

Abstract Type Component
 Private                    'Doesn't work right now for some reason, even though its necessariy in this case since we
                            'definitly dont want the user updating variables without triggering events to call the native gui.
 Field Location:Point
 Field Size:Size
 Field Parent:Component
 Field Caption$,Name$

 Public

 'MultiPlatform Layout stuff
 Field CaptionFont.Font     'Defined elsewhere

 Method SetLocation(X,Y)    'BMax really needs java/C# style properties.  All these functions could be replaced by stuff 
                            'like Component.Location=New Location(5,5) assuming we also get constructors, a little less likely.
  Location.X=X
  Location.Y=Y
  UpdateLocation()
 EndMethod

 Method SetLocation(n:Point)  'Assuming we'll get overloading
  Location=n
  UpdateLocation()
 EndMethod

 Method SetSize(W,H)
  Size.W=W
  Size.H=H
  UpdateSize()
 EndMethod

 Method SetSize(s:Size)
  Size=s
  UpdateSize()
 EndMethod

 Method GetPosition:Point()
  Return Location
 EndMethod

 Method GetSize:Size()
  Return Size
 EndMethod

 Method SetParent(P:component)
  Parent=P
  UpdateParent()
 EndMethod

 Method GetParent:Component()
  Return Parent
 EndMethod

 Method SetCaption(Text$)
  Caption$=Text$
  UpdateCaption()
 EndMethod

 Method GetCaption$()
  Return Caption$
 EndMethod

 Abstract Method UpdateEverything()
 Abstract Method UpdateLocation()
 Abstract Method UpdateSize()
 Abstract Method UpdateParent()
 Abstract Method UpdateCaption()'Updates based on user calls to set functions
EndType

Abstract Type CheckBoxBase Extends Component  'Base Class, pretty universal right now
 'Vars for multiplatform layouts:  (No readonly parameter :|)
 Field BoxS:Size,BoxO:Point 'Offset from control (If control is reversed, BoxO.From can=6.
 Field TextO:Point 'Text offset

 'Actual fields:
 Field Checked:Byte

 Method SetChecked(Value:Byte)
  Checked=Value
  UpdateChecked
 EndMethod

 Method GetChecked:Byte()
  Return Checked
 EndMethod

 Abstract Method UpdateChecked()

EndType

In the "Win32.bmx", a checkbox class would be created that derives from CheckBoxBase. Then, all you have to do is code the stuff that actually interacts with the native gui :0

Not sure why, but I was inspired to write a big code example in the browser 0_o.

Bot Builder

All they really need to do is look at wxWindows in depth and do that. The research has already been done (including how to handle the differently sized controls - via "sizers").

Ah. Huh. Never used wxWindows. Sounds nice.

Well, "nice" is in the eye of the beholder I guess. :) It works well enough. It's not pretty at times, but that's what you get if you want it to be cross platform...

WxWindows is not bad but you need to do it though c++ into blitzmax which c++ is a good sign for me.

I'm not saying they should use wxWindows, I'm saying they should do it LIKE wxWindows. That level of abstraction (or higher).

If I remember, Java has some kind of cross-platform GUI system which, unless I have my wires crossed, would show a GUI using the native GUI style rather than it's own, even though behind the scenes it still had a single interface for the programmer. I might be wrong, but that would be cool. I wouldn't *prefer* to have some `non-standard-looking` GUI in amongst everything else looking native. Still .. if the system is skinnable then probably it can be made to look like the native GUI.

It doesn't need to be skinnable, it just needs to create native controls.

www.wxwidgets.org

@skidracer

Why not use QT in Linux? That way the app will look correct for the current KDE theme.

doesn't qt cost about a trillion quid per app though?

Well Microsoft seem to be rather successful depite using non-standard UI controls.

Yeah, and besides, nobody uses KDE anyway. :o>

And that means ... what? That using standard controls for each OS is a bad idea?

Other than throwing out yet another flippant comment, what are you trying to say?

Os standard controls only, please.

I do not like the idea of some freaky 3rd party look unique to blitzmax.

For me, best of all worlds would be whatever simple single interface in BlitzMax and then completely customizable gui system that EITHER can look like some custom theme or like the native gui also. Actually, I have my own ideas about how GUI's should work but that's another story and I would be happy with the kind of support I just mentioned. (and have it run on OpenGL displays too)

For the start a crossplattform event module would be enough to create a gui system on top of it ...

wxWidgets looks good to me.

I think some people are confusing "in game" gui and the gui we're talking about. "In game" stuff can be whatever you want it to be. Once you step outside of the game window, it's important to use native controls.

I just want to make a button which is native looking across all computers and operating systems. Thank you. I will also pay for this of course.

I will not pay for garbage custom widgets that look like they are from some kind of science fiction OS, drawn by a spastic monkey.

lol.

Interesting viewpoint though - that game gui's have to always be separate from and have nothing to do with the native gui? Ie, one standard for the context of being an `application` and one standard for the context of being a `game`. Why?

Not so much that they have to be... but that they CAN be. You don't EXPECT a game to look the same graphically as your operating system though there are some exceptions to that (I think Civ2 ran windowed, but I can't remember). But ALL applications or windowed programs are expected to look like other windowed programs on the desktop. When you load up Word, you expect it to look the same as any other windows program.

Can native widgets be rendered to an OpenGL context? Not in Windows they can't. You can't use GTK (and hence wxWindows) to render to OpenGL under X Windows either. Cocoa might be different, I don't know.

If you want an in-game GUI you can't use native widgets. If you want native controls they'll have to be in a separate window.

> and one standard for the context of being a `game`. Why?

Mostly for immersion. A gui in a star trek game better look star trekkyish. One for a WWII game should not look like the native system either.

do you expect app gui's to look the same or have you COME to expect it?

It's vital that applications look and *BEHAVE* like the host os scheme.

This will enable users of your program to be immediately familiar with it, and also give them more time to learn your app, rather than learning the gui.

This means more shareware sales if you're in that biz.

Native gui can be rendered to a gl window as you might have seen multi applications do it i also this api is the best way to do it

that's the problem, compared to windows from linux, on linux we have so many widget sets to choose from, some GPL others LGPL there must be hundreds of the stuppid things, now on windows if you remove the ports from linux, you only have 1 winapi widget set to deal with.

The ideal for this is, you build a language to interface 'a' widget set irrespective of which widget your using, then take that way of accessing the gui and change the code acordingly behind it to work on which ever platform.

But what ever you do, don't use an index system for widget commands/windows etc. use 'real' pointers that are being used.