FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-04-2009, 11:33 PM
Samuel Thibault
 
Default Installing accessibility packages by default?

[Sorry to debian-accessibility people, re-sending with proper To:]

Hello,

It has been suggested a few times (471410, 511329, 516723) to
add an "accessibility" item to tasksel, which would e.g. install
gnome-accessibility. The task would be automatically selected when
accessibility features was used during d-i itself.

However, Mario Lang raised:

`While it is a possible approach to have the installer explicitly
select packages for the users who are going to use the machine,
it is also obvious that an administrator might not know in advance
that a person with special needs is going to use this machine.
If we think this through, we realize that what would be most desireable
is to have accessibility infrastructure installed by default on a
default desktop, so that a person with special needs can just activate
it at login time if they need to.'

`What if, for example, you walk up to a friend/coworker and talk about
some issue. You end up wanting to show them something, so you'd
actually like to login on tehir Linux machine with accessibility enabled
so that you can work together on the project. However, since nobody
thought their machine would ever be used by a disabled person, the
necessary software would not be installed.'

`That is why I think ultimately, accessibility infrastructure needs to be part
of the default desktop installation. There are a few other scenarios as well,
like public workstations (for instance in universities) running Linux.
Currently, for them to be accessible, the admin staff needs to know all the ins
and outs of accessibility, or they at least have to make a conscious decission
about providing it to users. If accessibility would work by default,
the chance of success for disabled people trying to find an accessible
computer would be much higher.'

So, I'm asking: would it seem reasonable to ask tasksel to install
accessibility packages along desktop packages?

I have tried to install Lenny with a gnome desktop, I ended up with
2.3GB disk usage. Adding gnome-accessibility and brltty used only 83MB
more disk. The figures are probably quite similar in the case of a KDE
desktop and kde-accessibility+brltty. Considering the great help it can
be to a not-so-small part of our users, is it too big?

I have also tried with a base system: 560MB disk usage. Adding brltty
and speakup brought 21MB. Maybe that more a concern. I'd tend to think
that people installing a base system usually already know what they will
want to install, and installing the gnome meta package would pull
gnome-accessibility as it's Recommended by gnome-desktop-environment.

Samuel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-05-2009, 05:14 AM
Christian Perrier
 
Default Installing accessibility packages by default?

Quoting Samuel Thibault (samuel.thibault@ens-lyon.org):

> So, I'm asking: would it seem reasonable to ask tasksel to install
> accessibility packages along desktop packages?
>
> I have tried to install Lenny with a gnome desktop, I ended up with
> 2.3GB disk usage. Adding gnome-accessibility and brltty used only 83MB
> more disk. The figures are probably quite similar in the case of a KDE
> desktop and kde-accessibility+brltty. Considering the great help it can
> be to a not-so-small part of our users, is it too big?


Speaking for myself and considering the numbers you point here, I
support the suggestion of installing accessibility-related packages
to default desktop installs.

We have the chance in Debian to have an active accessibility team that
can commit self to guarantee a good maintenance of this part of the
system (mostly by updating tasksel tasks when needed).

We have the goal to delive "The Universal Operating System".

We share values that promote non discrimination (that's at least the
"spirit" of one of the articles of the DFSG) and we certainly are proud
of them.

For all theses reasons, I wholeheartedly support the inclusion of
accessibility-related packages in default desktop installs.

One should also note that this is, TTBOMK, the choice of commercial
desktop environments.
 
Old 03-05-2009, 11:16 AM
Andreas Tille
 
Default Installing accessibility packages by default?

On Thu, 5 Mar 2009, Samuel Thibault wrote:


It has been suggested a few times (471410, 511329, 516723) to
add an "accessibility" item to tasksel, which would e.g. install
gnome-accessibility. The task would be automatically selected when
accessibility features was used during d-i itself.


I wonder whether this effort might profit from maintaining metapackages
for accessibility as it is done in the blends effort. The blends-dev
has tasksel support as well - so it is easily possible to include
accessibility related packages into tasksel. The extra profit would
be that you can provide an easy overview about accesibility related
programs in Debian - the only way I know is

$ apt-cache search accessibility

which is quite weak. Thinks of alternatives like

http://blends.alioth.debian.org/science/tasks/

(which might even work for non native English speakers) and you also
have a developer related overview about bugs

http://blends.alioth.debian.org/science/bugs/

There is no extra effort to create these web pages once you defined
the tasks.


`While it is a possible approach to have the installer explicitly
select packages for the users who are going to use the machine,
it is also obvious that an administrator might not know in advance
that a person with special needs is going to use this machine.
If we think this through, we realize that what would be most desireable
is to have accessibility infrastructure installed by default on a
default desktop, so that a person with special needs can just activate
it at login time if they need to.'


I admit that my suggestion above does not really help in this aspect.
On the other hand there were some ideas raised in the past to enable
a user to install certain tasks quickly inside the Blends framework.
Perhaps we should raise this topic again.


`What if, for example, you walk up to a friend/coworker and talk about
some issue. You end up wanting to show them something, so you'd
actually like to login on tehir Linux machine with accessibility enabled
so that you can work together on the project. However, since nobody
thought their machine would ever be used by a disabled person, the
necessary software would not be installed.'


The problem is that the typical admin does not have the specific
knowledge what actually is needed. The idea to iron out this knowledge
inside the tasks files to enable admins who have not enough specific
knowledge about the needs of their users is one means to help in
this issue.


`That is why I think ultimately, accessibility infrastructure needs to be part
of the default desktop installation. There are a few other scenarios as well,
like public workstations (for instance in universities) running Linux.
Currently, for them to be accessible, the admin staff needs to know all the ins
and outs of accessibility, or they at least have to make a conscious decission
about providing it to users. If accessibility would work by default,
the chance of success for disabled people trying to find an accessible
computer would be much higher.'


I perfectly see the point here. On the other hand I assume there are
most probably urgently needed packages who should be installed per
default and others which are just Recommended and Suggested. So IMHO
it makes sense to have a accessibility-gnome / accessibility-kde
(perhaps accessibility-desktop) metapackages which are part of a
default installation. But most probably there are other packages
which should be handled with different priority and you can perfectly
handle these by using metapackages. The advantage of using
accessibility-gnome / accessibility-kde metapackages is that you
can perfectly handle the dependencies inside the accessibility project
because there will be no need to change d-i or the Gnome / KDE tasks.
They need only depend from one single package and you can change the
dependencies on your own in case some additional packages will show up
or some names will be changed for whatever reason.


So, I'm asking: would it seem reasonable to ask tasksel to install
accessibility packages along desktop packages?


IMHO yes - but in the way I suggested above and not by using explicite
package names.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-05-2009, 05:40 PM
Samuel Thibault
 
Default Installing accessibility packages by default?

Andreas Tille, le Thu 05 Mar 2009 13:16:22 +0100, a écrit :
> On Thu, 5 Mar 2009, Samuel Thibault wrote:
> >It has been suggested a few times (471410, 511329, 516723) to
> >add an "accessibility" item to tasksel, which would e.g. install
> >gnome-accessibility. The task would be automatically selected when
> >accessibility features was used during d-i itself.
>
> I wonder whether this effort might profit from maintaining metapackages
> for accessibility as it is done in the blends effort. The blends-dev
> has tasksel support as well - so it is easily possible to include
> accessibility related packages into tasksel. The extra profit would
> be that you can provide an easy overview about accesibility related
> programs in Debian - the only way I know is
>
> $ apt-cache search accessibility
>
> which is quite weak.

Tags FTW. Look for Accessibility tags and you'll find a lot of
packages.

> Thinks of alternatives like
>
> http://blends.alioth.debian.org/science/tasks/
> http://blends.alioth.debian.org/science/bugs/

Let me point out something which I think is important (even if I think
that's not what you meant): accessibility is not a task. It's like i18n,
it's orthogonal to tasks: for all the tasks above you actually need
accessibility support.

I do not mean that the tool itself shouldn't be used of course.

> >`What if, for example, you walk up to a friend/coworker and talk about
> >some issue. You end up wanting to show them something, so you'd
> >actually like to login on tehir Linux machine with accessibility enabled
> >so that you can work together on the project. However, since nobody
> >thought their machine would ever be used by a disabled person, the
> >necessary software would not be installed.'
>
> The problem is that the typical admin does not have the specific
> knowledge what actually is needed.

The admin, no, but you (the disabled person) do know and just ask your
friend/coworker to run e.g. orca (already installed by default). With
USB braille devices, it would even be possible to automatically start
it, no even need to sudo.

> The idea to iron out this knowledge inside the tasks files to enable
> admins who have not enough specific knowledge about the needs of their
> users is one means to help in this issue.

Yes, we definitely need to have some sort of database that allows people
to know the name of the tools they can try to use to help them anyway.

> I assume there are
> most probably urgently needed packages who should be installed per
> default and others which are just Recommended and Suggested.

Possibly, yes.

> So IMHO it makes sense to have a accessibility-gnome /
> accessibility-kde (perhaps accessibility-desktop) metapackages which
> are part of a default installation.

Which can Depend/Recommend/Suggest depending on the criticity of the
help provided by various packages:
- can't use the computer without it (e.g. screen reader for blind people).
- hard for me to use the computer without it (e.g. color scheme).
- makes me more efficient (e.g. dasher).

> The advantage of using accessibility-gnome / accessibility-kde
> metapackages is that you can perfectly handle the dependencies inside
> the accessibility project because there will be no need to change d-i
> or the Gnome / KDE tasks.

Yes, I also think that'd be better.

> >So, I'm asking: would it seem reasonable to ask tasksel to install
> >accessibility packages along desktop packages?
>
> IMHO yes - but in the way I suggested above and not by using explicite
> package names.

Sure. We don't want to have to bother d-i each time new accessibility
packages get added

Samuel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-06-2009, 08:09 AM
Andreas Tille
 
Default Installing accessibility packages by default?

On Thu, 5 Mar 2009, Samuel Thibault wrote:


$ apt-cache search accessibility

which is quite weak.


Tags FTW. Look for Accessibility tags and you'll find a lot of
packages.


Sure. But do all our package handling tool support DebTags?
Are our users aware of DebTags. (Well I admit they might fail
to find metapackages as well.) So I'd regard DebTags as a very
important technique and joining DebTags information with Blends
techniques is quite high on my todo list.


Thinks of alternatives like

http://blends.alioth.debian.org/science/tasks/
http://blends.alioth.debian.org/science/bugs/


Let me point out something which I think is important (even if I think
that's not what you meant): accessibility is not a task. It's like i18n,
it's orthogonal to tasks: for all the tasks above you actually need
accessibility support.


I perfectly got this information out of your last mail. But IMHO this
is rather a question of terminology. I'd try to find out what might be
helpful for users and IMHO the Blends technique is quite useful. Feel
free to suggest a better terminus than task which fits all needs.


I do not mean that the tool itself shouldn't be used of course.


Fine. ;-)


The admin, no, but you (the disabled person) do know and just ask your
friend/coworker to run e.g. orca (already installed by default). With
USB braille devices, it would even be possible to automatically start
it, no even need to sudo.


That's fine for this specific case. But my idea is that it is easier
to ask for not by default installed packages on the phone line to your
local admin if you have to ask for a single metapackage rather than a
list of packages. While I share your point that a default machine should
have all needed accessibility features there might be a list of "suggested"
packages or even new packages. In the later case would an apt-get update
be sufficient to include new software if the metapackage was properly
adjusted and net even a phone call would be needed.


The idea to iron out this knowledge inside the tasks files to enable
admins who have not enough specific knowledge about the needs of their
users is one means to help in this issue.


Yes, we definitely need to have some sort of database that allows people
to know the name of the tools they can try to use to help them anyway.


Fine. That's what I'm talking about.


So IMHO it makes sense to have a accessibility-gnome /
accessibility-kde (perhaps accessibility-desktop) metapackages which
are part of a default installation.


Which can Depend/Recommend/Suggest depending on the criticity of the
help provided by various packages:
- can't use the computer without it (e.g. screen reader for blind people).
- hard for me to use the computer without it (e.g. color scheme).
- makes me more efficient (e.g. dasher).


Yes, that's the idea.


The advantage of using accessibility-gnome / accessibility-kde
metapackages is that you can perfectly handle the dependencies inside
the accessibility project because there will be no need to change d-i
or the Gnome / KDE tasks.


Yes, I also think that'd be better.


IMHO yes - but in the way I suggested above and not by using explicite
package names.


Sure. We don't want to have to bother d-i each time new accessibility
packages get added


Fine.

If you want to follow this idea I'd suggest the following things:

0. Try to convince listmaster to fix bug #514023 and subscribe the
resulting mailing list debian-blends. I see a big need to have
at least one member of the accessibility team lurking on the
Blends list to make sure that we do not trap into the pitfalls
of choosing narrow minded names (like tasks) or just do other
things which are contra productive for your goal.
1. I used your nice classification page [1] to create the stuff
you need to create tasks and bugs pages which are linked here:
http://blends.alioth.debian.org/accessibility/
You can adjust the informatio in the related SVN

svn://svn.debian.org/wsvn/blends/projects/accessibility/trunk/debian-accessibility/tasks

Please read my comments and fix the info there!
I can add you to the blends team or you can send me a patch.
BTW, thanks to your fine software categorisation page the
creation of the tasks files took me about 15 minutes. IMHO
the result of the tasks and bugs pages is worth this effort.
2. Try to investigate whether something is wrong with your packages.
a) http://blends.alioth.debian.org/accessibility/tasks/console.html
says that these packages do not have a homepage. This is possibly
not true but the control file of the package is lacking the
Homepage field. If you fix the package control information
the tasks page will be fixed after the next cron job run
(twice a day).
b) Consider group maintenance in a common repository - it has
turned out a good means to fix things like missing Homepage
fields, outdated policy versions etc.
c) Fix translations of package descriptions!
You might have noticed that some of the descriptions are
translated. IMHO this is *very* important. Just use the
links for tranlsation or fix translation to get quick
access to the DDTP server.
3. Ask questions if something remains unclear.

BTW, you have a broken link to GNOME Accessibility Project on [1]
The page http://developer.gnome.org/projects/gap/ does not seem to exist.

Kind regards

Andreas.

[1] http://www.debian.org/devel/debian-accessibility/software.en.html

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-06-2009, 11:29 PM
Samuel Thibault
 
Default Installing accessibility packages by default?

Andreas Tille, le Fri 06 Mar 2009 10:09:36 +0100, a écrit :
> On Thu, 5 Mar 2009, Samuel Thibault wrote:
> >> $ apt-cache search accessibility
> >>
> >>which is quite weak.
> >
> >Tags FTW. Look for Accessibility tags and you'll find a lot of
> >packages.
>
> Sure. But do all our package handling tool support DebTags?

See #472694 apt-cache: Filtering by tags for accessibility


> You can adjust the informatio in the related SVN
>
> svn://svn.debian.org/svn/blends/projects/accessibility/trunk/debian-accessibility/tasks

Fixed typo above
I'll send you a patch to expand it to a somewhat bigger list.

> I can add you to the blends team or you can send me a patch.

I'm sthibaul-guest on alioth.

Samuel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-07-2009, 10:29 AM
Tzafrir Cohen
 
Default Installing accessibility packages by default?

On Thu, Mar 05, 2009 at 01:33:29AM +0100, Samuel Thibault wrote:
> [Sorry to debian-accessibility people, re-sending with proper To:]
>
> Hello,
>
> It has been suggested a few times (471410, 511329, 516723) to
> add an "accessibility" item to tasksel, which would e.g. install
> gnome-accessibility. The task would be automatically selected when
> accessibility features was used during d-i itself.
>
> However, Mario Lang raised:
>
> `While it is a possible approach to have the installer explicitly
> select packages for the users who are going to use the machine,
> it is also obvious that an administrator might not know in advance
> that a person with special needs is going to use this machine.
> If we think this through, we realize that what would be most desireable
> is to have accessibility infrastructure installed by default on a
> default desktop, so that a person with special needs can just activate
> it at login time if they need to.'
>
> `What if, for example, you walk up to a friend/coworker and talk about
> some issue. You end up wanting to show them something, so you'd
> actually like to login on tehir Linux machine with accessibility enabled
> so that you can work together on the project. However, since nobody
> thought their machine would ever be used by a disabled person, the
> necessary software would not be installed.'

What does it take to "enable" them?

Furthermore, if you're a blind person using KDE, what good would it do
for you that dasher is installed on the system?

That is: accessibility sounds to me a bit like l10n: normally no point
in installing all of it. Most potential users would need just part of
it.

--
Tzafrir Cohen | tzafrir@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
tzafrir@cohens.org.il | | best
ICQ# 16849754 | | friend


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-07-2009, 10:13 PM
Andreas Tille
 
Default Installing accessibility packages by default?

On Sat, 7 Mar 2009, Samuel Thibault wrote:


I'll send you a patch to expand it to a somewhat bigger list.


Great. It is applied and shows up at the tasks pages now.


I'm sthibaul-guest on alioth.


You are now able to commit the changes yourself.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 06:36 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org