Registered Member
|
I posted this once but I don't see it. Pardon me if you end up seeing this twice.
Our application is experiencing a bizzare behavior starting in KDE 4 which we ended up with when we rebased from SuSE 10.3 to SuSE 11.1. The behavior is unique to KDE 4 and does not happen with the current version of Gnome so it's likely either a bug or a configuration issue. The application adds its own buttons to the title bar to replace the minimize, maximize and delete buttons. Initially the added buttons show up fine. But upon movement of the window or interactivity with other windows the new buttons either disappear, or are obscured by the old minimize/maximize/delete buttons as though those never went away. At times you could see the new buttons slightly from in between the old buttons. Any info on what might be causing this or what the fix is would be appreciated. |
Registered Member
|
What version of KDE are you using? By default openSUSE 11.1 comes with KDE 4.1, which was never intended for everyday use and has a lot of bugs and missing features.
This may have to do with what sort of window the application is identifying itself as, although I don't know what the proper one would be. But applications really shouldn't be painting their own titlebar or titlebar buttons, that should be handled by the window manager.
Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
-NASA in 1965 |
Registered Member
|
BlackCat,
Thank you for your input. We are indeed using KDE 4.1 with SuSE out of the box. I'm puzzled why SuSE chose to distribute something that's unstable. Would you mind pointing out what version of KDE is stable and where to download it? As for your second point, the application is not painting the title bar. It is customizing the buttons. This is nothing new. In fact KDE 3 had no issues with it whatsoever. If it's not allowed to customize the API shouldn't grant the call. Gnome 2.28 that is also bundled in SuSE 11.1 shows has no problems with this call. If, however, it's documented somewhere that it's not allowed to customize titles bars and buttons I would appreciate a reference to it so we pass it on to the application people. Thanks again. I still welcome other input by others. |
Administrator
|
Updating to KDE 4.5 is highly recommended.
http://download.opensuse.org/repositori ... SUSE_11.1/
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
Registered Member
|
I am not sure exactly what you mean. Do you mean it is changing the button icons, or do you meant it is changing which buttons appear?
Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
-NASA in 1965 |
KDE Developer
|
KDE's window manager never allowed applications to customize the buttons on the window decoration. This is out of scope for apps. I do not understand what you are trying to achieve but considering the various standards (ICCCM, NETWM/EWMH) the window manager is allowed to attach own window decorations to a window - no matter if an app wants it or not. There is no standaradized way to allow applications to interact with the decoration and at least KWin does not provide such a feature and won't at least for the lifetime of KDE 4 provide such a feature.
Nevertheless I think it's possible that I just completly missunderstood you. A screenshot might help to understand better... |
Registered Member
|
Thank you all for your input. I was away for a few days and unable to reply. Here are some answers to the questions posed.
The purpose of customizing the buttons is to create the same look and feel for the application under any window manager. The program shows the correct, requested buttons under gnome and KDE 3.5. Under KDE 4.x the window manager ignores the request for updated buttons (such as the maximize, minimize buttons) and shows the standard KDE (^ and v buttons for maximize and minimize). Upgrading to KDE 4.5 did not help the situation. Here is a stand alone containing the source. Once you build it with the following Makefile, run it under gnome, KDE 3.5 and KDE 4.5 and the difference is obvious. There are additional comments in the program header. We look forward to your input. Makefile: CFLAGS= -g -I. -I/usr/X11R6/include -I/usr/include/X11 LDFLAGS=-L /usr/X11R6/lib64 title_bar_buttons: main.o cc -o title_bar_buttons main.o $(LDFLAGS) -lXm -lXt -lX11
|
Registered Member
|
I haven't read the code, but based on your description, it sounds like a really nasty hack designed to work around the rules specifically set up to prevent this sort of thing. Applications are not supposed to to handle these buttons.
The whole point of the window manager is that the windows are managed by the window manager, not by the client window. The fact that gnome and KDE 3.5 do not enforce this behavior sounds like a flaw in them. Based on my understanding and a quick reading of the specs, KDE 4's behavior seems to be the one that is in line with the intention of the specifications. The fact that there is no built-in mechanism to modify the window's title bar button and you had to resort to hiding them with another window should probably be a hint that this sort of behavior is not supported. If you were meant to do this, there would be an API for it.
Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
-NASA in 1965 |
KDE Developer
|
Please read:
http://blog.martin-graesslin.com/blog/2 ... corations/ and http://blog.martin-graesslin.com/blog/2 ... corations/ and http://blog.martin-graesslin.com/blog/2 ... corations/ and http://blog.martin-graesslin.com/blog/2 ... corations/ Canonical btw dropped their idea about client side window decorations. It's not the task of the app to define the buttons. If you want to have a unified look between deco and app, just use the system defaults and you are done. My blog posts above should illustrate why what you tried to achieve is completely flawn and that it worked at all is pure luck. |
Registered users: abc72656, Bing [Bot], daret, Google [Bot], lockheed, Sogou [Bot], Yahoo [Bot]