From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from server1.shellworld.net ([64.39.15.178] ident=root) by speech.braille.uwo.ca with esmtp (Exim 3.35 #1 (Debian)) id 18pEQs-00071G-00 for ; Sat, 01 Mar 2003 16:22:10 -0500 Received: from localhost (ldavis@localhost) by server1.shellworld.net (8.11.1/8.11.1) with ESMTP id h21LM8137281 for ; Sat, 1 Mar 2003 15:22:08 -0600 (CST) (envelope-from ldavis@shellworld.net) Date: Sat, 1 Mar 2003 15:22:08 -0600 (CST) From: Luke Davis To: speakup@braille.uwo.ca Subject: Re: Configuration Files In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: speakup-admin@braille.uwo.ca Errors-To: speakup-admin@braille.uwo.ca X-BeenThere: speakup@braille.uwo.ca X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: speakup@braille.uwo.ca List-Help: List-Post: List-Subscribe: , List-Id: Speakup is a screen review system for Linux. List-Unsubscribe: , List-Archive: On Sat, 1 Mar 2003, Kirk Reiser wrote: > Well, you have to keep some things in mind when discussing or thinking > about changes to speakup for whatever reason: one is speakup is kernel > code. Two is speakup is kernel code. 'grin' Man, have I noticed.:) > What I mean is the fewer things you can do in kernel code the better. I will leave this here, as the cardinal rule of design. I am one of those who believes speakup probably shouldn't be in the kernel to begin with, but I do not trust my abilities even a fraction enough to tackle that perceived problem, and I am wavering ever so slightly as to whether it is, in fact, a problem. Still, the above statement has the ring of moral authority with me, so worry not. > So saying all of the above I would not recommend changes to speakup to > change it's settings directly because of the amount of time which > would need to be spent in kernel space to accomplish those changes. > Specifically I mean writing functions which would have to wait for > user input of data such as rate changes because of the time involved. No no no! Any changes would be done either by a user level program. The only thing that speakup would have to do, is load a binary file (don't like that idea, because it would be arch specific), file of number sets which had meaning only to speakup (bad because the users could too easily corrupt it), or hex file. >>From the Speakup side, there would be no direct user interaction for configuration, except maybe for the already existent /proc/speakup interface. > Now, changes which would be useful and as you pointed out are already I will just say this about the changes you suggested as alternatives. I am predisposed to writing the config interface for a few reasons. One of which is that I have experience doing this, and have a fairly developed mental picture of how it should happen. Another is that it is a change that interests me, and that I think I can probably accomplish, whereas things such as attribute identification, cursor tracking, etc., are items for which I can not even begin to conceive a solution. > on the todo list is a mechanism to identify what program/application > is running on this console and load a configuration change if one is > available to modify speakup for this app. I don't really think it is and where would it get said configuration changes? Perhaps from a config file? > Looking back through this I'm not sure I actually answered your > question. You did ask my opinion and you definitely got that. > Anything you wish to do to help speakups development is appreciated. > The more needed the enhancements the more appreciation will be accrued. Yes, I believe so. I'm putting you in the "probably not worth it" column.:) I'll probably end up writing it anyway, or at least starting/trying, unless you flat out ask me to abandon this line of activity, in which case I most likely will, in favor of something else. However, I really do think there is long term value in this. Luke