Still presents in KDE 4.6.0

I fixed this bug: https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/d43015c14ec4d7426283db1dfcfb45be311a87f6

Created attachment 62578 [details]
Screenshot which probably after first commiting to resolve this bug

Think that's bad idea to use QHeaderView::ResizeToContents, because "The size cannot be changed by the user or programmatically". It's wrong deny user from change column width. As I understand, icons() is just only application name column, so for me it'll be as in attached screenshot. It's bad.

Ok. Lets thinking what user want to see.
1. User should understand the application in the row.
2. User should understand current visibility and what visibility he can choose.
3. User should see the key bindings.

The problems:
1. The name length of many apps is small. But for system KDE apps the name length may be long (as I can see) and we don't know how long it will be (depend on i18n)
2. The right part of text shown in the button is truncated in normal mode, and the middle part is truncated when choose the value. For me it's bad because there are no difference in 2 values. (in next screenshot)
3. By default, I don't have key bindings. But if I have at least one key bindings I should know what it is for and what the binding is.

I was thinking a lot today about this problem. First, I think that we should set the width of the first row (where apps) to show the most of apps (maybe 80% or so). But I don't understand the level of width from what we should truncate the text. Then I just think about the main problems and see the list described above. And what I have thunk:

Variation A:
1. We should statically set width of the first column to the value, when the most of apps will be shown at whole.
2. Then dynamically set the width of the second column (depend on the localized text lentgh).
3. And dynamically set the width of the last column. 
The problem may occur, when the horizontal scrool bar added and the third column won't be shown. When user scrool right to change key binding he may not see the application name.

Variant B:
Change the columns order to be: visibility, apps name, key binding.
1. Dynamically set visibility column width depending on its content (the longerst of 3 values)
2. Set apps name column width as (100%_of_visible_field - visibility_width - 50px)
50 px is for the third column. In that case the horizontal scrool always would be presented but 50 px help the user understand that in right something is hide.
3. Dynamically set key bindings column width depending on its content (the longest of any key binings row) (should not be greater then 100%-apps_name_width by default)

I like the Variant B because:
1. The whole info is visible about visibility and key bindings and the most important part of app name (probably the whole text).
2. User understand about something at the right (it will be key bindings) and user always see apps name when edit visibility or key bindings.
3. Visibility - the important property is shown at whole by default.
4. The almost application name is shown.
5. User can manually change columns width.

What Aaron think about this?

Created attachment 62579 [details]
There no difference between 2 values in visibility columns whan try to change

I read your comments and agree with you that my commit doesn't fix the bug properly. Currently I'm working on a solution but sadly the Qt classes do not provide very convenient methods for resizing the columns. Maybe you want to have a look at the patch I attach and comment it (I played around with the functions Qt provides, maybe it's the right track - it's similar to your solution A). I added tooltips which can show the name of the application if it is shortened. Solution B seems pretty good but sadly there's no way to set the column size in percent.
Thanks for thinking about this.

Created attachment 62633 [details]
Proposed patch

Created attachment 62720 [details]
Screenshot 1 of Variant B

Created attachment 62721 [details]
Screenshot 2 of Variant B

I attached 2 screenshots of Variant B I'm talking about. Think this is the best way. I explain below, how it could be implemented. I don't have development environment, so I couldn't to make and test myself patch, so I hope to Jan Gerrit Marker.

Variant B is more sophistigated, but more better than others.
Implementation:
1. Change columns (visibility, appname, key bindings). Check if other code works properly with this changes and change if needed.
2. a) For the first column (visibility) use QHeaderView::ResizeToContents. Check the test cases 2, 4, 5.
   b) In case the a) has incorrect behavior, should use QWidget::fontMetrics()/QFontMetrics to understand the longest of 3 values. Use QHeaderView::Interactive and use QHeaderView::resizeSection to resize the section to appropriate value.
3. a) Create new method with the contents: resize the second column (appname) to be  m_autoHideUi.icons->header()->offset() - m_autoHideUi.icons->header()->sectionSize(0) - 50px.
   b) Check the test case 1 - how the third column is shown in default state. I'm not sure if absolute value (50px) is good idea because think in different screen resolution real visible width in default view will be different.
   c) If test case 1 will fail then should be think how to use the relative value.
4. For the third column (keybindings) use QHeaderView::ResizeToContents and check the test cases 2, 3.

Test cases (must be tested):
1. Change screen resolution.
  a) Open the systemtray widget settings and don't close. Then change resolution. Check it.
  b) Look the systemtray widget settings in one resolution, test it, then close. Change resolution, then open systemtray widget settings, look and test it again.
2. Change systemtray widget settings window width and look how it will be. Test the minimum width case and long width case.
3. And more key bindings (the maximum and the longest that possible) and test how column will be streched.
4. Click on visibility and choose every of 3 values. Check if the text is showed properly.
5. Change l10n KDE language and see if the text in all 4 testcases above is correct.

All test cases should be applied before finish patching.

Of course test case 2 to be worked appropriate behavior (slot) should be implemented.

what happend to this patch? please submit it to https://git.reviewboard.kde.org or else it will get lost here.

the behaviour in master is just fine. no need for increasingly odd layouts in that window.