MaxGUI roadmap

BlitzMax Forums/MaxGUI Module/MaxGUI roadmap

skidracer(Posted 2009) [#1]
Hi all,

Seb and I are having quite some discussion regarding where next for MaxGUI.

It continues to sell well and my attempts at moving to FOSS have been thwarted for next 12 months at least.

If you are a MaxGUI user, please feel free to post any real world requirements you may have.

Innocent bystanders will be interested to know there are some new drivers planned. One extremely ambitious the other implausible without significant community contribution.

I am in favor of locking down the maxgui interface for simplicity sake and adding a new module for platform specific extensions. Gadgets here will be designed to maximize coherence with underlying design of Cocoa, Win32 etc. hosts.

Should a simplistic/agnostic gadget interface to said platform specific calendar, movieplayer, scintilla control, playlist manager etc. emerge then cool but I don't think it's healthy for MaxGUI to be cross platform exclusive as we move forward.


Also, I am prepared to award best suggestion for inclusion in roadmap (bonus points for extending TGadgetItem) a bottle or 6 of winners own choosing.


Ked(Posted 2009) [#2]
I'm not sure I understand what's going on...


xlsior(Posted 2009) [#3]
While platform agnostic code is preferable of course, I don't see any reason not to include some features that may not work on all three, since not everyone is developing code for all three platforms at the same time.

Leveraging the strengths of (some of) the individual platforms is better than not having a feature on any platform IMHO...

As far as desired functionality, I'd appreciate the following:
- Calendar (Win32)
- multi-column listbox
- multi-column grid with sortable columns, images, etc.


degac(Posted 2009) [#4]

I'm not sure I understand what's going on...


Well, we are in 2...

And Sebholl seems to be working on multi-coloumn support if I have understood correctly....

I am in favor of locking down the maxgui interface for simplicity sake and adding a new module for platform specific extensions


This does mean - for example - we can have something like the D-Bug work (CocoExt) that allows MacOS-only gadget?


Beaker(Posted 2009) [#5]
Something I'd like to see is working maxgui frameworks for minib3d and blitz3dsdk that allow for key/mouse events to pass to the 3d window.

I'd also like to see some layout helper container stuff, similar to wxWidgits sizers.

Collapsable panels would be nice as well.


r(Posted 2009) [#6]
Would be usefull :
- calendar gadget and date/time picker
- listview
- rich editor
- grid

I know this is probably impossible...


d-bug(Posted 2009) [#7]
This does mean - for example - we can have something like the D-Bug work (CocoExt) that allows MacOS-only gadget?


Since this thread was opened I heavily ask myself, if I should continue or just lean back and wait what happens.


Knotz(Posted 2009) [#8]
* Skinning would be very nice.
* SetColor for the Menubar (I believe Leadwerks asked for that also).

The idea is that I can alter the look of the UI in such a way it merges nicely with the game graphics. I rather make complex dialogs in MaxGUI than using some homebrewed code which uses sprites.


Mark Tiffany(Posted 2009) [#9]
You can choose to ignore my thoughts if you wish (as probably fall into innocent bystander category now), but here goes with my thoughts on what you might want to consider:

0. Make sure that absolutely everything looks the same on all GUIs as possible. Things like the recent fix to toolbar helps here, but even things like font sizes for buttons : Windows tends to have poxy small fonts, Linux and MacOS big clunky ones. This may just be a case of publishing standard sizes people should use, or some way of forcing use of a particular font size for all gadgets, but is a real pain to sort out gadget re-positioning on all platforms.

1. Make the GTKmaxgui official. I know Brucey had a bit of a downer on this, and I believe that there are some meaty changes to be made, especially on how the timer stuff works, but I do think this should be a major boon to maxgui. I'll add a pinch of salt though in wondering how many people actually do (or would want to) use maxgui on linux...

2. "Table" or "Grid" view - can be simple initially, then extended outward to feature images, advanced formatting, in cell editing if demand is there.

3. Advanced custom text editor - essentially start by replicating the basic textarea functionality, but with custom code which is almost certain to be faster. Then extend onwards from there with built in text / code functionality like built in Undo / Redo levels, parsing, highlighting, code folding, etc, etc. This should also benefit MaxIDE too. You could consider Scintilla I guess, or possibly the custom proxygagdets posted by the community - there are a few decent efforts that could probably be used as a basis.

4. Built-in clipboard integration, i.e. Set/GetClipboard:Object which could be any number of objects, TImage, string, Null if format not recognised, etc.

5. "Layout" functionality like the splitter to aid screen construction by creating "panels" within a screen and being able to move them around, auto-hide them, etc. Again, would benefit MaxIDE.

6. I've always wondered if maxgui qould benefit from a GUI designer, and related "LoadWindow" function to load the screen, rather than having to handcraft it.

7. I've also always wondered about the benefit (and commercial appeal) of creating a "maxgui for graphics mode" driver. i.e. a completely custom (and skinnable probably) GUI for us inside games in graphics modes. It feels like it might be useful to some, but not sure how it would fit the maxgui design. I suspect it would be fun to try though...and presumably could be used as a custom (and skinnable) GUI outside of graphics mode too...

Anyway, just a few passing thoughts, feel free to ignore me...


SebHoll(Posted 2009) [#10]
And Sebholl seems to be working on multi-coloumn support if I have understood correctly....

Well that's been put on hold for now - Skid wants to freeze the API until we decide where we are going.


JoshK(Posted 2009) [#11]
It's probably impossible, but I love the menu and toolbars .NET programs use:




Ked(Posted 2009) [#12]
:) Here are my suggestions:

1. Multi-column Listbox Support (Same as what Mark T. said about the grid/table view: make really simple then extend it if needed/wanted)
2. Official GTKMaxGUI
3. Offical system tray API (including pop-up menus)
4. Mark T.'s number 3 :)

Well that's been put on hold for now - Skid wants to freeze the API until we decide where we are going.

GASP!


skidracer(Posted 2009) [#13]
GASP!


I just wanted a small idle period where anything new gets scrutinized and added to some kind of roadmap before we drop the clutch again.

Seb has done a fantastic job with 1.34 and after a series of release candidates I thought a few quiet weeks wouldn't hurt where we try and get things a little more planned (hence this discussion).


Ked(Posted 2009) [#14]
Yeah, I understand. I was just being a pain. :P

However, is this a request-new-gadgets thread or suggest-ways-for-MaxGUI-to-be-set-up thread?


skidracer(Posted 2009) [#15]
For all I know it could turn into a "MaxIDE really needs an icon editor" thread.


ziggy(Posted 2009) [#16]
I would just suggest that if there will be some controls only available on some OS, I would ask Mark to add a sort of 'throw warnings' to the max compiler, so people can see a warning when they're using a speciffic gadget that won't work on any other platform. (just a suggestion).


degac(Posted 2009) [#17]
Maybe the right question is: What are the gadgets 'non-common' on all the platforms, and what we can do to support these 'aliens' in MaxGUI?

Or - in a second attempt - what can be done via Proxygadget (with support for all current platforms) and what not?
And what are the current differencies in MaxGUI on each platform (one for all: HTMLview/JavaScript under FLTK - I doubt this can be easily resolved...)?

About advanced textarea there should be 'Scintilla': I dont' know (at the moment) what OS it does support, I dont' have any idea how difficult is to 'port it' to MaxGUI (and if the effort to do this!).

About skinning: if I'm running - for example - CrystalXP program (or what is its name) all my efforts to 'skin' my GUI are gone; delete from the list this 'suggestion' (in my opinion of course) this is not useful at all.


However, is this a request-new-gadgets thread or suggest-ways-for-MaxGUI-to-be-set-up thread?


Or what kind of interface 'under-the-hood' should MaxGUI have? (refering to Sebholl's multicoloumn list gadget 'suspended'.

I thought a few quiet weeks wouldn't hurt where we try and get things a little more planned (hence this discussion).


No problem here, indeed very kind your idea to 'open' the discussion.


Ked(Posted 2009) [#18]
About advanced textarea there should be 'Scintilla': I dont' know (at the moment) what OS it does support, I dont' have any idea how difficult is to 'port it' to MaxGUI (and if the effort to do this!).

Scintilla works fully on all three platforms (Win32, MacOS, and Linux (GTK))

About skinning: ... this is not useful at all.

Agreed.


Difference(Posted 2009) [#19]
1. Multi-column Listbox AKA Grid. Sortable with headers and resizing columns, right clickable headers etc.
2. Scintilla
3. "Layout" functionality
3. Calendar control.

I'd like to see as many controls as possible be available on all platforms. I think it's only natural if they look different, but as long as it makes sense, the functionality and code for them, should be the same. Layout functionality, should be responsible for sucking up the differences in size and such.


[EDIT]: Last paragraph edited to make the meaning clearer.


JoshK(Posted 2009) [#20]
Scintilla support is my #1 request.

Multi-select tree views and tree view checkboxes.

Something like this would be fantastic:



xlsior(Posted 2009) [#21]
0. Make sure that absolutely everything looks the same on all GUIs as possible.


The problem with that is that the design guidelines for the individual platforms are NOT the same. Imposing the same look and feel and sizing on all platforms may be convenient for the developer, but it makes the program stand out on the target OS, and not in a good way.

If your dialogs have fontsizes that differ significantly from the standard, it looks bad to the user. They don't care that you also released a windows/mac/Linux/whatever version, all they see is that their copy looks wrong.


DrDeath(Posted 2009) [#22]
6. I've always wondered if maxgui qould benefit from a GUI designer, and related "LoadWindow" function to load the screen, rather than having to handcraft it.

^ This. Definitely.

Handcoding the GUI is surely possible, but simply a pain in the arse.


Grisu(Posted 2009) [#23]
^ A GUI designer is for the weak. Also, there are already some out there. - I see no reason for reinventing the wheel here.

What is meant by "new drivers planned" btw? Do we finally get Dx9/Dx11 support?

*reenters innocent bystander mode


Mark Tiffany(Posted 2009) [#24]
GUI designers are funny things. You either love them or hate them. I think that the problem is that unless done really well, they are a paid. I've never liked GUI designers that generate code, or at least that generate code that then can't be loaded to the designer, then tweaked inthe designer, then saved again *without* frigging up your own code.

The problem with that is that the design guidelines for the individual platforms are NOT the same. Imposing the same look and feel and sizing on all platforms may be convenient for the developer, but it makes the program stand out on the target OS, and not in a good way.

If your dialogs have fontsizes that differ significantly from the standard, it looks bad to the user. They don't care that you also released a windows/mac/Linux/whatever version, all they see is that their copy looks wrong.

Actually, I agree with that, but still want to be able to write something once that will look okay on all platforms. I want my cake and eat it, I know!

But I can't help feeling that there must be some means, although I suspect that means would be something along the lines of the little I remember of Java (jwt was it? only ever used the original Java!), in that the developer doesn't get to specify sizes. i.e. specify where you want to gadgets and the GUI layer has to work out what size it needs, and where to position it. That's not without issues of course, e.g. I want my Ok and Cancel buttons the same size.

Maybe the new feature request should be for relative positioning and sizing of gadgets, which can be over-ridden (or min'd & max'd) with pixel sizes if required. There is some functionality in this respect already, but I don't think enough to truly do this.

Just don't ask me to code it! And would anyone use it?


Mark Tiffany(Posted 2009) [#25]
Seb, here's a relatively "simple" one for the splitter gadget - SPLIT_AUTOHIDE behaviour. Does what it says on the tin: shows / hides the splitter by hovering the mouse over the splitter, then by leaving the splitter (possibly after a short period).

Maybe something to work on "on the sly" while skid's stopping you from adding... ;-)

Then we could all have auto-hide bars in the IDE...


xlsior(Posted 2009) [#26]
Something else that could be useful, is a way to easily retrieve a some of the system-defined settings from within your program, like default window color, menu color, background color, font type, font size, text color, etc. Having access to those settings could make it easier to blend your program in well with the OS it runs on.

(Knowing the default windows background color, for example, makes it possible to create a canvas that blends in with the window regardless of the colorscheme the user has chosen)

I know that at least for windows there's some API calls in the code archives that will retrieve this info, but it would be nice if it were built in.


degac(Posted 2009) [#27]

Something else that could be useful, is a way to easily retrieve a some of the system-defined setting


Agree +1
And at this point (but not MaxGUI related...) some functions to retrieve the 'Home','Docs','Music','Apps' folders and so on (I know there are some solutions already available...)


EOF(Posted 2009) [#28]
I would like some kind of bare minimum GUI framework in which you can add extra components as you need them

Just as an example I use my own simple framework which allows the creation of a window and label text. The final executable is 58k (uncompressed)


Ked(Posted 2009) [#29]
Do we finally get Dx9/Dx11 support?

MaxGUI drivers... not Max2D drivers. :)


jsp(Posted 2009) [#30]
Actually when I am looking at what we have already and what people mailed me to implement in my designer, I don't think there is a lot of demand on new gadgets, but more on comfort in all directions. Nevertheless a grid and a calendar would not hurt.

So I would vote for:
Retrieving the system settings as stated above, but also (desktop) mouse coordinates, screens and such.
Scintilla
Set mouse-pointer pixmap, the current set is quite limited.
An ActivateGadgetOnHover function you could set like SetGadgetSensitivity to catch the focus to a certain gadget the mouse is over, thus you could immediately act on mousewheel scrolling (for treeviews, html, listbox, textarea and such) and other events without selecting it first.

Some nice to have:
System tray support
Multi line tabber


Mark Tiffany(Posted 2009) [#31]
A more advanced tabber might be handy (again, thinking of IDE usage). Some examples of what you could consider adding, probably in decreasing usefulness - an optional close gadget on each tab, optional multi-lines as above, ability to have a right click on each tab (and know which tab you are over), drag and drop to move them around?


JoshK(Posted 2009) [#32]
Maybe a callback option could be added:

SetGadgetHook(gadget:TGadget,hook:TEvent(event:TEvent))

Function hook:TEvent(event:TEvent)
Select event.id
Case EVENT_GADGETACTION
'blah blah
EndSelect
EndFunction

I know you can do this with AddHook(), but this would call the function only if the event source is the gadget, so it eliminates a lot of extra code.


theHand(Posted 2009) [#33]
Mark Tiffany said:
0. Make sure that absolutely everything looks the same on all GUIs as possible. Things like the recent fix to toolbar helps here, but even things like font sizes for buttons : Windows tends to have poxy small fonts, Linux and MacOS big clunky ones. This may just be a case of publishing standard sizes people should use, or some way of forcing use of a particular font size for all gadgets, but is a real pain to sort out gadget re-positioning on all platforms.

1. Make the GTKmaxgui official. I know Brucey had a bit of a downer on this, and I believe that there are some meaty changes to be made, especially on how the timer stuff works, but I do think this should be a major boon to maxgui. I'll add a pinch of salt though in wondering how many people actually do (or would want to) use maxgui on linux...


Ked said:
2. Official GTKMaxGUI


from wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits:
Whenever possible, wxWidgets uses the native platform SDK. This means that a program compiled on Windows will have the look and feel of a Windows program, and when compiled on a Linux machine, it will get the look and feel of a Linux program.

* A positive side effect is that wxWidgets is thus more likely to look, behave and feel native - sometimes including native features for free (e.g. possibility to have spellchecking built-in in all text areas on OS X).
* A negative side effect of this is that it is more likely that the behaviour is different between platforms; toolkits where widgets are lightweight lose some of the native aspect but also minimize platform-specific code (hence minimizing the risk of different behaviour from platform to platform and also minimizing the risk of platform-specific bugs). Concentrating on native looks also mean wx may not be best suited for applications that want a customized look instead of the system's theme


wxWidgets is the most mature of all three (GTK and FLTK).
Weigh which one is the best (not necessarily the easiest), but please, either make MaxGUI depend on wxWidgets or GTK.

If you want my personal opinion, I would like to see BlitzMax use Allegro to run, well, everything. But BlitzMax with Allegro seems unlikely. :D


skidracer(Posted 2009) [#34]
If you are attracted to wx, then please use the wx module.

If you like GTK then perhaps please help discover new interface paradigm, possibly single textstream interface to script based GTK object manager.

Currently neither fit very well with the MaxGUI "you not your gui own the main loop" paradigm. Once BlitzMax threading matures this point may be open to discussion.


Ked(Posted 2009) [#35]
... make MaxGUI depend on wxWidgets ...

Ew, no. I think it would be easier to just add a GTK module. But I do not want MaxGUI "depending" on it either...


degac(Posted 2009) [#36]
wx is too heavy: try to create a simple application (like a window) with MaxGUI and wxMax and you'll discovery the 'little' difference in size.

I would like to see implemented:
1 - Image/text alignment on all three platforms
2 - 'Shaped' buttons (are supported on Cocoa and FLTK)
3 - 'no border' buttons.

I'm quite sure that some of these hacks can be made (personally I've managed to get 1 & 2 - I've messed up all the 'costant' & IF style sentence, but it worked...)

What about a 'function' for auto-alignment?
(what follow it's only pseudo-code, I've made something in my application as 'layout manager')
SetGadgetGroup(parent)
SetGadgetAlignment(HORIZONTAL)
Local g:Tgadget=CreateButton("Test",0,0,0,0,window)
CloseGadgetGroup()


The idea is to 'adapt' the gadget in the group (in this case 'parent', a panel or a window), ignore the size & x,y position, and 'add' the gadget on the basis of the SetGadgetAlignment() statement.
If you have 5 gadgets in a panel with HEIGHT=100, every gadget has its own height of 20 pixels (100/5) automatically aligned.
It makes drawing a layout very easy.


EOF(Posted 2009) [#37]
I agree with that idea degac. It's one way to avoid the tedious guesswork out of gadget position and size parameters
I would like one command to cover the common parameters in one sweep:

Global myWindow:=CreateWindow("blah,40,50) ' unspecified sizes mean the DEFAULT system size will be used

' any newly-created gadgets will be placed vertically into 'myWindow' parent
SetGadgetDefaults VERTICAL,myWindow

Global btnPlay:=CreateButton("Play",20) ' all gadgets below will use 20 as X position
Global btnStop:=CreateButton("Stop")
Global btnNext:=CreateButton("Next")
Global btnPrev:=CreateButton("Previous")



JoshK(Posted 2009) [#38]
SetGadgetDefaults() is unnecessary.

It could just automatically use the y position + height of the last gadget created, plus a constant spacer value of maybe 4:

CreateWindow("window",0,0,800,600)

CreateButton("Button 1",8,8,60,18)
CreateButton("Button 2")'Creates with size 8,8+60+4,60,18
CreateButton("Button 3")

Some real usage would be needed to determine the optimal way to guess these parameters.


I think the default gadget layout should be changed to 1,1,1,1.


degac(Posted 2009) [#39]
Well, my idea was to implement a 'flag' (a GLOBAL) in the Tmaxgui_Driver: if this flag is actived (1)(ie: ALIGNMENT=1) create the gadget AND put it into an internal list (see below), otherwise (2) act as normal (returns the gadget created).
When in mode (1) the x,y coordinates are ignored, w & h could be saved to 'fix' a default width or heigth for the 'group'.
At the end, when the user calls GroupClose() MaxGUI reads from the list and with a 'setgadgetshape' (& 'SetGadgetLayout' if necessary) command redraw the gadgets to fit the desidered layout, clear the list and ta-da!
So basically the standard MaxGUI's way to create a gadget is save (and fully compatible with the current user source) - and there are no many changes in the MaxGUI source (or in the specific platform drivers).

Another suggestion: 'redirect' Notify & Confirm (from BRL.System?!?!) to MaxGUI (as for FLTK and MacOS...)


degac(Posted 2009) [#40]
Other things I would like...

1 - Window style for adding 'minimize' button without the need to fix min/max size
Edit: I need to stop eating aspirin...just re-read my post and I dont' know what I was thinking while writing!


2 -
SetGadgetStyle(gadget,style)
style=GadgetStyle(gadget) 'not very important...


to change the alignment of LABEL gadget (I have not found other solution than destroy and re-create a Label to change its text-alignment).
Maybe - if image/text alignment on buttons is implemented, this function can be useful too.

I was thinking on some 'automatic' functions to 'fill' ListBoxGadget/ComboBox reading items from a list/array - but I haven't found a 'standard' way to do this (of course!).
Maybe with Reflections and some fantasy...
Type mytype
     field title$
end type
...
global my_list:tlist
...
PopulateGadgetItems(gadget,my_list,"title",ADD|REPLACE|CLEAR)

Where my_list is - of coure - a list, "title" the field name that should be 'readed' and displayed in the listbox/combobox and ADD|REPLACE is a flag to indicate the behaviour: append to the existing items of the gadget, replace (for object) or clear everything and add. Of course the EXTRA field of the gadgetitem is used to store the object from the list.
Dont' know how much useful this could be...

3 - 'drop' html from MaxGUI [extremist!]

Yes, as these commands are not 'fully complaint' on the three platforms (read: FLTK doens't support Javascript) - the best solution is to 'drop' from MaxGUI all the 'engines' and leave only the interface (CreateHTMLView & co).
The engines themself should be placed in a separate mod (usable for other purpose) and 'exapandable' with other engines (Chrome for example, Webkit or whatelse will be in the future).
Consider that under win32 we are still using the same engine of IE (I'm not fully sure on this...) - so for example, we have no possibility to run a HTML5 page with MaxGUI: the limitation of the OS becames the limitation of a program...


GaryV(Posted 2009) [#41]
Seb and I are having quite some discussion regarding where next for MaxGUI


Please do not let MaxGUI get into the shape it was before Seb took over. It took Seb a long time and a lot of hard work to fix everything and get MaxGUI stable and usable. We don't want to see MaxGUI go downhill. Let Seb continue to be the one who works on, guides and directs the future of MaxGUI. If it is a money issue, name a price and perhaps the community can band together to raise the money necessary and donate it to Seb so he can buy out your share/interest in MaxGUI.


skidracer(Posted 2009) [#42]
That's a pretty debilitating attack, do you really think it's appropriate? Kuron???


GaryV(Posted 2009) [#43]
Just because you may disagree with it, does not mean it is an attack. It is a sincere post.

I know I am not alone in not wanting to see MaxGUI go back to the mess it was before Seb took over. MaxGUI would not even work properly when I bought it. MaxGUI was stagnant and virtually unsupported.

Seb took over and went to work. Now it not only works, it is stable, features are regularly added and bugs, when found, are fixed in a timely manner. How is wanting MaxGUI to continue to succeed a bad thing?

*edit* Some of us use BM & MGUI daily for app development for our livelihood. We need MaxGUI to continue with the stability and standards that Seb has brought to the product.


Mr. Write Errors Man(Posted 2009) [#44]
Hello world. I know this isn't going to happen and that saying this may not be too productive, but in my dream world all hours put on MaxGUI would be used to help Brucey with his Qt module so that we could have the ultimate Max GUI.


Brucey(Posted 2009) [#45]
I know this isn't going to happen

Indeed... move along, nothing to see here... :-p


GaryV(Posted 2009) [#46]
Brucey is too busy working on the 64 bit compiler addon.


degac(Posted 2009) [#47]
Hi,

Please do not let MaxGUI get into the shape it was before Seb took over.



I doubt it will ever be. Skid asked to the community useful contributions-idea-critics about the current MaxGUI and the future release.
Skid has mentioned the fact that there are new drivers planned, and this is a very good news.

So just relax, dont' worry and try to think if you like to see something new feature in MaxGUI.


Ked(Posted 2009) [#48]
BTW, how are things coming along, decision-wise?

Also, where's Seb? He hasn't been on here for a while, I don't think.


skidracer(Posted 2009) [#49]
Seb was back at school this week. He said the internet was too fast to use or some such...

I'm having a look at helping with fix for Klepto's ScintillaGadget.

It is an excellent example of community contributed OS level proxygadget that should be simple to use and integrate into MaxGUI apps with no contamination of MaxGUI restricted functional API. We need to add a new proxy GUIDriver so modules such as Scintilla can be factory for CreateTextArea function and a simple Import is enough to get new controller by default.


What this implies is that those wishing to use non trivial gadgets, of which I would like to suggest includes any type of column controller should be looking at that controller's specific documentation and not expect the MaxGUI core function list to keep growing.


Ked(Posted 2009) [#50]
I'm having a look at helping with fix for Klepto's ScintillaGadget.

Ooo. Nice, so you guys are going to make it cross-platform?

What this implies is that those wishing to use non trivial gadgets, of which I would like to suggest includes any type of column controller should be looking at that controller's specific documentation and not expect the MaxGUI core function list to keep growing.

You lost me. :) How is that going to affect the API of the "non trivial gadgets"?


Brucey(Posted 2009) [#51]
How is that going to affect the API of the "non trivial gadgets"?

I think the issue is that as more things are added, everyone wants bits of functionality hacked into the core of MaxGUI, where some of those things don't really apply to anything other than the new gadgets.

maybe.


skidracer(Posted 2009) [#52]
Sorry, am simply using too many words to say "one module per controller is the way forward IMHO".


GaryV(Posted 2009) [#53]
"one module per controller is the way forward IMHO".


I agree


Ked(Posted 2009) [#54]
Any updates on this? Haven't heard anything for a while. :)


skidracer(Posted 2009) [#55]
I am between jobs and Seb is knee deep in academia so I wouldn't be expecting too much MaxGUI development from either of us this side of Christmas.

24/7 support for MaxGUI customers with critical issues continues as usual....


GaryV(Posted 2009) [#56]
I am between jobs


Are you willing to relocate?


skidracer(Posted 2009) [#57]
I'm actually trying to migrate from C++ embedded software engineer to the web.

I'm not lacking options/offers on the C++ front, just a certain amount of stamina when it comes to monolithic app development. I do have some interesting interviews coming up.


slenkar(Posted 2009) [#58]
another vote for GTK (after christmas:_)))


danielos(Posted 2009) [#59]
I'd love multicolumn-listboxes with editable cells !


Ked(Posted 2009) [#60]
One thing at a time...


degac(Posted 2010) [#61]
Ok, this thread should be re-vitalized I think!


ShadowTurtle(Posted 2010) [#62]
If you are a MaxGUI user, please feel free to post any real world requirements you may have.

Ok. Often i had need making Gadget moveable per drag&drop and so on.

The gadget should be editable into size & position. Sample:

editableGadget( myGadget, editableGadget_size | editableGadget_position | editableGadget_usePanelAnchorSettings )


There are realworld examples:

1. address software in wich the user can build his own forms. The software is limited on his features (only address form blocks etc.).
2. sprite positioning & size editor in wich sprites must be moveable. Sprite editing can be instanced as gadget and used via editableGadget. So you can make your specifig "Adventure"/"Game Background" editor.
3. etc. etc. etc.

At moment i do use jQuery and Javascript + some xhtml code to create this sort of editors. The output is always some json code..

I would prever BlitzMax + MaxGui code sort of this things. So do please implement a command like editableGadget ...


jsp(Posted 2010) [#63]
@ShadowTurtle
It probably depends what you are exactly looking for, but in general one could do most of the stuff.
You are already able to edit the size and position during runtime. The difficult point is how would you detect a change made by the user. You could use SetGadgetSensitivity to get Mouse events on a certain gadget and act accordingly or you could use a panel instead in a special edit mode…
You could also create a json to MaxGui loader to build directly a changeable GUI (a json module is in the archive iirc), I did the same with XML for such things. That’s may not directly interactive but works for forms which need adjustments without code change.