-
I do not know if this is a bug with SFML or not, but the sf::Window::setSize function does not resize the window if the sf::Style::Resize flag is not passed to sf::Window::Create, as shown below.
#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>
int main()
{
// Create the window
sf::RenderWindow window(sf::VideoMode(640, 480), "SFML works!", sf::Style::Titlebar | sf::Style::Close /*| sf::Style::Resize*/);
window.setSize(sf::Vector2u(320,240));
// Create a simple shape
sf::CircleShape shape(100.f);
shape.setFillColor(sf::Color::Green);
shape.setPosition(400, 240);
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
}
window.clear();
window.draw(shape);
window.display();
}
return 0;
}
If sf::Style::Resize is uncommented, the window will resize just fine. Is this expected behaviour? If it is, how would you allow the window to be resizeable, but not allow the user to resize it directly (by dragging the corner of the window)?
-
No, this is not the expected behaviour. What's your OS?
-
I am on Linux (Linux Mint with MATE, if it helps). I also am using SFML 2.0.
-
Can you try SFML 2.1?
-
Can you try SFML 2.1?
Done.
Assuming I installed SFML 2.1 correctly, the bug still persists. Any idea what is causing this?
-
No, but I'll investigate. You should create an entry in the issue tracker so that I don't forget ;)
-
https://github.com/SFML/SFML/blob/master/src/SFML/Window/Linux/WindowImplX11.cpp#L237
With that 'hack' commented out setSize always works on Fedora 19 with Xfce.
-
Commenting the code has the same effect for me: setSize appears to work as intended. Unfortunately, removing said "hack" also allows the user to change the size of the window, effectively making all windows resizeable.
-
It allows setSize to work but doesn't allow user resize under Xfce.
-
Then MATE must be one of those windows managers that needs this trick to disable resizing. Does anyone have a different Gnome-derived windows manager and is willing to test this out?
Also, this is my first experience getting this low level with graphics stuff, but maybe the solution is to use this hack from the window creation method in the window resize function as well. Do any, more experienced programmers think that this might work?
-
You can try if you want,
add bool m_sizeHack; line as last line to class in WindowImplX.hpp and make these two changes:
void WindowImplX11::setSize(const Vector2u& size)
{
if (m_sizeHack)
{
XSizeHints* sizeHints = XAllocSizeHints();
sizeHints->flags = PMinSize | PMaxSize;
sizeHints->min_width = sizeHints->max_width = size.x;
sizeHints->min_height = sizeHints->max_height = size.y;
XSetWMNormalHints(m_display, m_window, sizeHints);
XFree(sizeHints);
}
else
{
XResizeWindow(m_display, m_window, size.x, size.y);//can also put that outside of else so it always runs, not just when size hack is false
}
XFlush(m_display);
}
// This is a hack to force some windows managers to disable resizing
if (m_sizeHack = !(style & Style::Resize))//intentional assignment
{
XSizeHints* sizeHints = XAllocSizeHints();
sizeHints->flags = PMinSize | PMaxSize;
sizeHints->min_width = sizeHints->max_width = width;
sizeHints->min_height = sizeHints->max_height = height;
XSetWMNormalHints(m_display, m_window, sizeHints);
XFree(sizeHints);
}
Still does the same(correct) thing on Xfce, and it seems that size hints are enough and it doesn't need XResizeWindow if size hints are set like that, but that may vary.
I don't know X at all by the way, so this might be very suboptimal.
-
All right, now that I have finally got a chance to try this, I can confirm that this produces the correct behaviour under MATE. So the question is, where do we go from here? I am rather new to the project and do not yet know the workflow. Should I fork the repo on Github, commit the changes there, and create a pull request?
-
I think I can copy and paste the code myself :P
And this one is a quick and dirty fix, now I need to clean it a little bit.
And by the way, thanks FRex :)
-
Yaay. ;D
The previous post comes with no warranty.
But really I hope it won't break (re)sizing on KDE and GNOME Shell , would be good if someone (with more linux-fu) checked, incidentally both MATE and Xfce are just GTK+2, no Qt or GTK+3. :-X
-
Yeah, more feedback would be really cool :)
And someone should create an issue on the tracker, so that I don't forget it.
-
Do you want another issue besides this one? https://github.com/SFML/SFML/issues/466
-
;D Sorry...
-
I found this thread when googling around, it seems I have a related or similar issue on Win8.1 with SFML 2.1.
Inside a class which inherits a RenderWindow (and a QWidget from QT-framework)
//In scope of init-method
sf::RenderWindow::create((HWND)QWidget::winId(), getSettings());
...
//In scope of update-method
sf::RenderWindow::setSize(sf::Vector2u(5, 3));
std::cout<<sf::RenderWindow::getSize().x<<std::endl;
std::cout<<sf::RenderWindow::getSize().y<<std::endl;
This code does not print 5 and 3 as expected, instead it prints whatever size the RenderWindow was initialized with. What's even more strange, to me, is that if I print the width and height of the QWidget, it is 5 and 3!
I'm not sure if this is Qt issue or SFML issue. Seems to me it's an SFML issue when setSize() doesn't make any difference when calling getSize(). Could this be the same issue that OP had?
Edit: Recreated issue with minimum code
#include <SFML\Graphics.hpp>
int main()
{
sf::RenderWindow renderWindow(sf::VideoMode(200, 200), "Title");
renderWindow.setSize(sf::Vector2u(1000, 1000));
while(renderWindow.isOpen())
{
sf::Event event;
while (renderWindow.pollEvent(event))
{
// "close requested" event: we close the renderWindow
if (event.type == sf::Event::Closed)
renderWindow.close();
}
}
return 0;
}
and I realized it's the window size that setSize changes, not the VideoMode settings.. So nevermind what I wrote before, I misunderstood what setSize actually does. I won't delete the post so someone else that did the same assumption as me could benefit :).
(Although it is somewhat confusing that setSize() sets the size of the window while getSize() returns whatever size renderWindow is!)