Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support disabling window decorations in X11 and Win32 #196

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

jpcima
Copy link
Collaborator

@jpcima jpcima commented Nov 5, 2019

Hi, this adds ability to hide the window captions.
It's a starting point to implement such things as popup menu widgets.

  • On X11, it's using some Motif properties, which seems the widespread method from various toolkits.

  • On Windows, it's the style WS_CAPTION, needing some particular care to set it on/off.
    It needs to recalculate the adjusted window size after setting the hint. I will preserve the former position of the window.

A detail: the window's drawable area has an offset between caption on/off on Windows, because the title bar's top-left is considered the rectangle's origin, unlike in X11.

Other: on Windows it still has the resize border, unless setting isResizable to false.

macOS to be implemented..

@falkTX
Copy link
Contributor

falkTX commented Nov 5, 2019

What is the usecase or this?

@jpcima
Copy link
Collaborator Author

jpcima commented Nov 5, 2019

It's to create some popup menus in their distinct window, such as it's not limited to the drawing area.
eg. traditional menu, context menu, combo box

Sans titre

@falkTX
Copy link
Contributor

falkTX commented Nov 5, 2019

So the window type does not change after it is created right?
If so, I would be prefer this to be a new parameter in the Window constructor, or better yet a new class that subclasses Window and calls its private methods as needed.
Adding 2 methods to the Window class that are only relevant to its creation doesn't seem nice. There is already a bit too much of that already

@falkTX
Copy link
Contributor

falkTX commented Nov 5, 2019

Another reason to have it as a new class is that these kinds of windows cannot use parentId (for embed).
So a new class would not make that constructor method available at all.
And potentially a parent Window class is required, so that it can set transient hint or even modal stuff.
What do you think?

@jpcima
Copy link
Collaborator Author

jpcima commented Nov 5, 2019

So the window type does not change after it is created right?
If so, I would be prefer this to be a new parameter in the Window constructor, or better yet a new class that subclasses Window and calls its private methods as needed.

It does not have any need to change after creating.
By personal preference, I would have the subclass instead of introducing a Nth constructor argument.

And potentially a parent window is required, so that it can set transient hint or even modal stuff.

Judgind by the documentation, I think it should definitely have it.
https://tronche.com/gui/x/icccm/sec-4.html#WM_TRANSIENT_FOR

@jpcima
Copy link
Collaborator Author

jpcima commented Nov 5, 2019

Hmm, I believe there exists an anomaly in Windows code.
It does a forbidden operation according to the MSDN.

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowlongptra

Do not call SetWindowLongPtr with the GWLP_HWNDPARENT index to change the parent of a child window. Instead, use the SetParent function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants