Results 1 to 3 of 3

Thread: ClanLib 0.9 GUI Questions

  1. #1
    ClanLib Developer
    Join Date
    May 2007

    Default ClanLib 0.9 GUI Questions

    I am have trouble understanding how the GUI works, there are some aspects to it that seem counter-intuitive.

    If you want to render to CL_Textures, you use: CL_GUIWindowManagerTexture, where there can be multiple gui textures for a single display window.

    If you want to render directly to the window where the entire window is controlled by the GUI, you use: CL_GUIWindowManagerSystem

    As I understand it, there is a single CL_GUIManager, which you attach either CL_GUIWindowManagerTexture or CL_GUIWindowManagerSystem.

    If you use CL_GUIWindowManagerSystem to create the display window, you cannot render the GUI to a texture. i.e. you cannot mix window managers for a specific display window.

    Focus Window
    CL_GUIWindowManagerSystem: the window focus is handled by the OS. All messages are passed onto the root component (which usually is CL_Window)

    CL_GUIWindowManagerTexture: the texture focus is controlled by the gui window manager (Passed to the focussed component, usually CL_Window)

    GUI Messaging
    CL_GUIWindowManagerSystem: the window messaging is controlled by dispatching messages from CL_DisplayMessageQueue

    CL_GUIWindowManagerTexture: the window messaging is controlled by dispatching messages from CL_DisplayMessageQueue

    How should the focus work on the CL_GUIWindowManagerTexture ?

    The focus control, currently does not appear to work correctly, because it only processes the message for the focused component (CL_Window), thus all other

    CL_Window's never have the opportunity to gain focus.

    I am not sure that the CL_GUIWindowManagerTexture should process CL_DisplayMessageQueue events?, as it does not own the display window.

    Instead, should the CL_GUIManager dispatch events to each root component (CL_Window), not the window manager

    CL_GUIWindowManagerTexture has functions like - set_cursor(), that is not relevant for a texture based gui window. Should these functions be removed?

    Would it be a better option to change CL_GUIWindowManagerSystem to inherit CL_GUIWindowManagerTexture? So it adds functionality to CL_GUIWindowManagerTexture to create a physical window instead of a texture
    Last edited by rombust; 02-09-2009 at 07:13 PM. Reason: cosmetic edit

  2. #2
    Master Sorcerer
    Join Date
    Sep 2006


    OK, I'll try explain why things are like they are.

    The GUI has two kinds of components: top-level and child components. This may seem similar to normal windowing systems (Win32 hwnd, X11, etc.) but there is an important difference: We treat the child components as internal implementation details of a top-level window, while normal windowing systems see them as distinctive objects.

    The main reason for our GUI to do this is because most windowing systems do not directly support a bottom-up rendering strategy, which is required for transparency. It also complicates situations where you want the rendering to be double buffered and displayed in a single frame update.

    However, another very useful side effect from this distinction is that we get a natural boundary between what is clanGUI's job and what is handled by the host windowing system. CL_GUIWindowManager is the abstraction which defines this boundary and manages all top-level windows that have been created.

    Since we handle all child components on our own, this naturally also means that we only have top level windows in the windowing system. A consequence of this is that things like focus management now becomes a little bit more complicated. If we had only OS windows, we could simply let the windowing system track our currently focused window. But since the OS only knows about the top components, we use the OS to tell us which top component has the focus and then clanGUI uses that knowledge to know which child component really has the focus.

    Messages are dealt with in a similar fashion. The system window manager is told via CL_DisplayWindow callbacks that something happened to a top level window, and then it tells clanGUI about this and clanGUI figures out which child window it was really intended for.

    Now regarding the texture window manager, this manager effectively simulates everything a windowing system does. There is no OS that can now tell it which top-level window has the focus - it has to decide this on its own.

    When the texture WM gets a key press from its CL_DisplayWindow, the key is not already bound to a specific top level window as it is with the system WM. Instead it needs to look at its own 'focused top level window' variable and dispatch it accordingly. The texture WM currently has a bug (reported by sphair) that makes it dispatch mouse clicks incorrectly. It sends them to the focused window instead of the window clicked. This is a fairly simply bug to fix though - just haven't gotten around to it.

    Things like set_cursor belongs to the window manager abstraction because it is only the WM that knows how to effectively do this. For the system WM this is fairly simple, it just forwards the request to the CL_DisplayWindow. But for the texture WM the cursor is only the right one when the cursor is above that top level window within the shared CL_DisplayWindow.

    I personally do not think its a good idea to make the system WM derive from the texture WM, simply because they do not really share any common functionality. Virtually all the code in the texture WM is not relevant for the system WM because it forwards those problems to the host windowing system.

    I hope this clears up bit of the design considerations for the window manager system in clanGUI.

  3. #3
    ClanLib Developer
    Join Date
    May 2007


    Thanks, that has helped a lot.

    The GUI focus problems have now been fixed.

Similar Threads

  1. Questions
    By in forum Dink Smallwood HD
    Replies: 1
    Last Post: 12-20-2005, 09:54 PM
  2. few questions :D
    By virtual_lady in forum Dink Smallwood HD
    Replies: 3
    Last Post: 07-10-2005, 07:02 AM
  3. Some questions
    By in forum Funeral Quest
    Replies: 1
    Last Post: 06-29-2004, 04:43 AM
  4. Questions
    By Davidi in forum Dink Smallwood HD
    Replies: 0
    Last Post: 01-20-2004, 08:53 AM
  5. few questions...
    By in forum Dink Smallwood HD
    Replies: 2
    Last Post: 07-02-2003, 01:53 AM



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts