XCreateWindow position fail - Xwindows

This is a discussion on XCreateWindow position fail - Xwindows ; Hi XCreateWindow(display, RootWindow(display, screen_number), 100, 100, 640, 480, 0, XDefaultDepth(display, screen_number), InputOutput, visual, attributemask, &attributes); I am using Debian 3.1R3 with KDE, i try to use XCreateWindow to create a window with a startup position 100,100, it is not working, ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: XCreateWindow position fail

  1. XCreateWindow position fail

    Hi
    XCreateWindow(display, RootWindow(display, screen_number), 100, 100,
    640, 480, 0, XDefaultDepth(display, screen_number), InputOutput,
    visual, attributemask, &attributes);

    I am using Debian 3.1R3 with KDE, i try to use XCreateWindow to create
    a window with a startup position 100,100, it is not working, the window
    init position at 0,0
    how to?

    thanks
    from Peter (cmk128@hotmail.com)


  2. Re: XCreateWindow position fail

    cmk128 wrote:

    Please do not crosspost without setting followup. Corrected, Fup2cwx.

    > I am using Debian 3.1R3 with KDE, i try to use XCreateWindow to create
    > a window with a startup position 100,100, it is not working, the window
    > init position at 0,0
    > how to?


    The position is only a hint, the window manager can honour or ignore it.
    Try static gravity for your window (then the position relates to your
    window, not the decoration frame of the window manager) or setting the
    override redirect attribute for your window (then your window will have no
    decoration).

    Daniel

  3. Re: XCreateWindow position fail

    cmk128@hotmail.com wrote:

    > I am using Debian 3.1R3 with KDE, i try to use XCreateWindow to create
    > a window with a startup position 100,100, it is not working, the window
    > init position at 0,0
    > how to?


    After the XCreateWindow(), use XMoveWindow() to force it to a specific
    position.


  4. Re: XCreateWindow position fail

    In comp.windows.x, Tony O'Bryan

    wrote
    on Tue, 19 Sep 2006 16:49:47 GMT
    :
    > cmk128@hotmail.com wrote:
    >
    >> I am using Debian 3.1R3 with KDE, i try to use XCreateWindow to create
    >> a window with a startup position 100,100, it is not working, the window
    >> init position at 0,0
    >> how to?

    >
    > After the XCreateWindow(), use XMoveWindow() to force it to a specific
    > position.
    >


    Not sure how well that will work; modern window managers like to
    reparent the window. Fortunately, they will also intercept the
    XMoveWindow() call, though it's far from clear exactly what they'll do
    with it.

    A quick test suggests it will work but it may depend on how forgiving
    the window manager is. :-) However, it may be off by a few pixels
    because of the window-manager-created border.

    --
    #191, ewill3@earthlink.net
    Windows Vista. Because it's time to refresh your hardware. Trust us.

  5. Re: XCreateWindow position fail

    The Ghost In The Machine writes:

    > In comp.windows.x, Tony O'Bryan
    >
    > wrote
    > on Tue, 19 Sep 2006 16:49:47 GMT
    > :
    >> cmk128@hotmail.com wrote:
    >>
    >>> I am using Debian 3.1R3 with KDE, i try to use XCreateWindow to create
    >>> a window with a startup position 100,100, it is not working, the window
    >>> init position at 0,0
    >>> how to?

    >>
    >> After the XCreateWindow(), use XMoveWindow() to force it to a specific
    >> position.
    >>

    >
    > Not sure how well that will work; modern window managers like to
    > reparent the window. Fortunately, they will also intercept the
    > XMoveWindow() call, though it's far from clear exactly what they'll do
    > with it.
    >
    > A quick test suggests it will work but it may depend on how forgiving
    > the window manager is. :-) However, it may be off by a few pixels
    > because of the window-manager-created border.


    It is very unfriendly of apps to move around windows like that.
    Window positioning should be left to the user, or the window manager
    if the user so chooses. I have configured my window manager to ignore
    application requests to move or resize windows.

    --
    Måns Rullgård
    mru@inprovide.com

  6. Re: XCreateWindow position fail

    Måns Rullgård wrote:

    > It is very unfriendly of apps to move around windows like that.
    > Window positioning should be left to the user, or the window manager
    > if the user so chooses. I have configured my window manager to ignore
    > application requests to move or resize windows.


    It's a matter of the programmer following accepted conventions. There are
    times when window placement should be left to the user, and times when it
    shouldn't be left to the user (and most users wouldn't want it to be left
    to them). An example of the latter is a popup dialog. The vast majority
    of users expect dialogs to appear at the center of their screen. Users
    would be quite annoyed if they had to manually move each and every dialog
    to the center of the screen, or if they had to search the screen for the
    window. It also reflects poorly on the windowing system.

    Also, most visual component of a user interface are windows (line input
    boxes, menu items, labels, scrollbars, etc). Not allowing the program to
    move those things automatically would be disastrous.

    Don't think of a window as just the main application window.


  7. Re: XCreateWindow position fail

    Tony O'Bryan writes:

    > Måns Rullgård wrote:
    >
    >> It is very unfriendly of apps to move around windows like that.
    >> Window positioning should be left to the user, or the window manager
    >> if the user so chooses. I have configured my window manager to ignore
    >> application requests to move or resize windows.

    >
    > It's a matter of the programmer following accepted conventions. There are
    > times when window placement should be left to the user, and times when it
    > shouldn't be left to the user (and most users wouldn't want it to be left
    > to them). An example of the latter is a popup dialog. The vast majority
    > of users expect dialogs to appear at the center of their screen. Users
    > would be quite annoyed if they had to manually move each and every dialog
    > to the center of the screen, or if they had to search the screen for the
    > window.


    This should be done by setting window manager hints on the dialog
    window. Then the window manager knows it is a dialog, and can use
    different placement rules.

    > It also reflects poorly on the windowing system.


    I don't understand what you mean by that.

    > Also, most visual component of a user interface are windows (line input
    > boxes, menu items, labels, scrollbars, etc). Not allowing the program to
    > move those things automatically would be disastrous.
    >
    > Don't think of a window as just the main application window.


    I was obviously only talking about top-level windows.

    --
    Måns Rullgård
    mru@inprovide.com

  8. Re: XCreateWindow position fail

    Måns Rullgård wrote:

    > Tony O'Bryan writes:


    > [Dialog centering] should be done by setting window manager hints on the

    dialog
    > window. Then the window manager knows it is a dialog, and can use
    > different placement rules.


    I don't see anything in WM_HINTS that tells the window manager about
    modality. It seems to be the responsibility of the application to handle
    the distinction.

    >
    >> It also reflects poorly on the windowing system.

    >
    > I don't understand what you mean by that.


    A window manager that requires the user to manually position windows that
    should be automatically placeable by the application is a poor window
    manager.

    >
    > I was obviously only talking about top-level windows.
    >


    I figured you were, but the X Window System mostly doesn't care about the
    distinction. Every visual component of a user interface is a window, and
    therefore is subject to movement by XMoveWindow (which is what my response
    is all about).

    That said, moving the window after creating it shouldn't be necessary. The
    XCreateWindow documentation says nothing about the x,y coordinates being
    merely hints. If the window manager does not place the window at the
    specified location, then I would consider either the window manager to be
    badly broken, or the documentation to be broken.


  9. Re: XCreateWindow position fail

    Tony O'Bryan writes:

    > Måns Rullgård wrote:
    >
    >> Tony O'Bryan writes:

    >
    >> [Dialog centering] should be done by setting window manager hints on
    >> the dialog window. Then the window manager knows it is a dialog,
    >> and can use different placement rules.

    >
    > I don't see anything in WM_HINTS that tells the window manager about
    > modality. It seems to be the responsibility of the application to
    > handle the distinction.


    I don't know the details, but my window manager (sawfish) lets the
    user choose placement rules separately for normal windows and
    dialogs. For dialogs, some additional placement modes are offered,
    such as centered on parent.

    >>> It also reflects poorly on the windowing system.

    >> I don't understand what you mean by that.

    >
    > A window manager that requires the user to manually position windows
    > that should be automatically placeable by the application is a poor
    > window manager.


    I said nothing about manual positioning. What I'm saying is that the
    window manager, not the application, should be in charge of placing
    windows. The window manager knows the locations of other windows, and
    can take user preferences into account. Putting that kind of
    functionality in each and every application would be stupid.

    >> I was obviously only talking about top-level windows.

    >
    > I figured you were, but the X Window System mostly doesn't care about
    > the distinction. Every visual component of a user interface is a
    > window, and therefore is subject to movement by XMoveWindow (which is
    > what my response is all about).


    I know about window hierarchies. We were talking about placement of
    top-level windows, dialogs in particular. Handling this is the
    purpose of the window manager. It does not and should not care what
    you do inside your top-level window. Please leave that aspect out of
    the discussion.

    > That said, moving the window after creating it shouldn't be necessary.
    > The XCreateWindow documentation says nothing about the x,y coordinates
    > being merely hints. If the window manager does not place the window
    > at the specified location, then I would consider either the window
    > manager to be badly broken, or the documentation to be broken.


    It is true that the documentation for that particular function doesn't
    mention that the window manager has the possibility of overriding the
    placement. That doesn't make it wrong of the window manager to do so,
    and the facilities it uses to accomplish this are well-documented
    elsewhere.

    An application should only be concerned with the *interior* of its
    windows. The positioning of windows in a screen is a task better
    suited for the window manager. A well-behaved application doesn't
    even need to know the on-screen coordinates of its windows.

    --
    Måns Rullgård
    mru@inprovide.com

  10. Re: XCreateWindow position fail

    In article ,
    Tony O'Bryan wrote:
    >
    >I don't see anything in WM_HINTS that tells the window manager about
    >modality. It seems to be the responsibility of the application to handle
    >the distinction.
    >


    WM_TRANSIENT_FOR, XGetTransientForHint(), XSetTransientForHint()

    >A window manager that requires the user to manually position windows that
    >should be automatically placeable by the application is a poor window
    >manager.
    >


    There wouldn't be so many window managers if we all agreed on what makes a
    good one.

    >
    >That said, moving the window after creating it shouldn't be necessary. The
    >XCreateWindow documentation says nothing about the x,y coordinates being
    >merely hints. If the window manager does not place the window at the
    >specified location, then I would consider either the window manager to be
    >badly broken, or the documentation to be broken.


    The documentation tells you what happens in the absence of a window manager.
    Anything else is in the scope of the window manager's documentation.

    --
    The attacker\x92s overall goal would very probably be to convince other users
    to run an unsafe program, by using the digital signature to convince them
    that it is actually bona fide Microsoft software and therefore safe to run.
    -- security bulletin MS01-017 ushers in a new definition of "safe"

  11. Re: XCreateWindow position fail

    In article ,
    Tony O'Bryan wrote:

    > Måns Rullgård wrote:
    >
    > > It is very unfriendly of apps to move around windows like that.
    > > Window positioning should be left to the user, or the window manager
    > > if the user so chooses. I have configured my window manager to ignore
    > > application requests to move or resize windows.

    >
    > It's a matter of the programmer following accepted conventions. There are
    > times when window placement should be left to the user, and times when it
    > shouldn't be left to the user (and most users wouldn't want it to be left
    > to them). An example of the latter is a popup dialog. The vast majority
    > of users expect dialogs to appear at the center of their screen. Users
    > would be quite annoyed if they had to manually move each and every dialog
    > to the center of the screen, or if they had to search the screen for the
    > window. It also reflects poorly on the windowing system.



    As others have pointed out, you are assuming too much
    about your users' preference.

    The approach you are taking is exactly what Microsoft
    Windows takes. Everything in your face type of a thing.

    Personally, I would consider an application forcing its
    window position upon me very rude at best and a virus-
    wannabe at worst.


    > Also, most visual component of a user interface are windows (line input
    > boxes, menu items, labels, scrollbars, etc). Not allowing the program to
    > move those things automatically would be disastrous.
    >
    > Don't think of a window as just the main application window.



    I am not. Again, as others pointed out, it should be
    left to the window-manager, which the user has chosen
    to use and potentially configured to his/her preference
    when it comes to managing window (_all_ window)
    positioning tasks!

  12. Re: XCreateWindow position fail

    patrick wrote:

    > I am not. Again, as others pointed out, it should be
    > left to the window-manager, which the user has chosen
    > to use and potentially configured to his/her preference
    > when it comes to managing window (_all_ window)
    > positioning tasks!


    So you would be okay with the command buttons on your applications appearing
    in semi-random locations each time you invoked a dialog? Or with your
    window manager enforcing a policy that all text input widgets must appear
    at (10,10)? I think not.


  13. Re: XCreateWindow position fail


    "Tony O'Bryan" wrote in message
    news:EsaWg.9967$vJ2.6142@newssvr12.news.prodigy.co m...
    > patrick wrote:
    >
    >> I am not. Again, as others pointed out, it should be
    >> left to the window-manager, which the user has chosen
    >> to use and potentially configured to his/her preference
    >> when it comes to managing window (_all_ window)
    >> positioning tasks!

    >
    > So you would be okay with the command buttons on your applications
    > appearing
    > in semi-random locations each time you invoked a dialog? Or with your
    > window manager enforcing a policy that all text input widgets must appear
    > at (10,10)? I think not.
    >


    The window manager only positions top-level shell widgets.
    It ignores other widgets such as buttons, texts, forms, labels, etc.
    --
    Fred L. Kleinschmidt
    Boeing Associate Technical Fellow
    Technical Architect, Software Reuse Project



+ Reply to Thread