ongui-developers — OnGui API Developers

[Ongui-dev] status

[Mike D. <mi...@cs...>]

Robin,

Just a summary of the state of OnGui:

Currently checked into CVS is a basic toolkit with working Labels, Buttons, Windows
and HLayout (horizontal layout).

It is GNU autoconf-ed and has test drivers in subdir /test.

My immediate plans are to get resizing working, then implement some more advanced
layout managers.

> Plans are in flux at the moment. I've had some new ideas, but am still
> researching them.

Please let me know if you think OnGui isn't going anywhere. For now, I'm learning
quite a bit, so I'm going to keep on trucking.

-m

Re: [Ongui-dev] platforms

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

Mike,

> So I started poking through the GTK-OSX project code. Do you see any
future
> integration between that project and OnGui?

Plans are in flux at the moment. I've had some new ideas, but am still
researching them.

Cheers,

Robin
-------------------------------------------------------------------
Rob...@Mo...   Hollywood, California
www.CinePaint.org   Open source digital motion picture film software

[Ongui-dev] platforms

[Mike D. <mi...@cs...>]

Heya,

So I started poking through the GTK-OSX project code. Do you see any future
integration between that project and OnGui?

Regarding how to accomplish our cross-platform goals, I'm thinking that a thin
"compatibility layer" might be sufficient. That is, for any necessary drawing, we
can provide "macro" drawing functions (similar to what GTK-OSX has done). So OnGui
would have separate implementations of draw_pushbutton(), draw_bevelbutton(),
draw_scrollbar(), etc. for each platform.

Is this what you had in mind? Were you more looking for getting rid of GDK
altogether? How about a high-level API that wraps around GDK on Linux and Aqua on
Mac?

-m

[Ongui-dev] widget state and style

[Mike D. <mi...@cs...>]

Robin,

I've got a Button class working. The one remaining "to do" is to make it appear to
"click" when a user clicks on it (either through color changes, or shadow changes).
The thing I'd really like your advice on is widget state handling and style
(specifically color).

For state, I'm thinking of implementing something close to what GTK+ does:
1) enumerated states, normal/active/prelight/selected/insensitive
2) if a container's state is set, all children's states are set identically
3) after state is changed, either an OnStateChanged event, or an OnDraw event, or both
4) each state will have an assigned fg/bg color combo

(Note that #2 will require a base container class, which I've been putting off
doing; probably with a foreach() method. Incidentally, how do you feel about using
STL for internal data structures? std::list, etc.? I know some people who are
extreeemely against using the STL in portable code; but my experience has been that
compilers/linkers are finally catching up to the STL, especially basic data
structures, on most platforms.)

As far as widget style goes, I'm kind of drifting. I know that whatever we build has
to be platform-dependent to match the style. However, I'm not familiar enough with
the GDK ports to other platforms (like Mac OS X) to know how to do this safely.

For now, I'm going to be stupid and hardcode some fg/bg values for each state. But
I'd really like to hear what you think.

-m

Re: [Ongui-dev] cvs import

[Mike D. <mi...@cs...>]

Doesn't appear that SF's web interface to CVS is getting updated with the imported
module. I've put in a support ticket. In the meantime, you can access the imported
code by 'co'ing modulename "ongui-test" from /cvsroot/ongui/.

-m

Mike Dalessio said:
> Hi,
>
> I've imported the alpha ongui code into sourceforge's CVS.
>
> Since the "attic" version, I've tried to implement a Button class. I'm having
> problems getting the button release event to come back with the right event window
> (the toplevel window's 'event window' gets the event instead of the button's 'event
> window'). I'm still investigating. Any idea why this might be happening?
>
> Please let me know if you get a chance to peruse the code, and any comments you
> have. Thanks.
>
> -m
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Ongui-developers mailing list
> Ong...@li...
> https://lists.sourceforge.net/lists/listinfo/ongui-developers
>

[Ongui-dev] cvs import

[Mike D. <mi...@cs...>]

Hi,

I've imported the alpha ongui code into sourceforge's CVS.

Since the "attic" version, I've tried to implement a Button class. I'm having
problems getting the button release event to come back with the right event window
(the toplevel window's 'event window' gets the event instead of the button's 'event
window'). I'm still investigating. Any idea why this might be happening?

Please let me know if you get a chance to peruse the code, and any comments you
have. Thanks.

-m

[Ongui-dev] ongui source

[Mike D. <mi...@cs...>]

Robin,

Just posted ongui-0.1.1.tar.gz to the developers' attic. You should be able to
./configure;make it. It requires you have glib 2.0 and gdk 2.0 installed. The test/
directory contains a test application.

Current version is very simple. There's a Window class, a Label class, and the
common base class Widget. I used the namespace OnGui to wrap everything. The only
event currently handled is GDK_EXPOSE.

Some obvious needs are: style (for colors) and containers and layout management.
Also, I think I remember you stating that you'd like each widget to have its own
event window. The current Label class uses its parent window; that's easily changed,
though.

Please critique anything and everything. Thanks!

-m

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

[Ongui-dev] Progress

[Mike D. <mi...@cs...>]

Hi Robin,

> It's *interesting* why you can't get text to display.

Well, interesting problem #1 was "really really small text". I was
calling pango_font_description_set_size(blah, 12) to try to get a
12-point font. I eventually solved this (experimentally) by using
size=12000.

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.

So, a case of the RTFMs. Sigh.

In any case, I'm back on track. I have dirty code which displays a
label in a window. Stuff which needs to get worked out in the
near-term, I think, in no particular order:
 * size management (request/allocation cycle)
 * event handling (which I haven't even started)
 * layout management

So, some questions for you:

1) Base widget class? All widgets will have to do size requisition and
   allocation, as well as some GDK resource management.
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?
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?

> 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.

Thanks,

-mike

Re: [Ongui-dev] Thoughts on programming idioms

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

Mike,

> Well, so far my problem has been "I can't get any text to display."
> Yesterday, I managed to get really really small text to display. If I
> can't get this to work in a few more hours, I'll post my code to the
> list. I sometimes have a hard time admitting defeat.

It is exploration, not battle. Please describe what you encounter as you go
along. Don't wait until after you finish the book to start telling the
story! It's *interesting* why you can't get text to display.

> It's interesting to me how different people think and approach reading
> code. I prefer to know "What can I do with it", which is usually what
> people walking up to an API will want to know.

Me, too. Except, I want to know both what it *can* do and what it *could*
do. If encapsulated nicely the data members tell that instantly. Then one
can study the methods looking for the right one. It is annoying to search
through a class looking for a method and discover later that the class
doesn't even contain the requisite data.

Not needing to know about the data is a theory promoted in a lot of books,
but is contrary to human cognition or even common sense. How do people learn
complex technology? Airplane pilots are taught how planes are built first so
they understand what the controls do when they fly them. Having a pilot fly
a plane by rote without understanding the mechanics is considered too
dangerous. An example closer to home, try explaining the procedures for
doing back-ups to someone who doesn't know about a disk drive.

> Especially if data
> members are private (they WILL be private, won't they?).

Yes, but not for no reason. If a higher level class has embedded in it
another encapsulated object whose data is already private then making it
private a second time tends to be redundant and verbose. And, at the lowest
level there is usually some raw data better off as unpretentious structs. A
C-struct that has been made into a class with a zillion getter and setter
methods is a nuisance.

Data should be private where it protects the integrity of the data.

> Actually, this was intentional. The C++ standard allows for "local"
> classes, which is what I was intending to do here. This class is only
> a one-off....

Let's not set out to prevent code from being reused! You never know.

The local classes trick was an idea that at one time seemed a clever way to
avoid name collisions, but we have namespaces now that are much simpler and
better because they were designed specifically for that issue. Another thing
with local classes, you can't count on all compilers supporting them
(especially for your example within a function instead of a class) and even
if they do compile the code can be sub-optimal. Local classes tend to stress
compilers. It's not worth it.

> Do you intend to pass commandline parameters to the OnGui
> infrastructure?

Yes, but only to pass it through to X11 as a legacy feature. I can't think
of anything OnGui would want to do with command-line options. There are a
couple ways to make the pass-through implicit so the user doesn't need to
see it. No need to worry about it at this time.

> I don't see this functionality in the gfx
> archive (however, I'm not familiar with some of the Windows idioms
> used there, so I may have missed it).

That's because only X11 does that sort of thing. It isn't common elsewhere.

> What's the advantage to having a member function MsgPump() for all top
> level containers? Not having a Windows-centric background, this is a
> little foreign to me.

I think it is like gtk_main() or XtAppMainLoop().

> Also, I really dislike the use of the name of MsgPump(). It's too
> hopelessly win32 to even bear. :) With your leave, I'd like to use
> run() or another alternative name instead.

Run() is fine by me, although not as descriptive.

> One last question, regarding your allusion to a resource file in your
> sample code. How much of the content do you see being managed by the
> resource file? Possibly all object attributes? Should all objects take
> an optional string name as a constructor parameter?

My enthusiasm for resource files is limited. There's one feature they
enable, but no GUI toolkit offers, that I want rather badly. I want to have
a developer mode I can activate to do on-the-fly GUI-building inside a live
app. In other words, it would be sort of like having Glade built into every
OnGui app. I want to be able to prototype GUI design right inside any app,
and not go through a compile cycle until I add functionality.

> Again, thanks for your time and patience.

You're welcome. And, thanks for your interest. You are supposed to ask
questions!

Cheers,

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

Re: [Ongui-dev] Thoughts on programming idioms

[Mike D. <mi...@cs...>]

Hi Robin.

> Please send documentation to the list of what problems you encounter and how
> you overcome them.

Well, so far my problem has been "I can't get any text to display."
Yesterday, I managed to get really really small text to display. If I
can't get this to work in a few more hours, I'll post my code to the
list. I sometimes have a hard time admitting defeat.

> Let's not do the m_ notation, or any other naming method Hungarianisms.

No problem. This is an affectation left over from my day job.

> If you don't mind, data members in class definitions before methods. I want
> to know what something is before I bother figuring out what it does.

It's interesting to me how different people think and approach reading
code. I prefer to know "What can I do with it", which is usually what
people walking up to an API will want to know. Especially if data
members are private (they WILL be private, won't they?). In that
sense, I was targetting our potential customers. If you prefer data
members listed first, though, I won't complain.

> Regarding method names, can you make those upper and lower rather than lower
> and upper? Your style is a bit too Java-ish for us old C++ dogs.

Heh. I don't even know Java. I'll take your word for it. :)

> > int main (int a_argc, char* a_argv[])
> > {
> > class Button1 : public OnGui::Button
>
> The definition of class Button1 had better be before main!

Actually, this was intentional. The C++ standard allows for "local"
classes, which is what I was intending to do here. This class is only
a one-off that we're only using locally for button-label binding. In
that sense, a local class is appropriate since that better represents
the true scope than a globally defined class.

However, your description of avoiding refcounting makes this a moot
point, since you prefer to shluff this sort of management (object
binding) off onto the container class (which owns both the button and
the label), which makes much more sense to me.

> > OnGui::init (a_argc, a_argv);
> > OnGui::run() ;
>
> What's this? We already have an implicit initialization and run methods.
> Don't  need these C-ish GTK-like calls.

Do you intend to pass commandline parameters to the OnGui
infrastructure? If so, how? I don't see this functionality in the gfx
archive (however, I'm not familiar with some of the Windows idioms
used there, so I may have missed it).

What's the advantage to having a member function MsgPump() for all top
level containers? Not having a Windows-centric background, this is a
little foreign to me. Why not have a global method to do this work?
How will the process handle multiple windows in a single thread? Is
each window required to run in its own thread? I'm definitely missing
something in your "big picture" here.

Also, I really dislike the use of the name of MsgPump(). It's too
hopelessly win32 to even bear. :) With your leave, I'd like to use
run() or another alternative name instead.

> Reference counting is evil.

As I said before, I now understand your take on object ownership,
etc. No refcounting needed. Understood.

> I don't know what it is you imagine counting.

However, I think I described pretty well how GTK+ forces
application developers to manage closures, which require the use of
reference counting. I wasn't _imagining_ counting anything, I just
didn't yet understand how to design applications using OnGui. Now it's
clear how things should work.

One last question, regarding your allusion to a resource file in your
sample code. How much of the content do you see being managed by the
resource file? Possibly all object attributes? Should all objects take
an optional string name as a constructor parameter?

Again, thanks for your time and patience.

-mike

Re: [Ongui-dev] Thoughts on programming idioms

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

Mike,

Hi. Good to hear from you. I was wondering how it is going.

> Having a hell of a time getting Pango to work. Nearly there.

Please send documentation to the list of what problems you encounter and how
you overcome them.

> int main (int a_argc, char* a_argv[])
> OnGui::Label *m_label ;

Let's not do the m_ notation, or any other naming method Hungarianisms. If
we're writing OOP (we are, right?) then there should be no global variables.
That means *every* variable in a method would be a member variable unless it
was explicitly passed into the method as an automatic. Using m_ and a_
doesn't clarify anything and makes code unpleasant to read.

If you don't mind, data members in class definitions before methods. I want
to know what something is before I bother figuring out what it does. By the
way, if it becomes tedious to look past the data members to the methods
because of too many data members in the class that is an indication of
insufficient encapsulation (not enough classes). Classes shouldn't need to
have a long list of data members.

Regarding method names, can you make those upper and lower rather than lower
and upper? Your style is a bit too Java-ish for us old C++ dogs.

> int main (int a_argc, char* a_argv[])
> {
> class Button1 : public OnGui::Button

The definition of class Button1 had better be before main!

> OnGui::init (a_argc, a_argv);
> OnGui::run() ;

What's this? We already have an implicit initialization and run methods.
Don't  need these C-ish GTK-like calls.

> 2) Reference counting.

Reference counting is evil. It never quite works right and always makes code
complicated to read and debug. If we need reference counting then we're on
the wrong track. The result will not be the sort of lightweight toolkit
envisioned. The point of the OnGui approach is that when the user hits the
callback he is already inside the relevant C++ object and can't get lost. I
don't know what it is you imagine counting.

Here's your example more like I have in mind:

class HelloDialog
:     public OnDialog

// OnDialog is derived from OnWindow is derived from OnLayoutMgr.
{    OnButton hello_button;
public:
    HelloDialog("hello_dialog")
    :    hello_button("hello_button",this)
    // In its ctor the hello_button adds itself to the 'this' OnLayoutMgr
list.
    {    hello_button.SetPosition(10,10);
        // Or, position could also be set by resource file:
        // "hello_dialog.hello_button.position 10 10"
        // Each object needs a string name for this to work.
    }
    virtual void OnClick(Msg msg)
    {    hello_button.Toggle("Not clicked","Clicked!");
    }
    virtual void OnClose(Msg msg)
   {    QuitProgram();// posts a quit message
}  };

int main()
{    HelloDialog hello_dialog;
      hello_dialog.Show();
      return MsgPump();
}

Comments?

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

[Ongui-dev] Thoughts on programming idioms

[Mike D. <mi...@cs...>]

Hi Robin,

Having a hell of a time getting Pango to work. Nearly there.

In the meantime, lest you think I'm dawdling my time away, I have been doing some
thinking about the new paradigm that we'll be selling along with OnGui's model. That
is, lots of GUI developers have the "listener" model hardwired in their brains.
We're going to have to convince them that the OnGui way is worth unlearning this
model.

So, I've been trying to figure out (perhaps prematurely) how programmers will write
code in this model; what common idioms might be used; and what we can do to serve
those needs.

If you'll bear with me, let's take a simple GTK+ app (please ignore the fact that
there are no parent containers):

<code>
void onClick (GtkButton *button, GtkLabel *label)
{
	gtk_label_set_label (label, "Clicked!");
}

int main (int a_argc, char* a_argv[])
{
	gtk_init (a_argc, a_argv);

	GtkButton *button1 = gtk_button_new_with_label ("Hello, World!");
	GtkLabel *label1 = gtk_label_new ("Not clicked (yet).");

	gtk_signal_connect (GTK_OBJECT (button1), "clicked",
						onClick, label1);

	gtk_main() ;

	return 0 ;
}
</code>

This is a pretty tight 18 lines of code. In it, we've created two objects, bound an
event to a handler, and even made a quasi-closure, where _label1_ is passed as a
parameter to the handler. The drawbacks, of course, include no type-safety, lots of
potentially slow indirection, wonky signal connection syntax, and the fact that I
haven't correctly implemented the reference counting I'd need in a larger app.

Here's the same app in OnGui (or, at least the version of it existing in my head):
<code>
int main (int a_argc, char* a_argv[])
{
	class Button1 : public OnGui::Button
	{
	public:
		Button1() : OnGui::Button ("Hello, World!") , m_label (0) {} ;
		virtual void onClick () {m_label->setText ("Clicked!");} ;
		void setLabel (OnGui::Label &a_label) {m_label = &a_label ;} ;
	private:
		OnGui::Label *m_label ;
	} ;

	OnGui::init (a_argc, a_argv);

	Button1 button1 ;
	OnGui::Label label1 ("Not clicked (yet).");
	button1.setLabel (label1);

	OnGui::run() ;

	return 0 ;
}
</code>

This is 20+ lines, a little more than the GTK+ model. Again, we've created two
objects, defined a handler, and created a quasi-closure. The new class, _Button1_,
acts as its own functor (closure), storing state which will be used in the handler
later on. Binding of the handler to the event is inherited from _OnGui::Button_.

I'm pretty sure this is the form which OnGui code will tend to take: a local class
representing a specific object, with data members to bind parameters for use in a
handler method.

Two things come to mind, for me, after doing this gedankenexperiment.
1) A very common idiom, binding parameters to a callback (which is handled by the
GTK+ connection model) is not provided for. From what little I know of Java Swing
and Qt, their models don't provide for it, and that's certainly not stopping the
anybody from using either. I know you think this kind of machinery should be
avoided. However, if it will enable developers to do it in less lines of code, this
might be something we may want to think about addressing down the road.

2) Reference counting. If programmers are going to be storing pointers (or
references) to objects for use in binding callback parameters, we may discover
refcounting is a necessity. I know you want to avoid the use of an inherited common
object class, but how would you feel about this? I think we're certainly going to
need a common base class for the "Widget" concept anyway ("something that takes up
space on the screen"). Or as an alternative, we could make reference counting part
of a virtual base class that objects would inherit only when necessary. A form of
"autoptr" may be a good thing, too, to establish ownership of an object where
ownership might be ambiguous.

Thoughts? Comments?

-m


-- 
mike dalessio
mi...@cs...

Re: [Ongui-dev] event model

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

Mike,

> ...I started a new job among other things.

That's great! Congratulations!

> On a lighter note, I think I've now convinced myself that your
> "simple" event model will work even for advanced applications
> (initially I was hesitant, if you remember, and was considering
> pushing a listener event model). So: never mind. Consider me a
> convert.

Whoo hoo! Glad to hear that!

My issue with listener architectures is they expose users to too much
plumbing. The OnGui model as implemented in the gfx prototype is not as
restrictive as it seems at first glance. There are three mechanisms
implemented in the architecture to enable covering all event contingencies
efficiently:

1.) The ususal case where you want to catch the dozen or so typical GUI
events. Applies 98% of the time. In OnGui the generic event model just
magically is there, no plumbing. Simply call the virtual On handler for your
event. However, what if you need to catch an atypical event without a
specific On handler in the generic model?

2.) The case where you want an atypical event in addition to the typical
events. There is a catch-all On handler at the bottom of the generic event
system. You can trap it there easily. But, what if that is too inefficient?

3.) The case where the catch-all handler and generic event system invoke too
much overhead, that you only want to catch specific events, to tune the
event model for maximum performance. In that case you write your own master
event handler and call the method that installs that in place of the generic
master handler for that window. Gives full access to plumbing when you need
it.

> In any case, I know we briefly discussed what low-level library to
> use. If you have no objections, I'd like to initially use GDK, since
> this is already ported (or being ported) to the platforms you
> specified.

I think you are right. Proceed using GDK unless we discover a strong reason
not to.

Cheers,

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

[Ongui-dev] ongui

[Mike D. <mi...@cs...>]

Robin,

The last week and a half have been pretty busy, since I started a new
job among other things. I have not put in much active time on ongui,
but I expect to get back on it this week.

On a lighter note, I think I've now convinced myself that your
"simple" event model will work even for advanced applications
(initially I was hesitant, if you remember, and was considering
pushing a listener event model). So: never mind. Consider me a
convert.

In any case, I know we briefly discussed what low-level library to
use. If you have no objections, I'd like to initially use GDK, since
this is already ported (or being ported) to the platforms you
specified. If you decide (now or later) that this is a bad idea, we
can rip it out. However, starting from scratch would be difficult and
yield little results in the near future. Opinions/comments/concerns?

-mike

Re: [Ongui-dev] OnGui development launched

[Mike D. <mi...@cs...>]

Hi Robin,

Downloaded and unzipped. I'll spend some time this weekend browsing
through it and hopefully I'll have some questions for you early next
week. Should be fun!

-Mike


Robin Rowe said:
> Mike,
>
> Hi. I have created the developers mailing list and added us to it.
>
> Zipped up my old GFX API source as a development prototype and placed
> in our
> developers attic on SF site.
>
> http://sourceforge.net/project/showfiles.php?group_id=93808
>
> Please download that, browse through the code for ideas, and start
> asking
> questions on the list.
>
> Look at the Window and Dialog test code examples for starters. GFX was
> not
> cleaned up or documented for other users. Will want to talk through
> it.
>
>> Why OnGui? Just curious.
>
> Because the event handlers use "On" in the method names, sort of like
> MFC
> does. Other than that, OnGui isn't much like MFC. ;-) Coincidentally,
> ongui
> may mean claw or nail in some languages.
>
> Found that libgfx was already taken by another GUI library and wanted
> to
> come up with a name quickly. Considered your suggestions, but had
> problems
> with each of them. Of your proposed names EGO (Easy Graphic Objects)
> was the
> best and the worst. I could just imagine what some would say if I led
> a
> project named that!
>
> Thanks for prompting me to get this off the ground. Appreciate your
> help!
>
> Cheers,
>
> Robin
> ---------------------------------------------------------------------------
> Rob...@Mo...   Hollywood, California
> www.CinePaint.org   Free motion picture and still image editing
> software
>

[Ongui-dev] OnGui development launched

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

Mike,

Hi. I have created the developers mailing list and added us to it.

Zipped up my old GFX API source as a development prototype and placed in our
developers attic on SF site.

http://sourceforge.net/project/showfiles.php?group_id=93808

Please download that, browse through the code for ideas, and start asking
questions on the list.

Look at the Window and Dialog test code examples for starters. GFX was not
cleaned up or documented for other users. Will want to talk through it.

> Why OnGui? Just curious.

Because the event handlers use "On" in the method names, sort of like MFC
does. Other than that, OnGui isn't much like MFC. ;-) Coincidentally, ongui
may mean claw or nail in some languages.

Found that libgfx was already taken by another GUI library and wanted to
come up with a name quickly. Considered your suggestions, but had problems
with each of them. Of your proposed names EGO (Easy Graphic Objects) was the
best and the worst. I could just imagine what some would say if I led a
project named that!

Thanks for prompting me to get this off the ground. Appreciate your help!

Cheers,

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

----- Original Message ----- 
From: "Robin Rowe" <Rob...@Mo...>
Sent: Thursday, October 30, 2003 7:57 AM
Subject: Re: Cinepaint GFX API


> Mike,
>
> The Swing listener approach is too much like GTK for my taste, and too
much
> exposed plumbing. The GFX virtual callback system was inspired by MFC,
> another system with too much exposed plumbing. GFX is much cleaner than
MFC
> though. Oddly, the GTK2 folks were apparently influenced toward GObject by
> MFC, which makes every class derive from a base generic object type.
That's
> an approach avoided in GFX.
>
> I was mentioning Swing as a set of capabilities, not a design approach.
> Swing doesn't include the kitchen sink like GTK, but does offer a more
> complete widget set.
>
> Not having Windows is not a problem. I can keep up the Windows side. You
do
> Linux and Mac please. On Linux I would like you to implement on both X11
and
> DirectFB. On the Mac use Carbon, not Cocoa.
>
> Will roll up the GFX Win32 stuff I have implemented.
>
> Cheers,
>
> Robin
> --------------------------------------------------------------------------
-
> Rob...@Mo...   Hollywood, California
> www.CinePaint.org   Free motion picture and still image editing software
>