[Suggestion] Message Box

[CharlotteCross1998]

Hi, I love this project and would love to see it grow. I think a good next step would be to add messagebox support. This would essentially be a separate window from the main program which has a return value depending on what buttons are on it. For example, if the programmer adds an OK button, it could return rg.MessageBox.OK. Other buttons could be CLOSE, YES, NO, CANCEL etc., as well as support for custom buttons.

The messagebox could have support for images and text within the window so the user knows what the buttons do. Example usages could be an "About" messagebox, which displays the programmers information and information about the software, and just has a simple CLOSE button. Another example could be a "Quit" messagebox, which asks the user if they're sure they want to quit, with YES and NO buttons.

Example of what the code could look like:

def messageBoxAbout():
    #As we only have close, we don't care about the return value
    rg.MessageBox.Show(text="Made By XXX\nUsing pyretro-gui", buttons=[rg.RetroButton(text="Close")])
menuItemAbout = rg.MenuItem("About", onclick=messageBoxAbout)

Some things would have to be reworked, like RetroButton needing to be auto-calculated where to put the button. Alternatively, create a rg.MessageBox.Button which is a wrapper around RetroButton which does this?

[bendikMichal]

Would be a cool addition, I'm all for it. Though why do you think the Retro button would need to be auto-calculated? As of now there are no rules that enforce no overlapping of Widgets... Some Widgets (including RetroButton) have a parameter called anchors, it is a list of two ints eg. [0, 1] which change the anchor of the widget, therefore it is possible to do rg.RetroButton(0, 0, anchors = [1, 1]) which would result in the button always being in the bottom right corner... Thanks for the great idea I'll think about it, implementing a new window could be interesting.

[bendikMichal]

Feel free to open a pr if you already have an idea in mind.

[bendikMichal]

Experimenting in dialog-testing branch

[CharlotteCross1998]

Would be a cool addition, I'm all for it. Though why do you think the Retro button would need to be auto-calculated? As of now there are no rules that enforce no overlapping of Widgets... Some Widgets (including RetroButton) have a parameter called anchors, it is a list of two ints eg. [0, 1] which change the anchor of the widget, therefore it is possible to do rg.RetroButton(0, 0, anchors = [1, 1]) which would result in the button always being in the bottom right corner... Thanks for the great idea I'll think about it, implementing a new window could be interesting.

I suppose there's no direct reason to have the buttons auto calculated. It's convention to have them on the bottom, but it's not a hard rule everyone has to follow. I haven't played with the anchor attribute but from what you describe, it sounds like it does the job already.

[bendikMichal]

You can try running _dialog_window.py in the previously mentioned brach to see a WIP of possible dialog implementation. This one is as a separate window, but I've also been contemplating just creating an in-window kind of dialog instead. Might be cleaner and simpler...

EDIT: Running the _dialog_window.py standalone no longger works, you have to pass arguments eg: _dialog_window.py 200 120 NoTitle "" 0, the last 0 will be flags, kindof experimental way of telling it what should be on the warning dialog...

[CharlotteCross1998]

Small issue where you can select both buttons at once. Giving them a little extra space solves it.

[bendikMichal]

Is this with the newest commit ? EDIT: This was fixed in this commit.