FWD » Core Development » User Interface

It is time to implement common-sense choices about how to display various windows in embedded mode. We can refine it later when we get feedback from a customer, but for now I want to make sure that a good default approach exists.

When I refer to chrome below, I mean all borders, titlebar and other window decorations.

Some initial thoughts:

• Anything which we decide should display with chrome would NOT overdraw the background of the existing window.
• Alert boxes should have chrome. They are modal and clearly are a pop-up. Without chrome they don't make sense.
• A regular window that is not a dialog (thus it is non-modal) should overdraw the entire iframe AND it should be justified to the top left of the iframe even when it is explicitly positioned on the screen.
• We need to figure out dialog boxes (which are modal). Large ones are probably best handled as normal windows (no chrome, top/left justified and overdrawing the full background). But small ones may be better with chrome and positioned relative to the owner window. For example, the date picker/calendar pane that is used in an app which expects the user to be able to see the owner window at the same time as the user interacts with the dialog. Please consider the different cases here and how we might make a good default.

What other cases can people think of here?

Greg Shah wrote:

What other cases can people think of here?

I am wondering whether we should somehow handle the window message area and status bar. IMHO it is a common case to have a modaless window without message area and messages output to the message area of the default window.

I am wondering whether we should somehow handle the window message area and status bar. IMHO it is a common case to have a modaless window without message area and messages output to the message area of the default window.

This is a good point. And it is a tricky case. Modal dialogs grey out the background today (in embedded mode). Displaying messages in another window's message area would potentially require a common message area that always stays visible. It might look pretty weird.

Greg Shah wrote:

I am wondering whether we should somehow handle the window message area and status bar. IMHO it is a common case to have a modaless window without message area and messages output to the message area of the default window.

This is a good point. And it is a tricky case. Modal dialogs grey out the background today (in embedded mode). Displaying messages in another window's message area would potentially require a common message area that always stays visible. It might look pretty weird.

We could get more creative and solve this by using a proprietary control. For example the messages could be shown on demand - the user clicks a "message area" button the iframe will be filled with the current messages until the view is dismissed back to the last app window.

1. all modal windows are left with their chrome on, regardless of their size. An issue here is if the top-most visible window is a modal (non-alert-box) window... it should not have chrome. You mention in note 1 about large dialogs: what do we use as reference? The top-most non-modal, visible window - if it exceeds its bounds, then remove its chrome?
2. non-modal windows are re-positioned to top-left corner via javascript
3. modal windows are centered using the top-most visible non-modal window as reference
4. all non-visible windows and all windows behind the top-most non-modal window (in z-order) are hidden via CSS, using display: none (and restored the same way)

You mention in note 1 about large dialogs: what do we use as reference? The top-most non-modal, visible window - if it exceeds its bounds, then remove its chrome?

Also, what about a nested scenario, using this z-order (from bottom to top): window1 -> dialog1 -> dialog2 -> dialog3, where dialog3 can not fit in window1 - should it be displayed without chrome, and hide window1, dialog1 and dialog2?

An issue here is if the top-most visible window is a modal (non-alert-box) window... it should not have chrome.

Agreed.

You mention in note 1 about large dialogs: what do we use as reference? The top-most non-modal, visible window -

I'm torn between using the owner window and your idea of the top-most non-modal, visible window. I can see reasons for using either one.

if it exceeds its bounds, then remove its chrome?

I think this is close. How about we check if either the height or the width is equal to or greater than the reference window, then we remove its chrome. It is common for a dialog to only exceed in one dimension, but even in this case it seems likely that the user would not be expected to need to see the window below. Any such case is a chrome-removal case since it will look cleaner than doing the modal overlay thing (with chrome).

what about a nested scenario, using this z-order (from bottom to top): window1 -> dialog1 -> dialog2 -> dialog3, where dialog3 can not fit in window1 - should it be displayed without chrome, and hide window1, dialog1 and dialog2?

Yes, I think so.

Greg, there is a catch in deciding on a per-dialog frame case if it requires decorations or not: we can't know this until the dialog is shown; the decision can't be taken when the dialog is built/instantiated, but when is shown. And, a certain dialog can end up with or without decorations, depending when is used: are windows behind it in z-order? or is this the only window on screen?

This wouldn't be problematic if there weren't properties like BORDER-TOP-PIXELS which depend on the fact if the dialog-box has or not a title... but, wouldn't we want for these properties to report the same values, regardless if embedded mode or not?

but, wouldn't we want for these properties to report the same values, regardless if embedded mode or not?

Yes, that is correct. The fact that the user can't see them doesn't matter. The 4GL code should "think" that they are there.

Greg Shah wrote:

Eric suggests disabling the ability of the user to grab and move the window using the titlebar. I guess in this case it would just never allow dragging.

I think this would degrade usability, there are valid cases when you want to move the window away, for example to see the information in its owner window.

We can limit the position so that the window never leaves its screen area. This behavior would have to be conditional, in Swing for example it is valid to have any window leave the screen.

Greg Shah wrote:

Notice how the shading is around the owner (non-modal) window. It is confusing because it suggests that we should be able to interact with that window. But the idea of the shading is to be a clue to the user that this is a modal dialog. So I would like the shading to go all the way up to the modal dialog's chrome (the date picker in this case). I think this change is important for the demo.

I've fixed this in 3209b rev 11153. I've added an internal overlay panel (in the P2J window...), to cover the P2J windows behind the topmost modal one. Note that there is an issue here: as there are two overlay panels, one internal in the iframe and one external in the embedded window, where they overlap (in the iframe) the color is darker; I don't know if this can be solved.

A second request is that I would prefer to have the stacking fix so that I don't have to exclude that case from the demo. BUT if it is too much to get done then we can leave it out.

I have an idea here: let every window draw with the chrome, and fix it in the javascript - get the boundary of the internal content (without chrome) and force the canvas to have the size and content as if no chrome exists. This removes the decoration logic from the P2J runtime and moves it at the driver. If this works, I think will be cleaner.

Hynek Cihlar wrote:

Greg Shah wrote:

Eric suggests disabling the ability of the user to grab and move the window using the titlebar. I guess in this case it would just never allow dragging.

I think this would degrade usability, there are valid cases when you want to move the window away, for example to see the information in its owner window.

We can limit the position so that the window never leaves its screen area. This behavior would have to be conditional, in Swing for example it is valid to have any window leave the screen.

Yes, this makes sense.

I've fixed this in 3209b rev 11153. I've added an internal overlay panel (in the P2J window...), to cover the P2J windows behind the topmost modal one. Note that there is an issue here:

This only works the first time a modal dialog is brought up. After that it never shows again.

Also, at least one time (but not other times) I have seen the other screens (e.g. Guests) fail to load after using the date picker a few times on the first screen (Available Rooms).

as there are two overlay panels, one internal in the iframe and one external in the embedded window, where they overlap (in the iframe) the color is darker; I don't know if this can be solved.

Wasn't that darker color also showing in the original approach? I think it is just being drawn darker anyway, this is the area of the iframe that is outside of the main window and is supposed to be drawn with the same background color as the 4GL window background. It is important to try to fix this as it is visually distracting.

Interestingly, when you nest dialogs, the inner shading "comes back" (after being missing).

From Guests, use the Update button to get to the Update Reservations dialog, then use the Update button on that window.

Perhaps the missing inner shading is due to the stacking issue.

I have an idea here: let every window draw with the chrome, and fix it in the javascript - get the boundary of the internal content (without chrome) and force the canvas to have the size and content as if no chrome exists. This removes the decoration logic from the P2J runtime and moves it at the driver. If this works, I think will be cleaner.

I don't have a major objection to this. But I do think it is possible that users may want to embed the Swing client in a larger application. One recent customer thought about doing this as a fall back plan (where they would have the P2J client embedded in and integrated with their Java application).

Having the logic in common code would be helpful for that case. I do realize the feature is not exposed to the Swing client today.

Greg Shah wrote:

Wasn't that darker color also showing in the original approach? I think it is just being drawn darker anyway, this is the area of the iframe that is outside of the main window and is supposed to be drawn with the same background color as the 4GL window background. It is important to try to fix this as it is visually distracting.

No, is not that, because I've disabled it

Interestingly, when you nest dialogs, the inner shading "comes back" (after being missing).
Perhaps the missing inner shading is due to the stacking issue.

The problem is with computing the z-index in removeZOrderEntryWorker - AFAIK all windows need to have different z-order values, but this allows two windows to have the same z-order. I'm trying to fix it.

I don't have a major objection to this. But I do think it is possible that users may want to embed the Swing client in a larger application. One recent customer thought about doing this as a fall back plan (where they would have the P2J client embedded in and integrated with their Java application).
Having the logic in common code would be helpful for that case. I do realize the feature is not exposed to the Swing client today.

OK, I'll try to think to a more generic approach... the idea would be the same, the driver will display on the undecorated content.

Greg, see 3209b rev 11154 - it fixes the overlay panel problems (not showing sometimes and the bgcolor).

It works perfectly! I really, really like it.

What is left on this task?

Greg Shah wrote:

What is left on this task?

1. how to handle status-area and message-area - haven't thought of a good solution for this yet - Hynek's idea is interesting, but the impl details are ... tricky.
2. generic approach to solve the dialog-box without chrome issue (when is top-level, when is wider/taller than the parent window, etc)
3. do not allow the dialog-boxes with chrome to be moved outside the iframe

how to handle status-area and message-area - haven't thought of a good solution for this yet - Hynek's idea is interesting, but the impl details are ... tricky.

You're referring to his idea in note 4? I like this idea, but would prefer not to put the control in the user's hands. The embedded app itself can control visibility of the proprietary control that displays these messages. Perhaps that would take away some of the trickiness.

If not using a proprietary control, then an alternative would be to provide them to the embedded app and let each app decide how/when to display the messages. The embedded app could register a callback that we can call every time new content would be displayed there. We might want to provide other info (whether it was a status or message, what window...), but that could easily be handled with parameters to the callback.

The callback approach could be done quickly and then we could defer the proprietary control as an improvement for later.

Greg Shah wrote:

The callback approach could be done quickly and then we could defer the proprietary control as an improvement for later.

I agree, the callback looks better.

How much time do you need to finish this task?

Greg Shah wrote:

How much time do you need to finish this task?

I think tomorrow will be finished.

Does anyone know how to get the iframe height (and not the screen height...) using javascript? I've tried document.body.scrollHeight executed from the iframe side, but this doesn't work in firefox - it returns 0... in chrome it works.

This is needed to not allow the dialog to be moved vertically beyond the iframe's bottom.

Something I haven't considered when translating the top-left origin and resizing the canvas, so that the chrome gets 'hidden': all mouse processing data, combo drop-down windows, right-click menus, etc, will use the untranslated/original coordinates... this complicates things a lot, as these would need to be intercepted and coordinates be adjusted. I'll try to think of a smart/easy way to intercept and adjust these coordinates.

To keep both legacy attributes (like border-related) untouched, one idea would be to color the titlebar/window border/etc with the window's bgcolor, so they are not actually visible, but they will still occupy space. Keeping these from responding on events is another tricky area.

Hmm. Good points. Is it worth deferring these pieces while we have more urgent work to complete?

Greg Shah wrote:

Hmm. Good points. Is it worth deferring these pieces while we have more urgent work to complete?

Beside adjusting the events/etc to consider that the chrome is not there, what is left is to 'hook up' the decoration verification code in these methods at the driver and testing:

resizeWindow(int, int)
setWindowBounds(int, int, int, int)
setWindowLocation(int, int)
setWindowVisible(boolean)
setWindowEnabled(boolean)
stackWindows(int[])
moveToTop(int, boolean)
moveToBottom(int)

I've created 3218a for these changes, you can take a look if you want.

I'll check on Monday if I can find a quick way to solve this; otherwise, I can switch to other work.

What is the status of this task? Do we have anything to do or have the issues been resolved by changes elsewhere?

Greg Shah wrote:

What is the status of this task? Do we have anything to do or have the issues been resolved by changes elsewhere?

3218a was WIP and not finalized. I need to re-review it to recall the state of the changes and what is missing, but as I recall there were some issues with opening another window from the 'main' embedded window (how deep to stack it, do we allow breadcrumbs to go back in the stack, some issues with removing decorations, what happens with large alert boxes, etc).

From 3218a branch, all usable code was extracted into #3469 branches and used. Otherwise, the branch can be archived.

I think this task can be closed, right?

Greg Shah wrote:

I think this task can be closed, right?

Yes. 3218a was archived as dead.