Description:
I am not sure if this applies to any degree under Windows/OSX but under Linux/X, GUI windows that are drawn may have role and class properties assigned to them to help identify the windows to the window manager.
For example - in Firefox and variants the main browser window has the role "browser" but the preferences modal window that appears from Edit ยป Preferences has the role "Preferences".
It is common for Linux window managers to have mechanisms that allow the user to state preferences/rules for windows as they are created and the windows are selected based upon their classes/roles. For example, I have a rule in place that selects windows belonging to the Firefox application of role "browser" and maximises them vertically when they are created. This does not affect any other kind of dialog that Firefox opens however.
MySQL Workbench creates almost all of its windows with the same class and an empty role, which makes it very difficult to use this functionality within my window manager to target Workbench. It is impossible for the window manager to differentiate between the different Workbench windows that are created.
How to repeat:
Under Linux/X-Windows, to discover the properties of any given window you may use the command:
xprop | grep -E '^((WM_CLASS)|(WM_WINDOW_ROLE))'
Your mouse pointer will change to a selection crosshair. Click the window for whose properties you wish to identify and the information will be output to the command-line (where the role is blank, nothing will be emitted).
---
Your window manager may also have a GUI mechanism for doing this, such as 'Configure Window Behaviour' within KDE4. There is a button named "detect window properties" that duplicates xprop's functionality in a friendly GUI mechanism.
Suggested fix:
Documentation on window classes and roles seems somewhat patchy but from what I can find/deduce:
Class is stored within the X property "WM_CLASS" and is two strings. The first should identify the application that opened the window (so it should be identical between all windows that Workbench opens). Currently it is set to the name of the executable: "mysql-workbench-bin" for every window that WB creates. I see no reason to change this.
The second string can be arbitrary and should be used to identify the specific window. Currently the second part of the class string for every window that WB creates is set to "Mysql-workbench-bin", which is not particularly helpful. I would suggest using this string to describe the exact window that is opened, such as "Loading splash screen" or "Main window" or "Export SQL CREATE script dialog".
The window role is stored within the X property "WM_WINDOW_ROLE" and is a single arbitrary string. Currently every window that WB creates has a blank/unset role, which is not particularly helpful. I would suggest setting roles based on the general purpose of the window opened, such as "splash" or "main" or "dialog".
