Posts by bhh

Thanks for sympathizing Tuur. It is really frustrating! The long touch does indeed work but unfortunately it is a really terrible and unacceptable user experience to have to instruct users to do that and 99.9% of users are just going to give up if it doesn't work on a single touch. It is simply a "broken" implementation and pretty pathetic there has not been a proper solution to this over the past 7-years given how prevalent touch and mobile have become over that time.

I think a workable solution for my use case may be to have the plugin append the text input to the body of the DOM rather than the plugin sprite. I had some success getting that to function properly late yesterday in a simplified testing environment so I'm going to try and implement it today in the actual project. Of course something else may pop up that prevents this from working as it should and I already noticed there will be some blurring challenges as well with this approach but it seems like the path of least resistance at this point.

I know this has been an ongoing issue since at least 2014...

https://krpano.com/forum/wbb/inde…52434#post52434


I basically have a plugin that needs user text input and it fails to receive focus in chrome on a touch device. It does works in Safari on an iPad but most of our clients are using Chrome.

For simplicity, I have reverted to the exact plugin example posted by Klaus back in 2014.

In addition, I have added a touchstart event listener:

inputelement.addEventListener('touchstart',text_click, false);


and the text_click function:

function text_click()
{
inputelement.focus();
inputelement.value = i;
i++;
}


I can confirm the text input is receiving touch inputs as it increments the i variable each time but the input never received focus and opens the ipad keypad. I've found lots of threads on this over the years but no definitive solution that seems to work for me. What am I missing here? Does anyone have a reliable work around for this? This is a temporary overlay over the pano an I don't need KR Pano interactivity while this text input is displayed so disabling anything in KRPano itself which is hikacking focus is an option.

Thanks. I've been stuck on this for several days now and its driving me a bit crazy.

Quote from klaus.krpano

Hi,

maybe your iPad Safari browser is running in Desktop Mode, in this case there are no information about the iOS version available.

But it is possible to check for device.iosdesktop to know if running in that mode.

Best regards,
Klaus

That was it! Thanks.
Is there way to determine if the user denied gyro permission? I'd like to tidy up the interface a bit, remove gyro buttons, etc. if so. I didn't see gyro2 functions that look like they would provide this info but I may be missing something. It appears events.gyro_onenable gets called even when it is canceled but that't can't be used for cleanup obviously.

Thank you.

This was implemented back at 13.1 to open a dialog allowing for the user to request gyro permission. Now on iOS 13.3.1, the iPad is returning 0 for the device.iosversion while my iPhone 10 is returning the correct version. Its really weird, anyone else run into this?

We've got a plugin that basically animates (pulses) some SVG graphics and renders them with css3d as clickable hotspots.
I just noticed that it is no longer animates in the current chrome version but does in firefox as well as an older chromium browser we have around. We use the same plugin to do the same with regular plan/map spots and they still works fine.

Is there another renderer available to us now we should be using that can render/animate these SVG graphics as a hotspot in chrome or do we need to redo this via some other method?

Thanks

Can anyone confirm that this fix requires a button click or user interaction to trigger the request permission dialog?

We've got a few projects that are running on an iPad specifically for the gyro control so I was enabling it automatically at startup. I'm now attempting to trigger the permission dialog at startup and I can't seem to get it to fire without linking it to a button. Works fine on a button click (yes, https).

Is there an undocumented function call we can make to the new gyro plugin that will request permission?

Thanks,
bhh

We'd pay for a subscription as well, or at least an upgrade fee for major releases

Ah, cool. Thanks! I was getting ready to write a "plugin" just to drop a div I knew the name of over the entire screen, lol.

I'm familiar with setting cursors.standard to none and that works brilliant on the actual pano but I need to remove the cursor over container layer that is still able to capture an onclick event so setting bgapture to false is not a viable solution either. Setting layer handcursor to false still has the default arrow. This seems like it should be easy but I'm having a brain fart and have been hung up on this for two days now. Is there a way to assign a class name or id to a container layer so we could just do it via css?

We use Let's Encrypt. It's free and a legit 3rd party provider so it doesn't trigger browser warnings like self-signed certs will.

Also, if you have a previous link saved to the iOS desktop as a "web app" with an http url, you will need to recreate that from a new safari page even with https redirects enabled.

Hi Klaus,
Yea, I experimented with that yesterday. It's pretty cool but my problem with the current implementation of the safearea_insets is that both sides are the same when the phone is horizontal regardless of which side the notch is on. This leads to an awkward layout aesthetically when side-justified UI elements are on the opposite side as the notch where the space is uncomfortably large. It looks good and makes sense when the notch is on the side with the UI but not the reverse. I suspect these variables come directly from the browser and is not a KRPano issue but until the phone "knows" which side the notch is on, designing an interface to take advantage of the notch is problematic IMHO.

The top and bottom bars are indeed huge on both Safari and Chrome on these phones but I'm not exactly sure what you mean by having tabs open. Can you elaborate? I'm using an XR and not sure what you are referring to as the tabs. You probably know this already but if not, the best way to get "full-screen" is to launch in Safari and then Add to Home Screen. Besides looking like a native app, launching from there loses the regular browser navigation bars.

We've moved our toolbar off to the side so that isn't a problem specifically but we have project logos that live in the lower corner and it looks pretty bad actually with the phone is in portrait mode. I think a bottom, center justified toolbar probably looks OK as long as there is enough padding off the bottom. If there is a way to detect these specific devices, it may be worth adding a 10 or so extra pixels to anything along the bottom to give it a bit more breathing room. I need to do some testing I suppose.

Just got a new iphone and don't like the way the new bar that replaced the home button that floats at the bottom of the screen collides with the layout of our tour UI. I was curious how you guys are dealing with it?

agreed. This is pretty cool, thank you.

Pur,
Thanks for posting. That works zooming in on a pano image but it has no affect for me on a regular image layer. Perhaps I'm missing something?
There may be an easier way but San7's solution I think is going to work in theory, I'm just having to reverse engineer how to apply that concept to recentering a scroll area since my zooms are just scaling up scroll area inside of a fixed window. It is making my head hurt but I think I will eventually work it out!

Also, Is the Scroll Area plugin's update() function broken? Seems to be triggering a WARNING: Unknown action error.
EDIT: updatepos() seems to be working.

Thanks San7. Not sure how I missed that the first time around! I see what you are doing, pretty clever. When I first tested, It was only working with the mouse zoom and not with touch but I see why when I looked at your xml file. I'm going to spend some time today working on this and and see what I can come up with along the lines of what you are doing.

My application is a little different because my image file is nested in a "scroll area" plugin layer so my "image_onmousewheel" action is scaling up my scroll area layer rather than the image. What I tried last night was converting the touch points to layer coordinates via screentolayer() and then using the scrollarea.setcenter() to shift the image center to the touch point when scaling up. It wasn't working great and was jerky but that also has some promise (I think it is bouncing back and forth between the touchpoints of both fingers currently).

Thanks for responding. Much appreciated.

EDIT: I've dug more into your "align_delta" function. Wow, very impressive! I'm hoping I have the brainpower to integrate this into my use case but great job

I've implemented a touch zoomable and touch panable layer (floorplan) via a combination of the scroll area plugin and the mouse zoom hijack trick Klaus illustrated in this thread...
https://krpano.com/forum/wbb/inde…touch#post72147

It works great and has a very native OS feel with the exception that zoom events take place around the layer alignment rather than the cursor/touch location.

My idea for a solution is to track the cursor/touch locations of that layer and just offset the alignment point to that location. That is proving impossible though since the only alignment options we have are lefttop, left, leftbottom, top, center, bottom, righttop, right, rightbottom. Am I missing something here or is there another work around anyone can think of? Is it possible to offset an alignment point to a custom value? Control.zoomtocursor works for the pano but seems to have no affect on other layers.

Thanks.