Some observations from using Juce on touch screens


#1

I suddenly felt the urge to check out the juce demo on my touch pad. This is what I experienced.

Combo boxes: You can select things, but when trying to close after not selecting anything by clicking the top text field i.e where you clicked when opening it, it remains open (or more precisely, it closes but immediately opens again like if the touch was doubled in some way.) Experienced in any place like Audio settings, Tabs and widgets etc.

Popup menu: (Tab & Widgets->Menus) Sub menus doesn’t work; no sub items will show, the “mother” item just flashes.

In sliders section (Tab & Widgets->Sliders): No context menus. And not in any other place.

Dialog boxes (anywhere; e.g Tab & Widgets->Toolbars, Customize) Can’t move them in a any predictable way, they jump spastically all around. Resizing same experience: spastical movements if any.

Native dialog boxes behave although.

Drag & Drop (Tab & Widgets) Flickering. If I position the mouse anywhere in the juce demo app, the dragged item flickers between that mouse position and where my finger is on its straight way to the drop target. If the mouse is switched off, the dragged item flickers anyway.

Code editor: no screen keyboard shows up, not even in pad mode.

Dialog boxes: Natives ok, juce versions exhibits spastic movements when dragged.

Strangely enough, the Mdi notes demo works fine when dragging notes. Unfortunately the keyboard shows up when mouse clicking in a note. It should really only show when touching, not when mouse clicking. As in notepad e.g.

Windows Demo: Nothing happens when touching the buttons. No windows appearing.

Contrary to expectation (mine anyway), the javascript console doesn’t engage any on screen keyboard when touching the code.

No touch scrolling in left (main) menu list, makes it hard to use (espacially when the tiny scrollist is almost the same colour as the background)

Some of the issues above seems to be caused by an existing or non-existing mouse. E.g if I silently put the mouse cursor in the combo box text field (i.e the field always visible) it works flawlessly, i.e it closes at it should when touching the text field a second time. If I remove the mouse, it mis-behaves again.

When trying to (touch) move a non-native dialog box it won’t follow my finger, instead it rushes to where the mouse was lastly situated. If the mouse is switched off prior to starting the demo app, they (the boxes) seem to feel the presence of a ghost mouse somewhere in the upper left corner of the display.

Is it not possible to discern between a mouse click and a finger touch?

Another disturbing fact is that after running the demo for a while, upon returning to e.g the Tabs & widgets demo or the Dialog Boxes the buttons get completely numb, that is, they won’t click, they merely change colour slightly but they fail to carry out their clicking duty.

I guess the purpose of this post is to know if this is known issues that you’re currently adressing or just… known issues or perhaps not even that. Or perhaps there’s not many using juce with windows touch screens anyway?

Tested om Windows 10 x64 updated t latest standards, latest juce demo from develop in debug mode.


#2

FYI Ed has been working on a whole pile of fixes for touch/pen on Windows, so hold your fire until we release that!


#3

Hope no one’s got hurt :neutral_face: I holster any gun…


#4

We do use JUCE to develop app for Touch Screen (Surface Pro), a Kiosk app. Reported 2 issues and JUCE team done some good work to solve that (thanks), but seems like there still some issues remains. Here are the issues I report FYI:


#5

Yep, I’ve been working on improving Windows touch and pen input and have just pushed my changes to develop. Can you check it out and let me know if it fixes these issues for you (or if it breaks everything and your touch pad bursts into flames)?

Thanks!
Ed


E.mods.isRightButtonDown() never set after long-press on touch screen
#6

Since the possibility of having or not having a Mice, touch screen, external keyboard and being in full screen mode or not gives you a combination of 16 (right?) combinations, you just frankly need a function setUseExternalKeyboard(bool useKeyboard) that does what it says that you can hook up to a user button. Or a method that can reliable detect if you have a keyboard connected or not.


#7

Thanks. Now dragging works.


#8

Great! Just a heads up, in response to this thread I’ve disabled the Windows pointer API by default for compatibility with Windows versions earlier than Windows 8 so to enable it again you need to set the ‘JUCE_USE_WINDOWS_POINTER_API’ flag in juce_gui_basics.h.

Ed


#9

:confused: You mean those who target an os that’s less than 8 years old (aka windows 7) should engage a special build flag. Hmmm, interesting…


#10

Yes. This change broke compatibility with Windows 7, an OS that JUCE supports, so IMO it’s better to have it disabled by default and allow those who want to use the improved pointer input API in JUCE to enable it themselves.

Ed