[brailleblaster] Re: Partial rendering
- From: Keith Creasy <kcreasy@xxxxxxx>
- To: "brailleblaster@xxxxxxxxxxxxx" <brailleblaster@xxxxxxxxxxxxx>
- Date: Fri, 4 Jan 2013 16:05:53 +0000
I still favor defining an "event" that gets queued in the Document class. A
single thread is responsible for processing events if a certain interval passes
before the event trigger is cleared. The events or operations are handled in
FIFO order and in some cases can be combined into a single operation, for
example if there are 10 insert char operations in a row they get merged and
then the DOM is updated and the views are notified.
In fact the switch to a new node can be queued so that any insertion events are
handled and then the new node is selected so everything stays nice and neat.
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: Friday, January 04, 2013 11:00 AM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Partial rendering
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
>>>>>>> formatting
>>>>>> right.
>>>>>>> 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 some
>>>>>> modifications.
>>>>>>> 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 UI
>>>>>> connected 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 same
>>>>>> page 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
>>>>>>> to
>>>>>> do 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 and
>>>>>> repositories.
>>>>>>> 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
>>>>>>> out
>>>>>> there 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
>>>>>>> how
>>>>>> HTML 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 not
>>>>>> expect 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 more
>>>>>> suited 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 far
>>>>>> better.
>>>>>>> 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.
>>>>>>>> Very
>>>>>>> helpful.
>>>>>>>> We need to work on the interface between the views and the document.
>>>>>>>> That
>>>>>>> probably 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
>>>>>>>> control
>>>>>>> of 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.
>>>>>>>> Anyone
>>>>>>> can 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
>>>>>>>> not
>>>>>>> acvaquaintged 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.
Other related posts:
