I'm all for floats there. Why would they be counterintuitive?Formatting is only slightly more difficult (e.g.: Format("%d.%dem", foo/10, foo%10)). But even there I doubt fractional values occur very often. If you need dynamically sized menus, the size dynamics will probably be multiples of whole lines of text or icon sizes.
![[de]](/mwf/flags/de.png "Germany")
PS: the not-pixels-as-absolute-unit thing has another drawback: stuff won't interact as good with menu decoration as it does now, because the menu decoration will always use pixel-graphics.Suggestions?
Also, what should be the standard icon sizes we aim for? 4 * font size? In what size should be graphics be drawn? Just use 128x128?
![[th]](/mwf/flags/th.png "Thailand")
Like everything else, the menu decoration has to scale as well. We will have to make another menu decoration in higher resolution.
Menu decoration would be zoomed with the font just like anything else.In fact, I would implement this using the GUIZoom feature, which already exists for exactly this purpose. It zooms the coordinate system of GUI elements just like the game coordinate system is zoomed with the GameZoom setting.
> Margins
I understand it now. The implementation of the custom GUI currently has no notion of margins. Instead, margins are defined manually by
1. offsetting the Left+Top corner and
2. by subtracting double that offset from the width+height / by offsetting the Right+Bottom corner.
by the GUI designer.
I suspect that margins will be used almost in every menu, so it is something that might make sense to streamline. As I noted in the above post, it looks very unclean, unclear (especially if in this mixed relative+absolute syntax) and is thus quite error prone as one needs to repeat specifying the margin all the time (for each coordinate / size).
If such an implementation is left out however, I agree with you that using
Left, Right, Top, Bottom is the clearer option.I see the custom GUI implementation from the user's side (the GUI designer's side) and I would like to have it as easy to use as possible. Would you comment on the example syntax I gave here? In my eyes, it is easier to write/read while it does not take away flexibility.
>Would you comment on the example syntax I gave here?
I really have nothing against adding an exclusive notation for margins. But I think that the array notation for positions is only helpful in one case - when you have plain, relative coordinates like in your example.
- I don't feel that using nested arrays is the right thing to do when we want readability (Pos = [[500, -20], [23, -453]]). Especially if someone gets the idea to tag their positions.
- That way you would always have to give both coordinates. Currently, you can use the defaults (0, 0, 100%, 100%) a lot. I don't think I have many window definitions that define all four coordinates at the moment - especially if you ignore margins.
- You couldn't just do
foo.X = 123; later in script. You would have to do foo.Pos[0]. And for that you'd have to make sure, that Pos is set: if (!foo.Pos) foo.Pos = [123, 0]; else foo.Pos[0] = 213;The minimal gain we get in simple examples (
Pos = [50, 420] instead of X = 50, Y = 420) does imo not make up the downsides coming from that notation.Nevertheless, even with an extra margin-notation, I still favour the Left/Top/Right/Bottom notation. Not only because you have to do less manual math and at least I find it really comfortable to work with, but also because you can provide the scripter with sensible default values.
Okay, a write-up about some changes that I think are either necessary or at least pretty good ideas:X/Y/Wdt/Hgt = [<rel>, <abs>] to Left/Top/Right/Bottom = "<rel>%+<abs>em"[DONE]- this of course includes changing the absolute position from pixels to em (1em = font height)[DONE]
- also this would allow decimal values (f.e. Top = "1.5em")[DONE]
Player" property for visibility (currently solved via "Target" property + Visibility for target object) [DONE]- make the naming of the Gui functions consistent
"CreateCustomMenu"[DONE - use CreateObject now]Margin" property as described by Newton[DONE]
>- make the naming of the Gui functions consistent
Poll:
Gui_Update or GuiUpdate? (With or without underscore?)
What all functions are there? Are the Gui-function in any way special that warrants a pseudo-namespace?
engine functions:Gui_Open
Gui_Close
Gui_Update
Gui_SetTag
Helper functions (probably more to come):
Gui_AddSubwindow
Gui_AddMargin
Gui_AddCloseButton
Gui_UpdateText
"Actions":
GuiAction_Call
GuiAction_SetTag
There is probably nothing "special". Only that there are more functions than with comparable things (CreateParticle etc.)
I'd go with GuiXYZ, without the underscore as we don't have this style anywhere else.Where is the difference between GuiSetTag and GuiActionSetTag, GuiUpdate and GuiUpdateText?
>I'd go with GuiXYZ, without the underscore as we don't have this style anywhere else.
sounds sensible
GuiSetTag is a normal function that you call to update an UI. GuiAction_ are those things that you put into the menu definition:
OnMouseIn = GuiAction_SetTag("Hover")I guess I will rename all functions that do something with existin GUIs to start with GuiUpdate (f.e. GuiUpdateTag).
The text updating function is just a wrapper for the normal one, that updates the Text property (because that's a common task)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
