[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