More Updates

In an effort to clean up outstanding style issues, I’m redoing the default style for the library. It doesn’t look much different than the original, aside from being cleaner with more accurate placement.

So, just to be clear… this post is just a place for me to note the things that are changing with the up and coming update.

  • New style info/images for both atlas and regular default UI.
  • All single float values that were used for defining a Vector4f now have the option of defining them as a Vector4f in the style info.
  • Checkbox and Radio Button Labels are now clickable (finally)
  • Window titles are now centered vertically for the default style
  • Indicator overlay text is now accurately center vertically for the default style
  • Sliders now use their own style info for both track and thumb. +++
  • Spinners now use their own style info for both the text area and inc, dec buttons. +++
  • Menu padding and highlight clipping is now accurate
  • ScrollArea and ScrollPanel are now handling text placement/clipping and child element clipping more accurately.
  • I’m trying to ensure that all element images have the ability to define themselves as tiling images from within style info. This one will likely take others requesting areas that I miss. This is a default function of Element if set, however controls could potentially override this behavior.
  • Optional window dragbar buttons should now size properly… my bad :wink:
  • Atlas enabled UIs can now use individual textures in both style definitions and via code… this is slightly different than defining a different/new atlas image as it allows for image tiling.

+++ = Will require custom styles to be updated.

NOTE: If you have a specific question/request regarding style updates that I did not cover here, please let me know as I’d like to cover as much of the really needs to be changed or really should have been areas as possible now.

4 Likes

Eh… probably be nice if I posted a screen cap of the updated default style. Don’t get overly excited… as I said, it has changed very little aside from just looking cleaner and more accurate placement.

EDIT: Note that I haven’t updated how OSRViewPort’s clip padding is handled yet.

1 Like

Couple more updates:

  • ChatBox and ChatBoxExt now use ScrollPanel instead of ScrollArea.
  • ChatBoxExt now use FlowLayout for more accurate placement.
  • Fix for ScrollPanel when setting the text multiple times
  • ScrollPanel should now adjust it’s scrolling accounting for both text and child elements. (Text that is not an added label will wrap)

I guess it is also note worthy to mention that the standard non-atlas UI will now work on all Android devices… though, I still think it is a bad idea :wink:

Excellent. I look forward to all of this, especially some attention to the accuracy of some of the alignment and padding stuff. It’s amazing how noticeable even the slightest misalignments are.

A few style related issues that come to mind are …

  1. ScrollPanel
  • “gap” i would LOVE to see this come back :slight_smile:
  1. TabControl

How is the alignment looking on the SlideTray now? I posted a patch WAY back because I had some alignment problems with it along with some improvements to how the sliding actually worked.

I think this also needs separate styles for selected or deselected buttons (including the ability to use different fonts)

The ability to use icons in the tab buttons instead of/as well as text might be nice.

In short, tab buttons need some better styling options.

Oh, also not styling related, but TabControl has no way of getting/setting the selected tab, and it has no hooks for getting notified when tab selection changes. I’ve had to employ some horrible hacks to work around this.

  1. CheckBox and RadioButton

VAlign doesn’t seem to work properly, when you have say an icon that is twice as big as the text, I’ve found it impossible to get the text to align center.

Some more will probably come to me, but its late. So not till tomorrow at least :slight_smile:

RR

@rockfire said: 1) ScrollPanel
  • “gap” i would LOVE to see this come back :slight_smile:

I meant to talk with you about this… there is a problem with the current implementation. I forgot what it is right now (of course)… but as soon as I find it again, I’ll post about it to let you know what needed to change and why.

@rockfire said: 2) TabControl

How is the alignment looking on the SlideTray now? I posted a patch WAY back because I had some alignment problems with it along with some improvements to how the sliding actually worked.

I think this also needs separate styles for selected or deselected buttons (including the ability to use different fonts)

The ability to use icons in the tab buttons instead of/as well as text might be nice.

In short, tab buttons need some better styling options.

Oh, also not styling related, but TabControl has no way of getting/setting the selected tab, and it has no hooks for getting notified when tab selection changes. I’ve had to employ some horrible hacks to work around this.

This control is about to get a rewrite. It was thrown together as a placeholder more than anything… and a chance to try out the slide tray… which is about to get an update as well.

@rockfire said: 3) CheckBox and RadioButton

VAlign doesn’t seem to work properly, when you have say an icon that is twice as big as the text, I’ve found it impossible to get the text to align center.

I believe this was just fixed with the option of using Vector4f for all padding/margin type definitions. I’ll verify… but 99.9% sure this is no longer an issue.

And PLEASE!! Keep posting them as you think of them!

@rockfire
Here is a screen cap of the updated TabControl:

The SlideTray also got a few updates in the process… here be a list of all changes:

  • SlideTray allows for setting zOrder sorting from FIRST_TO_LAST or LAST_TO_FIRST since the padding between elements can be a negative number.
  • TabControl allows you to set the tab overhang (padding)
  • TabControl allows you to set the tab label padding
  • SlideTray now hides the next previous arrows if not needed or depending on what’s in view.
  • Slide tray only slides next until the last tray element is completely in view
  • Tab Panel’s default image can be set in Tab.gui.xml

Eh… guess that’s pretty much it. Aside from a few aesthetics & some limiting (or cleaning up) of functionality, the tab control seemed to work fine.

1 Like

Couple other additions that will likely be added before the update is pushed out:

  • When adding a tab, you’ll have the choice of adding a Panel or ScrollPanel
  • All of the additional settings will be added to the Tab.gui.xml files.

The tab control improvements look amazing. I especially love that it seems you can make the tab buttons seemingly join the tab panel. How is that done?

Oh … also, is this sort of layout possible :-

i.e. you turn off the slide tray, and have the tabs flow left to right and then wrap to the next line when there is not enough space? I guess this may have been hard or impossible to do before. But now you have layouts … :slight_smile:

Also vertical tabs is a valid configuration …

or …

EDIT: One last tab related thing. I just noticed my local copy of TabControl also has some hooks for right-clicking tab headers (this was impossible to do without changing the source). Would be nice if those were provided too.

EDIT2: Lol just ONE more! Removing tabs … this are the hoops you current have to jump through to get a tab removed …

[java]

public void removeTab(int index) {
    /* Ugh .... It seems when removing elements that they don't get fully removed
     * from Screen AND the parent "elements" list
     */
    final Button removeButton = tabs.remove(index);
    screen.removeElement(removeButton);
    final SlideTray slideTray = getSlideTray();
    Element elTray = getSlideTray().getChildElementById(slideTray.getUID() + ":elTray");
    elTray.getElementsAsMap().remove(removeButton.getUID());
    final TabPanel remove = tabPanels.remove(index);
    screen.removeElement(remove);
    getElementsAsMap().remove(remove.getUID());
    if (index > 0) {
        setSelectedTabIndex(index - 1);
    }

    // *Sigh* .. need to remove from button group too
    List<Button> radioButtons = LUtil.getInaccessibleField(List.class, "radioButtons", tabButtonGroup, RadioButtonGroup.class);
    radioButtons.remove(removeButton);

    // *sigh* and slider tray

    List<Element> trayEls = LUtil.getInaccessibleField(List.class, "trayElements", slideTray, SlideTray.class);
    trayEls.remove(removeButton);

    // Need to fix the panel, button UIDs and keys
    Map<Integer, TabPanel> m = new HashMap<Integer, TabPanel>();
    int idx = 0;
    for (Integer i : tabPanels.keySet()) {
        // Fix button
        Button b = tabs.get(idx);
        b.setUID(getUID() + ":Tab" + idx);

        // Fix panel
        TabPanel p = tabPanels.get(i);
        p.setUID(getUID() + ":TabPanel" + idx);

        // Fix key
        m.put(idx, p);
        idx++;
    }
    tabPanels.clear();
    tabPanels.putAll(m);
    tabButtonIndex = idx;

    getLayoutManager().layout(this);
}

[/java]

1 Like
@rockfire said:

This is doable, of course… but I’ll have to put it on the after everything else is fixed list.

@rockfire said:

I’m fairly sure I can get this one done now. SlideTray has a horizontal and Vertical config… so it shouldn’t be too difficult.

@rockfire said: EDIT: One last tab related thing. I just noticed my local copy of TabControl also has some hooks for right-clicking tab headers (this was impossible to do without changing the source). Would be nice if those were provided too.

Maybe a valid solution would be to let the user optionally pass in a Button/ButtonAdapter when adding a tab? This would solve this and about 100 other possible needs.

@rockfire said: EDIT2: Lol just ONE more! Removing tabs ... this are the hoops you current have to jump through to get a tab removed ..

Total oversight on my part. I’ll make sure this is there.

@rockfire said: The tab control improvements look amazing. I especially love that it seems you can make the tab buttons seemingly join the tab panel. How is that done?

Ooops… forgot to answer this!

The slide tray is above the panel container. You can now set a height diff between selected and unselected tabs which shrinks the unselected tabs just slightly to make them appear behind the current tab, while the selected slightly overlaps it. The height of the slide tray and overlap of the panel container is adjustable as well.

This is doable, of course… but I’ll have to put it on the after everything else is fixed list.

:wink: understood

I’m fairly sure I can get this one done now. SlideTray has a horizontal and Vertical config… so it shouldn’t be too difficult.

Cool. I already have a place I can use this

Maybe a valid solution would be to let the user optionally pass in a Button/ButtonAdapter when adding a tab? This would solve this and about 100 other possible needs.

It would indeed! I would be totally fine with that approach.

Total oversight on my part. I’ll make sure this is there.

Awesome

The slide tray is above the panel container. You can now set a height diff between selected and unselected tabs which shrinks the unselected tabs just slightly to make them appear behind the current tab, while the selected slightly overlaps it. The height of the slide tray and overlap of the panel container is adjustable as well.

Understood, I’ll try and apply this to my own theme.

RR

@rockfire

Here is the vertical layout. I’m having issues aligning BitmapText labels after rotating them, so I need to change these to LabelElement(s) and rotate them using an origin to keep the placement proper. But… either way, it is coming along nicely:

2 Likes

@rockfire
Should the tab labels be rotated clockwise or counter?

Oops… had the z order sorting backwards for this orientation:

1 Like

Wow that was fast, it certiainly is coming along nicely! Heh.

Uhmm… I would rotate them counter clockwise. The rationale being thats how they would be if you rotated the whole tab.

1 Like

Another Utility addition… One that was mentioned before.

ScaleUtil.java - This is a helper class for scaling based on screen resolution or DPI.

It is automatically initialized when screen is initialized with a base reference resolution of 720 x 480. You can change the default dev resolution like:

[java]
screen.getScaleManager().setReferenceScreenDimensions(float REF_WDITH, float REF_HEIGHT);
[/java]

This will reinitialize the scale utility and refactor both the game scale and font scale. I added a few methods to screen to simplify calling the scale manager, these are:

[java]
public float screen.scaleFloat(float in);
public Vector2f screen.scaleVector2f(Vector2f in);
public Vector3f screen.scaleVector3f(Vector3f in);
public Vector4f screen.scaleVector4f(Vector4f in);
public float screen.scaleFontSize(float in);
[/java]

Here is an example of usage:

[java]
ButtonAdapter ba = new ButtonAdapter(
screen,
screen.scaleVector2f(new Vector2f(100,100)),
screen.scaleVector2f(new Vector2f(200, 40))
);
ba.setText(“Testing”);
ba.setFontSize(screen.scaleFontSize(24));
[/java]

Now the button & it’s text will display proportionate to the screen resolution.

This addition is mostly for Android/iOS dev.

EDIT: This will be available in tonight’s update… along with some cleanup/fixes/updates for all of the recent changes.

EDIT 2: I also wanted to note, that this is NOT the same as just scaling your UI. This provides scaling with the same level of detail that all images/atlas regions were prior to scaling.

Hmm…i’m pretty free for the next week or so. No uni whooo!

I could help with some documentation, tutorials or code examples if you think that’d be useful?

3 Likes

Yes please documentation is always good!

@avpeacock
Any and all help there would be sooooo appreciated. What can I do to help with this?