X3Photo Gallery Forums

Martin wrote:1)
Manage / 1.index / Gallery:
Second text ‘Width’ should be ‘Height’

Thanks, will fix for a new release scheduled this week.

Martin wrote:2)
Manage / 1.index / Gallery:
Toggle play on touch devices only works with touching.
My laptop has a touchscreen, but also a mouse; toggle play does not work when clicked on with a mouse.
And I do not mean the checking of the checkbox, but the starting/stopping of the slideshow.

This is also the case with the breadcrumbs under the carousel menu. Mouse does not work on my laptop with touchscreen, but touching does

Interesting. It is however an eternal battle in web development to distinguish between touch/mouse. Let me explain by example: Touch-devices trigger both CLICK event and TOUCH events. Therefore, we normally assign EITHER touch/click, based on detection of touch/mouse. In your case, you need both the click and touch events if you want to be able to use both touch and click. Unfortunately, that means the touch event will trigger twice. I guess that sounded a bit complicated ... Ultimately, we need to kinda "guesstimate" if the visitor is using either mouse or touch. I think we can fix it so that it will detect your mouse (instead of touch), but I think there will be problems if you try to use both mouse/touchscreen in the same session. Will look into it!

Martin wrote:3)
There is a pull down button on the preview image field, but it is not possible to navigate to other maps like “assets/”

The dropdown will list FILES (images) that are inside the folder, which is where you would "normally" assign your image from. You can't expect it to be populated with ALL images in ALL folders. If you have assigned an "assets" page, you won't get the panel to dynamically change, and list images from the assets into the preview-image setting ... Simply speaking, that is currently too advanced behavior to expect from assets setting. Besides, just because someone is using assets, doesn't necessarily mean they wont use a preview image physically located inside the folder. Currently, the "assets" setting is just a "string", which gets processed from the frontend, but the panel will not do anything with it.

Martin wrote:4)
If I want to use my own ‘favourite icons’ then I will still have to copy them to the map /public_html/public/img.
Is it possible to locate these files also in /config?

Yes, I was thinking something like that also. Let me look into it ...

Martin wrote:5)
On my iPad the menu button often starts/changes to a strange colorpattern

Indeed strange. Can't see it here neither on iphone or ipad, and haven't heard of it before, but will keep an eye out.

Martin wrote:6)
When I share to Facebook, it shares the correct image when an image or a gallery is involved, but when a folder (with galleries) is being shared, it does not send the preview image of the folder.
EDIT: I solved this one by using your facebook debugging info in an earlier thread (https://developers.facebook.com/tools/debug/og/object/). Some of my preview images were incorrect.

I have been testing Facebook sharing myself lately, from the demo gallery and mjau-mjau, and Facebook is a bit crappy. First time a new image/page is shared, it doesn't display the image ... Sometimes you have to refresh from their debugger. This is not X3's fault, or anything we can do anything about ... Facebook caches results from earlier, and also I believe it displays "no image" on first share preview if Facebook has not yet already cached the result ... It does that because it doesn't want to be slowed down by having to extract info from the origin-page before showing the share.

Martin wrote:7)
When I share an image to Facebook and someone who receives it in Facebook clicks on it, he/she links to my site and arrives on the image landing page. Is it possible to supress a) the technical data above and below the image and b) the disqus comment section below the image.

Not yet, but will look into it at some point. Why do you want to remove the title/description above the image though? That is part of the sharing process, and certainly affects SEO. Besides, when shared, the visitor will still see the image in a popup first. Also, is it necessary to disable Disqus if you have enabled Disqus for your site?

Martin wrote:8 )
When sharing on small devices, like smartphones the share-button is hard to find on the left side of the screen.
Maybe it’s an option to put the share-button on small devices in the footer.

So I assume you enabled sharing on mobile devices although it is disabled by default? We disabled sharing (toolbar) for two main reasons: 1) I don't know if you have tried from a smaller device like iphone, but it really gets annoying with a share button floating around in addition to other items ... It's just in the way. 2) Mobile browsers already have native sharing buttons, which connect directly with the App (Facebook, Twitter etc) ... If you click a share link in X3 instead of the browser, it opens a browser window with the service, and often requires login etc. Most people who actively use a service, will have the APP installed, and don't want a tedious web-login. Thus, our recommendation is to disable sharing-button for mobile devices ... If a visitor on mobile really wants to share, they already have native methods for that superior to the share-button, which just bloats the interface.

See screenshot with native mobile browser sharing, which includes the services the visitor has installed as apps, which is what they will be looking to share on anyway:



Thanks for all!

Martin wrote:No, it's not necessary to disable Disqus when it's enabled for the gallery of the shared image, but in my example that wasn't the case. I've enabled Disqus only for few galleries and not for the gallery of the shared image.

Sure, we will add settings for the image-page soon, but it is not top priority now. We will need to create a new settings-category for the "image-page", which technically speaking, is just a virtual page, and only used for image-sharing.

Toggle play on touch devices only works with touching.

Can you try something? Load a page without the slideshow first, and then navigate to the a page with slideshow by using mouse. Does the play-toggle work with mouse then?

Basically, a device is "touch" until the opposite is proven. In the case a device does not have "touch", it is always "mouse". In your case where a device has touch AND mouse, it will be considered a touch device until the mouse is detected (mouse motion, the only way). If the slideshow initiates on load before you have moved the mouse device, it will trigger control-events for touch. Why not both? Because mouse requires "click" event, which also triggers on touch, where we already have "touchend" event ... Thus a touch would trigger twice, so we don't want to use "click" for touch devices.

Not only are dual-input devices quite rare, but it would be highly unusual that someone using a dual-input device would switch between mouse/touch in the same browsing session. We need to trigger events for one of them.

I will look into these things in time as there is room for improvement. Ultimately, the issues are because of conflicts between touch/mouse-click on your dual-input device. The below gets a bit technical, but it's an interesting topic.

Martin wrote:Well, that's interesting.
Indeed, when I first go to i.e. http://martinbroeze.nl/emptiness and then click on my logo to go to the start screen I can click on the Toggle Play button and the slideshow stops and starts again after a new click.

This is expected behavior. Basically the system thinks it is touch until you move the mouse. If the slideshow loads before it has detected the mouse, it will listen to events for touch-only. If the device is not dual-input, X3 would already know 100% sure if it is touch or mouse.

Martin wrote:But the strange thing is that the other buttons (arrow left to previous image, arrow right to next image) don't have this problem, they react whether they are clicked on or touched regardless of the way I loaded my pages. This is also the case for the menu items, they react when touched or when clicked on.

It does not affect everything, especially not links. There is a global CLICK event that can be used for both touch and mouse, which is used for all non-UI elements (like links). Also, since next/prev buttons are not generally available for standard touch devices, they just use CLICK event anyway, which works for both.

Martin wrote:To make things more complicated (can it be ) the breadcrumbs of the carousel menu's still won't react to mouseclicks one way or the other.
But the button's on the right of the carousel menu work flawlessly (b.t.w. I see the button 'x' and the other one 'go to emptiness' only appear on my laptop and not on my desktop, but that's something we have noticed some time earlier).

Essentially the same issue as some UI items are trying to distinguish between touch/mouse ... which basically affects your desktop which has touch? Your laptop, unless it has touch, will not have any issues.

Martin wrote:I still do not understand why not both. That's probably due to my innocence in these technicalities . Why can't software react to different kinds of signals?... if it's touched on a button then react, if it's clicked then react too... if it's spoken to ... the same, react...
But I guess that this is not something that's unique for Imagevue but it's common for every web-interface...

Ok, I'll try to give it a shot for the sake of interestingness. To detect touch/click, there is an event CLICK, which basically works for both input types, which we do in fact use for a lot of UI elements ... However, this event is inferior for touch devices, because there is a 300ms delay when touch devices are trying to figure out if the visitor is dragging, touching or actually clicking something ... Its got something to do with the touch surface. Instead of using CLICK, we therefore use a separate TOUCH event for touchscreen devices. This is far superior for 99.99% of touch-devices, because its fast, and perfect for using with a touch UI ... Thus, when we use the TOUCH event, we cannot also listen for the CLICK event, because it would trigger all events twice on touchscreens (which also listen for click).

So basically, I could actually fix it easily by removing all TOUCH events, and simply using the global CLICK (which works on all devices). The downside of that, is that the UI becomes quite a bit less responsive on touch devices. So ok, I see we have some problems a few places with multi-input devices like yours, but we are facing a ratio of at least 1/1000 of multi-input devices vs touch-only devices. I'm therefore dubious about removing the TOUCH event ...

Complicated stuff