Re: Migration Paths for New Modules

2006-07-21 Thread Brian Nitz 
Shaun McCance wrote:
 On Thu, 2006-07-20 at 13:52 -0500, Shaun McCance wrote:
   
 Yikes, all right.  We should definitely keep the exec_ats key
 for legacy.  I suppose the Assistive Technology Preferences
 dialog should continue to set the old values, if possible,
 to keep older machines functioning the same.

 I'm not sure what keys are used by the Preferred Applications
 dialog.  The keys under /desktop/gnome/applications seem to be
 obsolete.  We could just make six keys: a boolean to enable
 each technology, and an exec string for each technology.

 Then there's the question of the interface.  Would we want to
 shunt stuff off to the Preferred Applications dialog?  I think
 it will be more obvious if it's right in the Assistive Technology
 Preferences dialog.  So something like
 

 I meant to say something else here, but forgot about it.
 What happens if I set my preferred screen reader to Orca
 on a fancy new machine, and then try to log into an older
 Gnome using the same home directory.  We don't have any
 sort of fallback mechanism in place.

 This problem isn't unique to us, by the way, and it goes as
 far back as networked Unix itself.  Changing your shell, for
 example, can be a real headache on a heterogeneous network
 with centrally-managed login information.  You won't even be
 able to log into a machine without your selected shell.

 I don't necessarily have a good solution to this problem.
 I can think of some strategies, but none that I think are
 much more than a hack.

 I know there's been blue-sky talk of a next-generation
 configuration system.  A general-purpose solution to
 problems like these would be a definite selling point
 for such a system.

 --
 Shaun


 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list
   
This is one of my biggest headaches in supporting enterprise GNOME 
users.  Consider these use cases:

1.An ISV creates creates a custom application and wisely chooses to 
base this application on GNOME components which won't change between 
releases.  He creates a launcher for this application in the main menu.  
The launcher stops working when GNOME is upgraded.  Not a huge problem 
for a developer on his laptop, a major headache for a sysadmin of 5,000 
desktops.

2.Someone logs into a server running GNOME 2.1X, logs out and logs 
into a server running GNOME 2.1.X+2 using the same NFS home directory.

3.Someone logs into a server running GNOME 2.1.X, _doesn't_ log out 
and logs into a server running GNOME 2.1.X+2 using the same NFS home 
directory.  (This can be common on Sun Ray and possibly other thin 
client GNOMEs)

Should we say that cases 1-3 won't be supported by GNOME?   or...

A simple but incomplete and probably slow solution (hack?) might be to 
put the entire home directory under CVS control or on top of a 
versioning filesystem and give gdm and gnome session the smarts to 
checkout the right branch during login.

Would something like this work instead?:

Move everything off the filesystem into the filesystem independent 
configuration database.  (this includes .gaim, .evolution, 
.gimp,.mozilla, font stuff, desktop files... which means the 
configuration database shouldn't be slower than the filesystem.)

The configuration system manages configuration objects which expose 
read/write methods based on release, key and migration rules.  E.G.

Key  :Range:Rule
default_screenreader:2.10-2.14:RW
default_screenreader:2.06-2.14:R
default_screenreader:2.16-2.20:M

The M rule means the migrate methods would be called for releases where 
Read or Write are not already defined in the rules. 
These methods would take key, version_key and version_now.  In this 
case, the migrate read method would decide that if default_screenreader 
GNOME 2.12 key value is gnopernicus, and the client is version 2.16, 
it returns orca.

Yeah, I know this idea is only 25% baked, but could it be refined into 
something which would improve the user experience?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-20 Thread Bill Haneman 
Shaun wrote:
 On Wed, 2006-07-19 at 14:03 -0400, Willie Walker wrote:
  A big question for me is what does it mean to be 'the screen reader' and
  how does it get launched (much like what it means to be 'the web
  browser' or 'the e-mail reader')?  This is something outside of the
  control of Gnopernicus and Orca, and I'm not sure how this works.
  Guidance here would be greatly appreciated.

The current behavior is partly hard-wired; there is a gconf key called
/desktop/gnome/accessibility/startup/exec_ats which is used to launch
more or more assistive technologies at startup. (IIRC it's a
semicolon-delimited string).

However the AT Prefs dialog, which has the 'screenreader', 'magnifier',
and 'onscreen keyboard' checkboxes, currently has hard-wired behavior;
if you tick the 'screen reader' box, it parses the above string and
ensures that 'gnopernicus' is included in the exec_ats string.

This is of course not the right way to do it, but at the time the idea
that there would be multiple screenreaders/etc. was not something that
the gnome-session maintainers or UI folks wanted to deal with (after
all, we only have one panel and one officially-blessed email client,
etc. etc.).

However I think now would be a good time to fix this.  I see several
possible solutions:

1) keep the exec_ats string as-is, using it for legacy behavior, but
associate the checkboxes with boolean gconf keys.  Then gnome-session
could read the 'screenreader' gconf key and launch orca automatically if
it were checked (same for 'magnifier' gconf key, with different params
passed to orca).

2) modify the exec_ats string the next time the user runs the AT prefs
dialog, warning the user of the change.  User can cancel and leave
exec_ats as-is.

3) Do both #1 and #2 above, i.e. add new gconf booleans and offer to
change the startup ats (via modifying exec_ats) when the user first runs
the AT support dialog.  We could also launch the AT support dialog
automatically if exec_ats is not empty, to inform the user of the
replacement of gnopernicus with orca.

Perhaps it would be appropriate to add 'screen reader', 'magnifier' and
'onscreen keyboard' (or 'keyboard alternative'?) to the
/desktop/gnome/applications directory and the Preferred Applications
dialog so that the user could configure which AT they wanted to do a
specific job (with orca the new default screen reader).  This would also
make it easy for users to select dasher instead of gok, for instance.

regards

Bill

 I'm not entirely sure about this either, and I'm not sure who's
 responsible for this.  Looking at the accessibility preferences,
 I see the following label on this machine:
 
   No Assistive Technology is available on your system.  The
   'gok' package must be installed in order to get on-screen
   keyboard support, and the 'gnopernicus' package must be
   installed for screenreading and magnifying capabilities.
 
 (Why isn't that label selectable?  And who thought that
 screenreading is a word?  It's two words, except that
 it's a compound adjective in this case, so it should be
 hyphenated.)
 
 With a label like that, it seems to me that the tools are
 hard-coded somewhere.  That capplet, at least, is found
 inside control-center, but I don't know what module is
 responsible for actually launching the screen reader.
 
  If there is a real world use case for why importing Gnopernicus settings
  is a necessity, however, we can look at importing them.
  
   How will her settings inter-operate with Gnopernicus if she
   has multiple machines using the same home directory?  
  
  The settings for the two are completely separate at the moment.  I'd
  really hesitate trying to combine them.  It could get rather ugly and
  might screw the user more easily than keeping them separate.
 
 I wouldn't necessarily worry about Gnopernicus's and Orca's
 settings.  What I'm worried about is if we have a GConf
 setting under /desktop/gnome for which accessibility tools
 to use, and how to launch them.  Selecting Orca on a system
 with Orca could then seriously mess up an older system, if
 we're not careful about the implementation.
 
 This isn't necessarily something the Orca team needs to
 concern itself with.  Rather, it's something we need to
 deal with in whatever desktop modules glue this together.
 
 --
 Shaun
 
 
 
 
 --
 
 Message: 7
 Date: Wed, 19 Jul 2006 15:21:55 -0400
 From: Luis Villa [EMAIL PROTECTED]
 Subject: Re: Mummy, I made a platform in my pants! [Was: focus!]
 To: Alex Graveley [EMAIL PROTECTED]
 Cc: Federico Mena Quintero [EMAIL PROTECTED],   Jeff Waugh
   [EMAIL PROTECTED], desktop-devel-list@gnome.org
 Message-ID:
   [EMAIL PROTECTED]
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
 On 7/19/06, Alex Graveley [EMAIL PROTECTED] wrote:
 
  Respectfully, I don't agree.  There is a big set of missing frameworks
  that stops rich interop in Gnome applications, and generally make
  applications much harder to write

Re: Migration Paths for New Modules

2006-07-20 Thread Shaun McCance 
On Thu, 2006-07-20 at 18:59 +0100, Bill Haneman wrote:
 Shaun wrote:
  On Wed, 2006-07-19 at 14:03 -0400, Willie Walker wrote:
   A big question for me is what does it mean to be 'the screen reader' and
   how does it get launched (much like what it means to be 'the web
   browser' or 'the e-mail reader')?  This is something outside of the
   control of Gnopernicus and Orca, and I'm not sure how this works.
   Guidance here would be greatly appreciated.
 
 The current behavior is partly hard-wired; there is a gconf key called
 /desktop/gnome/accessibility/startup/exec_ats which is used to launch
 more or more assistive technologies at startup. (IIRC it's a
 semicolon-delimited string).
 
 However the AT Prefs dialog, which has the 'screenreader', 'magnifier',
 and 'onscreen keyboard' checkboxes, currently has hard-wired behavior;
 if you tick the 'screen reader' box, it parses the above string and
 ensures that 'gnopernicus' is included in the exec_ats string.
 
 This is of course not the right way to do it, but at the time the idea
 that there would be multiple screenreaders/etc. was not something that
 the gnome-session maintainers or UI folks wanted to deal with (after
 all, we only have one panel and one officially-blessed email client,
 etc. etc.).
 
 However I think now would be a good time to fix this.  I see several
 possible solutions:
 
 1) keep the exec_ats string as-is, using it for legacy behavior, but
 associate the checkboxes with boolean gconf keys.  Then gnome-session
 could read the 'screenreader' gconf key and launch orca automatically if
 it were checked (same for 'magnifier' gconf key, with different params
 passed to orca).
 
 2) modify the exec_ats string the next time the user runs the AT prefs
 dialog, warning the user of the change.  User can cancel and leave
 exec_ats as-is.
 
 3) Do both #1 and #2 above, i.e. add new gconf booleans and offer to
 change the startup ats (via modifying exec_ats) when the user first runs
 the AT support dialog.  We could also launch the AT support dialog
 automatically if exec_ats is not empty, to inform the user of the
 replacement of gnopernicus with orca.
 
 Perhaps it would be appropriate to add 'screen reader', 'magnifier' and
 'onscreen keyboard' (or 'keyboard alternative'?) to the
 /desktop/gnome/applications directory and the Preferred Applications
 dialog so that the user could configure which AT they wanted to do a
 specific job (with orca the new default screen reader).  This would also
 make it easy for users to select dasher instead of gok, for instance.

Yikes, all right.  We should definitely keep the exec_ats key
for legacy.  I suppose the Assistive Technology Preferences
dialog should continue to set the old values, if possible,
to keep older machines functioning the same.

I'm not sure what keys are used by the Preferred Applications
dialog.  The keys under /desktop/gnome/applications seem to be
obsolete.  We could just make six keys: a boolean to enable
each technology, and an exec string for each technology.

Then there's the question of the interface.  Would we want to
shunt stuff off to the Preferred Applications dialog?  I think
it will be more obvious if it's right in the Assistive Technology
Preferences dialog.  So something like

  [ ] Screen reader
  Select: [__ Orca __]
  [ ] Magnifier
  Select: [__ Gnopernicus __]
  [ ] On-screen keyboard
  Select: [__ GOK __]

If each AT installs a .desktop file, we could have a special
key that indicates what sort of AT it is, like:

  [Desktop Entry]
  Encoding=UTF-8
  Name=On-Screen Keyboard
  Comment=The GNOME On-screen Keyboard
  Exec=gok
  Terminal=false
  Type=Application
  Icon=gok.png
  Categories=Application;Accessibility;
  X-GNOME-AT-Type=on-screen-keyboard

Then we could actually present a drop-down with choices.
Maybe we still need a Custom with a text area for the
exec string.  The Preferred Applications dialog allows
that.  And that would make the above interface uglier.
We'd probably want a way to pack in a warning label
for each checkbox when you don't have any known ATs
installed for that type.

I'm just tossing out suggestions.  Input is welcome.

--
Shaun



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-20 Thread Shaun McCance 
On Thu, 2006-07-20 at 13:52 -0500, Shaun McCance wrote:
 Yikes, all right.  We should definitely keep the exec_ats key
 for legacy.  I suppose the Assistive Technology Preferences
 dialog should continue to set the old values, if possible,
 to keep older machines functioning the same.
 
 I'm not sure what keys are used by the Preferred Applications
 dialog.  The keys under /desktop/gnome/applications seem to be
 obsolete.  We could just make six keys: a boolean to enable
 each technology, and an exec string for each technology.
 
 Then there's the question of the interface.  Would we want to
 shunt stuff off to the Preferred Applications dialog?  I think
 it will be more obvious if it's right in the Assistive Technology
 Preferences dialog.  So something like

I meant to say something else here, but forgot about it.
What happens if I set my preferred screen reader to Orca
on a fancy new machine, and then try to log into an older
Gnome using the same home directory.  We don't have any
sort of fallback mechanism in place.

This problem isn't unique to us, by the way, and it goes as
far back as networked Unix itself.  Changing your shell, for
example, can be a real headache on a heterogeneous network
with centrally-managed login information.  You won't even be
able to log into a machine without your selected shell.

I don't necessarily have a good solution to this problem.
I can think of some strategies, but none that I think are
much more than a hack.

I know there's been blue-sky talk of a next-generation
configuration system.  A general-purpose solution to
problems like these would be a definite selling point
for such a system.

--
Shaun


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-20 Thread Bill Haneman 
On Thu, 2006-07-20 at 19:52, Shaun McCance wrote:
(my comments on assistive technology gconf keys removed)
 Yikes, all right.  We should definitely keep the exec_ats key
 for legacy.  I suppose the Assistive Technology Preferences
 dialog should continue to set the old values, if possible,
 to keep older machines functioning the same.

I'm not sure it's important to keep back-compatibility if the user
re-runs the config dialog.  It might be better to use that opportunity
to offer to switch the user over.  

IMO the question is whether we want to post a dialog the first time an
AT user logs in to a new Gnome desktop, offering to migrate her/him.

While your combo-box suggestion is interesting and allows the user
maximum choice, it may be better just to change horses at this stage. 
Of course users who want to stay with gnopernicus should be able to do
so without too much interference, but otherwise perhaps we should keep
the interface simple.  If we do choose some sort of combo (and some
.desktop file convention as you suggest), perhaps one of the combo
entries should be Other..., icustom/i, etc. and trigger a simple
file chooser for picking an alternate.

Should we take this to some other list for discussion?

regards,

Bill

 I'm not sure what keys are used by the Preferred Applications
 dialog.  The keys under /desktop/gnome/applications seem to be
 obsolete.  We could just make six keys: a boolean to enable
 each technology, and an exec string for each technology.
 
 Then there's the question of the interface.  Would we want to
 shunt stuff off to the Preferred Applications dialog?  I think
 it will be more obvious if it's right in the Assistive Technology
 Preferences dialog.  So something like
 
   [ ] Screen reader
   Select: [__ Orca __]
   [ ] Magnifier
   Select: [__ Gnopernicus __]
   [ ] On-screen keyboard
   Select: [__ GOK __]
 
 If each AT installs a .desktop file, we could have a special
 key that indicates what sort of AT it is, like:
 
   [Desktop Entry]
   Encoding=UTF-8
   Name=On-Screen Keyboard
   Comment=The GNOME On-screen Keyboard
   Exec=gok
   Terminal=false
   Type=Application
   Icon=gok.png
   Categories=Application;Accessibility;
   X-GNOME-AT-Type=on-screen-keyboard
 
 Then we could actually present a drop-down with choices.
 Maybe we still need a Custom with a text area for the
 exec string.  The Preferred Applications dialog allows
 that.  And that would make the above interface uglier.
 We'd probably want a way to pack in a warning label
 for each checkbox when you don't have any known ATs
 installed for that type.
 
 I'm just tossing out suggestions.  Input is welcome.
 
 --
 Shaun
 
 
 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-19 Thread Shaun McCance 
On Sat, 2006-07-15 at 11:47 -0500, Shaun McCance wrote:
 Three of our proposed modules replace existing
 functionality in the desktop.  We need to think
 about the migration path for our users.  How we
 migrate has an effect on the documentation team
 as well, so I would like a very clear statement
 from the development teams about their plans.

Come on, nothing?  This is important.  This is the sort
of real software engineering discussion we'd be having
if we weren't all busy talking with language wars.

Having a cool application is no sufficient for inclusion
in the desktop.  We require stuff like working within our
release cycle, working with our translators, and working
with our documentation team.

Tomboy has no documentation that I know of.  Orca will
require a *LOT* of documentation updates and additions
in the Accessibility Guide and other places.  Alacarte
will involve changes to the User Guide.

In at least two of these cases, I can't even begin to
coordinate documentation efforts until I know how we
plan to integrate the programs and migrate the users.

I will not endorse a module that isn't cooperating with
the documentation team, no matter how much I happen to
like the program.

--
Shaun


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-19 Thread Willie Walker 
Hi Shaun:

 Tomboy has no documentation that I know of.  Orca will
 require a *LOT* of documentation updates and additions
 in the Accessibility Guide and other places.  

Is there a place we can search to look for references to Gnopernicus?
We're more than happy to submit patches to the various places needed -
finding them all is the hard part.

 I will not endorse a module that isn't cooperating with
 the documentation team, no matter how much I happen to
 like the program.

I certainly hope you do not sense a lack of cooperation on part of the
Orca team.  We're working very hard to be good community members and are
going through the process as best we can understand it.  If something
has given you the impression that we are not cooperating, I'd like to
know what it is so we can remedy it.

Thanks!

Will
(Orca project lead)


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-19 Thread Travis Watkins 

On 7/15/06, Shaun McCance [EMAIL PROTECTED] wrote:

Alacarte has probably the easiest job here,
but I want to make sure that people will get
Alacarte whenever they ask for a menu editor.
A symlink in /usr/bin is probably sufficient.


As far as I know the only place gmenu-simple-editor is exposed in the
UI is the Edit Menus item in the menu applet context menu. Ubuntu
has a patch (attached) that makes this menu item call alacarte if it's
installed. What else would need to be done?

--
Travis Watkins
http://www.realistanew.com
diff -Nur gnome-panel-2.14.1/gnome-panel/panel-menu-bar.c gnome-panel-2.14.1.new/gnome-panel/panel-menu-bar.c
--- gnome-panel-2.14.1/gnome-panel/panel-menu-bar.c	2006-04-14 15:31:19.0 +0200
+++ gnome-panel-2.14.1.new/gnome-panel/panel-menu-bar.c	2006-04-14 15:31:20.0 +0200
@@ -469,10 +469,19 @@
 	} else if (!strcmp (callback_name, edit)) {
 		GError *error = NULL;
 
-		panel_launch_desktop_file (gmenu-simple-editor.desktop,
-	   gmenu-simple-editor,
-	   screen,
-	   error);
+		if (panel_is_program_in_path (alacarte)) {
+			panel_launch_desktop_file (alacarte.desktop,
+		   alacarte,
+		   screen,
+		   error);
+		}
+		else {
+			panel_launch_desktop_file (gmenu-simple-editor.desktop,
+		   gmenu-simple-editor,
+		   screen,
+		   error);
+		}
+
 		if (error) {
 			panel_error_dialog (screen,
 	cannot_exec_gmenu-simple-editor, TRUE,
diff -Nur gnome-panel-2.14.1/gnome-panel/panel-menu-button.c gnome-panel-2.14.1.new/gnome-panel/panel-menu-button.c
--- gnome-panel-2.14.1/gnome-panel/panel-menu-button.c	2006-04-14 15:31:19.0 +0200
+++ gnome-panel-2.14.1.new/gnome-panel/panel-menu-button.c	2006-04-14 15:31:20.0 +0200
@@ -1004,10 +1004,19 @@
 	} else if (!strcmp (callback_name, edit)) {
 GError *error = NULL;
 
-		panel_launch_desktop_file (gmenu-simple-editor.desktop,
-	   gmenu-simple-editor,
-	   screen,
-	   error);
+		if (panel_is_program_in_path (alacarte)) {
+			panel_launch_desktop_file (alacarte.desktop,
+		   alacarte,
+		   screen,
+		   error);
+		}
+		else {
+			panel_launch_desktop_file (gmenu-simple-editor.desktop,
+		   gmenu-simple-editor,
+		   screen,
+		   error);
+		}
+
 if (error) {
 panel_error_dialog (screen,
 cannot_exec_gmenu-simple-editor, TRUE,
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-19 Thread Don Scorgie 
Hi,

On Wed, 2006-07-19 at 12:35 -0400, Willie Walker wrote:
 Hi Shaun:
 
  Tomboy has no documentation that I know of.  Orca will
  require a *LOT* of documentation updates and additions
  in the Accessibility Guide and other places.  
 
 Is there a place we can search to look for references to Gnopernicus?
 We're more than happy to submit patches to the various places needed -
 finding them all is the hard part.

AFAIR, there is only a small section in the accessibility guide about
the screen reader.  It basically contains a link to online Help for
Screen Reader and Magnifier.  Does orca provide a magnifier?  If so,
all that is needed, in the first instance, is to change that link (to
point to the new orca documentation).  If it doesn't, there are probably
other questions (like, what is replacing gnopernicus in the
magnification stakes?).  There is also section dealing with the
Assistive Technologies preference tool in the Desktop guide that might
need changing if it doesn't work the same way.

FWIW, I was planning on updating the accessibility guide again (I
updated it a little last cycle) once Feature freeze happened.  Hopefully
making the section on the onscreen keyboard and screen-reader and other
bits a bit more thorough, instead of just a link to the documentation.
Any help would be appreciated ;)

Don


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-19 Thread Shaun McCance 
On Wed, 2006-07-19 at 12:35 -0400, Willie Walker wrote:
 Hi Shaun:
 
  Tomboy has no documentation that I know of.  Orca will
  require a *LOT* of documentation updates and additions
  in the Accessibility Guide and other places.  
 
 Is there a place we can search to look for references to Gnopernicus?
 We're more than happy to submit patches to the various places needed -
 finding them all is the hard part.
 
  I will not endorse a module that isn't cooperating with
  the documentation team, no matter how much I happen to
  like the program.
 
 I certainly hope you do not sense a lack of cooperation on part of the
 Orca team.  We're working very hard to be good community members and are
 going through the process as best we can understand it.  If something
 has given you the impression that we are not cooperating, I'd like to
 know what it is so we can remedy it.

What I am primarily concerned with is how we intend to migrate
users from Gnopernicus to Orca.  It's not an issue of finding
the references to Gnopernicus in the documentation.  The team
is perfectly capable of writing and editing, when they know
what to write and edit.  (In the case of accessibility tools,
however, we often need more help from the developers, because
many of us don't understand the technologies very well.)

What's important to me is what happens to a Gnome 2.14 user
who upgrades to 2.16.  Will we automatically migrate her to
Orca from Gnopernicus?  How will her settings be migrated?
How will her settings inter-operate with Gnopernicus if she
has multiple machines using the same home directory?  What
sorts of problems is she likely to encounter, and how can
we address those problems in the documentation?

For the record, from what I've seen, I love Orca.  I think
it's the right move for Gnome, and I'm glad the Gnopernicus
folks are in favor of it.  But we have to be very careful
about how we manage migrations, because the sorts of people
who use Gnopernicus and Orca will be completely screwed if
something goes wrong with them.

--
Shaun


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-19 Thread Shaun McCance 
On Wed, 2006-07-19 at 11:37 -0500, Travis Watkins wrote:
 On 7/15/06, Shaun McCance [EMAIL PROTECTED] wrote:
  Alacarte has probably the easiest job here,
  but I want to make sure that people will get
  Alacarte whenever they ask for a menu editor.
  A symlink in /usr/bin is probably sufficient.
 
 As far as I know the only place gmenu-simple-editor is exposed in the
 UI is the Edit Menus item in the menu applet context menu. Ubuntu
 has a patch (attached) that makes this menu item call alacarte if it's
 installed. What else would need to be done?

Binary names constitute a public interface.  Maybe we didn't
officially declare those interfaces as stable, but without
other stable interfaces to do the same thing, third-party
developers will use them.

So from the patch, it looks to me like gmenu-simple-editor
would still be installed, but Alacarte would instead be
called if it's found.

I find this very disconcerting.  Shifty interfaces like
this are a huge pain for documentation.  Some distro will
choose not to install Alacarte, and then the documentation
will be wrong for those users.  (Then again, right now we
have the converse problem with Ubuntu including Alacarte.)

Why have two programs to do the same thing?  If we like
what Alacarte is doing, why don't we just make the menu
editor we have do that?  Or why don't we just replace it
with Alacarte, either by putting it in gnome-panel, or
by making gnome-panel depend on it?

--
Shaun


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-19 Thread Alex Graveley 

I would love to write documentation for Tomboy, and fully intend to. 
But as my users have not requested it, and Tomboy's acceptance into 
GNOME is still totally up in the air for other reasons, I hope you can 
understand why I've held off on it in favor of other endeavors.

-Alex

Shaun McCance wrote:
 Tomboy has no documentation that I know of.  Orca will
 require a *LOT* of documentation updates and additions
 in the Accessibility Guide and other places.  Alacarte
 will involve changes to the User Guide.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-19 Thread Willie Walker 
Hi Shaun:

 What's important to me is what happens to a Gnome 2.14 user
 who upgrades to 2.16.  Will we automatically migrate her to
 Orca from Gnopernicus?  How will her settings be migrated?

As of right now, we are not planning to migrate user preferences from
Gnopernicus to Orca.  We've not seen any demand for this from our users
(whom we interact with daily) and prefer not to add the complexity if we
don't need it.  These words may come across a bit stronger than I intend
them too, though, so please read on.  :-)

The setup for Orca is relatively simple (we provide both a self-voicing
text-based setup and a GUI-based setup), and the user is automatically
placed in setup mode the first time they run Orca.  Furthermore, Orca is
also designed to run in the absence of any settings.  As a result, the
following scenario should just work:

1) The user's session is set up to automatically launch the screen
reader, which happens to be gnopernicus.

2) The user's machine is updated, replacing gnopernicus with orca.

3) The next time the user logs in, the screen reader (which is now
orca) will be launched.  In this user environment, Orca will detect that
accessibility is enabled, automatically find a working speech synthesis
driver, connect to BrlTTY if it is running, and bring up the Orca
configuration GUI, which the user can navigate using Orca.

A big question for me is what does it mean to be 'the screen reader' and
how does it get launched (much like what it means to be 'the web
browser' or 'the e-mail reader')?  This is something outside of the
control of Gnopernicus and Orca, and I'm not sure how this works.
Guidance here would be greatly appreciated.

If there is a real world use case for why importing Gnopernicus settings
is a necessity, however, we can look at importing them.

 How will her settings inter-operate with Gnopernicus if she
 has multiple machines using the same home directory?  

The settings for the two are completely separate at the moment.  I'd
really hesitate trying to combine them.  It could get rather ugly and
might screw the user more easily than keeping them separate.

 What
 sorts of problems is she likely to encounter, and how can
 we address those problems in the documentation?

We've been keeping a list of FAQs and such at the Orca WIKI:

  http://live.gnome.org/Orca

From my experience, many of the problems the user will encounter are
related to audio configuration.  Bad configuration of the audio (outside
our control, unfortunately) will usually result in Orca and/or
Gnopernicus being silent.  We try to offer some coping/debugging
strategies for how to determine where the failure occurs.

 For the record, from what I've seen, I love Orca.  I think
 it's the right move for Gnome, and I'm glad the Gnopernicus
 folks are in favor of it. 

Thanks!  The Gnopernicus folks are a great team.  They've also been
contributing to Orca over the past few weeks and I'm happy to have
people with their skills and experience on board.

 But we have to be very careful
 about how we manage migrations, because the sorts of people
 who use Gnopernicus and Orca will be completely screwed if
 something goes wrong with them.

Agreed.  Our focus for Orca has, and always will be, the users.  My
mantra for the project is let the user requirements drive the
architecture, not the other way around.

Will


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-19 Thread Shaun McCance 
On Wed, 2006-07-19 at 10:43 -0700, Alex Graveley wrote:
 
 I would love to write documentation for Tomboy, and fully intend to. 
 But as my users have not requested it, and Tomboy's acceptance into 
 GNOME is still totally up in the air for other reasons, I hope you
 can 
 understand why I've held off on it in favor of other endeavors.

Just to make things clear, we do not require that new modules
have existing documentation.  Existing documentation certainly
eases the burden on the documentation team, particularly for
large applications (for instance, when Evolution was proposed).
But the documentation team can and will write new documentation
for accepted modules.

We only ask that the maintainers be cooperative.  This means
answering questions about obscure behavior and helping us
address problems users might encounter, including migration
problems.

--
Shaun


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration Paths for New Modules

2006-07-19 Thread Shaun McCance 
On Wed, 2006-07-19 at 14:03 -0400, Willie Walker wrote:
 A big question for me is what does it mean to be 'the screen reader' and
 how does it get launched (much like what it means to be 'the web
 browser' or 'the e-mail reader')?  This is something outside of the
 control of Gnopernicus and Orca, and I'm not sure how this works.
 Guidance here would be greatly appreciated.

I'm not entirely sure about this either, and I'm not sure who's
responsible for this.  Looking at the accessibility preferences,
I see the following label on this machine:

  No Assistive Technology is available on your system.  The
  'gok' package must be installed in order to get on-screen
  keyboard support, and the 'gnopernicus' package must be
  installed for screenreading and magnifying capabilities.

(Why isn't that label selectable?  And who thought that
screenreading is a word?  It's two words, except that
it's a compound adjective in this case, so it should be
hyphenated.)

With a label like that, it seems to me that the tools are
hard-coded somewhere.  That capplet, at least, is found
inside control-center, but I don't know what module is
responsible for actually launching the screen reader.

 If there is a real world use case for why importing Gnopernicus settings
 is a necessity, however, we can look at importing them.
 
  How will her settings inter-operate with Gnopernicus if she
  has multiple machines using the same home directory?  
 
 The settings for the two are completely separate at the moment.  I'd
 really hesitate trying to combine them.  It could get rather ugly and
 might screw the user more easily than keeping them separate.

I wouldn't necessarily worry about Gnopernicus's and Orca's
settings.  What I'm worried about is if we have a GConf
setting under /desktop/gnome for which accessibility tools
to use, and how to launch them.  Selecting Orca on a system
with Orca could then seriously mess up an older system, if
we're not careful about the implementation.

This isn't necessarily something the Orca team needs to
concern itself with.  Rather, it's something we need to
deal with in whatever desktop modules glue this together.

--
Shaun


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list