Window control methods

[johannphilippe]

A few methods could be added to improve the control over window, particularly when user handles several windows in the application.

• close() : simply closes the window. I could make it work easily with gtk_window_close(GTK_WINDOW(_window->host)); on linux.
• open() : opens the window that has been closed (or that has been created)
• hide() : minimizes the window without closing it
• show() : shows a minimized window.
  Those could be renamed to be more expressive.

That would imply to have a window object that does not necessarily displays when created so the user can decide when to display it or not.

Also, I could run several windows in one app fine, if the process to create a second window is delayed (responding to a click event for example), the second window displays, but the view content is not drawn.
For example :

int main(int argc, char* argv[])
{
    app _app(argc, argv, "Empty Starter", "com.cycfi.empty-starter");
    window _win(_app.name());
    _win.on_close = [&_app]() { _app.stop(); };
    view view_(_win);

    auto open_button = button("open");

    std::shared_ptr<window> win2;
    std::shared_ptr<view> view2;
    open_button.on_click = [&](bool)
    {
        win2 = std::make_shared<window>(_app.name());
        view2 = std::make_shared<view>(*win2);
        view2->content(box(bkd_color));
    };
    view_.content(open_button, background);
   _app.run();
   return 0;
}

[redtide]

Note: this is similar to #125 feature request, though in my case show() and hide() have a different meaning.

[johannphilippe]

Also in #125 you are talking about element object, and here it is about window, so I'm afraid it won't be the same process.

[redtide]

yep, at first I thought was a duplicate but it's not

[djowel]

Let's do this!

[djowel]

I'll probably follow GLFW's: https://www.glfw.org/docs/latest/window_guide.html#window_properties

[na2axl]

Hey @djowel, any updates on this?

I have a project which involves to have several windows, but now it's currently impossible due to the same reasons as the OP

[djowel]

Hey @djowel, any updates on this?

I have a project which involves to have several windows, but now it's currently impossible due to the same reasons as the OP

No update yet, But as always, I welcome a PR.

[djowel]

Hey @djowel, any updates on this?
I have a project which involves to have several windows, but now it's currently impossible due to the same reasons as the OP

No update yet, But as always, I welcome a PR.

Alright, if there are no takers, I'll take this.

[djowel]

Also, I could run several windows in one app fine, if the process to create a second window is delayed (responding to a click event for example), the second window displays, but the view content is not drawn.

@johannphilippe works on MacOS. I'll try Windows and Linux. Which platform have you tested with?

[redtide]

I've already dealt with this in the past with gtk3 and win32, but was many years ago, if needed I can help with gtk3 ATM.

2 things:

Also in #125 you are talking about element object, and here it is about window, so I'm afraid it won't be the same process.

I think element or host (window/view) we are dealing with "widgets" in general, so the concept should be consistent for both.

Second: don't want to be picky but some things are not clear to me now, in my opinion the logic in general should be:

• close(): a method that tells a window to be closed (destroyed), unless some close event/signal is ignored/skipped
• open(): I think I never seen this, which usually is used to be show()
• hide(): the window is set as invisible anywhere, which might be the state after being created
• minimize(): the window is reduced to icon in the "taskbar"
• maximize(): the window fits the current screen
• restore(): if minimized the window back to the previous size

but, how to deal with the widget destruction when the "close event" is accepted?
The GLFW documentation seems to not specify this (or I haven't found it there).
To me closed means also destroyed, which is not what most of implementations do:

• on GTK is not documented clearly (destroyed or hidden?)
• on win32 they say "minimized", which to me is same as "iconized" (what is the minimum?)

[djowel]

The GLFW documentation seems to not specify this (or I haven't found it there).

GLFW does not have widgets

To me closed means also destroyed, which is not what most of implementations do:

That is obvious.

[djowel]

To me closed means also destroyed, which is not what most of implementations do:

That is obvious.

Let me be more clear: Element's window does not own its view. Only the view destroys the elements it contains.

[djowel]

Let me be more clear: Element's window does not own its view. Only the view destroys the elements it contains.

But also take note that even child elements in a view can be shared.

Anyway, in short: lifetime management is not a concern of window

[djowel]

I've already dealt with this in the past with gtk3 and win32, but was many years ago, if needed I can help with gtk3 ATM.

That would be great. Thanks for the offer! I'll start with MacOS.

[djowel]

I've already dealt with this in the past with gtk3 and win32, but was many years ago, if needed I can help with gtk3 ATM.

That would be great. Thanks for the offer! I'll start with MacOS.

Any takers for windows?

[johannphilippe]

Also, I could run several windows in one app fine, if the process to create a second window is delayed (responding to a click event for example), the second window displays, but the view content is not drawn.

@johannphilippe works on MacOS. I'll try Windows and Linux. Which platform have you tested with?

I'm pretty sure it was Linux (Mint 20) since it was/is my dev platform.

[djowel]

• close(): a method that tells a window to be closed (destroyed), unless some close event/signal is ignored/skipped
• open(): I think I never seen this, which usually is used to be show()

I think the window should automatically open when constructed and close (destroyed) when destructed (C++ RAII). Then there should be hide() and show() to set the visibility.

[djowel]

Implemented hide() and show() in window_dev branch (MacOS for now)

[redtide]

• close(): a method that tells a window to be closed (destroyed), unless some close event/signal is ignored/skipped
• open(): I think I never seen this, which usually is used to be show()

I think the window should automatically open when constructed and close (destroyed) when destructed (C++ RAII). Then there should be hide() and show() to set the visibility.

The window is "opened" (whatever it means in a UI context, to me could mean "alive") when constructed, it's just not visible in some cases (like GTK and maybe also win32).
There might be a reason if other frameworks don't do that and wants an explicit show(); I guess one of them might be a tray icon application that doesn't show the window until the icon is clicked to pop it up, or for event loop related reason(s).

[na2axl]

• close(): a method that tells a window to be closed (destroyed), unless some close event/signal is ignored/skipped
• open(): I think I never seen this, which usually is used to be show()

I think the window should automatically open when constructed and close (destroyed) when destructed (C++ RAII). Then there should be hide() and show() to set the visibility.

The window is "opened" (whatever it means in a UI context, to me could mean "alive") when constructed, it's just not visible in some cases (like GTK and maybe also win32).
There might be a reason if other frameworks don't do that and wants an explicit show(); I guess one of them might be a tray icon application that doesn't show the window until the icon is clicked to pop it up, or for event loop related reason(s).

I agree with you. An explicit show() is better for many use cases, and I am (and I feel most other people are) already familiar with this.

For exemple I want to have a splash screen that does background initialization of my app. I will think to (maybe not the best way) create the 2 windows (splash screen and main window) first, do initialization in another thread (which involves to set some state values to the main window instance), and when everything is OK just show() the main window and close() the splash screen in the UI thread.

Automatically close() the window on destroy is good for me.