From kde-core-devel Tue Aug 08 14:52:43 2006 From: Simon Hausmann Date: Tue, 08 Aug 2006 14:52:43 +0000 To: kde-core-devel Subject: Re: Trolltech <-> KDE contact point for critical issues Message-Id: <200608081652.47036.hausmann () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=115504878611169 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1208179.7ZqWQTCXbO" --nextPart1208179.7ZqWQTCXbO Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 t= he > 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 scre= en > reader to enquire the user interface of applications. Making KDE accessib= le > 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 replaci= ng > 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) rath= er > 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 allocat= ed > 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-ti= me=20 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 backgrou= nd > 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 thinki= ng=20 of? > All widget styles: > - None of widgets shipped with Qt currently work with dark background col= or > 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=20 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 informatio= n=20 on how to reproduce this and how you encountered it? > QFontDialog: > - We need the ability to make relative changes to font settings, e.g. "Fo= nt > Family: Default, Font Style: Bold, Size: 120% (11)". (Usability, > Accessibility) Is this something specific to the actual user interface of the font dialog = or=20 are you referring to a potential QFont feature of being able to specify fon= t=20 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= =20 about the changes to the dialog you were thinking of? Also why is this=20 critical to the release of KDE 4.0? Can't this also be added later? After a= ll=20 it appears to affect only the implementation of the dialog, not the public= =20 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 cus= tom=20 delegate and a flag in the model. Please feel free to submit this as a wish to qt-bugs, along with an use-cas= e.=20 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 keyboar= d,=20 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 differe= nt > 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 whic= h=20 applications for example do you see this behavior? Other than that it doesn't sound like a totally unreasonable idea and shoul= d=20 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= =20 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 perhap= s=20 send me a ui file that shows it? Simon & Benjamin --nextPart1208179.7ZqWQTCXbO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBE2KU/WXvMThJCpvIRAraFAKC6M8dMJnsX3D0Pvtk5Zaoi6Fvu8ACfda3o mPcRQisPH4KE6R2YbPQf6Ps= =GjFC -----END PGP SIGNATURE----- --nextPart1208179.7ZqWQTCXbO--