Re: Review Request: KMimeTypeFactory: Fix handling of mixed case fast patterns

Re: tags

On Wednesday 30 June 2010 22:05:10 David Faure wrote:
> SVN commit 1144780 by dfaure:
> 
> Here comes kdesupport-for-4.5, based on the latest stable tag for each of
> its components. Just a problem with polkit-qt (tags/polkit-qt/0.9.3
> doesn't exist, I emailed Dario), and phonon not here yet (I'll import it
> from git)

I already mailed David but just so everyone knows: this will be settled for 
the weekend (polkit-qt stuff at least).

> CCMAIL: kde-core-devel <at> kde.org
> 
> 
>  A             kdesupport-for-4.5 (directory)
>  A             kdesupport-for-4.5/VERSIONS
>  A             kdesupport-for-4.5/akonadi (directory)
>  A             kdesupport-for-4.5/attica (directory)
>  A             kdesupport-for-4.5/automoc4 (directory)
>  A             kdesupport-for-4.5/oxygen-icons (directory)
>  A             kdesupport-for-4.5/polkit-qt (directory)
>  A             kdesupport-for-4.5/polkit-qt-1 (directory)
>  A             kdesupport-for-4.5/qca (directory)
>  A             kdesupport-for-4.5/qimageblitz (directory)
>  A             kdesupport-for-4.5/soprano (directory)
>  A             kdesupport-for-4.5/strigi (directory)
>  A             kdesupport-for-4.5/taglib (directory)

--

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B

Re: [Kde-accessibility] focus tracking

Hi Jos,

> Ok, thanks all for the responses. A couple of questions if you don't mind,
> to check I understand this properly:
> - AT-SPI does not have a way of tracking focus for magnification purposes?

AT-SPI does have a way to track focus, among a lot of other functionality.

To combine focus tracking with magnification, one needs an application that 
uses an accessibility API such as AT-SPI and that then informs the magnifier 
about the screen area that ought to be highlighted. In the Gnome accessibility 
world this is done by a full-featured screen reader named Orca.

The stable version of AT-SPI is CORBA-based and supported by Gtk, Firefox, 
OO.o and by the Java Accessibility bridge. The current development version
AT-SPI2 is D-Bus-based and aims to make it very easy to support it from Qt 
applications (including the ones from KDE). Proof-of-concept code for Qt 
support already exists, but it needs serious work to be fully functional. Many 
Qt applications will need improved support for the Qt Accessibility bridge 
before focus tracking and other more advanced accessibility features work 
without flaw. (A typical problem will be custom widgets and probably 
Plasmoids.)

> - So Gnome-Mag has developed an API for this, but it's currently CORBA based
> and thus needs changing - apps need to support this API for magnification to
> properly work

The magnification API needs to be supported both by the accessibility aid 
(Orca) and by the magnifier (gnome-mag, kwin, gnome-shell or Compiz).
It would make a lot of sense to use a common API for all these magnifiers.
I see no technical reason against such a cooperation, and I know of no
other reason hindering it, so I expect that when friendly asked, there would 
be interest from all of the various teams to cooperate on this.

For the KDE Plasma Desktop default configuration, it might be possible to 
automatically start a very small tool for simple focus-tracking that disables 
itself once Orca is started. It this tool supports the same magnification API 
as Orca, gnome-mag, kwin, gnome-shell and Compiz, then we get a maximum of 
interoperability.

Olaf

Re: [Kde-accessibility] focus tracking

On Friday 02 July 2010 09:17:48 Piñeiro wrote:
> From: Jos Poortvliet <jospoortvliet <at> gmail.com>
> 
> >> In terms of "complete all this":  GS-mag supports another route for 
> >> controlling its settings, namely, GConf.  Furthermore, that part of the 
> >> code is in the process of being converted to GSettings [1].  The idea is 
> >> that by changing a user's session wide magnification preferences via 
> >> GSettings live-updates the magnifier's settings.  A concrete example is 
> >> setting the mouse tracking preference in Orca's magnifier when running 
> >> gs-mag.  In this case, Orca uses GConf to change the user's magnifier 
> >> mouse tracking desktop preferences.  GS-mag "hears" that change and 
> >> responds appropriately.
> > 
> > Ok, thanks all for the responses. A couple of questions if you don't mind, to check I understand this properly:
> > - AT-SPI does not have a way of tracking focus for magnification purposes?
> 
> AT-SPI provides a way of tracking focus in general. Not just for
> magnification purposes.
> 
> > - So Gnome-Mag has developed an API for this, but it's currently CORBA based and thus needs changing
> 
> gnome-mag has developed an API so other apps can use it. Yes, the
> current one is CORBA based, work in progress to migrate to DBUS. [1]

So 'other apps', does that mean Orca and other screenreaders, or does that mean EVERY application needs to
support it for the magnification to be able to follow focus?!?

Or can any magnification tool follow focus in any app which supports AT-SPI properly? Sorry, I don't really
know how all this is chained together....

> > - apps need to support this API for magnification to properly work
> 
> This is the reason it is being implemented in Orca, as it one of the
> basic a11y tools in gnome, an it is already "talking" with AT-SPI.
> 
> > So, if this is the case, I wonder what the plans are? At the very least having a standard developed for apps
based on D-BUS which can be implemented by eg OO.o and Qt and KDE apps too, would be nice. I wonder if it's
possible to make this part of AT-SPI somehow?
> 
> I don't understand this paragraph sorry. What it is required to be
> implemented by eg OO.o? What feature are you missing?

I think I'm misunderstanding something here...

I'm mostly concerned with getting the magnification (either in Compiz, KWin, Gnome-magnifier or KMag) to
follow focus - so does that need changes in applications or not? Is AT-SPI support enough?

grtz and thanks,
Jos

> BR
> 
> [1] http://live.gnome.org/Accessibility/GNOME3#gnome-mag_.28port_to_D-Bus.29
> 
> ===
> API (apinheiro <at> igalia.com)
> 

Re: [Kde-accessibility] focus tracking

Jos Poortvliet wrote:
> On Friday 02 July 2010 09:17:48 Piñeiro wrote:
>> From: Jos Poortvliet <jospoortvliet <at> gmail.com>
>> 
>> >> In terms of "complete all this":  GS-mag supports another route for
>> >> controlling its settings, namely, GConf.  Furthermore, that part of
>> >> the
>> >> code is in the process of being converted to GSettings [1].  The idea
>> >> is that by changing a user's session wide magnification preferences
>> >> via
>> >> GSettings live-updates the magnifier's settings.  A concrete example
>> >> is setting the mouse tracking preference in Orca's magnifier when
>> >> running
>> >> gs-mag.  In this case, Orca uses GConf to change the user's magnifier
>> >> mouse tracking desktop preferences.  GS-mag "hears" that change and
>> >> responds appropriately.
>> > 
>> > Ok, thanks all for the responses. A couple of questions if you don't
>> > mind, to check I understand this properly: - AT-SPI does not have a way
>> > of tracking focus for magnification purposes?
>> 
>> AT-SPI provides a way of tracking focus in general. Not just for
>> magnification purposes.
>> 
>> > - So Gnome-Mag has developed an API for this, but it's currently CORBA
>> > based and thus needs changing
>> 
>> gnome-mag has developed an API so other apps can use it. Yes, the
>> current one is CORBA based, work in progress to migrate to DBUS. [1]
> 
> So 'other apps', does that mean Orca and other screenreaders, or does that
> mean EVERY application needs to support it for the magnification to be
> able to follow focus?!?
> 
> Or can any magnification tool follow focus in any app which supports
> AT-SPI properly? Sorry, I don't really know how all this is chained
> together....
> 
>> > - apps need to support this API for magnification to properly work
>> 
>> This is the reason it is being implemented in Orca, as it one of the
>> basic a11y tools in gnome, an it is already "talking" with AT-SPI.
>> 
>> > So, if this is the case, I wonder what the plans are? At the very least
>> > having a standard developed for apps based on D-BUS which can be
>> > implemented by eg OO.o and Qt and KDE apps too, would be nice. I wonder
>> > if it's possible to make this part of AT-SPI somehow?
>> 
>> I don't understand this paragraph sorry. What it is required to be
>> implemented by eg OO.o? What feature are you missing?
> 
> I think I'm misunderstanding something here...
> 
> I'm mostly concerned with getting the magnification (either in Compiz,
> KWin, Gnome-magnifier or KMag) to follow focus - so does that need changes
> in applications or not? Is AT-SPI support enough?

and my question;

What code in Orca(?) can someone look at to understand how such zoom-follows-
keyboard focus-tracking functionality was done?

Olaf =?iso-8859-1?q?Schmidt-Wischh=F6fer?= wrote:
> For the KDE Plasma Desktop default configuration, it might be possible to
> automatically start a very small tool for simple focus-tracking that
> disables itself once Orca is started.

... that sounds like the way to go for me at least for now.

What should a distribution for better accessibility support in KDE 4

Hi,

I'd like to discuss what a KDE distribution should do in terms of packaging and integration for giving a
better accessibility experience to the users.

We currently miss a lot of crucial parts (even things like speechd avoiding kttsd to be built). One of our
internship students will aim at improving the current state.

Is there any guide, howto, TODO list, etc. that you can point me? There are a lot of concepts that I'm not
familiar at all so It's very easy for me to get lost. We're currently using KDE 4.4 and will switch to >= 4.5 in
our next major release.

Thanks
Regards

Ozan Caglayan
Pardus Linux
--
http://www.pardus.org.tr/eng

Review Request: Change in KFileItemDelegate's renaming / editor behavior for directories

Moving the proxy model test suite to kdesupport?

Hi,

The test suite for proxy models is growing inside 
kdelibs/kdeui/tests/proxymodeltestsuite.

The unit tests for kselectionproxymodel and kdescendantsproxymodel depend on 
the test suite library.

Last week I added a ModelEventLogger which is useful for debugging model or 
proxy using applications, but as it is hidden inside kdeui/tests, the only 
way to use the logger is to hack the CMakeLists to find the library and 
headers.

kde-devel <at> bishop:~/kde/src/KDE/kdepim/kmail{master}$ git diff .
diff --git a/kmail/CMakeLists.txt b/kmail/CMakeLists.txt
index ee2fbd1..c1d89a1 100644
--- a/kmail/CMakeLists.txt
+++ b/kmail/CMakeLists.txt
 <at>  <at>  -33,6 +33,7  <at>  <at>  include_directories(
   ${CMAKE_CURRENT_BINARY_DIR}/../ontologies
   ${NEPOMUK_INCLUDES}
   ${SOPRANO_INCLUDE_DIR}
+  /home/kde-devel/kde/src/KDE/kdelibs/kdeui/tests/proxymodeltestsuite
  )

 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${KDE4_ENABLE_EXCEPTIONS}")
 <at>  <at>  -252,6 +253,7  <at>  <at>  target_link_libraries(kmailprivate
   ${QT_QTWEBKIT_LIBRARY}
   ${NEPOMUK_LIBRARIES}
   ${NEPOMUK_QUERY_LIBRARIES}
+  /home/kde-devel/kde/build/KDE/kdelibs/lib/libproxymodeltestsuite.so
 )

 set_target_properties(kmailprivate
diff --git a/kmail/kmkernel.cpp b/kmail/kmkernel.cpp
index 4abf35a..b828e00 100644
--- a/kmail/kmkernel.cpp
+++ b/kmail/kmkernel.cpp
 <at>  <at>  -108,6 +108,8  <at>  <at>  using KMail::MailServiceImpl;

 #include "searchdescriptionattribute.h"

+#include "modeleventlogger.h"
+
 static KMKernel * mySelf = 0;
 static bool s_askingToGoOnline = false;

 <at>  <at>  -233,6 +235,8  <at>  <at>  KMKernel::KMKernel (QObject *parent, const char *name) :
   mEntityTreeModel->setIncludeUnsubscribed( false );
   mEntityTreeModel->setItemPopulationStrategy( 
Akonadi::EntityTreeModel::LazyPopulation );

+  new ModelEventLogger(mEntityTreeModel, this);
+
   mCollectionModel = new Akonadi::EntityMimeTypeFilterModel( this );
   mCollectionModel->setSourceModel( mEntityTreeModel );
   mCollectionModel->addMimeTypeInclusionFilter( 
Akonadi::Collection::mimeType() );

I was thinking of moving the already self-contained proxymodeltestsuite 
library into kdesupport.

The library would be a build-time dependency for kdelibs and is needed only 
when tests are being built. 

The disadvantage is that people wishing to build kdelibs tests would need to 
build this external dependency. The advantage is that people hitting an 
assert in kmail etc would just need to install the library from a well known 
location, include the header and attach the logger. The library would not 
need to be packaged or versioned as far as I'm concerned. The 
proxymodeltestsuite library depends on Qt and my Grantlee templating system.

Any thoughts?

Steve.

PS, for more on this, attend my talk in room 1 this afternoon at Akademy :).

Re: Moving the proxy model test suite to kdesupport?

On 03.07.10 15:13:08, Stephen Kelly wrote:
> Hi,
> 
> The test suite for proxy models is growing inside 
> kdelibs/kdeui/tests/proxymodeltestsuite.
> 
> The unit tests for kselectionproxymodel and kdescendantsproxymodel depend on 
> the test suite library.
> 
> Last week I added a ModelEventLogger which is useful for debugging model or 
> proxy using applications, but as it is hidden inside kdeui/tests, the only 
> way to use the logger is to hack the CMakeLists to find the library and 
> headers.
> 
> I was thinking of moving the already self-contained proxymodeltestsuite 
> library into kdesupport.

Why not make it an installed part of kdelibs?

> The library would be a build-time dependency for kdelibs and is needed only 
> when tests are being built. 

Are you planning to maintain it and do regular releases (at least for
new KDE releases)?

> The disadvantage is that people wishing to build kdelibs tests would need to 
> build this external dependency. The advantage is that people hitting an 
> assert in kmail etc would just need to install the library from a well known 
> location, include the header and attach the logger. The library would not 
> need to be packaged or versioned as far as I'm concerned.

It has to, if it should be a proper library and a build dependency, that
is it has to have a version and a soversion so that if you break BC in
it you can let users know about this by changing the soversion. Same
goes for doing releases, you'll have to so distro's have something to
package.

> The proxymodeltestsuite library depends on Qt and my Grantlee
> templating system.

So actually there'd be 2 new dependencies, the test (why the hell do I
need a test library to build kdelibs?) and that templating system (which
is not available as package at least in debian currently, though thats
not an immediate problem as there's enough time until kde4.6).

Andreas

--

-- 
You will be singled out for promotion in your work.

Re: Review Request: Change in KFileItemDelegate's renaming / editor behavior for directories