Messages

Labels + buttons ready

Windows platform executable
http://www.mediafire.com/file/6hr1gs6ecevpdv4/KitchenSink.rar/file

Yes exactly, a background texture instead of background color.


Labels tab finished

During adding "labels" in kitchen sink i was thinking how awesome would be if a "texture" feature exist! There isn't a "texture" for labels, correct?

Ok, i 've already started.

Would a kitchen sink example would be useful for future tgui users?

What exactly do you want to me to look at with that gui?

Nothing really. Just to take a look. I haven't used fairygui yet but i was looking for an alternative among other libraries if some project of mine wanted advance features for gui. In my programming years i have use wxWidgets, QT and dotnet. However the last years since i abandoned "MARMALADE" (in fact they abandoned us in first place) i am using sfml and tgui which tgui is great since i never had any problems.

Take a breath.
Batch rendering is great but after the performance boost in latest versions is not completely necessary.
Instead of rewriting the whole project why don't you add the missing widgets.
Yesterday is saw default argument in "ignoreMouseEvents" (picture). Ok, why setEnabled or setVisible on the other hand don't have.
There are a lot of tiny improvements that can be done. Like having all those "signalNames" for all widgets in one place!
I know the worm of perfection since i have one but life is also fun..

You are correct. Is working. Really sorry. Investigating...

Code Select Expand


picture = tgui::Picture::create(mFlagTextures[0]);
picture->setPosition(Settings::handler()->layoutWidth(flagXpos), Settings::handler()->layoutHeight(flagYpos));
picture->getRenderer()->setOpacityDisabled(0.3f);
picture->connect("MousePressed", [=]()
{
nextLang();
});


I ll try on a minimal code project...hold on.

Setting OpacityDisabled for picture seems not working.

Code Select Expand


Picture {
OpacityDisabled = 0.3
}


However

Code Select Expand

picture->getRenderer()->setOpacityDisabled(0.3f); this is working.

Thank you texus

During showing a button with "show with effect" and interrupting the procedure with the "hide with effect", next time applying during "show the effect" alpha value never reaches 255.

Am i seeing correct?

Take a look at http://en.fairygui.com/

http://en.fairygui.com/examples/ examples running on browser.

A. Now you center the text both vertical and horizontal in center of button, correct? So a "setMargin(value), getMargin()" make thing simpler.

B. Image show the proper use of setRelativePos, SetHorzontalAlign, SetVerticalAlign.

If you were to set setRelativeTextPosition(0,0) there would still be some space next to the text

I can't see why you bother about the space next to text or even in front of it or up or down if someone sets new relative position?

What should be optional exactly?

maybe i misunderstand something here. I thought that you using setKeyRepeatEnabled with true parameter inside TGUI but that's is not happening. Correct?

setPressRepeat(sf::Time duration)

that is how i imagined that. Great.

So I think it might be better to add a function that prevents the button from gaining focus, instead of adding a function that disables space and return.

I don't mind at all. Having a disableFocusEvent function is also good enough for me.

Every text can have its own vertical and horizontal alignment on a given position inside the button. YES to position inside and YES to both alignments.

First you can add alignment. Right now you have both center in button as default. You can add setHorizontalAlignment and setVerticalAlignment like label and half of the problem goes away. If additionally there is a fuction "setRelativeTextPosition(Layout x, Layout y)"  then you do not calculate the cente pos of button but you use this one obeying the alignements and letting this on user.

so it seems to work exactly like TGUI works now (with setKeyRepeatEnabled set to true)

Perhaps this must be optional.

As far as I can tell it is the most common way to fire on mouse up events, all buttons that I come in contact with seem to work that way.

U half correct. There are plenty workcases that things works differenet. Like slot games or DJ programs for example. These are working in different way. Events are on down.
Sometimes are totally configurable like effect buttons both on dj program and on the dj controller (mechanical like pioneer).
a. Effect starts on down and play once.
b. Effect starts on down and play until mouse or key up.
c. Effect starts on down and playing until it presses again.

but all those stuff has nothing to do with TGUI apart from that the event is triggering on down action and not on up.
In my opinion triggering stuff is more important than anything else.

If u thinking of letting this to the user then perhaps u can add some signals like pressdown, pressup.

[not]

What happening if u call "mWindow.setKeyRepeatEnabled(false)". Still buttons trigering all the time via key down event?
I have never use key signals with tgui. I use the sfml's pollEvent  to trigger buttons via key presses aka shortcuts.

To clarify something. Space and enter do not have the same behaviour on buttons? if Yes how is this possible?

In my codes over the years i never used mouse up or key up events to fire an action on buttons. Instead i am using timers. (Or frame counters).
With counters-times i never worry about a thing. I can manipulate how quickly can be trigger an event
or if i want to do it repeatedly or once or even on up events just like u have it now in tgui.

Maybe I should also add FocusedHover and FocusedDown states? Right now you can't tell that a button is focused when it is being hovered.

maybe my overreaction is contagious. lol. I think FocusedHover and FocusedDown states is too much. Hovering is just an effe. Correct? And is just for as long as mouse is on it.

i think priority order in rendering is: Disabled, Down, Hover, Focused, Normal.

Maybe i am over reacting here with buttons and at the time i would like the best look of buttons maybe i ll push you into an overwork and more complicated source code. Cheer up. I have a brand new discussion list.

    1. Buttons can blink. Forget it. NO
    2. Every state (Normal, hover, etc) can have its own text color. This would look very nice if u use different sprite background colors. YES
    3. Every text for every state can have its own outline border. Keep one outline color. So NO.
    4. Outline can have a thickness value. Add one thickness value. So YES.
    5. Every text can have its own style (regular, bold). YES if possible.
    6. Every text can have its own size. No.
    7. Every text can have its own vertical and horizontal alignment on a given position inside the button. YES to position inside and YES to both alignments. (Have image)
    8. A button can trigger (or not) from one or more keys. In my game i give the owner the ability to add any key he wants for every available button. NO.
    9. Having 8,there is no need of having "space" and "enter" as default keys out of the box. NO AND YES. Default keys should be able to be disabled or not from a function.
    10. Focusing in my opinion is over estimated but essential when you want to navigate with tab box. Bilinking over rules hovering and focusing. FORGET IT.
    13. A button can be tongle - switch button. YES but i would propose it for a different widget so u can skip complexity.
    14. Hovering can be disabled in touch screens because it is unnecessary (for all widgets). YES AND NO. If i use same sprite for hovering no one understands if it is hovering. But i would be cool if i could disabled.
    15.Batch for rendering. YES

   11. Pressed time for "m_spriteDown" must be configurable. Action of triggering must be on the last frame. Zero value triggers the button at once showing one down frame.
   12. Clicks or key presses can have "continuality" or not. Meaning that over pressing time, buttons can re-triggered as long as mouse or key is down.

    In your code u wait for mouse up or key up event, correct?
   

Code Select Expand


   button->connect("MousePressed", [=]()
{
//mouse pressed event is triggering when mouse is up (after was down ok) correct?
});
   
   I ll come back on 11 and 12 if u answer my question.

Let's disccus it one by one.

    Every text for every state can have its own outline border.

Do you mean outline color or also thickness? Colors I can agree with, but I feel like nobody would ever change the thickness per state even if I made it possible.

I mean both color and thickness.
Let's say we have a color text for every state. When you have white color for text and black color for outline color (normal state) is cool but when you use blue (pressed state) for text color and outline color is still black(1 outline color) is not so cool. We always look for a outline color that matches all text colors.

When you have a thickness value per state then you can easily make some cool effects without changing background color. (different text position inside button for every state also make things cool but this is next to our conversation)

When i say cool effects i mean pressing, hovering, disabling, focusing event can look awesome.

Some warnings appeared building (32bit) latest tgui source code (github) with visual studio 2015.

nanosvg.h(807): warning C4702: unreachable code
GuiBuilder.cpp(1480): warning C4800: 'unsigned int': forcing value to bool 'true' or 'false' (performance warning)
GuiBuilder.cpp(1481): warning C4800: 'unsigned int': forcing value to bool 'true' or 'false' (performance warning)
GuiBuilder.cpp(1482): warning C4800: 'unsigned int': forcing value to bool 'true' or 'false' (performance warning)

Do not worry. All those need time for a proper discussion.

Code Select Expand


enum button_States
{
Normal,
Hover,
Down,
Disabled,
Focused
};

Sprite m_sprite[5];
Color   m_borderColor[5];
Color   m_backgroundColor[5];
Color    m_TextColor[5];

void setBackgroundColor(button_States state, Color color);
void setTextColor(button_States state, Color color);


Having a simple enum for all button states, you can simplify the code so you can have one function for all states.

Having different text position or and text size you can have very pretty pressed states. The text can grow or can be positioned a little downwards during the pressed event.

• Buttons can blink, meaning that over a period of time can change background and text appearence. For instance can tongle between normal sprite and focused sprite. (global timer)
• Every state (Normal, hover, etc) can have its own text color.
• Every text for every state can have its own outline border.
• Outline can have a thickness value.
• Every text can have its own style (regular, bold).
• Every text can have its own size.
• Every text can have its own vertical and horizontal alignment on a given position inside the button (i can show you some button images if that is not clear).
• A button can trigger (or not) from one or more keys. In my game i give the owner the ability to add any key he wants for every available button.
• Having 9,there is no need of having "space" and "enter" as default keys out of the box.
• Focusing in my opinion is over estimated but essential when you want to navigate with tab box. Bilinking over rules hovering and focusing.
• Pressed time for "m_spriteDown" must be configurable. Action of triggering must be on the last frame. Zero value triggers the button at once showing one down frame.
• Clicks or key presses can have "continuality" or not. Meaning that over pressing time, buttons can re-triggered as long as mouse or key is down.
• A button can be tongle - switch button. (I saw you think for a different widget. It is not a bad idea having different widget. In my case is configurable (setTongle)).
• Hovering can be disabled in touch screens because it is unnecessary (for all widgets).
• Batch for rendering.

Those are some stuff that i have implemented in my codes over the years. Buttons and lists are the more demanding widgets in my opinion.

Perhaps i should used a better expression instead of absolute. I didn't have in my any vodka since i drink tequila. I meant more control in look and in functionality. I can't see how my prospective will affect them over the other widgets since all widgets have some default view. But let me open a new thread where i can explain in details.

If you really want the absolute buttons, do not hesitate to ask me.
I am creating game buttons (directX opengl) for more than 18 years,
having all kind of controls like keyboard, touch, mouse, external electronic devices (www.heber.co.uk)

But now i am going to play music as DJ in a Greek bar (Thessaloniki Greece). I know i am old (47) but what the fcuk, a hobby is a hobby.
I see you tomorrow.