GWT-EXT WindowMgr, WindowGroups and their counterparts in SmartGWT

[mgrouch]

We are trying to estimate what it takes to switch to SmartGWT from GWT-EXT.
We have written a desktop window manager with GWT-EXT with taskbar
and support of icons on desktop.

In some parts we are using GWT-EXT WindowMgr, WindowGroups.
Can you point what are their counterparts in SmartGWT?

Thanks,
--MG

[Isomorphic]

Hello MG,

From a quick look:
- all SmartClient widgets support bringToFront()/sendToBack()
- you can put a number of Windows as normal children of a Canvas; if you wanted to track them separately from other children (like maybe icons) you could subclass Canvas and add an addWindow() / removeWindow method pair that just calls addChild() but also tracks Window instances.

[laurian]

Hi,
I'm also trying to build a window-manager.
I have a panel with a list of buttons corresponding to the windows. Clicking a button would show/bringtofront/minimize its corresponding window. When a window is in front, its button would look pressed. More or less MS Windows behaviour...
My problem is to detect when a window is in front. I was using Gwt-Ext before and there was the function WindowMgr.getActive() and the events WindowListener.OnActivate and WindowListener.OnDeactivate. Are there any similar functions / events in SmartGwt? If not, how could I make the desired behaviour?

Thanks,
Laurian

[svjard]

@Laurian: You could get that information by examing the set of window's z indices. The highest z-index would be the window in front. see Canvas.getZIndex()

[laurian]

OK, I was hoping there was a way to know directly the most-front z-index (smart gwt must know it because it sets the correct z-index when you bring a window to front...).
And do you know if there is a way to detect z-index change events? I still don't know when a window is activated/deactivated...
Thanks anyway!

[svjard]

@laurian: There is a parameter, isc.Canvas._BIG_Z_INDEX which defines which window is at the front. Basically if getZIndex() == _BIG_Z_INDEX then this is the front most window. You can use JSNI easily to create functions around this, however still you have X number of windows in the manager to compare the z index against, this is no different then how Gwt-Ext window manager works. It just provided you already defined functions, so you have to write like 3 lines of code to define your own activated/deactivated functions.

How would you consider a z index changing expect programmatically in which case why track it? Unless you are writing functionality such that when the window is clicked it automatically calls bringToFront() in which case you just need a click handler.

[laurian]

@svjard: Thanks for your reply. I was able to build my window manager.
In the end, I don't use the z-index, instead I'm handling:
- MinimizeClick -> deactivate window (and activate the new top-most window)
- MaximizeClick -> activate window (and deactivate the last active window)
- Click -> activate window (and deactivate the last active window)
- DragRepositionStart -> activate window (and deactivate the last active window)

I'm not handling DragResize as it doesn't change the z-index apparently.
Please, tell me if other events change the z-index, and if I'm doing something wrong...

[svjard]

I guess close click, restore click would have to be handled too, otherwise you have handled the rest. Unless key clicks are expected to do things, but generally that is a design call on your part, by default they don't do anything.

[laurian]

True, I have to handle CloseClick. But I dont think that RestoreClick is needed since I can't see a situation where Restore can be clicked on a non-active window...

Thanks anyway for your help.