AccessibleParentChangedEvent_getParentAccessible

What ATK signal corresponds to this function?

This is not a parent-changed signal.

We do have a property-change for accessible-parent?

Padraig

patch for AccessibleChildChangedEvent_getChildAccessible

The attached patch gets AccessibleChildChangedEvent_getChildAccessible() 
working.

OK to commit?

Padraig

Index: atk-bridge/bridge.c
===================================================================
RCS file: /cvs/gnome/at-spi/atk-bridge/bridge.c,v
retrieving revision 1.58
diff -u -p -r1.58 bridge.c
--- atk-bridge/bridge.c	14 Feb 2003 13:44:14 -0000	1.58
+++ atk-bridge/bridge.c	7 Mar 2003 10:25:07 -0000
 <at>  <at>  -61,7 +61,7  <at>  <at>  static guint toplevel_handler;
 */

 static guint atk_signal_text_changed;
-static guint atk_signal_child_changed;
+static guint atk_signal_children_changed;
 static guint atk_signal_active_descendant_changed;

 /* NOT YET USED
 <at>  <at>  -126,7 +126,7  <at>  <at>  extern void gnome_accessibility_module_s
 static void
 spi_atk_bridge_init_event_type_consts ()
 {
-  atk_signal_child_changed = g_signal_lookup ("child_changed", 

Re: patch for AccessibleChildChangedEvent_getChildAccessible

On Fri, 2003-03-07 at 10:25, Padraig O'Briain wrote:
> The attached patch gets AccessibleChildChangedEvent_getChildAccessible() 
> working.
> 
> OK to commit?

Yes  - BTW, were we really not emitting children-changed events before?
(failure of signal lookup) 

-Bill

> 
> Padraig
> 
> 
> ______________________________________________________________________
> 
> Index: atk-bridge/bridge.c
> ===================================================================
> RCS file: /cvs/gnome/at-spi/atk-bridge/bridge.c,v
> retrieving revision 1.58
> diff -u -p -r1.58 bridge.c
> --- atk-bridge/bridge.c	14 Feb 2003 13:44:14 -0000	1.58
> +++ atk-bridge/bridge.c	7 Mar 2003 10:25:07 -0000
>  <at>  <at>  -61,7 +61,7  <at>  <at>  static guint toplevel_handler;
>  */
>  
>  static guint atk_signal_text_changed;
> -static guint atk_signal_child_changed;
> +static guint atk_signal_children_changed;

AccessibleTextSelectionChangedEvent_getSelectionString

What should be returned by this function if there is more than text selection?

Padraig

Re: AccessibleTextSelectionChangedEvent_getSelectionString

On Fri, 2003-03-07 at 13:41, Padraig O'Briain wrote:
> What should be returned by this function if there is more than text selection?

I would suggest that if the event contains enough info to determine
which selection has changed, we should return only that selection, in
text-string form.

So if we have two non-contiguous selections, and we add a third, then
the third substring gets returned along with the information that we
have added a selection.

If we remove a selection, then we return an empty string.

If we edit a selection, we return the edited selection (one of possibly
several).

This would require that multiple selection additions/edits could not be
returned in a single event, and require that the event carry
selection-count information with it.  It would also require that the
event let us know which selection (index) it was associated with.

I am not sure that our current selection signal API can contain all this
info; do you think it's feasible?

-Bill

> Padraig
> 
> _______________________________________________
> Gnome-accessibility-devel mailing list

Re: AccessibleTextSelectionChangedEvent_getSelectionString

The text-selection signal in ATK does not provide any information other than 
that a text selection change has occurred.

On looking further I do not see an object which allows more than one text 
selection.

Padraig

> On Fri, 2003-03-07 at 13:41, Padraig O'Briain wrote:
> > What should be returned by this function if there is more than text 
selection?
> 
> I would suggest that if the event contains enough info to determine
> which selection has changed, we should return only that selection, in
> text-string form.
> 
> So if we have two non-contiguous selections, and we add a third, then
> the third substring gets returned along with the information that we
> have added a selection.
> 
> If we remove a selection, then we return an empty string.
> 
> If we edit a selection, we return the edited selection (one of possibly
> several).
> 
> This would require that multiple selection additions/edits could not be
> returned in a single event, and require that the event carry
> selection-count information with it.  It would also require that the
> event let us know which selection (index) it was associated with.
> 

Re: AccessibleTextSelectionChangedEvent_getSelectionString

On Fri, 2003-03-07 at 14:16, Padraig O'Briain wrote:
> The text-selection signal in ATK does not provide any information other than 
> that a text selection change has occurred.

Oops.

> On looking further I do not see an object which allows more than one text 
> selection.

However the API allows it explicitly.

It's not clear what we should do for the multiselect case, but perhaps
just concatanating the strings would be sufficient for the purposes of
this API.

Again we should probably limit the length of the string, overall.

The other possibility would be to report only the "delta" of the
selection, in the manner of text-changed.  That might be more
implementable for the general case.

-Bill

> Padraig

--

-- 
Bill Haneman <bill.haneman <at> sun.com>

at-spi patch

The attached patch fixes AccessibleTextSelectionChangedEvent_getSelectionString 
and AccessibleNameChangedEvent_getNameString.

OK to commit?

Padraig

Index: atk-bridge/bridge.c
===================================================================
RCS file: /cvs/gnome/at-spi/atk-bridge/bridge.c,v
retrieving revision 1.59
diff -u -p -r1.59 bridge.c
--- atk-bridge/bridge.c	7 Mar 2003 15:34:37 -0000	1.59
+++ atk-bridge/bridge.c	7 Mar 2003 16:38:46 -0000
 <at>  <at>  -21,6 +21,7  <at>  <at> 
  * Boston, MA 02111-1307, USA.
  */

+#include <string.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <stdarg.h>
 <at>  <at>  -48,9 +49,9  <at>  <at>  static SpiApplication *this_app = NULL;
 static gboolean registry_died = FALSE;
 static gboolean atk_listeners_registered = FALSE;
 static guint toplevel_handler;
+static gint max_selection_string = 255;

 /* NOT YET USED

Extended events

The attached poatch completes the implementation of extended event support in 
at-spi.

Is this OK to commit?

Padraig

? at-spi-1.1.8
? at-spi-1.1.8.tar
? at-spi.diff
? autom4te.cache
? configure.in.SAVE
? atk-bridge/bridge.c.NEW
? atk-bridge/bridge.c.TEST
? cspi/spi_accessible.c.NOWARN
? cspi/spi_event.c.SAVE
? cspi/spi_registry.c.TEST
? cspi/bonobo/cspi-bonobo-listener.c.NOWARN
? cspi/bonobo/cspi-bonobo-listener.c.TEST
? docs/reference/cspi/tmpl/at-spi-cspi-unused.sgml
? docs/reference/cspi/tmpl/spi_streamable_content.sgml
? libspi/Makefile.am.NEW
? libspi/application.c.TEST
? libspi/relation.c.NOWARN
? registryd/cpp.sh
? registryd/deviceeventcontroller.c.NEW
? registryd/deviceeventcontroller.c.NOWARN
? registryd/deviceeventcontroller.c.TEST
? test/event-listener-test

Re: Extended events

I have a couple of questions, inline, please search for [wph]:

On Tue, 2003-03-11 at 10:29, Padraig O'Briain wrote:
> The attached poatch completes the implementation of extended event support in 
> at-spi.
> 
> Is this OK to commit?
> 
> Padraig
...

> Index: atk-bridge/bridge.c
> ===================================================================
> RCS file: /cvs/gnome/at-spi/atk-bridge/bridge.c,v
> retrieving revision 1.59
> <snip> 
>  /* NOT YET USED
> -   static guint atk_signal_text_selection_changed;
>     static guint atk_signal_row_reordered;
>     static guint atk_signal_row_inserted;
>     static guint atk_signal_row_deleted;

[wph]
Maybe off-topic, but are we not emitting any kind of row/column
reordered events in at-spi yet?

> ...

>  <at>  <at>  -585,8 +586,101  <at>  <at>  spi_atk_bridge_property_event_listener (
>    gobject = g_value_get_object (param_values + 0);