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:
http://www.autohotkey.com/download/ ) 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.
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;
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
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
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
(http://bugzilla.gnome.org/) 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 (email@example.com) 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 http://live.gnome.org/Dasher, 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 http://svn.gnome.org/. 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
http://bugzilla.gnome.org/, 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
http://www.gnome.org/projects/outreach/a11y/ 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.
L'Inference Group è supportato dalla Fondazione Gatsby
e da una collaborazione con l'istituto di ricerca IBM di Zurigo
Ultima modifica Fri Oct 1 10:33:27 BST 2010