[Wine] Naturally speaking under wine help needed

Eric S. Johansson esj at harvee.org
Sun May 31 17:34:04 CDT 2009


jorl17 wrote:
> If I understand correctly, you need something that can automatically copy the
> text from any wine app into the currently active Linux app, right?

Almost but not quite right. I need to copy text from a specific application 
(either my own editor or a variant of Notepad) and paste it into the currently 
active linux application.  Your description is a generalized form but as you 
point out, significantly as complexity. By sticking with a specific, possibly 
customized editor, I believe we can make things easier

> If you build an application using Winelib, you can get access to both native
> Linux code and native Windows code. This would be ideal for you to write an
> application that would do this.

sounds like the thing to do with natlib

> The question here is the implementation. You need something that can detect
> what is being typed in the currently selected textbox, textarea, whatever,
> using Windows/Wine code (WinAPI). Then, you need to detect which
> application/window was last active (because the current active window is
> owned by a Windows App) and figure a way to detect where you were writing and
> paste it there.

Detecting the last application may be easier because we do have an event that 
happens when the last application is active. That event is the beginning of 
dictation. Where things get interesting is if we change focus manually, say, go 
to a browser to look something up, and then go back to dictating. I can think of 
two or three cases where last application tracking will get royally screwed up. 
It's not impossible, it's just tedious,

Using your idea of bridging both sides using Winelib has some interesting 
possibilities. From my perspective, that code would, on start of utterance grab 
the last application handle/tag if there wasn't a user dictation in progress. It 
would shift focus to the internal editor/notepad, wait for dictation to complete 
and then shift focus back to the last application.

Another possibility would be replicating the current dictation box model which 
is that you treat a dictation box as an application bound window.  That is, you 
cannot modify anything in the application as long as the dictation box is 
active. I'm not happy with this model is much because it means that the 
dictation box needs to go way in between uses and that user interface overhead, 
while tolerable, gets old real fast. It also interferes with the goal I have of 
being able to put plug-ins into this dictation editor for application-specific use.

A third option is an explicit binding. I give the command "bind to dictation 
editor" and an instance of the dictation editor comes up. This instance is 
forever bound to that instance of the application and should the application go 
way, that binding will be lost. Hopefully, any text in the dictation editor 
should be saved but, that's a future feature. In this third option, I should 
have the ability to manipulate the application as I see fit and then, when I 
give the command to paste, it pastes it into the currently active window.
> 
> One way to do this would be by opening this app at the moment of writing.
> Another one would be to have this application constantly running.

constantly running is my expectation
> 
> This really is a tough thing, if not in a certain way impossible. You'd need
> to get an experienced programmer here and I am by no means that experienced,
> though I would gladly like to help in any way I can.

thanks.
> 
> Maybe there is a simpler way to do this (which may be tougher on you, I am
> not sure). You could have an app that requested a source window and a target
> window (consider a window everything - button, scrollbar, etc...) - you would
> select them (My problem here is how you would) and it would gladly redirect
> the text from one to the other, and that really isn't that hard, AFAIK at the
> most it will envolve running parallell threads.

I think that is more difficult on the recognizer side.  I was hoping to keep it 
simple :-) (but knew better)



More information about the wine-users mailing list