Re: Proposed Orca Migration

[Bill Haneman <Bill Haneman Sun COM>]

Hi:

I seem to recall that there was a reason why we didn't use 'startup
programs' before.  Can't remember what it was... but I seem to remember
looking at and rejecting that before.  Maybe because we wanted the ATs
to launch first?  Or is there a problem with the 'startup programs'
API/interface itself?

My own preference would be for a middle path - 

1) keep exec_ats, don't launch orca if gnopernicus still exists, but
launch the AT config dialog if exec_ats is non-empty, on first login.

2) simplify the AT config dialog to not list "screenreader", "onscreen
keyboard", etc. but to put the various AT progs (from the .desktop
files, preferably) in a single combo box.  If the user wants/needs more
than one AT, use the method below:

3) add a text entry field after the above combo, where a
semicolon-delimited list of exec commands can be entered.

4) for the "magnifier" vs "screen reader" and other AT-config-related
issues, I suggest that ATs launch with some kind of config dialog as
orca now does, when they are run for the first time.

I'd be happy to work with Shaun etc. to get this done this week if there
is consensus that it's what we want.

Bill


On Mon, 2006-07-24 at 22:32, desktop-devel-list-request gnome org wrote:
> Send desktop-devel-list mailing list submissions to
> 	desktop-devel-list gnome org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> or, via email, send a message with subject or body 'help' to
> 	desktop-devel-list-request gnome org
> 
> You can reach the person managing the list at
> 	desktop-devel-list-owner gnome org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of desktop-devel-list digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Tomboy in Desktop (David Nielsen)
>    2. Re: dbus building pains (Jason D. Clinton)
>    3. Re: Proposed Orca Migration (Willie Walker)
>    4. Re: what happened to the build discussion?[was Re: dbus
>       building	pains] (Frederic Peters)
>    5. Re: what happened to the build discussion?[was Re: dbus
>       building	pains] (Luis Villa)
>    6. Re: Proposed Orca Migration (Peter Korn)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 24 Jul 2006 22:23:50 +0200
> From: David Nielsen <david lovesunix net>
> Subject: Re: Tomboy in Desktop
> To: Jamie McCracken <jamiemcc blueyonder co uk>
> Cc: desktop-devel-list gnome org
> Message-ID: <1153772630 1505 167 camel price>
> Content-Type: text/plain
> 
> man, 24 07 2006 kl. 19:49 +0100, skrev Jamie McCracken:
> 
> > I dont doubt that but FWIW when it comes to adding Tracker to gnome 
> > 2.18, I would like notes to be added as a first class object and stored 
> > in Tracker's DB. Tracker already makes it easy to add tagging, 
> > extensible metadata and linking to other objects so adding such support 
> > to sticky notes (and Tomboy too if maintainer allows) is one way of 
> > improving things in that regard. Im not commiting myself to fixing all 
> > your gripes in sticky notes just giving it a bit of tracker power that 
> > will hopefully make them more manageable and powerful.
> 
> I have no gripe with sticky notes, hell up till a few days ago I had
> blissfully forgotten it's existence. This is also not about Tracker,
> this is about Tomboy - the argument was starting to center around the
> notion that we could just "fix" sticky notes and my point was that
> Tomboy is a much better application today and users generally love it.
> 
> Sticky Notes comes no where near it and bringing it to the same state
> would take a lot of hard and pointless work. 
> 
> Merely adding spell checking (and I agree we should have a common spell
> checking API and HIG spec but that aside) and stuffing it in Tracker
> (which isn't an option TODAY as tracker is nowhere near ready either, by
> your own admission the plan for proposal is 2.18) won't magically make
> it Tomboy.
> 
> Tomboy is the product of innovation, it works well and is stable. I see
> no reason to not include it what so ever. I don't really see a reason to
> keep Sticky Notes either, it's not discoverable and I doubt many people
> actually use it - furthermore all the things you'd do in Sticky Notes
> can be done in Tomboy with ease. It's minimally different interfaces and
> modes of operation but it would be better to do a UI review of Tomboy
> and have one application, one good default.
> 
> If you want the same exact behavior as Sticky Notes, simply don't use
> the linking feature, voila - you have the same thing (but with spell
> checking, reference ability, etc). That is where Alex and I differ in
> opinion, I think we can replace Sticky Notes based on that observation.
> 
> But please don't retrofit Tomboy on Sticky Notes just because of the
> politics around Mono and don't bring up Tracker as a solution. We can't
> make decisions based on software we haven't even examined and debated
> for inclusion. I imagine the Beagle people might have arguments for and
> against their system for that debate when it comes around in 6 months or
> so.
> 
> That's my opinion.
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 24 Jul 2006 15:33:55 -0500
> From: "Jason D. Clinton" <me jasonclinton com>
> Subject: Re: dbus building pains
> To: "John (J5) Palmieri" <johnp redhat com>
> Cc: desktop-devel-list gnome org, Don Scorgie
> 	<DonScorgie Blueyonder co uk>
> Message-ID: <1153773235 5844 18 camel desktop1 localdomain>
> Content-Type: text/plain; charset="us-ascii"
> 
> On Mon, 2006-07-24 at 16:07 -0400, John (J5) Palmieri wrote:
> > The system bus (>=0.90) needs to be running and accessible by the 
> > build.  We need to remove this dependency in the future.  The quick fix 
> > is to build outside of jhbuild and copy the
> > 
> > dbus-bus-introspect.xml into the tools directory in D-Bus's jhbuild build root.
> 
> I have placed the needed .xml file at http://jasonclinton.com/ -
> hopefully that will help others whom are stuck.
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: This is a digitally signed message part
> Url : /archives/desktop-devel-list/attachments/20060724/984591e9/attachment.bin 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 24 Jul 2006 16:47:57 -0400
> From: Willie Walker <William Walker Sun COM>
> Subject: Re: Proposed Orca Migration
> To: Shaun McCance <shaunm gnome org>
> Cc: desktop-devel-list gnome org
> Message-ID: <1153774077 20099 70 camel localhost>
> Content-Type: text/plain
> 
> Hi Shaun:
> 
> I think we've all agreed that we want to replace Gnopernicus with Orca
> and I think we all agree that the accessibility dialog needs work.  I do
> not believe the work for the two must be coupled.
> 
> If I understand your primary concern with the migration, it's that the
> user who has configured their system to use a screen reader should
> continue to have a screen reader after an upgrade to GNOME 2.16.
> Furthermore, a user sharing their home directory between pre-GNOME-2.16
> and GNOME-2.16 systems should get expected results.
> 
> I'd like to make two alternative proposals that should hopefully address
> this concern with minimal impact.  The goal of each proposal is to
> address the problem of replacing Gnopernicus with Orca for GNOME 2.16,
> leaving the separate problem of redesigning the assistive technology
> dialog for another day (GNOME 2.18).
> 
> BACKGROUND:
> -----------
> 
> Based upon this e-mail thread and some digging around the code, here's
> what it looks like the current model is for launching assistive
> technologies:
> 
> 1) The gconf setting for which assistive technologies to use is
> /desktop/gnome/accessibility/startup/exec_ats, which is a list of names
> of executables for assistive technologies to be spawned by
> gnome-session.
> 
> 2) The gnome-at-properties application, which is the one that brings up
> the dialog for which you proposed modifications, writes the exec_ats
> property.  The code for it is in the following file, which has various
> hardcodings to things like gnopernicus and gok, and also has special
> code to handle cases such as the screen reader also being a magnifier
> (e.g., launch gnopernicus if the user selected either the screen reader
> or magnifier, and only launch it once):
> 
> gnome-control-center/capplets/accessibility/at-properties/at-startup-session.c.
> 
> 3) gnome-session/gnome-session/gsm-at-startup.c reads the exec_ats
> property and just spawns off processes for each entry it finds.
> 
> PROPOSAL #1:
> ------------
> 
> Merely modify gsm-at-startup.c:gsm_assistive_tech_exec to see if the
> exec string is 'gnopernicus'.  If it is, substitute it with 'orca'.
> 
> Here's how this would work - exec_ats would always still refer to
> gnopernicus.  On pre-GNOME-2.16 systems which still have Gnopernicus,
> gnopernicus would be run.  On GNOME-2.16 systems, where Orca has
> replaced Gnopernicus, orca would be run.  Furthermore, using the
> gnome-at-properties application to make AT startup preferences on any
> system using either the pre-GNOME-2.16 or GNOME-2.16 would have the
> desired effect both forwards and backwards.
> 
> The only thing that would not happen here is that Orca would read
> Gnopernicus settings.  Our user base does not seem to be clamoring for
> this seamless migration (we've not had one request).  If it is deemed a
> necessity, however, we could work on code to suck Gnopernicus settings
> into Orca when Orca is first run.
> 
> The documentation and release notes for GNOME 2.16 would also need to
> remind users that when they log in for the first time on a GNOME 2.16
> using a home directory that has been preserved from a pre-GNOME 2.16
> install, Orca will be launched instead of Gnopernicus and Orca will
> automatically bring up a configuration GUI for them to set up Orca.  
> 
> PROPOSAL #2:
> ------------
> 
> Cut everything out of the dialog except for the checkbox to enable
> assistive technology support.  Point users to the other mechanism that
> GNOME has for automatically starting applications when the user logs in:
> the "Startup Programs" of the gnome-sessions-properties application.
> This greatly simplifies the problem overall, reducing the need to
> squabble over classifications of things such screen readers vs.
> magnifiers, on screen keyboards vs. alternative input mechanisms, etc.
> 
> Will
> 
> On Mon, 2006-07-24 at 13:20 -0500, Shaun McCance wrote:
> > Doing Orca right in 2.16 will require some changes in core
> > Gnome modules.  Unfortunately, the feature and UI freeze is
> > today.  I'd like to outline a proposal for getting Orca in
> > this release cycle.
> > 
> > First, I don't know which module is responsible for starting
> > accessibility tools on log in.  Somebody must know.
> > 
> > The accessibility tools are currently stared in GConf in the
> > key /desktop/gnome/accessibility/startup/exec_ats.  This key
> > is a list of tools to start.
> > 
> > I propose we add the following six keys:
> > 
> > enable_screen_reader (boolean)
> > enable_magnifier (boolean)
> > enable_on_screen_keyboard (boolean)
> > screen_reader_command (string)
> > magnifier_command (string)
> > on_screen_keyboard_command (string)
> > 
> > The enable_* keys simply toggle whether that particular
> > tool should be launched on log in.  The *_command keys
> > provide what to exec to make it happen.  When a user
> > first logs into a 2.16 desktop, we migrate the values
> > in exec_ats to the new keys.  We could have a separate
> > key, exec_ats_migrated, that defaults to false and is
> > changed to true once the first-time migration has been
> > done.  Maybe there's a less hackish solution.
> > 
> > Then, we modify the code that launches the ATs to read
> > from these new keys.  Then, we modify the AT prefs tool
> > in control-center to set them, adding a means to specify
> > which program to use for each tool.  I made a mockup of
> > the dialog in glade and attached a screenshot.
> > 
> > The mockup I've sent presumes we can get a list of the
> > appropriate programs.  We can accomplish this with an
> > extra key or three in the applications' .desktop files.
> > We could either have one key that takes string values
> > from a controlled vocabulary ("magnifier", etc.), or
> > three boolean values for each tool type.  I'm pretty
> > indifferent.
> > 
> > We then add those keys to Gnopernicus, GOK, Orca, and
> > Dasher.  Then we pat ourselves on the back for a job
> > well done.
> > 
> > (Open issue: Bill suggested dropping the term "on-screen
> > keyboard", and I'm inclined to agree.  That term really
> > only describes GOK.  Dasher, and other potentially useful
> > programs in the future, are more generally "alternative
> > key entry programs".  But that just sounds obtuse.)
> > 
> > Today being the feature and UI freeze, this proposal is
> > already up against a wall.  But I've never let reality
> > stop me before.  For what it's worth, I'm giving the
> > go-ahead for the UI change as the documentation leader.
> > 
> > My concrete, time-based proposal is this:  We provide
> > provisional approval to go ahead with this course of
> > action, but we will not let it stretch way late into
> > our release cycle.  We will require that these changes
> > be implemented by next Monday, July 31st, and that we
> > get new releases of the affected modules immediately.
> > (The big code changes, I'm not going to get all pissy
> > about Dasher adding a key to its desktop file.)
> > 
> > If it can't be done in a week, we revert, and we hold
> > off on Orca until 2.18.  Though the changes are visible,
> > I don't think they're very difficult or high-risk.
> > 
> > I don't maintain any of the relevant modules here.  I'm
> > just being an active cheerleader.  We need to have good
> > cross-module cooperation for this to happen.  Without
> > buy-in from all affected maintainers, we'll just have
> > to postpone.
> > 
> > --
> > Shaun
> > 
> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 24 Jul 2006 23:03:35 +0200
> From: Frederic Peters <fpeters 0d be>
> Subject: Re: what happened to the build discussion?[was Re: dbus
> 	building	pains]
> To: desktop-devel-list gnome org
> Cc: build-brigade gnome org
> Message-ID: <20060724210335 GA16907 entrouvert com>
> Content-Type: text/plain; charset=us-ascii
> 
> Luis Villa wrote:
> 
> > Tangential to this, there was an awesome BOF at GUADEC about
> > continuous build integration, which hopefully would avoid problems
> > like this. Has there been any news on that front that I missed? :)
> 
> Things I know: Thomas looked at issues with coverage support in GCC 4
> and got it working[1], igalia guys[2] have been hacking on jhbuild to
> get different checkout behaviours and D-Bus integration[3].
> 
> As for me I added a few features to jhautobuild so Prashanth[4] can
> integrate LDTP test results and not much else, hacking habits suffered
> from summer weather.
> 
> 
> CC'ing to build-brigade@
> 
> 
>         Frederic
> 
> 
> [1] but I forgot to bookmark the URL with output samples
> [2] I should really activate IRC logging, I forgot who exactly worked
> [3] so it is possible to have out-of-process control of jhbuild build
>     state machine
> [4] SoC student
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 24 Jul 2006 17:07:10 -0400
> From: "Luis Villa" <luis tieguy org>
> Subject: Re: what happened to the build discussion?[was Re: dbus
> 	building	pains]
> To: "Frederic Peters" <fpeters 0d be>
> Cc: build-brigade gnome org, desktop-devel-list gnome org
> Message-ID:
> 	<2cb10c440607241407i4d3cfb42o63bc9c45bd73a743 mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 7/24/06, Frederic Peters <fpeters 0d be> wrote:
> > Luis Villa wrote:
> >
> > > Tangential to this, there was an awesome BOF at GUADEC about
> > > continuous build integration, which hopefully would avoid problems
> > > like this. Has there been any news on that front that I missed? :)
> >
> > Things I know: Thomas looked at issues with coverage support in GCC 4
> > and got it working[1], igalia guys[2] have been hacking on jhbuild to
> > get different checkout behaviours and D-Bus integration[3].
> >
> > As for me I added a few features to jhautobuild so Prashanth[4] can
> > integrate LDTP test results and not much else, hacking habits suffered
> > from summer weather.
> >
> >
> > CC'ing to build-brigade@
> 
> Ah, I didn't see the announcement of the list. I guess further
> discussion should go there. Totally understand about the summer
> weather-
> 
> Luis
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 24 Jul 2006 14:32:09 -0700
> From: Peter Korn <Peter Korn Sun COM>
> Subject: Re: Proposed Orca Migration
> To: Willie Walker <William Walker Sun COM>
> Cc: Shaun McCance <shaunm gnome org>, desktop-devel-list gnome org
> Message-ID: <44C53C59 1030309 sun com>
> Content-Type: text/plain; format=flowed; charset=ISO-8859-1
> 
> Hi Sean, Will,
> 
> If I might chime in...  I think either of Will's proposals is fine for 
> GNOME 2.16, with a slight preference to #2 - to move users to launching 
> AT at startup just like the launch other apps at startup.
> 
> Calling out "screen reader", "screen magnifier", and "on screen 
> keyboard" does nice things for visibility, but it oddly suggests those 
> are the only three kinds of AT.  As has already been noted, Dasher isn't 
> exactly an "on screen keyboard".  Certainly Dasher users might want to 
> have it started automatically at login.  Folks who have their computer 
> talk for them (a use the latest Dasher can be put to, as well as KMouth 
> from the KDE accessibility community) might want that device always 
> launched - especially folks for whom a main use of their computer is as 
> their (audio) communication device.  Also the KDE KMouseTool app that is 
> a mouse substitute is another "possible launch at startup" AT - which 
> again doesn't fit into our three existing categories.  Looking outside 
> of the UNIX desktop world, there are several additional flavors of apps 
> used for accessibility in Windows & Macintosh.  And finally, we've 
> already observed with both Gnopernicus and Orca - we have one app that 
> does both magnification & screen reading; so why have a GUI that 
> suggests they are different?
> 
> For GNOME 2.18, I think we should look at a user interaction session (I 
> had the term "wizard") to determine how the user wants his/her desktop 
> configured to best meet their needs - including but not limited to 
> automatically launching assistive technologies.
> 
> Regards,
> 
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
> 
> > Hi Shaun:
> >
> > I think we've all agreed that we want to replace Gnopernicus with Orca
> > and I think we all agree that the accessibility dialog needs work.  I do
> > not believe the work for the two must be coupled.
> >
> > If I understand your primary concern with the migration, it's that the
> > user who has configured their system to use a screen reader should
> > continue to have a screen reader after an upgrade to GNOME 2.16.
> > Furthermore, a user sharing their home directory between pre-GNOME-2.16
> > and GNOME-2.16 systems should get expected results.
> >
> > I'd like to make two alternative proposals that should hopefully address
> > this concern with minimal impact.  The goal of each proposal is to
> > address the problem of replacing Gnopernicus with Orca for GNOME 2.16,
> > leaving the separate problem of redesigning the assistive technology
> > dialog for another day (GNOME 2.18).
> >
> > BACKGROUND:
> > -----------
> >
> > Based upon this e-mail thread and some digging around the code, here's
> > what it looks like the current model is for launching assistive
> > technologies:
> >
> > 1) The gconf setting for which assistive technologies to use is
> > /desktop/gnome/accessibility/startup/exec_ats, which is a list of names
> > of executables for assistive technologies to be spawned by
> > gnome-session.
> >
> > 2) The gnome-at-properties application, which is the one that brings up
> > the dialog for which you proposed modifications, writes the exec_ats
> > property.  The code for it is in the following file, which has various
> > hardcodings to things like gnopernicus and gok, and also has special
> > code to handle cases such as the screen reader also being a magnifier
> > (e.g., launch gnopernicus if the user selected either the screen reader
> > or magnifier, and only launch it once):
> >
> > gnome-control-center/capplets/accessibility/at-properties/at-startup-session.c.
> >
> > 3) gnome-session/gnome-session/gsm-at-startup.c reads the exec_ats
> > property and just spawns off processes for each entry it finds.
> >
> > PROPOSAL #1:
> > ------------
> >
> > Merely modify gsm-at-startup.c:gsm_assistive_tech_exec to see if the
> > exec string is 'gnopernicus'.  If it is, substitute it with 'orca'.
> >
> > Here's how this would work - exec_ats would always still refer to
> > gnopernicus.  On pre-GNOME-2.16 systems which still have Gnopernicus,
> > gnopernicus would be run.  On GNOME-2.16 systems, where Orca has
> > replaced Gnopernicus, orca would be run.  Furthermore, using the
> > gnome-at-properties application to make AT startup preferences on any
> > system using either the pre-GNOME-2.16 or GNOME-2.16 would have the
> > desired effect both forwards and backwards.
> >
> > The only thing that would not happen here is that Orca would read
> > Gnopernicus settings.  Our user base does not seem to be clamoring for
> > this seamless migration (we've not had one request).  If it is deemed a
> > necessity, however, we could work on code to suck Gnopernicus settings
> > into Orca when Orca is first run.
> >
> > The documentation and release notes for GNOME 2.16 would also need to
> > remind users that when they log in for the first time on a GNOME 2.16
> > using a home directory that has been preserved from a pre-GNOME 2.16
> > install, Orca will be launched instead of Gnopernicus and Orca will
> > automatically bring up a configuration GUI for them to set up Orca.  
> >
> > PROPOSAL #2:
> > ------------
> >
> > Cut everything out of the dialog except for the checkbox to enable
> > assistive technology support.  Point users to the other mechanism that
> > GNOME has for automatically starting applications when the user logs in:
> > the "Startup Programs" of the gnome-sessions-properties application.
> > This greatly simplifies the problem overall, reducing the need to
> > squabble over classifications of things such screen readers vs.
> > magnifiers, on screen keyboards vs. alternative input mechanisms, etc.
> >
> > Will
> >
> > On Mon, 2006-07-24 at 13:20 -0500, Shaun McCance wrote:
> >   
> >> Doing Orca right in 2.16 will require some changes in core
> >> Gnome modules.  Unfortunately, the feature and UI freeze is
> >> today.  I'd like to outline a proposal for getting Orca in
> >> this release cycle.
> >>
> >> First, I don't know which module is responsible for starting
> >> accessibility tools on log in.  Somebody must know.
> >>
> >> The accessibility tools are currently stared in GConf in the
> >> key /desktop/gnome/accessibility/startup/exec_ats.  This key
> >> is a list of tools to start.
> >>
> >> I propose we add the following six keys:
> >>
> >> enable_screen_reader (boolean)
> >> enable_magnifier (boolean)
> >> enable_on_screen_keyboard (boolean)
> >> screen_reader_command (string)
> >> magnifier_command (string)
> >> on_screen_keyboard_command (string)
> >>
> >> The enable_* keys simply toggle whether that particular
> >> tool should be launched on log in.  The *_command keys
> >> provide what to exec to make it happen.  When a user
> >> first logs into a 2.16 desktop, we migrate the values
> >> in exec_ats to the new keys.  We could have a separate
> >> key, exec_ats_migrated, that defaults to false and is
> >> changed to true once the first-time migration has been
> >> done.  Maybe there's a less hackish solution.
> >>
> >> Then, we modify the code that launches the ATs to read
> >> from these new keys.  Then, we modify the AT prefs tool
> >> in control-center to set them, adding a means to specify
> >> which program to use for each tool.  I made a mockup of
> >> the dialog in glade and attached a screenshot.
> >>
> >> The mockup I've sent presumes we can get a list of the
> >> appropriate programs.  We can accomplish this with an
> >> extra key or three in the applications' .desktop files.
> >> We could either have one key that takes string values
> >> from a controlled vocabulary ("magnifier", etc.), or
> >> three boolean values for each tool type.  I'm pretty
> >> indifferent.
> >>
> >> We then add those keys to Gnopernicus, GOK, Orca, and
> >> Dasher.  Then we pat ourselves on the back for a job
> >> well done.
> >>
> >> (Open issue: Bill suggested dropping the term "on-screen
> >> keyboard", and I'm inclined to agree.  That term really
> >> only describes GOK.  Dasher, and other potentially useful
> >> programs in the future, are more generally "alternative
> >> key entry programs".  But that just sounds obtuse.)
> >>
> >> Today being the feature and UI freeze, this proposal is
> >> already up against a wall.  But I've never let reality
> >> stop me before.  For what it's worth, I'm giving the
> >> go-ahead for the UI change as the documentation leader.
> >>
> >> My concrete, time-based proposal is this:  We provide
> >> provisional approval to go ahead with this course of
> >> action, but we will not let it stretch way late into
> >> our release cycle.  We will require that these changes
> >> be implemented by next Monday, July 31st, and that we
> >> get new releases of the affected modules immediately.
> >> (The big code changes, I'm not going to get all pissy
> >> about Dasher adding a key to its desktop file.)
> >>
> >> If it can't be done in a week, we revert, and we hold
> >> off on Orca until 2.18.  Though the changes are visible,
> >> I don't think they're very difficult or high-risk.
> >>
> >> I don't maintain any of the relevant modules here.  I'm
> >> just being an active cheerleader.  We need to have good
> >> cross-module cooperation for this to happen.  Without
> >> buy-in from all affected maintainers, we'll just have
> >> to postpone.
> >>
> >> --
> >> Shaun
> >>
> >> _______________________________________________
> >> desktop-devel-list mailing list
> >> desktop-devel-list gnome org
> >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >>     
> >
> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >   
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> End of desktop-devel-list Digest, Vol 27, Issue 99
> **************************************************