I have a rich complex Java Swing Application. I would like the multi touch events to be converted into Mouse events for the Swing Applications.
Is there a way to do it without changing significantly the existing Java Application ?
When I did something that sounds similar to what you're asking, I ended up using the java.awt.Robot class to create mouse clicks according to the touch notifications. I was not using mt4j, though, but rather a proprietary multitouch screen's API that wasn't especially mature.
Related
How to get notified for mouse wheel interaction for MacCatalyst and windows at MAUI platform.
Answer 1: Scrolling.
What do you want to do based on mouse wheel interaction? If you simply want to scroll, or know when scrolling has occurred, then you can rely on ScrollView, and other views that handle scrolling themselves. E.g. ScrollView.Scrolled event.
Answer 2: General use of mouse scroll wheel.
Input functionality for mouse or keyboard has not yet been implemented in MAUI. Nor has a specification been finalized.
Here is one mouse proposal.
You could add a comment to that proposal requesting that mouse wheel support be included.
However, this might not be in the first release of MAUI, as the current emphasis is on stabilizing the functionality that is needed on all platforms (including mobile), some of which don't have mice.
In case anyone is wondering "shouldn't this be specified in .net 6?" (And then MAUI would simply use it.)
There are interactions between what is happening on the display (views or windows) and how mouse/keyboard input should be handled - it makes sense to put that input in the same code base that is displaying to the screen - therefore MAUI is a good place for it.
Especially given that touch is part of MAUI.
Until then, the solution is to make a DependencyService on each platform, to refer to the platform's APIs that you need.
Surprisingly, I'm not finding one that anyone has done for mouse on Windows and Mac.
Other than "implicitly", since a mouse can be used similar to a touch device. And text can be typed on a keyboard. The point is that there is no API specific to functionality that only makes sense if you have a physical mouse (scroll wheel) or a physical keyboard (global keyboard hooks).
TBD I'll look into this further.
Basic approach would be to look at what WinUI 3 uses as input APIs.
On Windows Desktop app, forward to those input APIs. Write an adapter on other platforms (Mac, Linux).
I'll see if Uno Platform or Avalonia have taken this approach.
I am using the MVVM light toolkit in a WP7 application and I am trying to wire up a canvas element's appropriate event to my view model using the 'EventToCommand' behavior. The event I am looking to intercept is the 'swipe up' gesture.
I have currently tried relaying the 'KeyUp' event but that doesn't behave like I had assumed it would. Is this even possible using behaviors or should I be doing something else? All the events I wire up to the viewmodel using the EventToCommand behavior work fine, but my basic problem is that I can't find an event for a swipe. I'm guessing gestures are handled differently?
What you need is a way to enable a gesture to trigger the behaviour.
Fortunately, Kevin Marshal wrote just such a thing and blogged about it.
I'm new to cocoa app dev, and I'm searching a solution to create a windows like the tweetie main windows with a left tool bar and a panel that point to the selected icon.
like this screenshot : http://i.stack.imgur.com/qvxWu.jpg
could anyone help me?
It's likely that a lot of the Tweetie UI is implemented using custom controls. You'll want to look into subclassing NSView and how to handle drawing and mouse events. There's nothing built into the Cocoa framework for this.
The NSView documentation has info on view programming, drawing, and event handling. If you're new to Cocoa, you may want to start off with something built in, though, as this will be a lot of work (and requires a pretty good understanding of how the framework works).
Well, currently chrome has out of process plugins. and firefox 4 will use same model.
That means plugin process is now seperated from browser process.
Plugin process might NOT have window at all.
My plugin is based on NSView.
Before cocoa event model, when I can access NSWindow in browser process, All I have to do is just add my_view as a subview of the contentView in the window.
[[the_window contentView] addSubview:my_view]
I do NOT need to process events myself. It worked itself.
But now, I convert NPCocoaEvents into NSEvents in event process code.
Do I have to change it myself?
Also some instance of NSEvents, I can not make them for example, wheel mouse events.
What should do I do?
Did I approach a wrong way?
Please enlighten me.
Do I have to change it myself?
If you plan to use the approach of forwarding NSEvents to your existing NSView then yes; there's no way to get access to the original NSEvents. They don't exist in the plugin process.
Another option would be to move away from trying to use native controls, and do your own drawing and event handling. This is the way most NPAPI plugins work.
A third possibility would be to open a separate window for your plugin content, and put your view in that window. This isn't technically supported by NPAPI, and it won't be perfect, but it might be a short-term way to get your plugin working while you explore long-term options.
Did I approach a wrong way?
Yes, what you were doing before was an unsupported hack, and not how NPAPI was intended to be used. Adding a view to a browser's window assumes things about the browser's view hierarchy that are implementation details, and subject to change at any time.
One option would be to use the FireBreath framework to create your plugin, as it already has a lot of the abstraction for negotiating the event and drawing models as well as an event abstraction. It's pretty straightforward to get up and going.
Valve's game manager application, Steam, has a very unique user interface, with custom buttons and windows. How would you create a Win32 application that has such a look?
Pretty much every windows common control supports custom and/or owner draw (not the exact same thing), that just leaves the dialog itself where you can customize its look by handling WM_ERASEBKGND and WM_PAINT or WM_NCCALCSIZE,WM_NCPAINT (If you don't want native titlebars and border etc)
As you can see, to do a custom GUI requires you to paint every control yourself... (And keep in mind that a lot of people hate skinned apps and would rather just have a native looking app)