Implementing a11y interface in the widget itself may require a big change in
atk
as API pointed out. So maybe we can move the gail code into gtk first and do
the
further integration later.
Li
On Fri, Feb 18, 2011 at 1:27 AM, Matthias Clasen
wrote:
> On Thu, Feb 17, 2011 at 12:23 PM, Piñeiro wro
>
> > I haven't particularly checked.
> > But if the two are incompatible, they should really take measures to
> > prevent running them in parallel, like taking a well-known busname...
>
> Well, Mike Gorse or Li Yuan would know the details better. Not sure if
> it is really incompatible, or if it s
On Thu, Feb 17, 2011 at 11:13 PM, Matthias Clasen wrote:
> On Thu, Feb 17, 2011 at 10:03 AM, Piñeiro wrote:
>
> >
> > Although move the gail implementation to gtk has his advantages, why
> > this would be better that just fix them directly on gail? One of the
> > big problems here is the lack of
From: Matthias Clasen
> On Thu, Feb 17, 2011 at 12:23 PM, Piñeiro wrote:
>
>>
>> So probably we could study that. Anyway, in the same way, right now I
>> don't see how this would better that the option proposed by Matthias.
>
> Oh, I think having the option of implementing the a11y interface i
On Thu, Feb 17, 2011 at 12:23 PM, Piñeiro wrote:
>
> So probably we could study that. Anyway, in the same way, right now I
> don't see how this would better that the option proposed by Matthias.
Oh, I think having the option of implementing the a11y interface in
the widget itself would be great
Heya,
Given that the "accessibility" gave the impression that it controlled
all the accessibility settings, I renamed the key in master of
gsettings-desktop-schemas to "toolkit-accessibility".
I also fixed at-spi2-atk to use this new key (so that
gnome-settings-daemon knows to which key to check
From: Dan Winship
> On 02/17/2011 11:22 AM, Piñeiro wrote:
>> You are proposing to forget this "proxy" approach on the accessibility
>> support. As far as I understand you are proposing to implement the ATK
>> interfaces directly on GTK, so instead of having a GTK widget and his
>> accessible equ
On 02/17/2011 11:22 AM, Piñeiro wrote:
> You are proposing to forget this "proxy" approach on the accessibility
> support. As far as I understand you are proposing to implement the ATK
> interfaces directly on GTK, so instead of having a GTK widget and his
> accessible equivalent, just having a GTK
From: Matthias Clasen
> On Thu, Feb 17, 2011 at 11:55 AM, Piñeiro wrote:
>
>> 1 of 4 is failing. Could you elaborate why this theorical points have
>> "failed miserably"?
>
> In my view, keeping the a11y implementation in their separate module
> ghetto is a failure in terms of maintenance, per
On Thu, Feb 17, 2011 at 11:55 AM, Piñeiro wrote:
> 1 of 4 is failing. Could you elaborate why this theorical points have
> "failed miserably"?
In my view, keeping the a11y implementation in their separate module
ghetto is a failure in terms of maintenance, performance, and
robustness. We just do
From: Matthias Clasen
> On Thu, Feb 17, 2011 at 11:22 AM, Piñeiro wrote:
>>
>> Ok, so you are proposing a change more deep that I thought.
>>
>> You are proposing to forget this "proxy" approach on the accessibility
>> support. As far as I understand you are proposing to implement the ATK
>> int
On Thu, Feb 17, 2011 at 11:22 AM, Piñeiro wrote:
>
> Ok, so you are proposing a change more deep that I thought.
>
> You are proposing to forget this "proxy" approach on the accessibility
> support. As far as I understand you are proposing to implement the ATK
> interfaces directly on GTK, so inst
From: Matthias Clasen
> On Thu, Feb 17, 2011 at 10:03 AM, Piñeiro wrote:
>
>>
>> Although move the gail implementation to gtk has his advantages, why
>> this would be better that just fix them directly on gail? One of the
>> big problems here is the lack of resources, so doing the move would
>>
On Thu, 2011-02-17 at 09:43 -0500, Matthias Clasen wrote:
> The current state of affairs cannot be useful for anybody.
let's also look at the state of Atk's API, and what's required to do to
create an ATK implementation. when I looked at the accessible
implementations in GtkSpinner and GtkSwitch
From: Emmanuele Bassi
> On Thu, 2011-02-17 at 09:43 -0500, Matthias Clasen wrote:
>
>> The current state of affairs cannot be useful for anybody.
>
> let's also look at the state of Atk's API, and what's required to do to
> create an ATK implementation. when I looked at the accessible
> impleme
On Thu, Feb 17, 2011 at 9:54 AM, Emmanuele Bassi wrote:
> On Thu, 2011-02-17 at 09:43 -0500, Matthias Clasen wrote:
>
>> The current state of affairs cannot be useful for anybody.
>
> let's also look at the state of Atk's API, and what's required to do to
> create an ATK implementation. when I loo
On Thu, Feb 17, 2011 at 10:03 AM, Piñeiro wrote:
>
> Although move the gail implementation to gtk has his advantages, why
> this would be better that just fix them directly on gail? One of the
> big problems here is the lack of resources, so doing the move would
> add a extra work that could be u
From: Matthias Clasen
> I've spent the last night poring through gail bugs and code, and came
> to the conclusion that we need to face the tough reality that the
> state of a11y in GTK+ is sadly declining. There were years old patches
> in bugzilla which fix pretty obvious bugs; on top of that,
On 02/17/11 09:43, Matthias Clasen wrote:
> Hey,
>
> I've spent the last night poring through gail bugs and code, and came
> to the conclusion that we need to face the tough reality that the
> state of a11y in GTK+ is sadly declining. There were years old patches
> in bugzilla which fix pretty ob
Hey,
I've spent the last night poring through gail bugs and code, and came
to the conclusion that we need to face the tough reality that the
state of a11y in GTK+ is sadly declining. There were years old patches
in bugzilla which fix pretty obvious bugs; on top of that, I've fixed
at least one bu
20 matches
Mail list logo
