Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - texus

Pages: 1 2 [3] 4 5 ... 95
31
General Discussion / Re: Kitchen Sink
« on: 14 June 2019, 08:30:58 »
I can't think of a reason. It seems to be missing in scrollbar too.
Usually the state is called "down" instead of "pressed", but that might be unclear here.

32
General Discussion / Re: Kitchen Sink
« on: 13 June 2019, 18:56:38 »
Now that you mention it, it does sound like that. Maybe I should rename it to setTimeBeforeDisplay or setTimeBeforeShowing?

33
General Discussion / Re: Kitchen Sink
« on: 13 June 2019, 18:22:21 »
If you added it to the widget with setTooltip then it should show up on the bottom right of your mouse cursor (4 pixels to the right and 8 pixels down in this case) if put the mouse on top of the widget and don't move it for more than a second. You shouldn't have to call pLabelToolTip->setPosition at all, unless you want to add an extra offset to the tooltip which other widgets don't have.

Is there nothing in front of the clickable widget?

34
General Discussion / Re: Kitchen Sink
« on: 13 June 2019, 17:59:28 »
Are you calling something like "gui.add(pLabelToolTip)" somewhere by any chance?
pLabelToolTip->setPosition shouldn't be called like that. The position will be relative to the mouse.

35
General Discussion / Re: Kitchen Sink
« on: 12 June 2019, 19:46:51 »
I've added a TextureBackground property to the label renderer.

I really like how it looks, but I got some minor feedbacks on some parts.
- On the "Labels" tab it also says "Canvas", is that something you are still going to add there or am I missing something?
- Labels can do more than demonstrated. Maybe at the bottom you can have a label with a lot of text in it, so that it gets a vertical scrollbar. There is also the possibility for a Label to have word-wrap by setting a width without setting a maximum height (via setMaximumTextWidth), although showing the version with a scrollbar is probably more important to showcase.
- Maybe "Double click me" would be better than "Click me double"?
- The arrow buttons in the Buttons tab don't seem to have a separate hover and down states. They might look better if the entire rectangle become a little more white when hovered and only gets the black arrow when in down state.
- Maybe pressing the Button0 again should switch it back to the original state? After you clicked on them you can see what they did but it is too late to actually pay attention to it. It is arguable that it serves mostly so you can see how to do it in the code, but then you might as well not switch the text at all.
- The "Button theme2", "Button theme3" and "Button theme4" buttons are probably named that way because they are "themed" button number X, but when I saw the names I expected them to have a different theme, just like the labels. If the name was e.g. "Button 2 with theme" then it would be more clear that the number is about the button, not the theme.
- Maybe swap the location of the "Open keyboard" button and the radio buttons? It is probably just because I wasn't paying attention, but I was clicking around and suddenly I got a different keyboard as before and I didn't immediately realize that it was because of the radio buttons next to it.
- To me the "CappsOff" and "CappsOn" seem inverted. It works either way as it depends on how you interpret it: does it show the current state vs the state you are going to. I personally expected it to be the latter instead of the former.

Overall I still love how it looks and what it is becoming. Keep up the good work!

36
General Discussion / Re: Kitchen Sink
« on: 11 June 2019, 17:53:23 »
How would a texture of a label be displayed? Do you mean a BackgroundTexture property as alternative to the BackgroundColor?

37
General Discussion / Re: Kitchen Sink
« on: 10 June 2019, 15:03:29 »
I think it would definitely be useful.

38
General Discussion / Re: Buttons 0.9
« on: 08 June 2019, 11:52:31 »
Quote
Yesterday is saw default argument in "ignoreMouseEvents" (picture). Ok, why setEnabled or setVisible on the other hand don't have.
Because setEnabled and setVisible are equally likely to be called with true or false while you would only call ignoreMouseEvents with true (as false is the default and you typically don't toggle that property). That being said, I know that some function have default arguments while others don't where I can't make such a clear distinction. The problem is that I don't really like the default arguments as I feel like people might incorrectly see them as an indication of what the default is when the function isn't called and the default parameter value is usually the exact opposite of the default value used by the widget. So in more recent additions I didn't add a default argument at all.

Quote
Instead of rewriting the whole project why don't you add the missing widgets.
Because widgets and extra functions can always be contributed by others, nobody other than me is going to change the architecture of the entire gui.
I also tend to work in 2 phases, during development of a new version I can change the API so I try to change as much as possible at once while after the API gets more stable again I can focus on adding functionality that doesn't break the API (such as adding new widgets). By spending too much time in the unstable phase I always end up dividing the community in 2 versions (those using the older stable version and those using the newest unstable version), so I don't want this phase to last longer than 1-2 years. So things that can be done after tha API gets stable tend to get delayed during early development of a new version.

Quote
There are a lot of tiny improvements that can be done. Like having all those "signalNames" for all widgets in one place!
This is hard to do with the inheritance. I'm also planning on a system like using the onSignal objects directly instead of using the signal names so it might get even more difficult to get things in one place.

39
General Discussion / Re: Picture and OpacityDisabled
« on: 07 June 2019, 14:01:08 »
It seems to work for me. Could you share the code you are using (it may be related to the order things are executed)?

40
General Discussion / Re: showWithEffect and hideWithEffect
« on: 07 June 2019, 13:02:41 »
This should be fixed now.

41
General Discussion / Re: showWithEffect and hideWithEffect
« on: 06 June 2019, 20:15:51 »
You are right, the value is indeed incorrectly reset. The code actually does reset the value to 255 by immediately finishing the show animation, but this happens just after the hide animation had already looked at the current alpha value.

I'll see if I can fix this tomorrow.

42
General Discussion / Re: TGUI and Unicode
« on: 04 June 2019, 16:44:47 »
Based on what I can find, Arial itself doesn't support these characters. I just downloaded a font called "Arial Unicode MS" which is 22MB in size and the characters are being displayed correctly.

My code is as simple as this:
const char* buffer = "\x41\x42\xe6\x9d\xb1\xe4\xba\xac";
text->setText(sf::String::fromUtf8(&buffer[0], &buffer[8]));

Edit: for some reason that I haven't figured out yet, it only works when you use "m_labShipname->getRenderer()->setFont(font)" like you are doing. When using tgui::setGlobalFont I still get squares.
Edit 2: That seemed to be because I need to keep the font alive which is passed to setGlobalFont. Once I did that it also works when setting a global font.

43
General Discussion / Re: TGUI and Unicode
« on: 04 June 2019, 16:22:00 »
I don't see anything wrong with your steps.

Maybe storing the buffer in an std::string can be skipped if fromUtf8 supports a begin and end pointer (I'm not sure if it does), but it will work equally well when first stored in an std::string.

The type is Uint32 because it stores the string as UTF32. Two bytes wouldn't be enough to store ALL possible unicode characters.

If squares are displayed then it would mean that the chosen font (arial.ttf in this case) does not contain these japanese characters.

44
Themes / ===== Read before posting =====
« on: 04 June 2019, 12:50:02 »
In this forum section you can share themes that you created. For general help with themes, the help requests section would be a more suitable place.

When sharing a theme, please provide at least the following information:
  • A list of widgets supported by your theme
  • A screenshot showing some of the widgets with your theme

All themes shared here are freely usable and considered public domain unless explicitly stated otherwise!

45
General Discussion / Re: Buttons 0.9
« on: 02 June 2019, 14:30:31 »
What exactly do you want to me to look at with that gui?
FairyGUI looks great, and they focus completely on games, 2 things you can't say about TGUI :)

I'm currently unsure how TGUI should continue in 0.9. There are just too many customizations to implement to really have a tunable gui (and I don't have the time to implement them). So I want to provide some way that the user can write their own code to extend the widgets. That way they can still do complex things (as I can't provide code for every scenario) while it would also be possible for me to sometimes merge the code back into TGUI to provide the functionality for everyone.

I'm completely stuck on a design for this though. The current design doesn't make it easy to extend the widgets at all, you would have to inherit both the widget and the renderer and override multiple functions. I was thinking about moving the draw function to the renderer so that most of the time you only need to inherit from the renderer. The issues with splitting the code in 2 part still remain though: mouse event functions and draw functions need to be equivalent, mouse press needs to know about borders, padding and spaces between items, which would all depend on the custom draw function.

Merging the widget and renderer into a single class again would simplify things and probably make it easier to extend it, but it probably makes it more difficult to implement skins. I tried looking into the code of some other guis but they usually have a complex structure. That is probably good for the extendability but I want to keep TGUI easy to use as well. It don't want to e.g. make it more difficult to have a simple list box with some strings just because someone may want to create a list box with subwidgets.

So instead of thinking about all that, I'm currently just spending my spare time playing borderlands 2, which is why I haven't responded for a few days :)

Pages: 1 2 [3] 4 5 ... 95