The current Oxygen style and window decoration for KDE4 can be found in SVN under http://websvn.kde.org/trunk/KDE/kdebase/runtime/kstyles/oxygen and http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/clients/oxygen
We no long accept bugs here.
Please use bugs.kde.org under Oxygen
We strongly suggest that you come to #oxygen on irc first to discuss the bug.
DO NOT EDIT SECTIONS WITHOUT PERMISSION.
Incoming New Bugs
- docked dockers might need a nicer frame
- Mouse handling in menus: When the mouse pointer goes below the visible selection decoration of the last item in a menu, the item does not get deselected but a click or release event will not trigger the item. The item does not get deselected until the pointer leaves the menu. The correct behavior would be to deselect the item once the pointer leaves its selection decoration and enters the bezel, as e.g. in similar KDE 3 styles (e.g. Domino). Or to trigger the item despite the pointer being outside its selection decoration, given that it is still shown as selected. As it stands, you can go to the last item in a menu, not notice that you overshoot it because it doesn't go deselected, and your click/release will do nothing, which is jarring.
- In (double) spinboxes the font is positioned one pixel too high. Lowering it one makes it baseline-aligned with labels in front. Unfortunately not possible. We want them to be the same size as editable comboboxes and lineedits and buttons so those line up. The 1px wrong placement of text is a qt weirdness that gives visual bugs when we try to work around it
- Centered group titles pose several problems. Left align group titles instead. See Discussion for more details.
- KMenu::addTitle() adds a widget action to display a title in a popup menu. This is not specific to Oxygen, but the widget it creates could use some polishing. (to see this, right click any icon in the system tray)not a style bug report to kmenu maintainer - and don't ever add things to "accepted bugs" below again - this went unnoticed because of that
- "flat" buttons drawn same as regular buttons we may not want flat buttons - considering
- With everything around it styled nicely, having just a plain colour for selected items, e.g. in the speedbar, looks a bit disconnect from the rest of the GUI. Thus any effect that polishes this bit is welcome, such as a frame or even translucency.unfortunately that part of qt is not stylable
- progress bars still not like the artist wants priority
- should repaint on globalChange signal (how?) releasable
- this seems to only be a problem for the colors kcm, may not even be a style bug
- headers in tables
- not really done - but the plain color look is acceptable for now releasable
- Rounded corners of floatables (windows,menus dockers) should be done with alpha
- Windeco should use alpha for corners (need kwin improvements?)
- make flat more homogeneous in look with normal (very short regular?)
This is helpful checklist to use when looking for bugs in a style:
- reverse layout
- high-contrast color schemes (i.e. all fg/bg black or white)
- reverse-light/dark color schemes (e.g. light-on-dark buttons with dark-on-light views, etc.)
- QA color scheme
- sliders, scrollbars, progress - in all orientations and good cross section of values
- content padding works for all controls, does not break sizeToContents functionality
- controls align nicely and controls that should be the same size, are
- no obvious glitches in uidemo
Content is available under Creative Commons License SA 4.0
unless otherwise noted.