Is it possible to implement a Windows Application or extension? to enable iPad like scrolling System wide for all apps ?
The OSX equivalent would be SmartScroll:
www.marcmoini.com/sx_en.html
Possible ?
I found your question in elance.com.
If you need those functions implemented in ALL Windows applications - the answer is NO. Some applications can be forced to scroll smoothly, but not all of them: applications can use custom objects to implement scroll bars. Actually, this task is possible for one (or few) selected apps, but you need to write some code and do testing for each application. For example: Logitech "Flow Scroll" software implements smooth scrolling in popular browsers, i have M325 mouse with this function. In other apps this software don't work.
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 create my first app for Windows 10. I will use the app for Windows 10 desktop and phone. Great that one code will run on desktop and phone. In my old application for Windows Phone 8 I use Panorama control with three tabs. But I can not decide which component to use - SplitView or Pivot? For desktop better suited SplitView . For phone better suited - Pivot. Need to choose one solution. What do you advise?
First, your following statement is incorrect.
For desktop better suited SplitView. For phone better suited - Pivot.
SplitView and Pivot are for different purposes -
SplitView consists of two parts - Pane and Content. The Content is where the main content goes. The Pane is really just a drawer. This control is meant to provide a very common drawer navigation pattern to the new UWP apps, similar to many iOS and Android apps.
Note that this control is also very flexible, you can use AdaptiveTrigger to customize its DisplayMode to completely hide the Pane when it's on a phone, and make it always visible when on a desktop machine.
Prior to UWP, the original Metro Design heavily relied on the Panorama control (i.e. the Hub control in UWP) for menu navigation and this later becomes a bit boring since almost all the apps that need a menu, use a Pano. So having a new SplitView will definitely help developers be a bit more creative on the main layout design. And besides, the drawer navigation is so widely used across other platforms and users generally know how to interact with it.
Pivot on the other hand, is simply a swipe-enabled tab control. It's meant to display information at the same level and should never be used like a navigation frame. Leave the navigation bit to the SplitView or the old panorama style Hub control, or whatever creative ways you can come up with.
So to answer your question, you don't have to choose one between them, these two controls can co-exist since one does the navigation and the other shows the information, just like what's in the picture below -
I have a mobile app. On the two major smartphone platforms, I employ tabbed UI - there are 3-4 screens with pretty much independent functionality, they exchange info very occasionally, most of the time screen switching is performed by the user, in arbitrary order.
Windows Phone 7 does not have a tab control, and page navigation assumes a stack model (you go back to where you came from). What would be a sensible WP7 alternative to that kind of UI?
The general Phone-7 replacement for the tab paradigm would be either a Pivot or a Panorama. Which you choose depends a lot on exactly on what you're showing, but generally speaking the Pivot is probably what you're after.
I would recomend a pivot control
WP7 UI is built around the metro style and it was a deliberate choice to not have a tab control. (have a look at the official guidelines here) I would recommend you use a metro control like panorama or pivot.
It seems Windows is unable to display different background images on different monitors on a multi-monitor system out of the box. But I noticed there are quite a few commercial applications available which provide this feature.
Which APIs can be (mis-)used to provide this functionality? If there's no special API for this feature, can it be done by hooking into another Win32 API function? If so, which one?
You could also try to programaticaly create an image the size of the virtual desktop joining several images making the divide fall where each monitor ends and then set that image as a wallpaper.
Simple and low tech.
Wallpaper replacement applications on Windows don't hook into the Windows API, they make a window the size of the desktop and render an image on it. There's APIs in Win32 to make such a window unclickable and living below everything else, and sized correctly for the desktop.
I want to build a desktop app where the size of both the window and the content is resized automaticly according to the resolution of the monitor. I know it can be done easily with the docking features of .NET Forms, but my customer insists on going with Linux so I can't use it.
I tried Flex & Air, but the content is not resized automaticaly when I put the app in fullscreen or in another resolution (the app goes full screen but I still have tiny buttons). Now, I am looking at Qt and Gtk...
Is there a GUI framework that can do that? I don't care about the programming language.
Also, since the app will go in a bar it would be nice to be able to customize easily the skin. (like in Flex, WPF, etc.)
Regards,
Pascal
An excellent place to start is understanding how the Screen class works: MSDN Even though that is .Net, it will give you an idea of how the screen size, dpi, etc. can be obtained. In addition that information should translate to the Mono platform. Since your client is insisting on Linux, you should look at MonoDevelop and then possibly the GTK# framework. My understanding is that GTK# is not a very friendly (that is pretty) development system (yet).
See:
MonoDevelop
GTK#