Re: [Ongui-dev] event dispatch and layout mgr

[Robin R. <ro...@Mo...>]

Mike,

> Followup research reveals that the size which
> pango_font_description_set_size() takes is in "pango units." There are
> PANGO_SCALE pango units in one device unit (a point in my case). And,
> drum roll please, PANGO_SCALE is defined as 1024.

Didn't know that either.

> 1) Base widget class? All widgets will have to do size requisition and
>    allocation, as well as some GDK resource management.

class OnWindow;

> 2) For now, I'm going to use a global function to process
>    events. Going forward, though, do you intend for the top level
>    containers to have a member method for this purpose? And how will
>    this interact with threading?

Don't all native GUI APIs use a message pump at their core? Do you see a
problem with reusing the architecture from GFX? Isn't that what we set out
to do, extending its approach to other platforms?

In GFX a 'this' pointer is tucked into the Win32 window struct as a void* at
window creation. I think X11 will let you do the same thing. The GFX Window
class also sets a Win32 windproc, a callback function for events in that
window. The Win32 message pump dispatches the event by calling the relevant
callback. Every window must have a callback in order to respond to events.
In that callback (provided internal to OnGui) a cast is used so that void*
gets turned back into an useful object pointer, then it routes the event to
the user by calling the appropriate virtual method (where the user's
functionality is added). That 'this' is tucked into the native window struct
is the heart of the system. That the user doesn't have to code the event
dispatch, cast, or callback cuts out a lot of repetitive coding.

To the user it seems the event shows up like magic in the virtual method.
OnGui does the plumbing, but based on the native windowing event system. It
doesn't re-implement the native event dispatch system, just hides the ugly
callback code.

In native window APIs there is one message pump per GUI thread. Less would
cause event starvation -- with nothing to dispatch events. A goal in OnGui
is to be close to the native API, with a thin abstraction layer so it will
be portable. The GFX API was designed for that, but was never ported. OnGui
is an effort to port and extend the GFX architecture, right?

In the old days programmers sometimes used multiple message pumps in the
same process (thread) as a form of non-preemptive multi-tasking for lack of
access to launching threads. That shouldn't happen in a new design. With GUI
threads it is one-and-only-one message pump per thread.

> 3) Layout classes: coming from a GTK+ background, I think in terms of
>    bins, hboxes, vboxes and "fixed position" containers, each with
>    various packing and padding options. This, I think, is a little
>    unwieldy at times. I'm familiar with other layout models, but I
>    haven't used anything else enough to form an opinion. Do you have a
>    particular philosophical bent on this?

Yes, minimalist. Effort seems wasted on clever layout managers in other GUI
APIs.

Let me tell you about Java. A lot of thought was put into it on layout
managers, and it is a recent design. It has a layout manager base class and
several derived classes to do different styles of layout. Most Java
programmers use one of these stock layout managers -- and can never quite
get the layout the way they wish. It is too automatic. In frustration, Java
programmers often resort to placing everything in absolute pixel
coordinates. That often works better, despite not being very elegant. Few
programmers override the layout manager class in Java to take control of
layout indirectly, though that can work well and is more elegant.

OnGui should do some layout math, but not be overly clever. Base class
OnLayoutMgr doesn't do a thing except keep a list of sub-windows for use by
more complex derived layout managers. It is a trivial layout mgr that allows
sub-windows to be placed in absolute pixels without interference.

The derived OnAbsoluteLayoutMgr also places sub-windows in absolute pixels -
- nothing about moving sub-windows around. It does, however, query each
sub-window for its size so that it can scale a container window's size to
fit around them. It would simply calc the bounding box from each
sub-window's box and adjust a box (resize the container) accordingly.

OnWindow would contain an OnLayoutMgr reference. By default it would
reference a global instance of an OnAbsoluteLayoutMgr so that every window
has minimal layout management, but can set a custom layout manager if it
chooses. To do that would require deriving a new class from OnLayoutMgr and
assigning it to the layout_mgr reference. An advanced layout manager can
adjust sub-window boxes simply by setting their box coordinates directly
then telling them to redraw.

Something like this:

struct OnBox
{  int x;
    int y;
    int dx;
    int dy;
};

class OnWindow;

class OnLayoutMgr
{    Dl_list sub_window_list;
public:
    virtual void AddSubWindow(OnWindow* window)
    {  // keeps a list of sub-windows but does nothing with them.
        sub_window_list.Append(window);
    }
};

class OnAbsoluteLayoutMgr
:    public OnLayoutMgr
{public:
    void Resize(OnBox* container_box)
    {    ... walks sub_window_list calculating minimal container_box.dx and
            container_box.dy to contain sub-windows.
    }
};

OnAbsoluteLayoutMgr alm;

class OnWindow
:    public OnMsgDispatcher // event callback stuff from GFX
{    const char* string_name; // used by resource file
      int window_id; // used in event dispatch?
public:
    OnBox bounding_box; // deliberately public objects
    OnLayoutMgr& layout_mgr;

    OnWindow(const char* name,OnWindow* container_window=0)
    :      layout_mgr(alm)
    {      bzero(bounding_box);
            string_name=name;
            window_id=LookupWindowId(name);
            if(container_window)
            {    container_window->alm.AddSubWindow(this);
            }
      }
      void Resize()
      {    layout_mgr.Resize(&bounding_box);
      }
      ...
};

GFX has an implementation of the event stuff, but no layout mgr. In GFX
there is no separate window-less base class that has just the event stuff.

> > I want to have a developer mode I can activate to do on-the-fly
> > GUI-building inside a live app.
>
> Ah, the holy grail of GUI toolkits. This is exciting stuff. At my last
> job, I spent some time pondering this sort of functionality. So when
> we get to that point, I hope to be able to contribute.

Sounds good!

Cheers,

Robin
---------------------------------------------------------------------------
Rob...@Mo...   Hollywood, California
www.CinePaint.org   Free motion picture and still image editing software