Recent Posts

Pages: 1 ... 6 7 [8] 9 10
71
General Discussion / Re: Buttons 0.9
« Last post by texus on 30 May 2019, 09:41:01 »
So the following will definately be in 0.9-dev when it gets released:
- Every state can have a text color and text style (already in 0.8)
- Button can have an outline thickness and outline color (same for all states)
- Batch for rendering

Things to look into for 0.9-dev:
- Toggle and switch buttons
- Way to disabling hover state
- "Continuality" option
- Way to handling space and return


For the "continuality", how about a "setPressRepeat(sf::Time duration)" function? If set to 0 (default) then the button triggers on mouse up, but when a duration is set it would trigger the pressed signal on mouse down and again after every "duration".


While I was thinking about adding an enablePressBySpaceOrReturn function to disable space and return keys, I'm not sure if that would be the best way. I've looked online for questions where people ask to disable the space key and found the following behaviors:
- For javascript, the solution would be to either intercept the key event or to unfocus the button when you receive the focus event.
- For windows apps / .Net, the solution was to either intercept the key event or set IsTabStop to false to prevent the button from gaining focus.
- For unity, "Navigation" has to be set to "None", which as far as I can tell on first sight means not allowing it to be focused.
- Other random results came up where it was impossible to change the behavior or where it was suggested to unfocus the button after it gains focus.

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.


Quote
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.
This is still the part that I find the most difficult to provide a generic solution for. I agree that the buttons you showed look great, but I'm not sure how to best give enough control to set the text position for buttons like that.

Maybe I shouldn't try to get the functionality in TGUI but to just make it easy enough to add it yourself? Imagine if you would be able to inherit from renderer classes and the ButtonRenderer would have a virtual function like this:
void ButtonRenderer::drawText(RenderTarget& target, const Button* button, const FloatRect& rect, const String& text) const
{
    const TextProperties& textProperties{getCurrentTextColor(button), getCurrentTextStyle(button), m_textOutlineThickness, m_textOutlineColor};
    const FloatRect& bounds = target.calcTextBounds(text, textProperties);
    target.drawText(text, textProperties, {rect.left + (rect.width - bounds.width) / 2.f, rect.top + (rect.height - bounds.height) / 2.f});
}

All you would have to do is inherit from ButtonRenderer, override just the drawText function with your own implementation and call button->setRenderer(...) with an instance of your custom renderer.
72
General Discussion / Re: Buttons 0.9
« Last post by texus on 30 May 2019, 08:42:26 »
Quote
Perhaps this must be optional.
What should be optional exactly?

Quote
Like slot games or DJ programs for example.
Slot games and dj programs aren't the ones where I imagine people tabbing between buttons and using space to activate them, so you would only need mouse events. If you only need the mouse events (or touch events) then you can use the MousePressed signal to get a callback when the button is pressed down.
73
General Discussion / Re: Buttons 0.9
« Last post by billarhos on 29 May 2019, 23:52:37 »
Quote
so it seems to work exactly like TGUI works now (with setKeyRepeatEnabled set to true)

Perhaps this must be optional.

Quote
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.

74
General Discussion / Re: Buttons 0.9
« Last post by texus on 29 May 2019, 22:44:26 »
Quote
What happening if u call "mWindow.setKeyRepeatEnabled(false)". Still buttons trigering all the time via key down event?
Then it would only trigger once because the key press event would only be send once. It simply responds to the sf::Event::KeyPressed event that you get from SFML's pollEvent.

Quote
To clarify something. Space and enter do not have the same behaviour on buttons? if Yes how is this possible?
In TGUI they do have the same behavior, but I tested it on a simple HTML button with both firefox and chrome and it looks like they really do have different behavior for space and return. (I tested it via https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_button_test where I replaced the onclick event with "console.log('test')"). While looking into the onSelect event for edit box recently I saw really weird behavior with HTML as well so I wouldn't want to blindly copy their behavior, but it does raise questions about what the most common behavior is.

My linux system seems to repeat for both space and return key, so it seems to work exactly like TGUI works now (with setKeyRepeatEnabled set to true).

Quote
In my codes over the years i never used mouse up or key up events to fire an action on buttons.
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.
75
General Discussion / Re: Buttons 0.9
« Last post by billarhos on 29 May 2019, 21:23:25 »
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.
76
General Discussion / Re: Buttons 0.9
« Last post by texus on 29 May 2019, 19:56:21 »
Quote
In your code u wait for mouse up or key up event, correct?
The pressed signal is triggered on mouse up.
For the space and return key the behavior turned out to be a bit less expected. It triggers on a key press event. Which means that if you currently hold the key it will trigger multiple times.

I was going to write that just like the Clicked signal the Pressed signal fires on mouse release, but that made me realize something: you can already "disable" the space and return keys. The difference between the Clicked and Pressed signal is exactly that: Clicked only fires when clicking the button while Pressed also fires when pressing the space or return key while the button is focused. So if you don't want to get a callback on space/return then you can just use the Clicked signal.

Edit: I just looked at how it happens in my browser. Buttons were triggered when releasing the space key but continuously when holding the return key. So maybe I should also have a look at how other libraries handle it.
77
General Discussion / Re: Buttons 0.9
« Last post by billarhos on 28 May 2019, 23:31:38 »
Quote
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.
78
General Discussion / Re: Buttons 0.9
« Last post by billarhos on 28 May 2019, 23:20:28 »
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]
   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.
79
General Discussion / Re: Buttons 0.9
« Last post by texus on 28 May 2019, 22:12:51 »
For other widgets I'll keep the amount of out-of-the-box customizability with outlines limited, but I guess for buttons I can put some extra effort into it and allow a different outline thickness (and color) for every state. Buttons are probably the most used widgets after all.

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.
80
General Discussion / Re: Buttons 0.9
« Last post by billarhos on 28 May 2019, 21:21:13 »
Let's disccus it one by one.

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

Quote
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.


Pages: 1 ... 6 7 [8] 9 10