Inference Group

Для чего нужен Dasher?  
Как работает Dasher? 
·Три страницы 
·Try Dasher in your browser 
Скачать Dasher 
·Подсказки для Новичков  
Dasher для особых случаев 
Другие языки 
Заглядывая в будущее 
История Dasher 
·Development 2008 « 
·CVS branches 2005 
·Driving methods 
·Button Dasher Notes 
·Japanese alphabets 
·Notes from March 2005 
·Version 3.0.2 Release Notes 
·API Notes 
·Version 3.0.1 Release Notes 
·Notes from 12/02 
·Notes from 11/02 
·Notes from 10/02 
·Further notes 08/02 
·Dasher Plan 07/02 
·Discussion 07/02 
·To Do List 07/02 
·To Do List 04/02 
Обзор прессы 

Search :

Development 2008

Here are some notes on the development of Dasher in 2008.

List of packages required to build Dasher for Gnome (From Peter Conlon.)

Before building, I thought I had installed everything
listed in README in the dasher folder.

The first error was fixed by installing

The following were then needed as I got a little further down automake:
libgtk2.0-dev   (perhaps I didn't have the -dev package initially)
libxtst-dev      (don't know what this is)
libgnome2-dev    (needed dev package)
libgnomeui-dev   (needed dev package)

It also complained about my version of gnome-doc-utils, 0.6.1 on
Debian/etch. Consequently, I had to upgrade to something bigger than 0.9,

So it seems I just didn't have the right -dev packages.

Work-arounds for annoying Dasher features

 1. Solution to the nagging confirmation pop-up. We have a very talented
 amateur-programmer here on the Dasher Group. Himself being handicapped
 (although probably in a somewhat lesser degree) he's very resourceful
 and can customize his communication with the computer, so that it would
 require much less effort. I hope he gets in touch with you, because he
 could probably help you quite a bit more than I. His name is Andre Luiz
 dos Santos. You might have seen his postings to the group. Anyway, he
 works little miracles with a scripting language that is the key element
 of a little task-automating application called AutoHotKey. The miracle
 he worked for me is a tiny script that watches the system for the
 occurence of that particular pop-up and just auto-negates it for me. It
 works brilliant and saves me a bunch of totally useless, unnecessary
 clicks that really got on my nerves. You'll find the the script in the
 attachment. I believe the script should work for any Dasher version.
 Obviously, for the script to work you've got to install the AutoHotKey
 application first (here is the link: ) After that all you need to do is
 to start the script (by double-clicking) -- once you install the
 application, the scripts' file extension "ahk" will be associated with
 it and double-clicking a script file will automatically start the
 AutoHotKey application and load the script into it. As far as I'm
 concerned I created a shortcut for the no-more-confirmation script and
 placed it in the AutoStart folder (to be found in menu Start->Programs).
 That way the script starts together with the system and I can cross the
 confirmation pop-up's problem from my mind for good.

See also


Overview of Dasher status (email by DJCM)

[recap of some of Chris's main points:] >> For the past few months, my frustration with recent versions of Dasher >> had grown to the point where I was seriously considering trying to >> rewrite large portions of it. >> Many projects that are initiated by companies and universities have difficulty working with outside developers. >> I'd like to see a public mailing list for developers. >> I'd like discussions about the plans for Dasher to have a means for outside input. Patches should be posted to a list so they can be commented on, and improved. Using git for the version control would be nice. Someone needs to go through the bugs in Gnome's bugzilla. New commits to the version control should be well-described in the commit message, and should be small and focused. We need tests, and tests should pass before changes are committed. Normal, good development practices. You know what I'm talking about. It's time to bring the development into the open. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When we made Dasher open-source, our hope was that many outside developers would get involved, and that by now Dasher would be out of our hands, being looked after by other people. When I raised money to support a full-time Dasher developer (a position which was funded for 5 years here in Cambridge), the job description was very much along the lines suggested by Chris: Normal, good development practices; involve users; do tests and make sure all releases pass all tests; get other developers involved; document everything. I always wanted the development to be in the open and to have a tight feedback loop with users and testers. That's always been the dream, but many of these desires haven't been realised. The situation now is, having employed three Dasher developers over those 5 years, we have now lost Phil Cowans to .com-land, and the money has run out (at least until September 2008). So Dasher is a drifting tanker with no engine, except for us volunteers. (The local volunteers in Cambridge Physics dept are Keith Vertanen and David MacKay, and we still have occasional help from Phil Cowans.) Maybe in Sept 2008 we'll get a new engine fitted, and perhaps we can do a better job of satisfying Chris's list. Until then, we need a volunteer plan to handle the most urgent issues. I suggest that a wiki and an email list will be the best way to handle things. One option is to simply use _this_ email list as the forum for the volunteer crew to discuss things. If there are any strong feelings that that would be a bad idea, please email me so and I will sort out another email list. I will send another email shortly with wiki coordinates. thanks all, and sorry that there's not better service from Dasher Central at present!

and From Phil Cowans

Dear Chris and others,

Thanks for yor recent comments on Dasher. As you maybe know, I am no
longer able to devote more than a few hours a week to Dasher as it is no
longer part of my job. However, it does look like there may be enough
momentum here to keep the project alive as a community effort, so we
should try to make that happen and I should try to set things up so that
this can happen as easily as possible.

In terms of tools, we do have the standard set up (version control, bug
tracking etc.), but as development was largely done by me they weren't
generally used by the wider communty. If anyone does want to have access
to these then let me know and it can be arranged. I'll also try to take
stock of the various lists we have lying around and either repurpose one
as a development list or set up a new one so that people interested in
development have a place to talk. Please drop me a line if you'd like to
be on this list and let me know which email address to use.

Aside from that, there are a couple of points to be considered. Firstly,
someone needs to manage the release process - I can try to do that
myself, but I can't guarantee that I'll not run into problems due to my
time constraints, so if anyone is willing to take this on let me know
and I'll explain exactly what's involved.

Secondly, Chris is right that we need to focus on code quality rather
than new features. There is quite a long list of bugs in the database
( which need to be confirmed, prioritised and
eventually fixed, and the code base does need to be thoroughly tested.
Basically there is a role for people who aren't in a position to
contribute code to help with testing and bug checking, so let me know if
you fall into that category.

Finally, if you are interested on working directly on the codebase, drop
me a line with a brief summary of what you expect to be able to
contribute and how much time you can spare, just so I have an idea of
where we stand in terms of resources.


[This message is being sent to the dasherteam Yahoo! group, but being
copied to dasher-text-entry as well. If you are not on the former yet,
but would like to be involved with the development process, let me know
and I'll add you to the list.]

As you may know Dasher does not currently have anyone working full time
on development. However, there is clearly a lot of demand from the user
community for bugfixes and new features, so it would be fantastic to
open the development process up to more community involvement. The
intention is to use this list ( to coordinate
development activities, so if anyone has any ideas for features, or is
interested in working on any particular aspect of Dasher then send a
message to the list. I have also created a wiki page on the GNOME Live!
site at, which might be useful for
prioritising work, keeping shared developer documentation and so on.

The source code for Dasher is in the GNOME Subversion repository, which
is located at The site includes instructions on
how to use Subversion for anyone who's not familiar with the system. To
have write access to the repository you need a GNOME account, but anyone
can check out the latest version of the code. I'd ideally like to get
people committing their changes directly as soon as possible, but to
start of with please submit patches either through the bug tracking
system or by email.

Bugs are tracked through the GNOME Bugzilla system, at, under the product 'dasher'. I've just spent
some time cleaning up the bug listing, so things should be fairly up to
date and have the correct severities. I'd be very happy for anyone to
claim any of the bugs marked as new or unconfirmed - let me know if you
need your Bugzilla account permissions changed to be able to do this. If
you do take over any of the bugs, please assign them to yourself so that
others know that the issue is being worked on.

In terms of priorities, I think it would be good to first check the
unconfirmed bugs. These are mainly from the crash reporting system, so
there are probably a lot of duplicates. Having done that we should work
down the list in order of severity, and then start with the
enhancements. Something you may be interested in is that the GNOME
outreach programme is offering cash for people to fix accessibility
bugs, including several in Dasher - see for details.

One other issue is the roadmap and release process. It might be a good
idea to use the wiki to try and plan future development, including
target release dates and what's going to be included in each release.

Finally, if anyone has any ideas on how to encourage community
participation, I'd be very interested.

"The Inference Group" при поддержке "the Gatsby Foundation"
и в тесном сотрудничестве с "IBM Zurich Research Laboratory"
Дэвид Маккэй
Последнее обновление сайта Fri Oct 1 10:33:21 BST 2010