Trolltech <-> KDE contact point for critical issues

[Simon Hausmann]

On Friday 28 July 2006 18:27, Olaf Jan Schmidt wrote:
> Hi!
>
> In KDE's Human-Computer-Interface (HCI) working group, we have collected a
> number of items that need to be changed in Qt4 for our plans to improve the
> usability, accessibility and artwork of KDE4.
>
> Some of them (e.g. all of the accessibility issues) have already been
> mentioned to various Qt developers during the development of Qt 4.0 and
> 4.1., but so far we have not managed to convince Trolltech that all of
> these are important for KDE.
>
> We are therefor summarizing the points in an "official" list that has the
> joint support from members of the various HCI-related teams in KDE
> (accessibility, usability, artwork, documentation, internationalization).
>
> The list contains all requirements that we have managed to refine enough to
> request them at this time. We expect to develop others as the time goes on
> and will then contact Trolltech again about having them implemented in
> future releases.
>
> The items can fit into roughly three areas.
>
>
> 1. AT-SPI:
>
> - In short term-perspective, an official statement of planned AT-SPI
> support in Qt and a rough schedule for it are very important. Because of
> the politics in the Free Standards Group, we need a reply from Trolltech on
> this issue as soon as possible.
>
> - The AT-SPI protocol allows assistive technologies such as the Orca screen
> reader to enquire the user interface of applications. Making KDE accessible
> to blind users is a key priority to our work on KDE4. This of course
> requires educating developers how to use the Qt Accessibility Framework in
> custom widgets, which means that we need proper documentation and testing
> tools at least by aKademy.
>
> - The implementation of AT-SPI is currently uses a number of GNOME
> dependencies, e.g. bonobo and ORBit2. IBM already started work on replacing
> these dependencies with D-Bus, but they stopped the work after Trolltech
> released Qt 4.0 and Qt 4.1 without the AT-SPI support promised in the
> release announcement of the Qt 4.0 Technology Preview.
>
> - The Free Standards Group is currently discussing whether to standardize
> the current AT-SPI implementation (including the GNOME dependencies) rather
> than waiting for a possible D-Bus version that no one is publically seen to
> be working on. We plan to prevent this, because it would make it much more
> difficult to later implement support for it in Qt.
>
> - We know that Harald Fernengel has been working on a D-Bus based version
> of AT-SPI during the last two years, and incidentally he sent a first
> snapshot of the code to members of the KDE accessibility team today. This
> work is extremely helpful for supporting our position in the FSG. What is
> also needed is a quotable statement confirming that Trolltech has allocated
> resources for D-Bus based version of AT-SPI. With it, we have good chances
> to convince the Free Standards Group not to standardize the GNOME
> dependencies of current version of AT-SPI.

Harald is allocated to spend at least a month on accessibility work half-time 
when he returns from vacation. Is that good enough for a statement?

> 2. We are currently working on a detailed concept to replace the color,
> font and icon settings in KDE4. The document is not finalized yet, but
> during our work on it so far, we found various Qt-related issues.
>
> QPalette:
> - The algorithm computing the values for "Light, Midlight, Dark, Mid,
> Shadow" and for the disabled color group does not work with dark background
> color schemes. This is a problem both for artists designing color schemes
> and for users with visual impairment, who might be unable to read text on
> light backgrounds. (Artwork, Accessibility)
>
> - In KDE4, we are planning to change the color roles defined in KDE's
> color schemes. Some of the new color roles need to be passed on to the
> widget styles. This should be possible either by extending QPalette or by
> subclassing it in KDE. (Artwork, Accessibility)

Can you provide us with some more details of what color roles you're thinking 
of?

> All widget styles:
> - None of widgets shipped with Qt currently work with dark background color
> schemes. This might be caused by bugs in QPalette (see above).

With this and the first item (QPalette) are you referring to the fact that Qt 
4 applications currently do not pick up the color scheme set up in KDE 3?

If the first item is different can you provide us with some more information 
on how to reproduce this and how you encountered it?

> QFontDialog:
> - We need the ability to make relative changes to font settings, e.g. "Font
> Family: Default, Font Style: Bold, Size: 120% (11)". (Usability,
> Accessibility)

Is this something specific to the actual user interface of the font dialog or 
are you referring to a potential QFont feature of being able to specify font 
sizes relative to for example the main application font?

> QColorDialog and KColorChooser:
> - We have worked out a suggestion for a new color selection dialog in KDE4
> that combines the improved user interface of the Qt color dialog with the
> features of the KDE3 color dialog. It should be evaluated whether the
> implementation of it makes more sense in Qt or in kdelibs (Usability)

This sounds like a good idea. Can you provide us with some more information 
about the changes to the dialog you were thinking of? Also why is this 
critical to the release of KDE 4.0? Can't this also be added later? After all 
it appears to affect only the implementation of the dialog, not the public 
API.

> QCombobox:
> - Add the ability to have separators within a combobox (or ensure that it
> is easy to add those in a KDE subclass). (Usability)

We can confirm that this is possible to do since Qt 4.0 by the use of a custom 
delegate and a flag in the model.

Please feel free to submit this as a wish to qt-bugs, along with an use-case. 
Also how critical is this for KDE 4.0?

> 3. The third important topic is full accessibility of the user interface
> via keyboard.
>
> All widgets:
> - Make sure all widgets can be completely used via keyboard.

Do you have a list of Qt widgets that are not completely usable via keyboard, 
apart from the problems listed below?

> QToolButton:
> - The toolbars should be part of the normal tab order as in Gtk+. Moving
> the focus within a toolbar can then done with arrow keys, selection of a
> focused tool button with space. If the operating system defines a different
> method to set the keyboard focus to tool buttons (like in Mac OS X), then
> this should additionally be supported.

We were actually unable to reproduce this with Gtk+ or on Mac OS X. In which 
applications for example do you see this behavior?

Other than that it doesn't sound like a totally unreasonable idea and should 
probably be configurable through a style hint.

> QToolBox:
> - It would be great if keyboard accelerators in QToolBox headings set the
> keyboard focus to the first item within the toolbox page. (They appear not
> to work at all in Qt3.)

That sounds like a good idea. We've created a task for that (125178 in the 
public bug tracker)

> QRadioButton and QCheckbox:
> - If the accelerator of a radio button of check box is pressed, then the
> keyboard focus should move as well.

This works fine here using Qt 4.2, how can I reproduce this? Can you perhaps 
send me a ui file that shows it?


Simon & Benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060808/8c67ec01/attachment.sig>