OK, simply fixed, have a LastRunChecker instance for each node and call the run method for the node being updated. Probably you would have a HashMap<String, LastRunChecker> to map string node IDs to the LastRunChecker instances.
One could do this slightly different by changing the LastRunChecker class so that waitDuration is of type HashMap<String, long> and the run method takes node ID as a string. However this then makes the LastRunChecker specific to node updating.
Michael Whapples On 04/01/2013 15:44, John J. Boyer wrote:
Thanks for the example. However, suppose the user types something and without pausing moves to the next node. The translation would never be made. We will work this out in time. Can you find an example of a dialog in SWT where the user can tab to different fields and edit them? Thanks, John On Fri, Jan 04, 2013 at 03:28:29PM +0000, Michael Whapples wrote:I don't think waiting for a second after the last key press is too much more complicated. Here is a quick class which should do such checking. public class LastRunChecker { private long waitDuration = 1000; private long lastRun; public void run() { lastRun = System.currentTimeMillis(); try { Thread.sleep(1000); } catch (Exception e) { // Does not need handling } if (System.currentTimeMillis() - lastRun > waitDuration) { // Code for retranslation } } } Note that every call to run should be in a separate thread, may be the starting a new thread should really be in run. At least I think the above will work, I have not actually gone through running it. I think retranslation on pressing space would be error prone as if I were correcting a spelling error I might not actually press space. Michael Whapples On 04/01/2013 14:39, John J. Boyer wrote:Hi Michael, You have a good point. Retranslation could be done when the spacebar is pressed or after the user has not typed for a second or so. However, for text nodes of reasonable length retranslating only from the point of the change is probably not justified by the extra complication. I am copying this message to the list, since I think that is where it should be. John On Fri, Jan 04, 2013 at 10:09:53AM +0000, Michael Whapples wrote:I don't know what my initial view was, but certainly looking at it now, does this seem sensible? What I mean by this, is it wise to retranslate on every character key press? There will be points where it does not logically make sense to translate it as it will not stay that way. An example is if I were typing a word, until the word is complete I am not really bothered about how it has translated it as I will be adding more characters and the translation probably will change very soon. Going with the average word length being approximately 5 characters (I know the precise figure may differ but this is close enough and makes the maths easy), and assuming someone is only typing complete words (not correcting spelling errors), then approximately 80 percent of translations will be rubbish and quickly replaced. Also in most cases the translation before the insertion point will not change, this seems like a huge amount of retranslation which is just unnecessary. So I will ask the question, when is it the user wants a translation done? Once we know that then we can try and find the event which relates to that want. While being a bit more complicated to implement, I would have thought a more efficient thing would to wait for the user to stop typing before retranslating (eg. if they stop typing for a second or more). This still may not quite be when they want the translation done (it is my guess of when I would want it), so back to the question of when do they want it. Michael Whapples On 03/01/2013 20:03, John J. Boyer wrote:We've gone through this before. I thought we had agreed that each text node in an xml file would be dynamically retranslated whenever a character key was pressed. This might throw page breaks, etc. off, but the document could be re-rendered as a whole when it is saved. I've worked out a new function for liblouisutdml to do translate single text nodes, but not implemennted it yet. This would be fast and shouldn't cause a noticeable perfourmance hit. There is no need for radical changes. Just the new function. John V On Thu, Jan 03, 2013 at 06:41:04PM +0000, Keith Creasy wrote:Someone explain to me why we have to pump the entire xml document through LibLouisUTDML other than for pagenation and volume breaks? I'm thinking that we don't but maybe I'm wrong. I have some ideas but they aren't fleshed out yet. Keith Keith Creasy Software Developer American Printing House for the Blind KCreasy@xxxxxxx Phone: 502.895.2405 Skype: keith537 -----Original Message----- From: John Gardner [mailto:john.gardner@xxxxxxxxxxxx] Sent: Thursday, January 03, 2013 1:17 PM To: 'Michael Whapples' Cc: Keith Creasy; 'John J. Boyer' Subject: RE: Steering committee Michael, yes there are lots of good reasons that you don't want to send page-by-page info to any printer. As for device-independence, yes it is true that the utdml Braille formatting is done for a particular page size, line length, etc. But if one wants to send it to another device, you just send the file back to liblouistdml with different parameters. At least liblouistdml is fast. I really don't see any advantage to doing anything else if the goal is getting embossed Braille. I just don't know whether it is practical to use liblouistdml for on-the-fly Braille translation/formatting. Probably not because it will spend too much time re-processing previous pages. So what one would need is some kind of differential liblouistdml that would accept everything up to page x and then translate/format everything beyond that point. Maybe not elegant, but it might be better in some ways than using style sheets. Thoughts from JJB and Keith? John -----Original Message----- From: Michael Whapples [mailto:michael.whapples@xxxxxxxxxxxx] Sent: Thursday, January 03, 2013 10:06 AM To: John Gardner Cc: 'Keith Creasy'; 'John J. Boyer' Subject: Re: Steering committee I guess with on the fly formatting, the speed would depend on how much one had to get done. An example would be if the on screen display only showed one Braille page then it only need format one page before it can show it, the rest could be done in the background or if it were fast enough done as those pages come into view. Whether for embossing one could actually start sending the first page to the embosser while formatting the next page, and so on I don't know. I get the feeling for ViewPlus embossers, possibly not as it goes through the Windows print system and for that doesn't one need to send the whole file at once, otherwise there may be a risk that something else may send its document between your pages (IE. if you sent a page at a time by sending a file which contained each page). Although I have to say it does sound a nice idea if one could have a Braille translation of a document which was device independent and it is formatted when one decides what device they will be sending it to. Michael Whapples On 03/01/2013 17:55, John Gardner wrote:I'm not quite following the subtle details of this discussion Keith. What I think I hear is that you would like an architecture that would send text to liblouis (or other) to be translated as a step in the process. Then as a separate step, you would allow CSS or XSLT to format that Braille on the fly. I see no role for utdml in that process. There is nothing wrong in principle with doing it your way, but there would need to be a big development project to get the formattingright.FYI there is a French-led project to translate math using CSS. I understand that it does a good job on French math and maybe others, but it is apparently very very slow. And it is not intended to be 'on the fly'. Is speed gonna be an issue for on-the-fly formatting? John -----Original Message----- From: Keith Creasy [mailto:kcreasy@xxxxxxx] Sent: Thursday, January 03, 2013 7:46 AM To: John Gardner; 'Michael Whapples'; 'John J. Boyer' Subject: RE: Steering committee Hi John. The disagreement is more about how and where UTDML gets applied I think. I assume we'll be using LibLouis UTDML perhaps with somemodifications.Yes, I do think translation and formatting are two separate things but that's a different issue. My intent is to make them separate at some point even if it means extending BrailleBlaster. As far as mainstream applications formatting braille correctly I'm not sure what you are asking. No application that doesn't have rules for braille are going to do it right. In that sense I do agree. I would submit however that CSS and XSLT as well as other technologies are pretty powerful and could go a long way toward rendering braille correctly from any XML document type. I even had a discussion with Brandon this morning about the possibility of using a web-based UIconnected to a service.In any case I think we've decided, once again, that we'll let BrailleBlaster go where you, Michael, and John B. want it to go and we'll contribute as we can. If we deccide it doesn't really work well enough in a production environment then we'll extend it or simply create another UI for LibLouis and LibLouis UTDML. Keith Creasy Software Developer American Printing House for the Blind KCreasy@xxxxxxx Phone: 502.895.2405 Skype: keith537 -----Original Message----- From: John Gardner [mailto:john.gardner@xxxxxxxxxxxx] Sent: Thursday, January 03, 2013 10:28 AM To: Keith Creasy; 'Michael Whapples'; 'John J. Boyer' Subject: Steering committee Hi, I took this discussion off the list for a short steering committee discussion. I fully approve of BB as an XML editor - it has been from the beginning, but also from the beginning we wanted it to look and feel like a simple WYSIWYG to novices. I think we are all on the samepage here.Where we are not on the same page is about the utdmo format, and I am not enough of a software person to know how to bridge this gap. Utdml was devised to be a format for embossed Braille, having all the Braille formatting embedded. Admittedly it is a strange beast, but the formatting is 90% of the problem in Braille "translation" according to my friend Susan Jollly. I agree with Susan in this respect. My understanding is that Keith would like to have Braille formatted separately from translation and to have it done in BrailleBlaster, not in liblouistdml. As long as we get properly-formatted embossed Braille out, I guess it wouldn't really matter. But in fact the liblouistdml routine that does both is working pretty well now, and ViewPlus is using it in virtually all new developments. It would be a big problem for us to reverse course unless we had a really big reason todo it.So Keith, I guess I put this into your court. I do not believe that any standard mainstream application can format Braille and get it right. Am I wrong? John G -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith Creasy Sent: Thursday, January 03, 2013 6:50 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: Different Approaches to document processing. Michael. What other design patterns/practices do you think we should consider? Yes, I agree 100% that whenever possible we should use established mainstream design practices and standards, like MVC CSS, and XSLT, because a lot of developers already know and understand them. About XML editing, don't confuse the term XML Editor" with something that has to be complicated and technical. It can still be fairly simple. Also, I've always felt that it should be something that doesn't have to be used by people who just want to write and print braille. Since we are editing XML (UTDML) then one could posit that BrailleBlaster is an XML editor whether it appears that way or not to users. Keith Creasy Software Developer American Printing House for the Blind KCreasy@xxxxxxx Phone: 502.895.2405 Skype: keith537 -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples Sent: Thursday, January 03, 2013 9:36 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: Different Approaches to document processing. Hello, I have had some concerns over the design of BrailleBlaster for a little bit, that is partly why I decided to keep away from dealing in the code too much and restrict myself to managing the project site andrepositories.Keith I know you mentioned about MVC, yes that probably would be a good idea, but may be BrailleBlaster needs to make use of other design patterns and other good practice as well. By neglecting these things its probably made the code and design much harder to follow and means that where one might use standard terms these might not apply or may even have a different meaning and so leading to miscommunications. Regarding the use of semantic actions, I would dispute the arguement that they are easier to use than XSL. My reasoning here again goes along the line of using something familiar to people, XSLT is widely used and so potential developers may already be familiar with it, should one have a difficulty in making it do what they need then it is much more likely they will find an answer (even if the answer is "not possible") by searching the internet as there is much more information outthere on XSLT.Keith you mention about defining a document interface, yes this is something I have felt for some time, the view should have no need to understand the underlying document format, it should deal with a single document interface which through various adaptors/providers will modify the document in the appropriate way. As an example, the view should only deal with headings, it should not be concerned with howHTML or DocX store a heading.My understanding at present is that the semantic actions miss out the document interface stage, mapping straight from a file format to how they should be presented. This step really should be split, actions for adapting the format into the document interface and actions for how the view will render the document structure element. The former of these would not need to be customisable by users (only developers who want to add support for additional formats need work with it), whereas the latter would be desirable to be customised by users (eg. sighted users may want headings shown in a different colour, but those who are colour blind may wish to configure it so that headings can be distinguished without the use of colour). If one does not separate these concerns then users may need to deal with every file format they wish to use, meaning additional work for the user and potentially requiring them to have fairly advanced knowledge we really should notexpect of users.As for whether BrailleBlaster should have a XML editor, my view would be not. Such an editor would be contrary to the initial aims of BrailleBlaster being easy to use by those with little computer knowledge (IE. not expect more knowledge than knowing how to use a word processor like Word), as an XML editor would require understanding of the underlying XML format. As mentioned, if someone wishes to have such an editor then there are probably other tools moresuited for doing that XML editing.Also I feel by spending time on features not really adding to what BrailleBlaster is aimed to achieve will just delay BrailleBlaster ever reaching the goal of what we want it to be. I know some may feel I possibly have a restricted view of what BrailleBlaster should be, my response is that I feel keep it focused to do a particular task for a particular type of user and do that very well. If one tries to make something which is everything for everyone, then it runs the risk of actually not working well for anyone (IE. its too complicated for beginners and have annoying features for experts). There is certainly some software I can think of which falls in the category of trying to be everything to everyone but not working well for anyone, where competing products while more restricted work farbetter.There possibly is more, but I possibly have raised it in the past with little affect. So in that spirit, I have pretty well said what I feel, unless further discussion would go anywhere I don't really have much apitite to get into big discussions now. In general I think Keith is making some reasonable points. Michael Whapples On 03/01/2013 12:45, Keith Creasy wrote:Yes, I've read the comments in the code and your architecture file. Veryhelpful.We need to work on the interface between the views and the document. Thatprobably means defining a document interface and a view interface that is XML centric.John, I'm not sure what anyone else can contribute since you want controlof the word processor and the document model. Until those are fleshed out there's not really much anyone else can do. At least, speaking for myself, I can't think of anything substantive I can contribute.I'm beginning to think that an XML editor really has no place here. Anyonecan just use an external XML editor if they need to do that.Keith Creasy Software Developer American Printing House for the Blind KCreasy@xxxxxxx Phone: 502.895.2405 Skype: keith537 -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer Sent: Thursday, January 03, 2013 1:50 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Different Approaches to document processing. Hi Keith, Yes. Please do outoline your approach. There may be some here who are notacvaquaintged with it. My approach is described in detail in the files in the documentation directory of the brailleblaster.newdesign repository. In addition, Semantics.java contains considerable documentation in the form of javadoc comments.Thanks, John -- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. http://www.abilitiessoft.com Madison, Wisconsin USA Developing software for people with disabilities-- ________________________________ Michael Whapples | Software engineer | ViewPlus 541.754.4002 x 282 | www.viewplus.com ________________________________ PRIVILEGED AND CONFIDENTIAL: This message and any files transmitted with it may be proprietary and are intended solely for the use of the individual to whom they are addressed. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited; please notify the sender and delete the message. ViewPlus Technologies, Inc. accepts no liability for damage of any kind resulting from this email.-- ________________________________ Michael Whapples | Software engineer | ViewPlus 541.754.4002 x 282 | www.viewplus.com ________________________________ PRIVILEGED AND CONFIDENTIAL: This message and any files transmitted with it may be proprietary and are intended solely for the use of the individual to whom they are addressed. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited; please notify the sender and delete the message. ViewPlus Technologies, Inc. accepts no liability for damage of any kind resulting from this email.
