This topic contains 5 replies, has 3 voices, and was last updated by 
AdamStrange
2 years, 7 months ago.
-
Posts
-
I’ve been working with mojox and making new controls. everything was going well until it came down to the layout systems.
My first gripe is Borders. It took me quite a while to work out that the border is added to the size of the control and not the other way round!
also minus numbers make no sense until you realise that a border is add/minus the outside of the size
E.G.
A holding panel of height 200. plus a control of height 200 and (supposed uniform) border of 10 border( -10, -10, 10, 10). gives a control of 220 height. which has broken the height and therefore needs to be resized and taken care of.
It makes much more sense for the border to be calculated within the control size and also all number being positive. So a border would then be Border(10,10,10,10) <- the control height would be 200 and with the border the internal size would be 180. positive numbers also make sense.
E,G,
Q “what is the left border?” A. 10 pixels. -10 pixels just feels wrong
OK further with borders is why not (basically) ignore the left/right/up/down and just apply a border that is uniformly applied?
E.G.
Border = 10
would make a control with a border of 10 pixels all around. Nice n simple and clear.
Ignoring the above gripe with borders. What I have found is that mojox does not handle layout at all well. It does the basics, but fails with any complex gui.
Example:
a left aligned panel with vertical buttons. then another left aligned panel with 1 control at the top and three controls underneath it. You really need to be able to directly access the width/height to control how they are all scaled and sized. This is virtually impossible to do with any control. and the resulting code quickly becomes messy with lots of workarounds.
Another Example:
How about two identical sized controls. One is hidden and one is shown. pressing a button will swap the show/hidden controls thus making a ui that shows two things. That is until you add mojox and it will crash with layout issues. Cause the layout engine doesn’t like initially hidden controls. and now you get a quick flash of multiple controls until it settles down.
Note the only way I could get this to work a it should was to track the controls themselves and manually hide/show in an appidle watcher, which is really not a good way
Now I’m not knocking mojox for the sake of it. But I feel it is not fit for anything other than simple ui’s and even then is not really simple to be usable.
OK. Here’s another (really good) example
Keyboard access, and control focus.
Lets assume you have two horizontal faders: Music and FX. How do you set both of these?
Basically you use a mouse. But what if you only have a keyboard?
left/right arrow would adjust the fader. but which one – you need a focus to show which is the fader that is accepting the keyboard?
further: up/down arrow should really move the focus from one fader to the next fader?
Taking this further still: Joysticks
Using the left/right joystick should alter the focussed fader and up/down joystick should move the focus
This is a very simple example and one that mojox just couldn’t do. In that regard I feels that mojox is great as the ui component for Ted but not really for anything game related.
I think my final gripe is the complexity of mojox. It is very difficult to look at the source and know what is going on and how it is working! It is extremely clever and has a code brilliance running through it. but nothing in it is obvious and Mark moving it into a module has now fixed it for anyone else to do anything about?
Lastly. because of all the problems I am looking at completely scrapping mojox for something else that answers the above issues.
First proposal would be a design view where in a single line you could show control positions
Next up would be base grid system. Where you give a ‘page’ a base grid (say 3×3) or 80×60 or whatever.
A control could be simply added to a ‘page’ by a grid x,y position and grid width/height
Or
A control could be simply added to a ‘page’ by a pixel x,y position and pixel width/height
the grid automatically resizes when the window sizes and the controls automatically resize – even hidden ones.
because you could ‘show’ the grid, you could easily work out where to put controls in the grid without %, etc
Have a much more intelligent layout engine.
Be able to show/hide controls with a simple command and have the UI automatically resize without any further control references
Here’s a photoshop concept is design view:
Where the purple is the page showing a base 3×3 grid
The red lines show the left/right/top/bottom alignment edges. These would intelligently move depending on how the controls are aligned – sort of similar to mojox but more comprehensive
the yellow rectanges are the controls showing their internal borders. There are 6 controls
The green rectangle is also a control, but is a spacer allowing you to have user controlled ‘whitespace’
Attachments:
Lastly. because of all the problems I am looking at completely scrapping mojox for something else that answers the above issues.
I think this is probably a good idea.
You’re obviously not getting into mojox and have plenty of your own ideas so go for it, it certainly wouldn’t hurt monkey2 to have several GUI systems.
it certainly wouldn’t hurt monkey2 to have several GUI systems.
I think so too and am working on one right now. Even with alternatives there are always going to be issues and users who do not agree with the code structure, implementation and so on. With my own GUI I use no OS native GUI resources which for some is great and for others not so great. In fact when I do release my GUI I would think game developers will like it but application developers will not be as impressed. This makes sense as my goal is developing a game friendly GUI which has different aspirations form a application centric GUI. So, I can see the need for several focused GUI’s and mojox is one of them.
Mojox is here now and just getting started. It’s a good first step solution given the scope of the development load Mark is under. Plus you cant beat the cost.
I think this is probably a good idea.
Mark – Thank You
This means I can take the current V1.02 and make modifications to the mojo app so I can use V1.03 fixed features for the base GUI.
That means I can move code from V1.02 slowly over to V1.03+ and keep compatibility with everything.
I’ll shut up now…
No problem – it’s open source, you can do whatever you want with any of it!
mojox will continue to evolve, but it’ll be a slow process as I have other 1001 things to do as well.
Things generally get added when I need them, eg: I’m working on ‘project settings’ right now which means I will be adding some sort of ‘combo box’ tomorrow – not really looking forward to it!
@Mark: Isn’t a combo box just a static dialog with a scroll list and a primary linked button?
@Richard: You gui definitely sounds a bit like mine. I’d certainly be up to share concepts and ideas.
My primary goal is to have a gui that will allow both games and app to use the same mechanism. It’s core is the ‘page’
E.G.
Menu page, option page, etc
Where a page then has ui controls.
I’m also working on a visual designer to make everything much simpler. but the current task is getting the layout engine correct.
You must be logged in to reply to this topic.