Before building, I thought I had installed everything listed in README in the dasher folder. The first error was fixed by installing libgconf2-dev 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) libatspi-dev 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.
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. See also http://www.nabble.com/forum/ViewPost.jtp?post=10330255&framed=y
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 (dasherteam@yahoogroups.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.EndPage Alias CVSbranches2005.html FoldingPage CVS branches 2005
Gnome is going into feature freeze for its 2.12 release cycle from today; the release of Gnome 2.12.0 will be on September 7th. This means that we need to start preparing a CVS branch for that release, and that string or UI changes to that branch will first need to be announced, and later (after July 25th) need permission from the Gnome release team. Since we have some new release targets of our own, we'll be making several CVS branches immediately: dasher_3_2: This branch will be for the 3.2 release that coincides with DJCM's July 13th deadline and subsequent releases of 3.2. (In practise, we don't expect many more of those. See below on HEAD.) gnome-2-12: This branch will be for the 3.2 release that freezes immediately and is released with Gnome 2.12.0. Bug fixes will be applied, but not DJCM's eight proposed new features, and preferably not string or UI changes unless necessary. If they *are* necessary, please let me know before committing them and I'll let the release team know. HEAD: This branch will be for Dasher 4.0.0, which will contain a heavily rewritten core, as proposed by Phil and Brian. So. Please commit the bugfixes that turn (what was until today) "current HEAD" into a stable Dasher release to the gnome-2-12 and dasher_3_2 branches, committing bugfixes to gnome-2-12 and bugfixes plus new features to dasher_3_2.EndPage Alias Documentation05.html FoldingPage Documentation
We strongly encourage users to optimize the training text for their personal use. Dasher learns all the time as you write, and saves what it learns in a file (for example, all the writing of a linux user using English will be stored in a file called ~/.dasher/training_english_GB.txt). It is a great idea to take a load of text that is like what you are going to write in the future and put it into this file, or into the equivalent system-wide file (for example, /usr/local/share/dasher/training_english_GB.txt on a linux system). Next time Dasher is started, or next time you switch alphabet, both these files will be read so as to train the language model to make appropriate predictions.
Users can configure the colours used by Dasher. Dasher uses 242 colours at any one time. How those colours are defined and used is specified by two files, the alphabet file (Example) and the colour file (example). Both these XML files are plain text files that you can edit. The alphabet file specifies by numbers between 1 and 242 which colours each letter and group in the alphabet should have. The colour file defines what those 242 colours actually are.
Version 4 of Dasher offers several colour schemes to choose among. Many of our alphabets use a colour scheme (a 'palette') called European/Asian. Here's how the default colours work for European languages. The GROUPS are coloured like this:
This page describes uses of Dasher in educational settings, especially in mainstream schools.
Dasher is a component in a project by
Ian Usher E-Learning Co-ordinator, Research & Development School Improvement Service, Buckinghamshire County Council [e] iusher[AT]buckscc.gov.uk [skype] iusher [t] 01296 382038 [m] 07747 757868This project is being developed as a `Nesta Futurelab design challenge'.
Neil Dennison [Neil[AT]THEi.info], in a City Learning Centre in Bristol, has conducted pilot projects where young children are plonked in front of Dasher and asked to write.
Dr. Mark Winterbottom [mw244[AT]cam.ac.uk] is also interested in research projects investigating Dasher in schools.
Dr. Mark Winterbottom [mw244[AT]cam.ac.uk] Lecturer in Education Faculty of Education University of Cambridge
If you know of other educational work with Dasher, please let David MacKay know.
EndPage Alias DrivingDasher.html FoldingPage Driving methodsI have put a lot of effort into making alphabet files. Helped by omniglot, mimer, and theodora.
All the alphabets can be found here. And this table has them all sorted by region.
Recent additions for which I need help or advice are
The core zooming function of regular Dasher involves the following sequence of subroutines[in files shown]
TapOn[DasherInterface]
-> TapOnDisplay [DasherViewSquare]
-> Tap_on_display[DasherModel]
-> Render
DrawMouse
Display
-> NewFrame
With the new button modes, we mimic the above sequence by calling
GoTo[DasherInterface]
which calls
MultiStepGoTo[DasherInterface]
-> PlanGoTo [DasherViewSquare]
-> PlanGoTo [DasherModel]
Loop through iSteps{
-> StepGoTo [DasherViewSquare]
-> NewGoTo [DasherModel]
-> Render
-> Display
}
-> FinalGoTo [DasherViewSquare]
-> NewGoTo [DasherModel]
-> Render
-> Display
It is important that we exploit the full accuracy of the user's click timing. It is very likely that their accuracy is similar to, or possibly even smaller than, the time between successive renderings of the falling pointer. It's thus essential, I think, that we keep track of the actual TIME of the click event, relative to the last rendering time, in order to get SUPERRESOLUTION of the mousey coordinate.
So the code should look something like this:
set pointer coordinate
render the pointer at y1
note the time t1
decide where the next pointer will be rendered y2, and
estimate the time t2 at which that will happen
IF ( click event happens )
Note time t at which click event happened
Define
y = (t-t1) * y2 + (t2-t) * y1
-------------------------
t2-t1
Initiate zoom in on location y.
(Special case event handling:
if t>t2, declare t=t2, before doing the y formula;
and if a click occurs before we have rendered the first
pointer at y1=CANVAS_TOP, declare y=CANVAS_TOP)
During a zoom: When the above computation of "y" has occurred, I think it will be very helpful to the user to see visualized on the screen a splat mark that shows WHERE Y WAS. That way, they will learn whether they clicked earlier or later than they intended. I think a good way to do this will be to create a new routine called draw_splat_at_dasher_coordinate_y(dashery) .
The way this will work is: when the zoom is initiated, my GoTo routine, which receives dashery (which has been put through screen2dasher) remembers that dashery value, and, every time it does a Render and Display, it will also Draw a splat object (which should be an object that looks just like the pointer arrow object, except maybe it could have a different colour, like red) at that dashery coordinate (appropriately mapped through dasher2screen). Because a zoom is busy happening, the splat object won't be rendered at the same canvas y coordinate as the click happened - indeed, during the zoom, it will be rendered at a sequency of positions that drift to the CENTRE of the screen, because of the zoom being a zoom-in-on y.
I'd like there to be two objects, a splat object that GoTo knows about and renders, and the regular bouncing pointer, which is not rendered during the zoom event (or else is rendered at CANVAS_TOP during every frame of the zoom), and which is another piece of code's responsiblity. The regular bouncing pointer should be reset to CANVAS_TOP when the zoom event is started.
Some handwritten notes on Dasher code are here
EndPage Alias ChineseDevelopment.html FoldingPage ChineseI have found a Chinese corpus which gives both pinyin and Chinese Character strings together. I used this corpus to make our pinyin corpus download/training/training_pinyin_CN.txt and a "Ruby" corpus download/training/training_chineseRuby_CN.txt . [Ruby is our name for mixed phonetic text and chinese or Japanese characters; in Japanese, we call Ruby furigana.]
The original corpus is in /home/mackay/dasher/incoming/chinese/pinyin and /home/mackay/dasher/incoming/chinese/character.
My perl program that creates the Ruby output is /home/mackay/dasher/incoming/chinese/pinyin/CONVERTP.p . The associated alphabet file is alphabet.chineseRuby.xml
My perl program that creates the pure pinyin output is /home/mackay/dasher/incoming/chinese/pinyin/CONVERT3.p . The associated alphabet file is alphabet.pinyin.xml .
On Fri 5/8/05 I fixed an error in my conversion program, with the help of Chunlin Ji. Here are his notes.
Rules to mark the tone for Pinyin:
For a detailed guide to the rules of Pinyin,please refer to the following webpages (in English) Combinations of initials and finals (http://www.pinyin.info/rules/initials_finals.html) Where do the tone marks go? (http://www.pinyin.info/rules/where.html) Basic Rules of Hanyu Pinyin Orthography (http://www.pinyin.info/readings/zyg/rules.html)
Software: Here are some free and popular input methods in Linux. I guess they may contain the source codes to convert Pinyin to Chinese characters. 1.SICM: http://www.scim-im.org/ (Input methods include (Simplified/Traditional) Chinese, Japanese, Korean and many European languages) 2.Fcitx: http://www.fcitx.org/main/ (In English: http://www.fcitx.org/main/?q=node/10) 3.XCIN: http://xcin.linux.org.tw/intro.En.html (widely used in Taiwan) 4.Chinput: http://www.opencjk.org/~yumj/project-chinput-e.html 5.XSIM: http://developer.berlios.de/projects/xsim/
The bopomofo alphabet is here.
EndPage Alias meeting0407.html FoldingPage Japanese alphabetsFor the last two years, our only Japanese alphabets have been alphabet.Japanese.xml, includes 7000 Kanji sorted into an order recommended on an alphabetization webpage. We also have hiragana, katakana, and roman numerals.
On Tue 10/8/04 I added several more punctuation characters, including middle-dot and Japanese comma, plus lower and upper case romaji to the alphabet.Joyo.xml alphabets. A full list of punctuation characters can be seen in punctuation.xml.
Kaburagi has implemented Furigana scripts.
Further ideas about Japanese Dasher are in the Japanese Dasher wiki
EndPage Alias meeting0503.html FoldingPage Notes from March 2005
Combining accents
are also working well in some linux fonts, but not all. (Which shows, I think,
that we have done it right; it's a font defect.)
For the time being all our european languages use the "composed" form (ie we do not
use combining accents), but from time to time we should revisit this
issue and ask europeans whether they would prefer to
use combining accents.
In anticipation,
I have created a single
latin
ISO-8859 alphabet
in which every latin language can be written.
I've just released version 3.0.2 of Dasher, which can be downloaded from http://www.inference.phy.cam.ac.uk/dasher/Download.html This version should fix the bugs related to zooming at the top and bottom of the canvas, and also introduces a keyboard control method using the up, down and left cursor keys. This is intended for people using switch input, but may be useful for other purposes. Unix users have a new GTK2 interface, which will be compiled automatically if GTKMM is unavailable or if the --with-gtk2 option is passed to ./configure. There's an RPM of the GTK2 version, which should make life easier for people who've had problems satisfying GTKMM dependencies in the past. Developers should note the introduction of a (mostly) C layer that interfaces between the interface and the C++ core. At the moment this still contains some vestigal C++ code, but in future it should be possible to write Dasher interface code in C rather than C++ if desired. Thanks to Phil Cowens for contributing this code. -- Matthew Garrett
Dasher is listed as a Debian unstable package
EndPage Alias api.html FoldingPage API Notes \include{../english/api.html} EndPage Alias meeting0303.html FoldingPage Version 3.0.1 Release Notes Tue 18/3/03The main aims in this release were to deal with obvious bugs and provide various features to support disabled users. The one dimensional input mode may also prove interesting to other users - it may take a small amount of time to get used to it, but you may also find it easier than the traditional two dimensional input.
This version should be considered a fairly good basis for porting to other platforms. I've added an experimental GTK2 interface to the source tree - it works, but most features aren't implemented yet. It's probably a better example for anyone who isn't familiar with GTKMM or Win32 code.
What's changed: General: Default alphabet reordered API documentation added Font size changeable Interfaces now use a crosshair within the Dasher canvas Flicker reduced One dimensional input mode introduced Logical position of the mouse pointer can be displayed All settings should now be saved between runs Various fixes to improve prediction Windows: Windows version can be started and stopped using the space bar rather than themouse Fixed Windows file operations Import training file should now work Fix handling of rapid mouse clicks Unix: GTK version gettextised for ease of translation Added experimental GTK2 versionEndPage Alias meeting0212.html FoldingPage Notes from 12/02
1) The colour scheme and alphabet are pretty intimately related,
so a possible method would be to have the alphabet
file be turned into an augmented file that
specifies the alphabet and the colours too.
2) But that seems a bad idea because it means that every
time a new english alphabet is made, four copies
of ti have to be made, one for each of the four standard
colour schemes (say).
And the way in which (alphabet1,colourscheme1)
differs from (alphabet1,colourscheme2)
will probably have a lot in common with
how (alphabet2,col1)
differs from (alphabet2,col2)
3) So we think that a componential scheme is desirable,
consisting of three components.
Component 1: a list of the letters of the alphabet.
Component 2: an allocation of those letters to
"colour integers".
Component 3: a mapping of those colour integers
to a PAIR of actual colours (one for each
of the levels in the DJW alternation of two
colour sets)
Colour integers could be anything from 0 to 127,
then the total number of colours used by Dasher would be at most
256.
Does this sound a sensible plan?
The idea then is that component 2 could be constructed with
some logical categories in mind; then any component 3 can
respect those logical categories easily.
Examples of requested colour schemes include
a) virtually monochrome
b) very bleached colours
c) reverse video: white chars on blackish backgrounds
d) blue on yellow
e) yellow on blue
XML suggestion
I suggest that the header in the XML file for
alphabets be made a bit more informative.
instead of saying " This file was created by blah "
it should also say
"This file is read by Dasher version 3;
it may be edited by the user to change the alphabet"
or
"This file is read by Dasher version 3;
it should not be edited directly; rather, you should edit
the widg.blah file and then run foo to re-generqate this file"
----
The help file in Dasher 300 is out of date and has
a few minor errors in it.
Dasher 3.0.0 preview 2 is now ready for release on both windows and linux. (Windows 2000 is fine, win 95 not checked yet.) Releases are being bundled today and hopefully will be linked to the website this week. Default location for releases will be at www.inference.phy.cam.ac.uk/dasher/platformname/versionnumber
Please send URLs to DJCM when ready.
The character/square over-writing problem has been solved.
Minor bugs remaining are:
MJG will have more time for Dasher from Dec 9th 2002.
Regular Dasher meetings will happen Wednesdays at 10.15am.
MJG has got Dasher working (nearly) in WINElib so that windows development is possible in a linux environment.
The Dasher job has been advertised and the closing date is this Friday.
Demonstration non-english languages are not yet in 3.0.0; Phil will find out standard portuguese alphabetical order from a friend. lccollate also offers information on alphabetical orders.
The master CVS will be moved from sourceforge back to local machines shortly.
A dedicated old linux machine will be used to run dasher CVS and bugzilla services. Hanna will set up Bugzilla. Phil will select the right machine. Bugzilla should be laoded up with sourceforge bug lists and with old bug lists from /home/mackay/dasher/incoming/bugzilla and with this: http://sourceforge.net/tracker/?atid=481717&group_id=56761&func=browse
Copyright: Code written by Phil is (c) Phil for the time being. Donors outside the group are asked to transfer copyright to the (c) owner of the file they modified, or transfer it to MJG.
Hanna will have version 3 for linux ipaq packaged soon.
MJG recommends buying dasher.org.uk for two years, and having cvs.dasher.org.uk redirect to mull.ra.phy.cam.ac.uk (or whatever the machine will be) because cvs.dasher.org.uk is easier to type than mull.ra.phy.cam.ac.uk.
Good progress is being made on creating Dasher 3.0.0 pre-release for both GNU/linux and ipaq-running-linux.
The procedure for installing linux 300 from sourceforge is
cvs -d:pserver:anonymous@cvs.dasher.sourceforge.net:/cvsroot/dasher login cvs -z3 -d:pserver:anonymous@cvs.dasher.sourceforge.net:/cvsroot/dasher co dasher3 cd dasher3 ls aclocal autoconf automake ./configure make make install
Hanna is working on the port of Dasher 3 to the ipaq-running-linux and is also planning to work on "dash", the dasher command shell.
EndPage FoldingPage Notes from 10/02
Present: David MacKay (djcm), Phil Cowans (pjc),
Iain Murray (iam), Matthew Garrett (mjg)
Priorities from the point of view of iam
1. Standardise / stabilise core - review design first (mjg to do this)
2. Desired release types:
(a) Windows - installer .exe
(b) Linux - GTK ok, but not necessarily gnome
Would like .deb, .rpm and .tar.gz at least, with
minimal dependencies.
3. Documentation, comments, explaining everything to mjg &c.
4. Rearrange CVS structure to make internal/external interface
differentiation clear
5. Need detailed specifcation for the core
6. Finalise splitting/combining rules etc. for unicode accent marks
Possible functions to be included in future versions:
(a) Dasher core
(*) Control menu character - like esc in vi, appearing before 'a'
and containing things like 'oops', 'stop', other menu optons
(speak &c.)
(*) Core support for one-dimensional version (possibly just a
mapping to an effective cursor position)
(*) [Support for hiding passwords?]
(*) Piping to other apps (such as speech synthesizer) - should be
accessible through control character
(*) Embedding / better interaction with other apps (ActiveX,
Bonobo etc.)
(*) Capability to include foreign chracters in text
(*) Identify and reject stupid (eg pdf) training files (eg if more
than 10% of characters end up being ignored) (also, how should one
deal with the odd foreign character in the training file, eg an
umlaut on the word naive?)
(*) Multithreading to enable training in background
(*) Port for palm, psion etc.
(b) UI tweaks
(*) Combining / unicde conversion etc. to be finalised - There are
three possible ways of doing this:
(i) Force minimal expansion (one char per glyph)
(ii) Allow standard expansions, to be handled by a standard
library
(iii) Allow custom combination rules (hard to implement)
It was decided that implementing (i) and (ii) was a sensible
compromise.
(*) Support to guess alphabet from locale etc.
(*) Colours - user confgurations, also assigning specific colours
to specific symbols.
Plan for the future:
1. Get 3.0rc1 out the door for Win NT, Win 9x, Linux, Mac etc.
(a) WinNT right away
(b) Linux - need alphabet/settings etc., but possibly relatively soon
(c) 9x later
(d) Give source to mac os person
And then work towards full 3.0 release based on peoples comments,
maybe at the end of November.
2. 3.1 has control mode (+ continue with bugfixes etc.), gtk v2.0 in Linux
Languages can be added along the way
--
Further notes added by DJCM Mon 21/10/02
The new eyetracker was installed on S's win98 machine by Phil today.
Dasher works pretty well at 70cm. No recallibration was necessary
between uses. The lens focal length is too short for
satisfactory use at a range of 100cm. I have asked Eyetech whether
we can get a longer focal-length lens. A first run with S may
take place on Wednesday. An important issue is the creation of
an appropriate button-driven control for starting and stopping Dasher.
EndPage
Alias plan0208.html
FoldingPage Further notes 08/02
I've started uploading stuff to CVS on sourceforge. To save you some time, here is some info to get you started. Its all documented at sourceforge. You can browse CVS on the web here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dasher/ There seem to be 2 shell accounts - but I think they both map to the same home space. I think that only the second will allow access to the Dasher website. ssh username@shell.sourceforge.net ssh username@dasher.sourceforge.net To get passwordless access to the shell accounts, do the usual thing of uploding your .ssh public key to .ssh/authorised_keys on sourceforge. The CVS respository is here: cvs.dasher.sourceforge.net:/cvsroot/dasher You should be able to ssh to it to test it. To get passwordless ssh access to CVS, you have to upload your ssh public key via the web interface (go to account maintenance). It takes six hours for the public key to go live. I seem to have everything working smoothly now without passwords (with WinCVS 1.3.6 and ssh1.2.14 for Win32). Let me know if you have any questions. Only 'Developers/Admins' can check in stuff. That list is currenly me,IAM,PJC,DJCM,mrtgrady.EndPage Alias plan0207.html FoldingPage Dasher Plan 07/02
IAM will be developing Dasher full time for the next ~2 months until mid-September 2002. DJCM is looking into support for the project beyond that. The commitment required will depend on the amount of help we can obtain from the Open Source community, though we probably want someone in the group to manage the project.
IAM will address the most pressing needs of Dasher 2.x. For example the zoom-rate of the Dasher interface needs to be controllable rather than a constant. Some other parts of the user interface needs attention, but it must be kept simple to use. Once DJCM is happy that the current source tree is usable and license issues are sorted out we can make our first release on Sourceforge. By this stage we have not necessarily finalised the class interfaces. Therefore we must emphasise that people should not rush into building ports around this version, but instead ask for comments and bug reports. DJCM will email people that have expressed interest in Dasher in the past about this release. The source to 1.6.8 could be released at the same time.
The advantages of using Sourceforge are apparent:
However, for the moment Sourceforge is unfamiliar and IAM is not ready to interact with other contributers yet. We will continue to use CVS on coll. DJCM, PJC, IAM and DJW will have write access. The rest of the group will have read access. Until the CVS is moved to Sourceforge we will have to provide regular archives of the source so that any contributed diff's will be useful.
After the initial release IAM will work through his TODO list (coll:~iam23/Dasher2do.txt), which is based largely on Bugzilla and the Dasher site. It is desirable to make the code completely Windows independent. Ideally a Dasher library could be used by any application on any system.
We would like to publicise Dasher as widely as possible. Perhaps on Slashdot and FreshMeat. We are likely to get the best response from these audiences if an up-to-date Linux version is available.
IAM will look seriously at producing an interface to a Dasher library using wxwindows. This is a set of C++ libraries that could allow easy support for Windows, Mac and UNIX simultaneously. The Pocket PC version should be addressed too.
If IAM has time he will look into a new approach for updating the zoom-rate of the interface.
Currently we have no plans to trademark the name Dasher. The license and copyright notices attached to the Dasher source-code are still undecided. Features of the required license include:
Discussions so far have centred around the GNU General Public License, the GPL, and its Lesser variant, the LGPL. A BSD-style license was rejected as it does not ensure derivatives make their way back to the group. At the moment we have not had a chance to look into other open source licenses.
There is concern that a license with GNU in it may put of some potential backers of the project. In particular Microsoft's support may be important as the provider of the most popular desktop operating system. We need to find out if this will be an issue. Releasing the code under the GPL is irreversible, so we need to be very sure before we do so. Otherwise the GPL could be appropriate for Dasher as a whole. It allows people to charge for distribution and anyone to use it. In addition it guarantees perpetual access to the source for all.
It is possible that the core of Dasher, made available as a library, could carry different license terms to its graphical user interface (GUI). We believe that the GPL could also be appropriate for an application that can embed itself into other applications, for example using OLE under Windows, or Bonobo under GNOME. However, we will consider the LGPL for a core library version of Dasher.
Since the meeting IAM has noted Free Software Foundation (FSF) advice to include a sound copyright notice. Only the copyright holder of a work is able to take action if the GPL is violated. In fact the FSF insists that any contributions to its software are donated to them and advises others do the same (The rest of the FAQ is useful too). Also the LGPL, although not preferred by the FSF, may be appropriate if our aim is to ensure widespread use:
We call this license the "Lesser" General Public License
because it does Less to protect the user's freedom than the
ordinary General Public License. It also provides other free
software developers Less of an advantage over competing non-free
programs...
...on rare occasions, there may be a special need to encourage the
widest possible use of a certain library, so that it becomes a
de-facto standard.
I have been thinking about dasher while reading a book about Open Source. I suggest the following plan for "control while dashing" 1. Have an option to add an "ESC" character to the alphabet. a) in all contexts b) only in post-punctuation contexts Option b means that the ESC character has very near zero probability when the latest character is a..zA..Z or any other letter in that class. In other contexts, the ESC character is given a probability at least pESCmin (eg 1/100), and possibly larger, depending on how strong the predns are in the current context. If the lang model makes a strong prediction (eg it knows what word is coming next) then we don't want to spoil this predn by filling the screen with ESC. But in a bland context, maybe as much as 1/15 could be ESC. 2. Show the ESC character by a special colour box, located at the top of the alphabet before a. Note, this will solve the aaaa problem, perhaps. 3. Inside the ESC box, provide a set of equal probability boxes emulating a menu of control options. If necessary have some options lead to sub options. Have the control options be identical to the optins available by clicking buttons off the dasher canvas. For crucial actions such as "close dasher", "new file", have a confirm dialog, "yes"/"no", all implemented by regular dashing dynamics. For all appropriate menus, have the bottom item in the list be an "abort command mode" option, coloured a special colour, which takes one back to writing in the current context.
djcm to djw: Iain was asking whether there is any particular reason for the distinction between the two boundaries in pocketPC dasher - text that has fallen off the LHS goes into the text box when writing; when not writing, text to the left of halfway goes in the text box. I am used to this and it doesn't bother me, but Iain was suggesting an alternate procedure of putting stuff in the text box when it has passed halfway and corresponds to a box that contains the crosshair. My guess is that your rationale was to only put stuff in the text box when it has been definitely committed. (except when the user stops writing) This probably is a good rationale, since otherwise users will start to fret about thinking they have written something and trying to undo it when in fact they simply clipped a big box on the way to their intended little box. It might be helpful if you told us your thinking on this. A possible problem with the LHS rule is that if the user wishes to use a large left-hand context on screen (as can be done in 168 with the log controls) then there is a big delay before stuff goes to the text box. djw to djcm: I intended that version 2 should always display the text upto the crosshair and not just dump it out when you lift the pen. See version 168 for the behaviour I prefer. However, the LHS is significant for me because that's when I add characters to the language model (also where I prune the data structure but that's just implementation). If you add what ever appears under the cross-hair to the LM then you end up feeding part-gibberish into it. But my method of adding to the LM can also break if you are allowed to zoom out or edit text. Removing stuff from the LM would be very tedious. So there are some things to think about. How Dasher would operate as a conventinal keyboard is not straightforward. E.g. if you write rm -rf\n into your shell, when does it execute the command? What if I zoom out - can I undo my command!!! David. djcm to djw: ------------- I would suggest this: whenever there is a character which is the final character in a command of some sort (eg \n in rm *\n ) this character should contain within it a special coloured sub-square, of size (say) 1/3, padded on either side by two alternate "abort" squares, so that the user is unlikely to accidentally pass the special "do it!" subsquare, which is central, over the crosshair. The "abort" squares could be functionless squares that just act as padding, or they could have an appropriate function (equiv to C-C, say)EndPage Alias todo2.html FoldingPage To Do List 07/02
Punctuation ideas.
I would like to suggest a minimal alphabet, a medium alphabet, and
a full alphabet.
The default would be the medium one.
(1)
MINIMAL = lower case only, and a tiny number of punc chars.
No numbers. Good for writing conversation, email. Similar to dasher 168.
Space character always at end of list (displayed by underscore, by default,
but the character used to show the space should be adjustable by the
user, eventually).
(I won't show the space char in the any of the following)
a..z'-?!,.
(2) a MEDIUM punctuation list.
Let's build it up. Upper case included in the default.
a..zA..Z0123456789$'-?!,.
or
1234567890$'-?!,.
probably the latter is more standard, cf keyboard. (zero location)
- provide this punctuation set as standard in all languages.
Other punctuation to be optional.....? Or maybe....
(1a) Borderline punctuation chars that
could have a strong case for being in the minimal standard list:
/:@
I'll leave this decision up to you. I think I would tend towards
including them.
Where to include these if you do include them:
I don't have a strong opinion, but suggest this,
which preserves a distinction between "ordinary writing" ( $'-:?!,. )
and funny characters.
VV V
1234567890/@$'-:?!,.
However an argument for this order:
1234567890/$@'-:?!,.
is that $ is associated with numbers more than is @.
Another borderline character is the NEWLINE character, represented by P
here. I would put it here
(since it is a lot like white space)
1234567890/$@'-:?!,.P
Note the grouping of all characters with status similar to full stop adjacent to
the space char. - The chars "/$@" are not similar to full stop. The others are.
The character "'" is not always like a full stop but you do tend
to find it at the end of words.
The characters ( and ) should perhaps be included in the
minimal alphabet too.
Where to put them?
Either straight after a..zA..Z
()1234567890/$@'-:?!,.P
or else adjacent to the quote mark, since it is a similar delimiter:
1234567890/$@()'-:?!,.P
Another candidate for the minimal alphabet is the POUND sign,
or #, to be located next to the $. I will write it as # from now on.
In conclusion this is the largest "medium" list I would go for.
1234567890/#$@()'-:?!,.P
(2) Here is a suggestion for the whole punctuation list
What have we left out?
stop-like characters: ;
quote-like: "`
paren-like: []{}<> (in your choice of order)
strange characters, like @ |\~^_& (in any order)
characters associated with numbers, like / and $:
%*+= (in any order)
any others? YEN, Euro.
I would put these in the medium list along with their cousins.
So it looks like this:
1234567890%*+=/#$|\~^_&@[]{}<>()"`'-:;?!,.P
That's my best stab, feel free to modify it.
EndPage
Alias todo.html
FoldingPage To Do List 04/02