myremylar / pygame_gui Goto Github PK

Is your feature request related to a problem? Please describe.
Right now, the library has a really lazy approach to loading files like fonts, images and them files. Of just loading them all immediately.

Describe the solution you'd like
Instead, I'd like the option to disable this lazy loading and hand over to the users something like a list of file paths to be loaded and the places where they should be loaded too.

This also needs to account for a file, like the theme, file adding more files to be loaded to the list.

Additional context

This is a slightly complicated topic so likely needs a good example demonstrating how it would work, a new UIProgressBar element to demo it with and some documentation explaining the reasoning and theory behind why it is a good idea to load files in a more complicated way.

To Do List:

• Effect parameters to control variables.
• Add a UI event generated when an effect is finished.
• Add HTML tag and set_effect parameter to limit applied effects to tagged areas only.
• Add ability to apply text effects to labels.
• Add optional 'post-finalise' transform matrix (translate, rotate, scale) for effects usage.
• create more elaborate/interactive text effect example file in examples project
• Add two new effects for whole chunk transform.

Just a page covering how to check them and what they currently are. We may want to review the events at this time and check we have all the events we want.

• Scrolled to bottom of text box? (could be useful for EULA type 'you must read this text'? type things maybe... though who cares about that.)

Is your feature request related to a problem? Please describe.
There are various string IDs like ui_button_pressed and typing_appear - it would be useful if these were provided by the module as constants - as well as reducing typos it would make them more discoverable by IDE autocomplete.

Describe the solution you'd like
pygame_gui.UI_BUTTON_PRESSED = 'ui_button_pressed' or similar

Used in the UIAppearanceTheme class' load_theme() function as a type hint.

New options have been added for shapes, colour gradients and live theming.

Check each element & core docs:

• Core docs
• Button
• Drop Down
• Slider
• Label
• SS health bar
• WS health bar
• Text Box
• Text entry line
• Tool tip
• Scroll bar

Building Pygame 2 applications on Android is becoming possible via Python-For-Android (aka P4A):

https://github.com/kivy/python-for-android

Here is a relevant issue on the subject over on the pygame GitHub: pygame/pygame#727

When it is working relatively reliably we should test Pygame GUI on there and see what the state is. This may have relevance to other issues like #27 .

Aiming for this to be the base library support version.

Currently the project has no python version requirements set.

3.4 is five years old now and game developers should generally be targeting more recent releases of python.

Can't see any particular reason to go any lower as 3.4 gives us the path library as standard which I'm using.

A check box/radio button group where you can only check one box/activate one radio button and clicking another in the group deactivates the previously selected one.

Probably make a group element where you supply a list of button labels and it creates it for you out of buttons.

Definitely need a better name for this- Tkinter?

• Visually choose a colour by clicking.
• Get the picked colour from the element as a pygame.Color.

Right now you either have to look a the code directly or make an educated guess refined by trial and error to pick the right colours to theme GUI elements. It might be nice if the theming documentation was supplemented by enlarged images of the elements being discussed with arrows pointing out which colour applied to which bit.

Additionally, for elements composed of sub elements these could be highlighted in the diagram also.

Is your feature request related to a problem? Please describe.
Sometimes the current theming options are not enough. If you want to make buttons that are mostly like other buttons but with one small change, right now you can inherit from a root 'button' element theming block and overwrite some of those parameters with an object ID block, which is OK as far as it goes.

But what if you want to make a window element with a bunch of theming options then another window element which looks mostly the same with only a few changes? Right now you are out of luck, there is no 'window' element theming block to inherit from because, right now, any window you make is it's own element and could have any design of theming parameters.

Describe the solution you'd like
As a general solution we could take advantage of the prototype design pattern in the theme .json file to allow users to set any, already loaded, theming block (i.e. one higher in the file, or in the default theme) as a 'prototype' for the current one.

The current block would then inherit all the theming parameters of it's protype before loading it's own (and possibly replacing some of those loaded from the prototype.

This will put the power of theming parameter inheritance flexibly into the hands of the person writing the theming file. They could inherit from inappropriate blocks, but this won't really affect the overall system because elements only get data from their theming block that they actually use.

Hopefully it will make for shorter theme files, with less duplication, overall on large projects with lots of UI - and can be completely ignored on small projects.

Code example:

"#CoolWindow":
{
    "prototype": "#BaseWindow"
    
    "colours":
    {
        "normal_bg": "#45F412"
    }
}

Likely to be quite involved process, may need to create a another new element to make it work nicely (thinking of the text list of files).

• Model off PyCharm Open file dialog for functionality.

Thinking here of a classic RPG style inventory UI system as seen in games like Minecraft, Stardew Valley or Baldur's Gate.

Is your feature request related to a problem? Please describe.
Sometimes you want a 'panel' with basically nothing much on it that behaves a bit like a window but stays at whatever layer of the UI it starts and contains other elements.

This is sort of a halfway house between a window and the current bare-bones Container.

Describe the solution you'd like
You make a Panel, it has basic theming options (shape, shadow, border, padding) a rectangle then you fill it with other elements.

Unlikely that it could get as fancy as CSS buttons on web pages but some extra pizzaz might be nice:

See link below for examples of different button effects:
https://bashooka.com/coding/25-css-button-animation-examples-2018/

-test in -onefile mode to see if that works too.

Just to show off the theming for demos.

The documentation could use more pictures in general.

While the module tries to use relatively standard terminology, for users unfamiliar with GUI conventions I think gifs might be a nice option to stick in a few places to make it clear to users what the class being discussed is meant to look like in action.

Standing in for linux testing.

• Add an 'embossed' theme for borders.

• 'embossed' creates an 'inverse luminance' version of the border colour and draws the bottom
  and right sides of the border with it.

  lum = (r+g+b)/255
  colour_map = (r/255, g/255, b/255)
  inv_lum = 255 - lum
  final_col = pygame.Color(inv_lumcolour_map[0], inv_lumcolour_map[1], inv_lum*colour_map[2])

aiming to mimic style of minecraft menu buttons:

Just to make sure we are only getting valid object IDs.

• create a function on UIElement to handle this 'create_valid_ids()' or something - probably can bundle up current ID assembly structure into it.

Currently there are three text effects with no documentation.

• UIButton
• UIDropDownMenu
• UIHorizontalSlider
• UIVerticalScrollBar
• UITextEntryLine
• UITextBox
• UITooltip
• UIScreenSpaceHealthBar
• UIWorldSpaceHealthBar
• UIMessageWindow

Seems like a good place to advertise the library to new people.

Maybe clean up the section while there.

When trying yo use examples on Linux following traceback appears:

Traceback (most recent call last):
  File "/home/jtiai/projects/pygame_gui/pygame_gui_examples/general_ui_test_app.py", line 4, in <module>
    from pygame_gui.ui_manager import UIManager
  File "/home/jtiai/projects/pygame_gui/pygame_gui/__init__.py", line 3, in <module>
    from . import elements
  File "/home/jtiai/projects/pygame_gui/pygame_gui/elements/__init__.py", line 11, in <module>
    from .ui_text_entry_line import UITextEntryLine
  File "/home/jtiai/projects/pygame_gui/pygame_gui/elements/ui_text_entry_line.py", line 8, in <module>
    from ..core.utility import clipboard_paste, clipboard_copy
  File "/home/jtiai/projects/pygame_gui/pygame_gui/core/utility.py", line 7, in <module>
    from ctypes.wintypes import HGLOBAL, LPVOID, BOOL, UINT, HANDLE, HWND, DWORD, INT, HMENU, HINSTANCE, LPCSTR
  File "/usr/lib/python3.7/ctypes/wintypes.py", line 20, in <module>
    class VARIANT_BOOL(ctypes._SimpleCData):
ValueError: _type_ 'v' not supported

Root cause of traceback is attempt to import Windows specific ctypes ctypes.wintypes which is only available on Windows.

I don't have a mac.

Is your feature request related to a problem? Please describe.
Sometimes you don't want to position a rectangle by the top left corner and lock it's position to the top left corner of it's container.

Describe the solution you'd like
options to lock an element to the right, bottom and centre co-ordinates and combinations thereof, and to do so using the element's right, bottom and centre co-ordinates.

Additional context
Godot does something like this we could learn from:
https://godot.readthedocs.io/en/3.0/tutorials/gui/size_and_anchors.html

Suggested by: jtiai on the pygame Discord server

Code for a basic gradient in pygame:

def create_gradient(colour_1, colour_2, angle, size):
    longest_diagonal = int((size[0] ** 2 + size[1] ** 2) ** 0.5)
    colour_pixels_surf = pygame.Surface((2, 1), flags=pygame.SRCALPHA).convert_alpha()
    gradient_surf = pygame.Surface((longest_diagonal, longest_diagonal), flags=pygame.SRCALPHA).convert_alpha()
    colour_pixels_surf.fill(pygame.Color(colour_1), pygame.Rect((0, 0), (1, 1)))
    colour_pixels_surf.fill(pygame.Color(colour_2), pygame.Rect((1, 0), (1, 1)))
    pygame.transform.smoothscale(colour_pixels_surf, (longest_diagonal, longest_diagonal), gradient_surf)
    gradient_surf = pygame.transform.rotate(gradient_surf, angle)
    gradient_placement_rect = gradient_surf.get_rect()
    gradient_placement_rect.center = (hello_button.rect.width / 2, hello_button.rect.height / 2)
    final_gradient_surface = pygame.Surface(size, flags=pygame.SRCALPHA)
    final_gradient_surface.blit(gradient_surf, gradient_placement_rect)
    return final_gradient_surface

We will need to have syntax for loading gradients from theme, something like:

"button":
{
    "colours":
    {
        "normal_bg": "#ffafbdAA,#ffc3a0AA,(0,1)"
    }        
}   

Ideally will be able to support different directions:

• create gradient shape based on region we are trying to theme by finding longest side of
  rectangle and building a square bounding box that will contain it whatever the rotation.
• rotate shape with pygame.transform, clear area to be filled, blit rotated gradient square down
  centered on element rectangle (width/2, height/2) and clipped to shape.

Describe the bug
Unable to install pygame_gui.

To Reproduce
Steps to reproduce the behaviour:

1. python -m pip install pygame-gui

Expected behaviour
Installation of pygame_gui

Screenshots
None

Platform and software (please complete the following information):

• OS: Windows 10 (64bit)
• Pygame GUI version: 0.4.0
• Pygame version: 1.9.6 / 2.0.0dev6

Additional context
Tried two versions of pygame.
Google suggested possibly a Path issue. Confirmed python's Path points to the project directory.

Traceback (most recent call last):
File "", line 1, in
File "C:\Users\Gabriel\AppData\Local\Temp\pip-install-56tyfvta\pygame-gui\setup.py", line 2, in
from stringify import stringify_py
ModuleNotFoundError: No module named 'stringify'
----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

Right now default theming is done simply via code fallbacks. It'd be nicer to always load some default theme parameters now that we have a better method to theme individual buttons in scrollbars and such like.

Pygame GUI supports two type of IDs for elements 1. An Element ID that is just a string telling you what type of element it is e.g. 'button' for a UIButton and 2. An Object ID, mainly set by the user, which is used to distinguish two elements of the same type from one another e.g. '#button_1' and '#button_2'.

Pygame GUI was recently refactored to support a more hierarchical system for identifying individual elements in theme files. This means an individual element that may be nested within other elements (e.g. a UIButton in a UIVerticalScrollbar in a UITextBox) now has multiple 'combined IDs' that should be ordered from 'most specific' (i.e. the tree of IDs with the most Object IDs in it) to 'least specific' (i.e. in the example case above the least specific id would be 'text_box.vertical_scroll_bar.button' which would identify all buttons in scroll bars that are part of text boxes.)

For convenience, the event system has also been providing element's object IDs when they were fired making it easy to identify the push of a specific button even if that button's object was not currently accessible.

I suspect it may be advantageous to alter this system slightly so that it now gives the 'most specific' combined ID available when fired. Will allow us to identify specific events for which it is currently awkward to obtain the code object from, and without needing much refactoring of existing code.

Possible many platforms will have options to trigger a platform onscreen keyboard as an overlay?

Right now everything in the UI is very rectangular. Not a problem for things where rectangles are the only option but things like buttons could be different shapes.

it may be possible to keep rectangles as the default while allowing optional 'shape' parameter that would be used for determining appearance, clicking and hovering.

• model on options in pygame draw e.g. circle, polygon

Describe the bug
I can't seem to get my theme to load into the UIManager, let alone be applied. I've been comparing the code to the tower defence game you linked and using the same approaches.

To Reproduce
Load the theme:
gui = pygame_gui.UIManager((VisualInfo.BASE_WINDOW_WIDTH, VisualInfo.BASE_WINDOW_HEIGHT), "data/ui/themes.json")

Configure the theme (themes.json):

{
     "#skill_button":
     {
         "normal_image":
         {
             "path": "assets/skills/placeholder/icon_00.png"
         },
         "hovered_image":
         {
             "path": "assets/skills/placeholder/icon_00.png"
         }
     }
 }

Create the button:

skill = pygame_gui.elements.UIButton(relative_rect=pygame.Rect((x, y), (width, height)), text=f"{skill_slot}",  manager=manager,
                                                 container=self.get_container(), object_id=f"#skill_button")

Expected behaviour
Expected button to be shown with an image.

Platform and software (please complete the following information):

• OS: Windows 10 (64 bit)
• Pygame GUI version : 0.4.0
• Pygame version: 2.0.0dev6

Additional context
Nothing is applied on screen to the buttons, and when I inspect the gui (UIManager) the theme attirbutes show a lot of data I haven't set, like "#message_window", which I assume is somewhere in the defaults. Although, I didn't even see that when I was looking into the UIAppearanceTheme.

Am I missing something obvious? I tried using an os.abs path, and setting a colour in the json. Setting a colour in a "button" block applied to all buttons, and in the "#skill_button" block also applied, but the images didnt show either way.

P.S. I debated adding this to the thread on reddit, but assumed it would be better suited here. Let me know if you'd rather I raise it somewhere else!

Probably we can mash this into the regular button class but some further thought and analysis may be required.

Seems to have some bad characters and repeated strings.

Needs further investigation to see if it can be fixed.

• UIButton
• UIDropDownMenu
• UIHorizontalSlider
• UIVerticalScrollBar
• UITextEntryLine
• UITextBox
• UITooltip
• UIScreenSpaceHealthBar
• UIWorldSpaceHealthBar
• UIMessageWindow

Will allow tweaking of theme parameters while code is running.

TODO:

• Add 'reload_theme()' method to UIManager to clear & reload the currently set theme.
• Go through all UI elements to refactor functions so that they can regrab their theme parameters
  from UIAppearanceTheme object data and then redraw.
• Add a UIElement method called something like 'rebuild_from_theme()'
• Have UIManager trigger rebuild_from_theme on all UIElements it is managing.

Element list to tick off

• UIButton
• UIDropDownMenu
• UIHorizontalSlider
• UIImage
• UILabel
• UIScreenSpaceHealthBar
• UITextBox
• UITextEntryLine
• UITooltip
• UIVerticalScrollBar
• UIWorldSpaceHealthBar
• UIMessageWindow

Testing:

• auto reload? Check if file has changed?

Describe the bug
I believe shadow rendering on rectangles is wrong if you increase the size of the shadow beyond the default 2.

To Reproduce
Steps to reproduce the behaviour:

1. Make a large shadow on a rectangle.

Expected behaviour
Proper shadows.

Screenshots
TBD

• UITextBox
• UITextEntryLine
• UIButton
• UIDropDownMenu
• UIHorizontalSlider
• UILabel
• UIScreenSpaceHealthBar
• UITooltip
• UIVerticalScrollBar
• UIWorldSpaceHealthBar
• UIMessageWindow

It's common in UIs now to leave out these buttons. I think I'll still include them by default though because I kind of like them.

As discussed here indygreg/PyOxidizer#69 file is apparently being sort of deprecated for use in python modules for loading resources. Right now, support for alternatives also seems a bit patchy so there is no great rush.

I'm not certain that pygame is supported by PyOxidizer either yet.

• Choose library for automated tests.
• write a few tests
• measure test coverage
• write the rest of the sodding owl/tests
• require passing tests before merging branches/pull requests

As title, currently they are all set to the magic number of 170 pixels.

Loathe as I am to increase the number of colour theming parameters these colours feel necessary for completeness.

As title.

• Cover topic in general in theming intro.
• For each element with sub elements document how to pick them out individually, or as a group.
  • This will require adding more object IDs to current sub elements.

I suspect that Pyinstaller won't work with the current, very basic way, we are loading images. This is likely linked to issue #52 and issue #2 as we need an all round better loading solution that we can be confident works across platforms and in all kinds of 'freezing' libraries.