SFML community forums
Help => Window => Topic started by: Sirt on January 10, 2009, 06:31:28 am
-
First Hi,I'm one of the many people flocking from SDL to SFML
and I'm loving it.
My question is this,
When I create a window with sf::Style::Titlebar the title bar area including the minimize and close buttons is invisable, but present.
I'm running sfml 1.4 on Ubuntu Hardy via the CLI (gnome interface).
Is this a known problem,I haven't seen it mentioned anywhere.
Everything else works fine,also the sample programs have the same problem except for the X11 sample program which does show the titlebar.
I can provide the code if you want to check my code is not the problem,
I'm guessing it's a Linux compat setting I am unaware of?
Thanks for this great library.
-
Please post a minimal example to reproduce your problem.
-
Okay thanks Tank,
this minimal code won't display the titlebar though it is there because I can hover the mouse over it and the bubble box's appear (minimize,maximize),also the screen is not cleared to black in that area ...
(on Ubuntu 8.04, using Gnome 2.22.3 interface if it helps!)
#include <SFML/System.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>
int main()
{
sf::RenderWindow App(sf::VideoMode(800, 600, 32), "test sfml", sf::Style::Titlebar | sf::Style::Resize | sf::Style::Close);
sf::Event Event;
sf::Font MyFont;
// Load from a font file on disk
if (!MyFont.LoadFromFile("Widelands.ttf"))
{
if (App.IsOpened()){ App.Close();}
return 1;
}
App.SetFramerateLimit(12);
sf::String Text("test", MyFont, 50);
Text.SetPosition(100, 100);
while (App.IsOpened())
{
while (App.GetEvent(Event))
{
// Window closed
if (Event.Type == sf::Event::Closed)
{App.Close();}
// Escape key
else if ((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Key::Escape))
{App.Close();}
}
App.Clear();
App.Draw(Text);
App.Display();
}
return 0;
}
[/code]
-
Well I have just turned off all visual effects that I had running (main menu -> appearance -> visual effects),and now the titlebar shows.
Which is good.
-
Hi!
Did you ever find a fix for this other than turning the visual settings off? I've just encountered the same problem in Hardy 8.10. But I liked the rubber windows.
Cheers.
-
The problem is the OpenGL Rendering Context and Compiz Fusion in Ubuntu. Somehow, Compiz Fusion interferes with most OpenGL applications. Thus if you use SDL with OpenGL similar problems will appear while having effects enabled.
I don't think this is a SDL/SFML-library specific problem. It's either OpenGL/MESA, X11, or GNOME that has to do something about this.
Could also be that the error is Hardware specific.
-
Thus if you use SDL with OpenGL similar problems will appear while having effects enabled.
This isn't correct. I'm in the same boat as everyone else. Yet SDL/OpenGL displays the titlebar just fine. It even renders everything in the window with the only artifacts being bleed-through from other openGl contexts updating.
-
I said similar effects, both problems is caused by OpenGL on Linux machines with Compiz Fusion Enabled. :P The similar effects I was talking about is the bleed-trough.
A guess is that, using XLib to open a window makes it incompatible to the Compiz engine? So maybe a better solution is to use GTK to open? Nah I don't know.
-
A guess is that, using XLib to open a window makes it incompatible to the Compiz engine? So maybe a better solution is to use GTK to open? Nah I don't know.
Yeah, you don't know :D
XLib is the low-level API for windowing on Linux, other APIs (including GTK) are built on top of XLib.
-
A guess is that, using XLib to open a window makes it incompatible to the Compiz engine? So maybe a better solution is to use GTK to open? Nah I don't know.
Yeah, you don't know :D
XLib is the low-level API for windowing on Linux, other APIs (including GTK) are built on top of XLib.
Yea but the problem is Compiz, I think it uses GNOME's functions to do what it do. So maybe Xlib opened windows are not compatible with it.
-
Ah, ok I get it. You mean that Gnome may add something to windows to make them compatible with Compiz. But it would still not explain the problem, the window manager catches all X11 calls, so it can add any extra processing on top of any window, even those created directly through XLib.
-
It's more likely a bug in the graphics driver, since I don't experience any Compiz/OpenGL/SFML issues.
-
It's more likely a bug in the graphics driver, since I don't experience any Compiz/OpenGL/SFML issues.
Yeah,I wasn't even using openGL when I had this problem,
unless SFML is built on top of openGL that is!
Just SFML with a console window.
I couldn't be bothered looking for another solution and I miss my rubber windows.
-
unless SFML is built on top of openGL
It is ;)