Vyzor, UI Manager for Mudlet

[Oneymus]

Small update to package. Fixed a text cutoff issue.

[Oneymus]

I have removed the SampleGui because it is outdated. Stay tuned for a whole new sample at some point.

[Caled]

How do I size an object such as a frame in such a way that it maintains a particular aspect ratio? For example, if I wish to make a clickable button that is always a square, but will still be resized larger/smaller as the mudlet window is changed? Is this possible?

[Oneymus]

It is not (currently) possible in Vyzor itself, but you can achieve that effect by manually resizing a Frame after every update; you can use VyzorResizedEvent and call <frame>:Resize( nil, <frame>.Size.AbsoluteWidth * <ratio> ). I would test, but I'm writing this on my phone at work.

[Caled]

Hrm. I'll play around with that, thanks.

There may actually be a better way to achieve what I want, let me know what you think?
I'm trying to build a framework for touch screen mudding on x86 tablets (notably, windows 8). The tablets in question don't exist yet, but the following is almost certain to be true:

16:9 screen aspect ratio
1920x1080 resolution or,
1366x768 resolution or,
2560x1440 resolution (eventually)
* A variety of different pixel densities for each depending on the screen size

It is that last which is the problem, because that is the most variable. Dealing with 3 possible resolutions that are all in the same ratio is simple, but dealing with different pixel sizes within each is, at least with my limited knowledge, a nightmare.

The buttons must be within a certain size. Too small and fat fingers will miss them in the heat of fast paces combat. Too large and they will look stupid. Yet they still need to scale, somewhat, with the rest of the GUI. (or do they?)

Ultimately I could just do it for myself and twiddle stuff until I'm happy, then never share it. But since I have months to do this, I may as well build it properly.

What may solve this, is an ability to specify physical size. If pixel density, screen area, resolution and window size is all known information, it is reasonably simple math to convert from millimeters to the number of pixels. Harder to convert to percentages when frames are nested inside frames, but probably still possible.

Do you think I am on the right track, reinventing the wheel, or just plain going off on a tangent when there is a far better way to do it?

[Caled]

One more, kind of small, thing.
The handle borders option - I dislike how changing the right border, brings the scroll bar in toward the center of the screen. How difficult do you think it would be to allow Vyzor to set left, top and bottom - but not the right - borders? Usually when making a gui with geyser, that is exactly what I do. Word wrap ensures that there is space on the right so it isn't actually necessary to set this border at all, and not setting it means I don't end up with an ugly grey column splitting my gui.

[Oneymus]

One more, kind of small, thing.
The handle borders option - I dislike how changing the right border, brings the scroll bar in toward the center of the screen. How difficult do you think it would be to allow Vyzor to set left, top and bottom - but not the right - borders? Usually when making a gui with geyser, that is exactly what I do. Word wrap ensures that there is space on the right so it isn't actually necessary to set this border at all, and not setting it means I don't end up with an ugly grey column splitting my gui.

Code: [show] | [select all] lua

-- This will turn off the right Border.
Vyzor.Options.Borders = { Right = 0 }

If you want something on the right side of your screen, inside the scroll bar, you can add Frames directly to Vyzor.HUD.

Now, for the rest: knowing exact resolution is unnecessary when everything is dynamically sized. If you want a square, it should be a square no matter the resolution (i.e., aspect ratio = 1.0). Where resolution tends to matter in distribution is asset sizes; a small image will stretch and look ugly and pixelated. Typically (my experience is with video games), they ship super-sized assets (as big as would ever be necessary) that are then scaled down by the program.

In short: you don't need to know resolutions, you just need to know how much screen real estate each widget gets.

[Caled]

Thanks!
That makes sense.

Incidentally, I tested that advice you gave earlier and it does work, though it does mean you can't declare your frames as local variables, unless there is another way to refer to them.

I have a question,more about GUI-ing in general than Vyzor (should I be making a new thread, it seems a lot of this isn't strictly Vyzor specific).

When using images for things like abilities, if you want an image to be greyed out, for example, is it usually done by covering it with another frame of equal size (for this example, grey with an alpha of ~50%), or do people generally create a new image entirely? Is there any drastic disadvantage to doing it either way?

[Oneymus]

Any further general GUI questions should be moved elsewhere, yes.

To answer your question, though, it's a matter of overhead, though it may be negligible. I suppose tests could be done to see whether the creation and maintenance (hiding/showing/moving) of another label is more computationally expensive than switching an image in a label. It is my belief that the difference would be unnoticeable except at ridiculous volume.

In a program like Photoshop, it is trivial to simply desaturate an image until it's black and white, but it may be more difficult if you don't have access to something like that (though there is GIMP).

I suppose the point of this story is: pending evidence otherwise, go with whatever's easier for you.

[Vadi]

I'd recommend to go with the label method - it'd be far less work (don't have to make duplicate images) and easier to work with in that regard.