![[de]](/mwf/flags/de.png "Germany")
I wrote some sort of tutorial on the menu stuff, might turn out to be helpful if someone would want to do something there: http://wiki.openclonk.org/w/Script:_Menus(Note that the API itself is not in the docs, but it is really simple.)
![[th]](/mwf/flags/th.png "Thailand")
Nice writeup!Some comments about the documentation.
Regarding the documentation:
+ This should land in the docs latest when it is merged to master. For now its good that it is in the wiki for interface review.
+ The documentation should in its final version include some example pictures regarding the positioning of the windows.
+ The script functions revolving around the script gui should also be documented.
+ Perhaps rename the script menus either script GUI or script windows. I know that classically the GUI parts in the engine were called menus, but I understand that your window system is more powerful than that. So lets drop the misleading "menu" word.
Questions regarding the script interface
+ I don't understand the callbacks example:
1. Where do I set the size of the whole window, the window that contains the gold and the rock icon?
2. Where is the difference between an ID and a menu ID? How local or global is an ID? Why do I need an ID at all, couldn't it be possible to do it like this?: CustomGuiUpdate(update,my_menu_id,"description_box"); (use the key of the proplist)
3. Is a GuiAction_Call or CustomGuiUpdate synchronized over network? If not, what is?
+ Layouts and style: I guess those styles also define how many items are shown in one column etc. Can I change properties of these styles for my menu? How would a menu be defined that is basically a grid but has a description area at the bottom. Also, what are the other styles and its properties? This needs some documentation.
+ CreateCustomMenu: Why does CreateCustomMenu return an object (or proplist?) but CustomGuiOpen an integer? This seems inconsistent - as if we had 2 GUI apis, not one. I guess the new_child property of a menu definition is then the bridge between the two APIs or what?
Critique regarding the script interface
1. It is good that positions and size are given in ‰ relative to its parent window because this makes menus resolution-independent. So, the times of ever-shrinking menus, GUI-buttons, HP-bars are over. This is a great concept.
But: your interface still offers to optionally position the elements in absolute pixels which you already heavily use in the examples. There are even functions to add an absolute margin to windows (instead of a relative one). So you offer the scripter a way to break the resolution independence. But what is the use case for fixed-pixel-size windows?
The use case you offer in the example is that perhaps you only have a 64x64 title graphic and thus don't want to have it overscaled into a blurry mess. But well, it's no problem for us to create new, bigger sprites if we design GUI buttons that turn out too large on high resolutions for the few sprites we have. A feature like this would only lead to 64x64 (or any other arbitrarily set "OK size") being hardcoded everywhere as the symbol size. This will be a bloody mess, I mean you already started that in your examples everywhere!
2. Functions like GuiAction_SetTag look odd to me. We never had _ in function names. Also, the order of the parameters should be changed (for that function at least)
3. Drop the CustomGUI prefix, rather name it simply GUI, e.g. WindowOpen / GuiOpen as there will be no other GUI (accessible to the player). And I venture to say that the old menu gui will be thrown out in effect.
Good points!Some of the function names just grew to be like they are now. I'll rename them in a consistent manner. But I'd still prefer the prefix
"Gui_" for that, even if we have not used such prefixes before.>But what is the use case for fixed-pixel-size windows?
For some things like margins or even those fixed icon sizes(!!) an absolute size in a fixed unit is important. You would usually neither want the margins to scale with resolution (instead you want the real contents of the windows
bigger) nor would you want icons to scale, but instead display more icons.
I tried to change some pixel values to relative values (menu test scenario) to illustrate what I mean:
Normal:
Everything relative:
Also you can see how poorly it interacts with fixed-size menu decoration (which will always be drawn in a fixed pixel-size).
But I can see the point about hardcoded icon sizes. We could either introduce a constant for some icon sizes (small/medium/large) or I could add styles that automatically set the size to some pre-defined values (
Style = IconSmall).>+ CreateCustomMenu: Why does CreateCustomMenu return an object (or proplist?) but CustomGuiOpen an integer?
CreateCustomMenu is basically just a wrapper for CreateObject. I think I'll throw out the function so that the scripters know that they are actually just creating an object.
I'll clear up the documentation, maybe later today or tomorrow.
I hereby license the file ScreenShot013.jpg under the CC-BY license
I hereby license the file ScreenShot015.jpg under the CC-BY license
Attachment: ScreenShot013.jpg - absolute values (91k)
Attachment: ScreenShot015.jpg - all relative values (81k)
Yes, obviously, everything within the window needs to scale; including decoration and most of all, text. So that the menu looks exactly the same on all resolutions, only that it's resolution is higher.Both your examples show quite nicely that otherwise, the interface designer has to keep in mind that his GUI needs to be usable on very low resolutions but also on very high resolutions. E.g. your example menu on the upper left is already unusable with 64x64 icons. I predict that this will lead to, once again, tiny menus on big resolutions because they must be usable on small resolutions still. Much useful information cannot be displayed in the menus because on resolutions too small, it would obfuscate the display etc. etc.
In short, interface designer need to worry not only about the design of their window, but also worry about how it looks on 640x480, how on 1680x1200 etc. This is horrible because you might have added the absolute-in-pixels feature to give the designer more freedom but you achieve the opposite: It limits possible GUI designs much more.
With your redesign, we have the possibility to change that now. All we gotta do is to ensure that menus look the same on any resolution and there is no way for scripters to circumvent that.
IconSmall, no problem, but as said, that should be a value in percentage. Or better yet, a property of the grid style.
> In short, interface designer need to worry not only about the design of their window, but also worry about how it looks on 640x480, how on 1680x1200 etc.
Isn't that something that's very common in interface design (as it is with web design)? Also, with scaling designs the designer still has to check whether the window works on small resolutions (i.e. are the buttons to tiny to click on, is the font readable etc.; while on high resolutions you'd get ridiculously big buttons / fonts). What your approach does it to limit the designer to the smallest possible resolution and work from there. And all other players with nice resolutions are limited as well. From a player's perspective, you'd want the GUI to be more accessible on higher resolutions i.e. more stuff visible in your menu. What you don't want is extremely upscaled elements that look like you're working on a elderly's PC.
I really don't see the advantage in your approach.
> Isn't that something that's very common in interface design (as it is with web design)?
Yes, and that is a major design issue of HTML in my opinion.
>What your approach does it to limit the designer to the smallest possible resolution and work from there. And all other players with nice resolutions are limited as well.
Yes. But the limit of what you can stuff in a menu is put much lower here as everything scales with the viewport size. Imagine the same thing defined with fixed-size icons: You'd have to decide whether to use 32x32, 16x16, 64x64. If you'd have a more complex window with many submenus, you MUST use a very small icon size, e.g. 16x16 to make it usable at all on small resolution. But then again, you have still 16x16 on your big widescreen. You don't have this problem if you work with icons that scale with the viewport size.
> From a player's perspective, you'd want the GUI to be more accessible on higher resolutions i.e. more stuff visible in your menu. What you don't want is extremely upscaled elements that look like you're working on a elderly's PC.
Yes? Why? Why should a GUI be more accessible on higher resolutions? That implies that it is less accessible on lower resolutions. Why not have it accessible for any (reasonable) resolution? (I will just call anything above and including 640x480 a reasonable resolution) If it scales with the resolution, the GUI windows will always stay the same relative to the screen! So, no, I want "extremely upscaled elements" for high resolutions, but only so that they will be the same size on screen as on lower resolutions.
That was the whole point of the "Clonk Zoom" project: That a clonk on a 640x480 display and on a 1280x1024 display are the same size on the display and that is exactly how it works now with
SetPlayerZoomByViewRangeBut I get your point: You claim that windows that are designed to work even if downscaled to 640x480 can't be complex enough to display what needs to be displayed (in the sense of displaying sufficient information), would look squished. And because of that, one needs fixed-size icons etc. so that on higher resolutions, the extendable part of the menu becomes more clear.
Well, I think that is wrong. As simple as Clonk is, I claim that if a GUI window does not fit a 640x480 screen, it is too complex. The screenshots above are a bad example because they only show what effect a margin had that scaled with the resolution while keeping everything else fixed size.
> That implies that it is less accessible on lower resolutions.
Well, that is a common tradeoff when lowering the resolution: Less stuff fits onto your screen. But I'm not talking about poorly designed GUIs (i.e. too complex windows that won't fit on small resolutions) but those were you can't know beforehand how big it will grow. Like the buy menu. Say someone creates a scenario with hundreds of buyable objects. On a big resolution, you'd expect it to show more item entries than on a lower one, while it's not unusable at 640x480 but just shows less entries and will need more scrolling. So, it's not about complexity but comfort. More items, less scrolling, that's the comfort you'll always get when using a higher resolution.
It is true that the icon will effectivly shrink. Personally though, I'd like to have more items than just how many the designer seemed fit at 640x480 instead of a 4x3 grid with extremely detailed pictures.
What kind of screen has a 640x480 resolution anyways? The lowest case I can imagine is playing OC on a beamer with 800 x 600, but who does that? For normal screens 1280 x 720 is the lowest I can think of.And multiplayer support on one pc has been dropped?
Well, I'm not sure about optimisation for that resolution, too. But to be fair, there might be slow / old PCs out there which might not run OC fluidly on a higher resolution.
But I wouldn't design a gui that looks good on those 5 PCs out there that rely on that low resolution, but instead make one that looks good for 99% of the players.
![[eu]](/mwf/flags/eu.png "Europe")
Two cases:If you play in windowed mode or if you play in splitscreen.
Multiplayer support on one PC has not been dropped, it is currently just broken because the last controls rework effectively broke gamepad support (can't use gamepads to navigate through menus) and as it was clear that async engine supported menus will come soon, there were other more important things to do than to design and implement a usable gamepad interaction with menus that were seen as an intermediate solution anyway.
So, the GUI developed in the controls branch is actually the time and place to think about a GUI that works with gamepad and with lower viewport size.
Split a big screen or beamer resolution by 4 players max and you get something along the lines of 500 to 800 px width.
> As simple as Clonk is
What? Either you are joking or I'll have to be heavly confused. I'm dead serious here: Clonk is easily the most complex game I know in terms of context dependent UI. We have containers, construction sites, production queues, build menus, production menues, material cost displays, inventories, the quickbar, a list of every possible action as a function of the currents clonk position, a List of all my Clonks, floating lightbulbs, more often than not some scoreboard, dialogs, scenario goal display, money display, an independent player menu, a title bar with clock and god knows what I might have forgotten. Do the cross product of this with the concepts of drag'n'drop or even controller support, and I really have to wonder about what might give the impression that designing a smooth, self-describing, effective and efficient UI is a trivial task on a resolution of 640x480.
Why would we even want to design our game for resolutions below 1280 x 720 (which was already a low resolution 5 years ago)?
This value is completely unrealistic nowadays, and we should rather aim/optimize for 1920 x 1080 which is the standard for any computer screen you would buy nowadays.
This value is completely unrealistic nowadays, and we should rather aim/optimize for 1920 x 1080 which is the standard for any computer screen you would buy nowadays.
Well, what would be your suggestion for, for example, the font size?
Attachment: FontSizes.jpg - Monitor and font sizes, why would we use percentage based sizes.. (46k)
Get the DPI information from the OS and make a decision based upon that.
I am trying to follow/understand Newton's suggestion, that every GUI should look exactly the same on every resolution. That specifically does not aim for a good readability - so as I understand it, DPI information would be pretty useless there?
> That specifically does not aim for a good readability
I don't think that the point Newton was trying to make was that readability should take a back seat behind making everything look the same both on a 14" monitor and a 60" TV.
If you're doing a text-heavy UI, then you need to make sure it's perfectly readable - otherwise, your UI will fail at its most basic task, which is to convey information.
>only that it's resolution is higher.
Well there's that approach, and there is that other approach. Current design trends include so called "responsiveness", which means that the layout and all sizes adapt to the screen real estate they have.
IF you decide to go with "everything scales", please also specify what resolution is the "default" which should look good - because it's not only "higher resolutions" (also: scaling up looks shitty as well), but much more "lower resolutions" that need to be taken into account.
Be aware of the fact that while screen resolutions differ greatly, pixel sizes most often do not. So between a 1024x768 and a 2k monitor, the menu will in both cases take up the whole screen, with everything in it - including buttons, text and the like - taking up double(!) the screen real estate with double the real world size. I'm not sure this is desirable, because every resolution that is higher than whatever we specify now as "standard" will have scaling artifacts in it.
> Be aware of the fact that while screen resolutions differ greatly, pixel sizes most often do not.
True, this is a point. But as I said to Clonkonaut, that is how the world zoom (SetPlayerZoomByViewRange) works like. On big screens, the clonk will take the same space relative to the screen size, but will take up - as you say - more screen real estate on bigger screens.
> I'm not sure this is desirable, because every resolution that is higher than whatever we specify now as "standard" will have scaling artifacts in it.
Text is vector-based, title graphics are for the most part rendered models.
>I'm not sure this is desirable, because every resolution that is higher than whatever we specify now as "standard" will have scaling artifacts in it.
Couldn't it scale up until the point with the highest resolution is reached and then stop scaling up?
PS: One more naming thing I am unhappy with:Currently the coordinates of a windows are X, Y, Wdt, Hgt. But Wdt and Hgt are not the "width" and "height", but the right and bottom border of a window.
The "best" naming (like it is done internally, too) would probably be Left, Top, Right, Bottom. I only chose X, Y, Wdt, Hgt because it's something people are familiar with and will probably have to look up less often in the documentation.
Comments?
Well why not make Wdt and Hgt the width and height?How is it more convenient/simple to write
Left=250, Top=500, Right=500, Bottom=750than
X=250, Y=500, Wdt=250, Hgt=250If you want some icon to take the space
+----+
| |
| |
| @ |
| |
+----+in a 4x4 raster?
When you want to place an icon on a random position, it really does not matter.I think that the common case is something different, though: subdividing a window into smaller subwindows (which depend on each other positionally).
Imagine the simple example of having two windows next to each other with a small margin around them.
var menu = {
first = {
X = [0, 64], Y = [0, 64],
Wdt = [500, -32], Hgt = [1000, -64]
},
second = {
X = [500, +32], Y = [0, 64],
Wdt = [1000, -64], Hgt = [1000, -64]
}
}
compared to
var menu = {
first = {
X = [0, 64], Y = [0, 64],
Wdt = [500, -2 * 32], Hgt = [1000, -2 * 64]
},
second = {
X = [500, +32], Y = [0, 64],
Wdt = [500, -64 - 3 * 32], Hgt = [1000, -2 * 64]
}
}
.. and I am not even sure whether I translated everything correctly. The examples obviously become more confusing as complexion grows.
(And the example would of course look similar if only relative and not absolute margins were used..)
The idea for such a coordinate setup actually came from CE GUI (for Ogre3D). Their wiki entry about the coordinate system is here.
After working with that for some time, I actually found it pretty good. You had to do way less math than with other, traditional approaches I know.
Err, could you use Left,Right,Top,Bottom for your example? I don't know which is which and both look quite complicated.Also, the thing with the margins... if this is not an important part of your argument, could you leave it away? I don't quite understand that margin syntax. And in case it is: Why not introduce a
Margin=[marginWdt, marginHgt] field? What do you think about this syntax?:var menu = {
first = {
Position = [0,0],
Margin = 64 // can be a [marginWdt,marginHgt] and even a [marginLeft, marginTop, marginRight, marginBottom]
Size = [500, 1000]
},
second = {
Position = [500, 0],
Margin = 64,
Size = [500, 1000]
}
}
By the way: Currently, margins are always absolute? There is no way to define relative margins?
Okay, here is the same example with only relative margins and with Left/Rigth/TopBottom:var menu = {
first = {
Left = 64, Top = 64,
Right = 500 - 32, Bottom = 1000 - 64
},
second = {
Left = 500 + 32, Top = 64,
Right = 1000 - 64, Bottom = 1000 - 64
}
}compared to
var menu = {
first = {
X = 64, Y = 64,
Wdt = 500 - 2 * 32, Hgt = 1000 - 2 * 64
},
second = {
X = 500 + 32, Y = 64,
Wdt = 500 - 64 - 3 * 32, Hgt = 1000 - 2 * 64
}
}The essence of that example is not how you define margins or anything else, but that you imo usually have to do more manual math when you define width and height instead of relative position of the corners.
> I don't quite understand that margin syntax
Well, to get a margin, you add numbers to your actual coordinates. You move the left side a bit to the right and the right side a bit to the left -> margin.
>By the way: Currently, margins are always absolute? There is no way to define relative margins?
Currently, you can do whatever you want. I don't see why anyone would every want to define relative margins, though: it would mean that your vertical margins might be a different width than your horizontal margins if the resolution (/or parent) is not a perfect square.
> I don't see why anyone would every want to define relative margins, though: it would mean that your vertical margins might be a different width than your horizontal margins if the resolution (/or parent) is not a perfect square.
To have the GUI scale with the resolution of course. But yes, you mention an important point. We would have the same problem if we defined icons in a raster menu that is not a perfect square to be relative in size - suddenly they would be in the same way not be square.
So actually, there are two different units:
1. Size relative to the parent window's width and height (separately)
2. and size relative to the overall size of the parent window (the root parent window would be the whole viewport): Probably Min(width, height)
The second is the kind of relative size that is needed for scaling the GUI with the resolution.
Do you have any ideas how to solve this?
Or another example for that problem, we have a grid with icons in a window and below the grid is a description field which reserves 1/3 vertical space because on normal 4:3 resolutions, we need for some reason this much space for the text. But then, we play splitscreen 2 players and suddenly we have a 2:3 resolution.Now, how I imagine it, the whole window should be only half the size (e.g. text should be half the size, icons in the raster half the size, border and margins half the size) but is stretched vertically. The description window however should keep its aspect ratio (because as the whole window is now half the size, including the text within, the description window does need exactly the same space as before) while the raster should take up the extra vertical space.
Here's an idea how to completely avoid absolute values. Any comments?
var menu = {
Width = 900,
Height = 900,
icons = {
Width = 100,
Height = 750,
Margin = 5,
Overflow = MENU_Scroll
},
description = {
Y = 750,
Width = 100,
AspectRatio = [4,1], // Height not specified, absolute height will be calculated after the width has been calculated into px width
Text = "Einen Kopf ueber dem Dach hat man gerne. Aber..."
}
};
var icons = [Rock, Firestone, Gold, Loam, Musket, Bow, Mushroom, Dynamite, Shovel, Axe, Sword, Hammer, Pickaxe, IronBomb, TeleGlove, Metal];
var items_in_row = 4;
var columns_used = floor(icons / 4);
var column, row;
for(var iconID in icons) {
var icon = {
X = 1000 * column / items_in_row,
Y = 1000 * row / columns_used,
Width = 1000/items_in_row,
AspectRatio = [1,1],
Symbol = iconID
};
SetProperty(Format("icon%d",i), icon, menu.icons);
column++;
if(column >= items_in_row) { column = 0; row++; }
}
So, I really don't see the gain.
Hmm? The point of this example was to show a way to have icon sizes defined relatively by defining on creation of the grid how many icons should be shown in one row. So, the icons wouldn't have a fixed size of AxA pixels but instead the size is dynamically determined by the designer who decides how many of the icons he wants to stuff in the grid.Edit:
What is the gain? This:
Imagine you set a fixed icon size of 64x64em in a grid that has a relative width of 80% of the screen size. Here, you will always have a blank border of up to 63em on the right hand side because the grid width will seldomly be a multiple of 64em. To solve this, you would need to define the width of the grid in absolute size as well. That is what Sven suggests: Use absolute sizes for most windows but make the whole GUI scale with viewport size. And the other solution is to define both the grid and the icons width relatively like I showed in the example above.
>So, the icons wouldn't have a fixed size of AxA pixels but instead the size is dynamically determined by the designer who decides how many of the icons he wants to stuff in the grid.
I still think the most common case would that the designer wants "as much icons as possible, as long as they can still be easily made out". For example in the buying menu, production menu, research menu, inventory menu, etc...
>Here, you will always have a blank border of up to 63em on the right hand side because the grid width will seldomly be a multiple of 64em.
That is one of the real issues with that, true. Imo that is still the minor issue compared to having differently-sized grids on one screen with their respective icons in different sizes..
One of the motivations behind the gui system was that we could implement consistent-looking UIs. For example, it should be desirable that the icons in the inventory menu are the same size as the icons in the production menu - even if the production menu is a bit shorter, because it needs to display the required materials somewhere.
I am really not convinced of relative-sized icons at all.
> I still think the most common case would that the designer wants "as much icons as possible, as long as they can still be easily made out". For example in the buying menu, production menu, research menu, inventory menu, etc...
But you realize that with what Sven2 suggested, the icons would be also relative to the viewport size?
>Do you have any ideas how to solve this?
Yeah. By just changing the unit of the absolute value from "pixels" to "millimeter" or something else that can be calculated from the DPI info.
..or something like tenth-em. So a margin of
10 would be exactly as high as one letter. The font size could then be set in the normal options.(The value would still be absolute and therefore not suffer from aspect-ratio weirdness or other stuff that is impossible to control.)
This does not really solve your second issue (with the two nice images!). You could tell the text to be always X lines/cm high, but you could not fix its aspect ratio. Is that really something that is needed?
Yeah, I think it makes sense to have a different unit than pixels for UI elements and it would be good to couple it to font size.The unit should be something related to the default text line height so that it's relatively easy to do those calculations. The engine should also make sure that there the coordinate space provides a predictable area so you don't have to define "large" and "small" versions of every dialog.
My suggestion would be this:
* Standard font height is 20 UI units
* The engine ensures that there is always a range of e.g. 600x300 of screen estate available. Low resolutions scale units down, high resolutions scale them up
* For non-matching aspect ratios, the engine still ensures that the smaller dimension matches. E.g. the UI resolution could become 800x300 on a wide screen display. Dialogs that are unaware of this will just not use the letterbox space.
* For high resolutions and low DPI values, the available screen range may be larger than 600x300. Again dialogs that are unaware of this will just not use the extra space.
* By default, all positions/sizes are given in these (absolute) UI units
* Elements that want to use exactly the space available (e.g. menus that want to use all available vertical space or subelements that want to divide the contained in half) can use another notation where coordinates are given as strings. E.g.
Wdt="80%".
If the engine wants to be really advanced, it could even replace all "%" by "*(containerwidth)" and run the value through eval() to allow stuff like Wdt="50%-10".
> couple it to font size
Font size as defined in the options? I remember an argument that the option should be removed and instead the font-size will be automatically defined according to resolution.
>* By default, all positions/sizes are given in these (absolute) UI units
Why would we suddenly use absolute positioning as the default D':
>If the engine wants to be really advanced, it could even replace all "%" by "*(containerwidth)" and run the value through eval() to allow stuff like Wdt="50%-10".
Wdt=";GameOver();"
> Why would we suddenly use absolute positioning as the default D':
Ah, sorry. I meant only absolute *scales*, because you don't want to do math based on the parent container every time you place e.g. a label that should have the height of one text line.
Positions can be relative to the top left of the parent container.
Well, yeah. That's the reason why we can't do without absolute values.But I still think that the most common operation is subdividing a window into new windows based on some relative layout ("half of the window" i.e.).
Also I think mixing up the defaults between position and size (one relative and one absolute) would be a bad, bad, bad idea.
For your example that you have one label (here the menu title with the absolute height of exactly
2 * fontSize) and some other stuff below it, I propose the following:
var menu = {
title = {
Bottom = [0, 20],
Style = GUI_TextHCenter,
Text = "THIS IS A COOL MENU, PLEASE DO STUFF IN IT"
},
menu_contents = {
Top = [0, 20],
Style = GUI_VerticalLayout,
...
}
};
.. making good use of the default values (0%, 0%, 100%, 100%).
Which juuust happens to be the current implementation. Minus "Y"/"Hgt" instead of "Top"/"Bottom" and minus having the absolute unit in pixels instead of in tenth-em.
The cool thing is: you could put the above definition everywhere without changing anything, because you don't have to take the parents' sizes into account and you don't have to calculate weird stuff manually.
All the rest like possibly forcing the menu in a decent aspect ratio on all screen layouts should be completely transparent to the scripter. It could even be made an option or something like that, just because everything is so flexible..
> Which juuust happens to be the current implementation. Minus "Y"/"Hgt" instead of "Top"/"Bottom" and minus having the absolute unit in pixels instead of in tenth-em.
Ah, right. I missed the part where you can mix relative positions.
Well, the syntax is a bit awkward; I'd prefer doing Bottom="20px" or Bottom="50%" instead of Bottom=[0,20] or Bottom=[500,0] because it is more readable. But maybe that's better left as some feature request for the future.
Using pixels instead of font height is probably also fine for now as long as we agree on a line height to be used consistently. The GUI code could later be adjusted to interpret these coordinates as UI units that are zoomed for large resolutions without any changes to existing scripts.
>Well, the syntax is a bit awkward; I'd prefer doing Bottom="20px" or Bottom="50%" instead of Bottom=[0,20] or Bottom=[500,0] because it is more readable.
True. I am only scared that if that were the only way to define those coordinates, people would end up getting confused over
Formating their %-signs away or awkward Format calls in general.But I guess it would be both a sensible and easy-to-implement alternative to the current syntax.
And if we decide to use em instead of pixels, I'd rather do that early ("now"), too, than fixing up stuff later.
>alternative to the current syntax.
Now, that wouldn't make sense. Edit: Or you mean that e.g. if you leave out the unit, it automatically assumes something, like, say, % coordinates?
> And if we decide to use em instead of pixels, I'd rather do that early ("now"), too, than fixing up stuff later.
Same opinion here.
>Now, that wouldn't make sense. Edit: Or you mean that e.g. if you leave out the unit, it automatically assumes something, like, say, % coordinates?
I mean that you can do either X = [<rel>, <abs>] or X = "<abs>em" or X = "<rel>%" or X = <rel> - note that some are strings and some aren't
Yes, I don't see the sense in that. It is not as if one method offers more flexibility than the other. It is like having two functions for the same thing, SetPlrVwPrtARt and SetPlayerViewportAspectRatio because "some people might like the shortness of the one more and some other people want to rather write it out for readability".
The idea behind that is that the most common case would be using either the relative or the absolute values. Mixing them would be very uncommon.So the result would be that 90% of the coordinate definitions would be in the more readable form of "90%" or "10em" - but it would still allow the combined variant (or something that relies on in-line math) to be used if necessary.
> SetPlrVwPrtARt and SetPlayerViewportAspectRatio
Because not the declaration name changes but the way you present your data, I'd rather compare it to something like
RGB vs RGBa or CreateParticle vs CreateParticleAtBone or [] vs CreateArray
Parsing stuff like "50%+10em" wouldn't be infinitely difficult though. It doesn't have to be eval; just split the string at the +/-, parse the preceding number of each individual part and use the remaining part to look up the unit.If you include the + and - in the splits, you don't even need special cases for the different signs, but will just parse the sign as part of the following number.
It wouldn't allow brackets or arithmetic, but I don't see a case where this would be required.
> or something that relies on in-line math
You can always do X=Format("%dem", SomeMath()). Besides, I still think there should be a default case where you can pass integers and they would be treated as px or em.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
