[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tm-dev] TextCanvas in automatic testing - a method to read the content is missing
|
On 2017-05-31 12:08, Vaclav Kadlcik wrote:
> Thanks Martin,
>
> I took a look and played a bit.
>
> Let's call the method, that I need in TextCanvas.java,
> getTextContent().
>
> My first and very naive attempt was like:
>
> public String getTextContent() {
>
> ITerminalTextDataReadOnly terminalText
> = terminalText.getTerminalText();
>
> // Collect all snapshot.getChars(i), skipped for brevity.
> // Return the "sum" of them.
> }
>
> This didn't work - all "scrolled out" lines came out as empty.
> In other words, I got only lines actually visible at the
> respective moment.
This is done by design. When I implemented the original terminal,
efficiency was very important. Other implementations tried to
draw every character that comes form the source to the screen.
This does not work well, when there is a high speed connection
and a huge amount of data has to be processed.
Any terminal operation (e.g the vt100 operations) can only modify
the visible area of the screen. Once a line is scrolled out of
the visible area, it is not modifiable anymore. Therefore the trminal
treats them differently form the visible area where the escape sequences
can modify the characters.
For the visible part of the screen, I decided to not try to draw every
change that comes form the escape sequences immediately. Instead, there
is a thread that processes the escape sequences and form time to time
a snapshot is taken and handed to the UI thread, which is then used
to draw on the screen. This snapshot mechanism made the terminal
much faster than any other implementation that tries to draw
every character on the screen (which has to be done in the UI thread).
When it comes to testing you have to decide what exactly you
want to test. Because of the asynchronous snapshots, you cannot
test the exact output at the level of the UI. You have to wait
until the last snapshot has been rendered.
The rendering originally has two modes: one mode where the render
engine assumed that all characters have the same width (fixed font).
And another mode where each character is drawn into a box (which
is slower).
Anyway, on the screen there is now a matrix of characters and not
a "text" in the classical sense.
To get to the text, you have to access the model.
Unfortunately, it's long ago that I actively worked on the
terminal and I forgot a lot of details.
> OK, I took a look how getSelectedText() and getSelectedText()
> work, as they are the gist of my current workaround. From them
> I distilled a new attempt:
>
> public String getTextContent() {
>
> ITerminalTextDataReadOnly terminalText
> = fCellCanvasModel.getTerminalText();
>
> ITerminalTextDataSnapshot snapshot
> = ((ITerminalTextDataSnapshot)terminalText)
> .getTerminalTextData().makeSnapshot();
> snapshot.updateSnapshot(true);
> snapshot.detach();
>
> // Collect all snapshot.getChars(i), skipped for brevity.
> }
>
> This seems to work, at least as a proof of concept. However,
> the need to cast terminalText to ITerminalTextDataSnapshot
> indicates that I'm working on a wrong level of abstraction.
Int he original version, I have tried to hide the implementation.
I think for a test, the cast may be OK. Unfortunately, I am
currently not actively working on the terminal.
What I can offer you is to have live session where we share
a screen and we add our knowledge to find a good solution..
Which timezone are you in?
Michael
> But
> I haven't intended to spread my changes outside of TextCanvas.
> At this moment I'm not sure how to proceed further. Any
> suggestion?
>
> Thanks in advance
> Vaclav
>
> ----- Original Message -----
>> Hello Vaclav,
>>
>> Thanks for the background information, and for your drive towards test
>> automation!
>>
>> Code contributions would be welcome to provide the APIs that you need.
>>
>> Thanks,
>> Martin
>> --
>> Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
>>
>> On 29/05/17 12:22, "tm-dev-bounces@xxxxxxxxxxx on behalf of Vaclav Kadlcik"
>> <tm-dev-bounces@xxxxxxxxxxx on behalf of vkadlcik@xxxxxxxxxx> wrote:
>>
>> Hello list!
>>
>> o.e.tm.terminal has become *the* text interface in several other
>> Eclipse projects, e.g.
>> - Docker containers' terminal in Linuxtools
>> - Debugger Console view in CDT
>> therefore its accessibility in automatic testing is more and
>> more important. Testing frameworks (for example SWTBot or Red
>> Deer) need to locate widgets and perform some actions on them.
>> In case of o.e.tm.terminal, these tasks roughly translate to:
>>
>> 1. locating instances of TextCanvas
>> 2. typing some text
>> 3. reading the content
>>
>> There's no major obstacle in achieving 1 and 2. However, 3 isn't
>> that easy; at least I cannot see a public method in TextCanvas
>> that would provide that. For now, I'm using a "clipboard"
>> workaround:
>>
>> textCanvas.selectAll();
>> content = textCanvas.getSelectionText();
>>
>> which sort of works but is obviously bad and inherently fragile.
>>
>> I already filed this as a RFE [1] but then it came to me that
>> bringing the issue to the mailing list (and adding some
>> background) could be a good idea...
>>
>> Best regards
>> Vaclav
>>
>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=517358
>> _______________________________________________
>> tm-dev mailing list
>> tm-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/tm-dev
>>
>>
>> _______________________________________________
>> tm-dev mailing list
>> tm-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/tm-dev
> _______________________________________________
> tm-dev mailing list
> tm-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tm-dev
>
