Matthias:
I would argue that if all the widgets dealing with text really have
the same needs, they should really support the same interface in GTK+,
and there should be no need to write n adaptors for widget-with-text
to atktext, but instead just one for text-widget-interface to atktext.
And id
On Fri, May 13, 2011 at 12:15 PM, Piñeiro wrote:
> On 05/13/2011 05:47 PM, Piñeiro wrote:
>>
>> The magnifier requires it for focus-tracking. As I said Joseph was
>> planning
>> to try to use some at-spi functionalities on the gs magnifier. As right
>> now
>> at-spi2 python bindings are created wi
On 05/13/2011 05:47 PM, Piñeiro wrote:
The magnifier requires it for focus-tracking. As I said Joseph was
planning
to try to use some at-spi functionalities on the gs magnifier. As
right now
at-spi2 python bindings are created with gobject introspection, in
theory it
could be possible to hav
On 05/13/2011 04:47 PM, Benjamin Otte wrote:
On Fri, May 13, 2011 at 4:32 PM, Matthias Clasen
wrote:
I would argue that if all the widgets dealing with text really have
the same needs, they should really support the same interface in GTK+,
and there should be no need to write n adaptors for wi
On 05/13/2011 04:32 PM, Matthias Clasen wrote:
On Wed, May 11, 2011 at 11:09 AM, Brian Cameron
wrote:
Another example is that the ATK abstracts common characteristics of
widgets in a way that is useful to AT programs. All widgets that deal
with text (labels, entry fields, combo boxes, etc.)
On 05/13/2011 04:48 PM, Matthias Clasen wrote:
On Thu, May 12, 2011 at 5:25 AM, Piñeiro wrote:
On 05/11/2011 02:57 PM, Benjamin Otte wrote:
Well most of the paragraphs were already answered by Brian, but I would like
to add a comment here.What concerns me a lot is that there is only very few
a
On Thu, May 12, 2011 at 5:25 AM, Piñeiro wrote:
> On 05/11/2011 02:57 PM, Benjamin Otte wrote:
>
> Well most of the paragraphs were already answered by Brian, but I would like
> to add a comment here.What concerns me a lot is that there is only very few
> applications
>
>> that actually make use o
On Fri, May 13, 2011 at 4:32 PM, Matthias Clasen
wrote:
> I would argue that if all the widgets dealing with text really have
> the same needs, they should really support the same interface in GTK+,
> and there should be no need to write n adaptors for widget-with-text
> to atktext, but instead ju
On Wed, May 11, 2011 at 11:09 AM, Brian Cameron
wrote:
> Another example is that the ATK abstracts common characteristics of
> widgets in a way that is useful to AT programs. All widgets that deal
> with text (labels, entry fields, combo boxes, etc.) all implement the
> same AtkText interfaces,
On 05/11/2011 02:57 PM, Benjamin Otte wrote:
Well most of the paragraphs were already answered by Brian, but I would
like to add a comment here.What concerns me a lot is that there is only
very few applications
that actually make use of this huge abstraction layer that is AT-SPI.
I'm often t
Benjamin:
Overall, I was just trying to suggest that I think we need more analysis
before making a decision. You raise a number of important issues at the
GTK+ layer, but there are many high-level issues that also need to be
considered. Cross-free-desktop interoperability is just an example.
On 05/11/2011 08:57 PM, Benjamin Otte wrote:
On Tue, May 10, 2011 at 10:46 PM, Brian Cameron
wrote:
A main reason that there are multiple sets of interfaces is to make the
free desktop accessibility interfaces widget-set neutral. A huge
amount of effort has been invested over the years to mak
On Tue, May 10, 2011 at 10:46 PM, Brian Cameron
wrote:
>
> A main reason that there are multiple sets of interfaces is to make the
> free desktop accessibility interfaces widget-set neutral. A huge
> amount of effort has been invested over the years to make GNOME and KDE
> accessibility interoper
On 05/11/2011 02:13 PM, David Zeuthen wrote:
Hey,
On Wed, May 11, 2011 at 4:14 AM, Piñeiro wrote:
So if in the future we change D-Bus for "MyAwesomeIPC" that would be totally
broken. On the current state, gail code, cally code and in general any ATK
implementation didn't require to be modified
于 2011/5/10 22:28, Benjamin Otte 写道:
Due to the previous reasons, the ATK interface is bitrotting. The code
is crashing more and generally behaving buggier with every release.
This was not that much of a problem while the GTK API remained mostly
stable during the GTK 2 cycle, but turned a lot wor
于 2011/5/11 2:38, Federico Mena Quintero 写道:
ATK is "duplicated" interfaces. It needs to be kept in sync with the
rather axiomatic interfaces provided by at-spi. It has to deal with
messy details like GTK+'s reference counting (and who knows if at-spi is
amenable to that kind of detail).
By
On 05/10/2011 08:38 PM, Federico Mena Quintero wrote:
In general your mail is a good summary (IMHO). Some brief comments.
Instead, you want a central abstraction so that you only have to write
(N+M) implementations.
at-spi is the central abstraction. It lets you "navigate" a user
interface in
On 05/10/2011 04:28 PM, Benjamin Otte wrote:
So I've been thinking about accessibility in GTK for a while (since it
broke all the time during the unstable GTK 3 development to be exact).
And I've been wondering how to fix the somewhat sad state of the code
we do have. Unfortunately I have no idea
Benjamin:
A main reason that there are multiple sets of interfaces is to make the
free desktop accessibility interfaces widget-set neutral. A huge
amount of effort has been invested over the years to make GNOME and KDE
accessibility interoperable. By making both GNOME and KDE talk to the
ATK i
On Tue, 2011-05-10 at 16:28 +0200, Benjamin Otte wrote:
> The TL;DR version is this:
> I think the problem is the fact that we support a separate API for
> accessibility.
Let me present my (very limited) understanding of how a11y works right
now. This is for the benefit of gtk-devel-list; people
Hey,
So I've been thinking about accessibility in GTK for a while (since it
broke all the time during the unstable GTK 3 development to be exact).
And I've been wondering how to fix the somewhat sad state of the code
we do have. Unfortunately I have no idea how to solve it, but I have
an opinion a
21 matches
Mail list logo
