HUD Groups

by Forum_account
An easy way to manage screen objects.
ID:121452
 
I posted another update which made very few changes to the library, but added two demos. "chat-demo" is a simple example of an on-screen message log. "interface-demo" shows how to create and use basic interface controls (labels, buttons, radio buttons, and checkboxes) using screen objects.

Here is the complete list of changes:
  • Added the width and height named parameters to the HudGroup's add proc. These specify the width and height of the screen object just like you would by calling the HudObject's size() proc.
  • Added the "chat-demo", which shows how to create and use an on-screen chat log.
  • Added some procs to the Font object which are just aliases of other procs. The original procs had misleaning names because the name said "word" but you didn't have to pass just one word to the proc, you could pass a multi-word string. The aliases say "text" instead, but the original procs are kept anyway.
    • Added the text_width() proc to the Font object which is just an alias of the word_width proc.
    • Added the cut_text() proc to the Font object which is just an alias of the cut_word() proc.
  • Added the "interface-demo", which contains HUD-based implementations of some interface controls. Each control is implemented as its own type of HudGroup, which means you just have to instantiate the object type to create the control and can use its pos() proc to move it. The demo currently contains:
    • Labels: labels can display text and capture click events, so they can also be used as buttons. You can set the background color, size, text alignment, action (the proc that's called when clicked), and position.
    • Buttons: they're a child type of the label object that have some different default values (ex: size, background color, border, etc.)
    • Option Groups: you can define a set of options and the selection mode. The selection mode determines if the list uses radio buttons (you select a single value) or check boxes (you select any combination of values).
Perhaps changing the heights of certain letters would be a useful feature.
I'm not sure what you mean by "certain letters". If you want a different font you can modify the .dmi file or make your own. I've considered adding support for effects like bold or italic text but it's not a very high priority because you'd only need effects like this for a single HudGroup object to have text with different styles. Currently if you want a label to have bold text you just need a Font object that represents the bold version of a font.
What about a feature that shows how to combine a few of the already made features/ Such as creating a message box(Alike the one from the bumping into stuff demo) that has a persons avatar, text of said person talking, and such? Maybe, if possible, a way to easily create custom alert boxes without having to do anything in an interface/winset way? these might have already been done, but im not very active on BYOND anymore, so im just throwing in my two cents. if they have been done, just ignore this comment.
There's a demo that creates an alert-style message box but it doesn't have too many features, just a custom message (no custom buttons). There are definitely some features I could add to that.
I added my custom font and the "g" appears to be a bit higher than the other letters, is there any way I can change that?
You just have to position the letter within the icon states so they'd line up. You can't just place them in the bottom-left corner of the icon, you'd have to place them like this:

//    g:        o:
// +------+ +------+
// | ### #| | #### |
// |# ##| |# #|
// |# #| |# #|
// | #####| | #### |
// | #| | |
// |##### | | |
// +------+ +------+

That way the bottom of the "o" lines up with the bottom of the "g" when they're placed at the same vertical position.
Alright, I'll do that then. Thanks for your advice.
You can use the Font object's descent var to give a vertical offset to all letters. In the case of the letters in the previous example, the descent would be 2, since that's the furthest a letter can drop below their baseline.

It's mostly just for convenience. When you position text by specifying pixel coordinates, without specifying the decent, the letters might appear higher up on the screen than you'd expect them to be.