Closed JohnGymer closed 10 years ago
Hi John, I have done something I think you are looking for. I have created an image with 50% opacity (I have enclosed the image) and made it the background of a new Shell (SWT.NO_TRIM | SWT.APPLICATION_MODAL), (Size:160, 128). On the shell I have put, in the middle, a progressbar (SWT.INDETERMINATE) and under the progressbar a label to inform what's going on.
This is the result: This mimics very well a "real" iOS blocking progress dialog.
Here's the image:
Cheers, Tom
Hi
The solution tom proposed is a very valid. If you need to block full screen that is a good approach.
From a pure UX point of view, it is nicer if you can circumvent full screen dialogs and indicate progress in place. Of course that would not block the UI but the experience is nicer
Greets Moritz
On Fri, May 17, 2013 at 10:23 PM, Tom Bauwens notifications@github.comwrote:
Hi John, I have done something I think you are looking for. I have created an image with 50% opacity (I have enclosed the image) and made it the background of a new Shell (SWT.NO_TRIM | SWT.APPLICATION_MODAL), (Size:160, 128). On the shell I have put, in the middle, a progressbar (SWT.INDETERMINATE) and under the progressbar a label to inform what's going on.
This is the result: [image: ios simulator screen shot]https://f.cloud.github.com/assets/2749761/520169/2bca096a-bf2f-11e2-82f5-90bfa5863333.png This mimics very well a "real" iOS blocking progress dialog.
Here's the image: [image: ios-loading70]https://f.cloud.github.com/assets/2749761/520104/2909fe12-bf2d-11e2-98d5-1e96373e0c26.png
Cheers, Tom
— Reply to this email directly or view it on GitHubhttps://github.com/eclipsesource/tabris/issues/119#issuecomment-18084040 .
Moritz Post EclipseSource Email: mpost@eclipsesource.com Tel: +49-721-66-47-33-33 Fax: +49-721-66-47-33-29 http://www.eclipsesource.com/ ========================= Legal Disclaimer ================================= According to Section 80 of the German Corporation Act Innoopract Informationssysteme GmbH must indicate the following information: Address: Lammstraße 21, 76133 Karlsruhe Germany General Manager: Jochen Krause
Thanks Tom/Moritz. It is quite similar to the solution I currently have - although yours appears neater. I'll play around with the image a bit. Thanks for your pointers!
Hi Tom/Moritz,
Unfortunately the use of APPLICATION_MODAL is still causing all of the other Shells behind to go 'dim', which is what I was trying to avoid. What I really need is for APPLICATION_MODAL Shells NOT to cause all the other Shells to dim. I understand this is standard behaviour in RAP and Tabris, and it is actually very useful most of the time, but in RAP there is the workaround of changing the CSS theme as I mentioned previously:
Shell-DisplayOverlay { background-image: none; background-color: #FFFFFF; opacity: 0.01; }
There is no equivalent in Tabris on the device, so that is what I was hoping for.
Any other bright ideas? I really don't want the other Shells going dim while the modal Shell is visible...
Thanks, John
What about a fullscreen Shell that has Alpha set to 0 to block events for the UI below. And then another Shell on top of the transparent one with your "pseudo-modal" UI.
Like it - will give it a go... thinking outside the box (or the Shell in this case) ;-) J
While I'm here... Tom mentioned using a ProgressBar with SWT.INDETERMINATE to get the spinning wheel, but on Android this gives a horizontal animated bar... I know Android supports the spinning wheel somehow, but how do I choose that instead of the bar?
You mean like this: myShell = new Shell(main.topDisplay, SWT.NO_TRIM); myShell.setFullScreen(true); myShell.setAlpha(0);
Tabris on Android doesn't appear to honour the setAlpha(0)... or am I doing it wrong? J
setAlpha(0) works ok on iOS, but not Android
Correct. Known limitation. But in fact i think you are approaching the problem wrong. What would the user expect? The dimm effect is used throughout the platform so when you want to block the entire screen, that is what the user would expect.
On Wed, May 22, 2013 at 5:26 PM, JohnGymer notifications@github.com wrote:
setAlpha(0) works ok on iOS, but not Android
— Reply to this email directly or view it on GitHubhttps://github.com/eclipsesource/tabris/issues/119#issuecomment-18286183 .
Moritz Post EclipseSource Email: mpost@eclipsesource.com Tel: +49-721-66-47-33-33 Fax: +49-721-66-47-33-29 http://www.eclipsesource.com/ ========================= Legal Disclaimer ================================= According to Section 80 of the German Corporation Act Innoopract Informationssysteme GmbH must indicate the following information: Address: Lammstraße 21, 76133 Karlsruhe Germany General Manager: Jochen Krause
Sure, but the application often has a series of short processings, each popping up the 'busy' indicator, and each needing to block the UI while they run. We cannot predict how users will implement their event handling, and it seems very common that there could be a number of these such sequences, and the overall visual effect is that the whole display keeps flashing because the other shells are being dimmed then 'normaled' a number of times in quick succession. An option to honour the setAlpha, or 'not' cause the dimming of other shells when a modal shell is visible would be very useful for us.
John/Moritz,
How do you see this from a UX point of view? My idea is that if you put a progress bar on a widget, meaning that there is an action going on for that widget, it should not need to block the entire UI, but rather the widget for which the action is going on. If there are a number of actions (or short processings) to be completed then you should disable the other widgets programmatically, no?
In my app I have several short actions that need to be executed sequentially and each has a busy indicator. I disable the next actions until the previous action has been completed. On my screen I have other input fields which the user should be able to input while an action is running.
@bauweto
Your approach sounds very reasonable. For your short running jobs you should use ServerPush to disable the progress indicator after the job has finished.
Exactly!
Should be fixed with the ShellDecorator.setOverlayColor(..) introduced in Tabris 1.2. Please reopen if issues arise.
Hopefully someone can suggest a good solution for a 'display' issue I have under Tabris... let me explain the situation first...
I have various background threads that get kicked off, some long, some quite short, but while these are happening I need to block all user input without totally blocking the UI. Bearing in mind that the same runtime/app needs to support SWT, RAP and Tabris (albeit with minor variations)...
My solution for SWT is to disable all the other Shells in the application temporarily and change the mouse cursor to a busy cursor, then re-enable them once the background thread is done.
For RAP, I create an application modal shell with an animated gif to indicate it is busy, and use CSS theming so that you don't get the other shells all greyed out. The CSS looks like this:
Shell-DisplayOverlay { background-image: none; background-color: #FFFFFF; opacity: 0.01; }
This avoids an annoying 'flickering' of the screen, which I really don't want for the quick processes and makes the user experience much slicker and seemless. The 'flickering' is because RAP actually creates a full-screen shell which has something like 50% opacity so everything under it gets a 'greyed' look.
For Tabris, there is no CSS support in the same way, so the app modal dialog results in that greying out of the rest of the display, so what I need is a way to achieve the 'opacity' style close to 0 in Tabris... unless there is another solution altogether?
The application itself works well functionally, and I get the required blocking that I need, but just with the constantly greying-out as by background threads execute and the 'busy' app modal dialog is visible.
Hopefully that makes sense?! It is a little difficult to explain without a video! Thanks, John