Onboard's window class and name are vague, and window title, ID and role are blank

Hi, thanks for the bug report.

Correct me if I'm wrong, but I seems window title and window name are the same thing. Also the only window ID I know of is a 32bit integer. This would leave

window class: 'onboard' (or 'Accessibility'?)
window name: 'Onboard'
window role: 'On-Screen Keyboard' (or simply 'Keyboard')

for identification.

xprop on onboard gives me:
WM_CLASS(STRING) = "onboard", "Onboard"
WM_NAME(STRING) = "Onboard"

So the only thing missing may be the window role. I've looked into this, but so far I'm a bit reluctant to add this. Onboard saves multiple window positions and sizes itself and doesn't benefit a lot from session management. Adding a window role for session management seems to be superfluous. Again, correct me if you think we should do it anyway.

What version of onboard were you using in your testing? The current 0.97 has title and class set, older versions should have had at least the title set properly.

Greetings,

Thank you for responding to my bug report.

I'm afraid, being a lay end-user, I can't speak to whether window title and window name are one and the same. Except to say that Compiz definitely has separate entries for them within its window selection dialogue.

I've just double checked, using Compiz's window selection tool, and all of the various window attributes (if that's the correct word) are detected as I reported initially. Whether this is an omission in OnBoard or bug in Compiz's window selection tool I can't say. If there's any way to determine this on my end, do tell.

As it happens, I'm running OnBoard 0.96.1-0ubuntu0.1 and Compiz 1:0.9.6+bzr20110929-0ubuntu6.1 under an up-to-date install of Ubuntu 11.10 (x86-64). Apologies, I should have included this information in the original bug report (I've amended the original report to reflect these version numbers). So not the latest version of OnBoard then, I shall poke around and see if there's a more up-to-date version hidden away on launchpad's many, many PPAs.

If there's anything I can do at this end to help diagnose this bug, or close it proper, do let me know.

P.S.: To be honest, I'm not really planning to use any heavy Compiz window management for OnBoard. I just want to use the window rules plug-in to disable/hide the close window titlebar button; I much prefer to minimise to tray and occasionally find myself accidentally closing OnBoard.

So I learned name and title are not the same thing. The window name is actually the first element of the WM_CLASS property, title would be WM_NAME (xprop lists the window properties).

Onboard 0.97 has the following:
window class: 'Onboard'
window name: 'onboard'
window title: 'Onboard'
window ID: some unpredictable integer

I've looked at the window rules plugin in ccsm and it does appear to show class and name properly, but fails to get title and ID. I'm not sure why that is, from the source it looks like it should work. Anyway, the information is there (xprop) and class/name may already be sufficient to identify Onboard.

What I'm wondering is, why do you need to remove the close button? Onboard from version 0.96 has no window decoration by default. Do you have a special reason to keep the title bar enabled? Not that there's anything wrong with it, I'm just curious.

Our stable PPA is here
https://launchpad.net/~onboard/+archive/stable
but 0.97 isn't in there yet, though it probably will be soon.

Thank you kindly for going to the trouble of double checking this at your end. That was very courteous of you. Also, thank you for referring me to the official OnBoard PPA, I shall add it to my (extensive) list of third-party PPA later.

To answer your question, the reason I resort to using Compiz for window management is two fold.

1) For consistencies sake.

2) Because until 5 minutes ago, I wasn't aware that window management (moving and minimising) were possible (via buttons within the virtual keyboard) in an undecorated OnBoard. ;-)

Now that I know 2) I'll probably stick with an undecorated OnBoard. Although it would still be nice to have the option to use Compiz in the way described above. You know, for the sake of consistency.

I'll mark this bug as invalid with respect to OnBoard and I may rephrase (else file a separate bug report) it to highlight the above mentioned anomalous 'attribute grabbing' behaviour of Compiz, as well as refile the bug against Compiz. Alas, I doubt it'll be a high priority.

I have to resurrect this bug. It's not true that Onboard has the right value for WM_CLASS at all times. It does so when it's launched from the project directory, but not necessarily when run from anywhere else.

Fixed in trunk.

You can find Onboard 0.97.1, that contains the fix to this problem in our Stable PPA for oneiric, precise and quantal:
https://launchpad.net/~onboard/+archive/stable