On Fri, Sep 12, 2008 at 5:21 AM, Sebastian Werner
<[EMAIL PROTECTED]> wrote:
> Just note that "appear" is post-layout and post-DOM. You might see the
> window in the original dimensions first. Better is to use the resize
> event. Can you test this as well and tell us if it works OK, too?
>
> Sebast
In cases where you develop some kind of inner windows for something like
a MDI window e.g. something like a pseudo desktop in your application.
But most often windows are added to the root (and this happens
automatically in 0.8).
Sebastian
Oleksiy Golovko schrieb:
> Hm... Never thought that w
Hm... Never thought that window may be a part of any other widget but
root. Or you're talking about the Inline applications?
Sebastian Werner wrote:
> In your special case, when the windows are part of the root you may also
> use qx.bom.Viewport.getWidth/getHeight instead of the whole resize thi
In your special case, when the windows are part of the root you may also
use qx.bom.Viewport.getWidth/getHeight instead of the whole resize thingy.
Sebastian
Oleksiy Golovko schrieb:
> Yes, 'resize' definitely works better. Thanks for the hint :)
>
> Previous snippet (modified):
> var win = ne
Yes, 'resize' definitely works better. Thanks for the hint :)
Previous snippet (modified):
var win = new qx.ui.window.Window('Title');
win.addListener('resize', function(e) {
var bounds = qx.core.Init.getApplication().getRoot().getBounds();
this.set({
width: bounds.width * 0.
Just note that "appear" is post-layout and post-DOM. You might see the
window in the original dimensions first. Better is to use the resize
event. Can you test this as well and tell us if it works OK, too?
Sebastian
Oleksiy Golovko schrieb:
> Sebastian,
>
> Thanks for the explanation, I see t
Sebastian,
Thanks for the explanation, I see the technical problem with it. So I
think the best way to configure window dimensions relative to screen is
to count them manually in the 'appear' handler. Here is the code snippet
which might be useful for other developers having similar task:
var
Oleksiy Golovko schrieb:
> Sebastian
>
> Thank you for the explanation, but I'm not yet accustomed to new qx
> layouting system, so I often think - are 'width' and 'height' widget
> properties or layout ones. Yeah, I've read the ui_layouting aricle but
> seems that I want to re-read it once agai
Sebastian
Thank you for the explanation, but I'm not yet accustomed to new qx
layouting system, so I often think - are 'width' and 'height' widget
properties or layout ones. Yeah, I've read the ui_layouting aricle but
seems that I want to re-read it once again :)
Regarding the moving/resizing w
Please also keep in mind that percent dimensions keep percent. So using
them might break the support for resizing and moving of such a window.
You can disable these if this is OK, otherwise mhh, you are maybe out of
luck for the moment.
Sebastian
Sebastian Werner schrieb:
> Just saw you add
Just saw you add it to the root of your application. If you use a
traditional Standalone application you can define a percent width at the
insertion time of the window as a so-named layout property e.g.
app.getRoot().add(dlg, { width : "30%" });
You may also double check that you have read this
You could add some methods to the Window class to support environment
variables (such as the container etc) to compute the width and height
according to given percent parameters, no ?
-
This SF.Net email is sponsored by the Mob
Dimensions can only be given using pixels. Other dimension values depend
on the layout you use inside the parent widget of the window.
The HBox, VBox, Dock, Canvas layouts supports percent dimensions. But
all other do not. Where do you insert the window to?
Sebastian
Oleksiy Golovko schrieb:
Hi
I'm trying to set window dimensions using 'NN%'-like form without any
success. The only effect I see is that "X"-close button got moved closer
to the window title text. Here steps to reproduce:
var dlg = new qx.ui.window.Window('Error', null)
.set({
//wid
14 matches
Mail list logo