Re: [directfb-dev] [directfb-users] Problems in GdkWindow Events with Gtk - DirectFb backend

["Mike Emmel" <mike emmel gmail com>]

On Dec 6, 2007 12:19 PM, Christopher Johnson <cjohnson cswl com> wrote:
> Mike, even your flames are welcome.  I know Mike personally and have
> worked with him in the past, and have nothing but the highest respect.
> So here's my semi-flame in return.
>
> I've been working with GTK+ and DirectFB for only a few months now, and
> I only have the limited and poorly maintained information on the web
> from which to draw my conclusions.  I ask you to interpret this
> statement from the Wiki:
>
> "This wiki page is an howto about building GTK+
> <http://www.gtk.org> (/http://www.gtk.org/) libraries with
> DirectFrameBuffer backend enabled, which permits running a generic GTK+
> application directly on top of DFB instead of X11. The DFB backend is
> meant for embedded use so hasn't all the features the X11 backend has
> but it's complete and stable enough to run even complex applications
> like the GIMP."
>
> I don't see anything here at all like your statement (although I believe
> your statements).  In fact, just the opposite.  I'm led to believe that
> programs, even complicated ones like gimp, can be moved from GTK/X to
> GTK/DFB.  Of course, it all depends on the meaning of "generic" and
> "permits".  Even though I'm porting some VERY complicated GTK/X programs
> to dfb, many of the most generic examples are not "permitted" to run
> (and actually work).
>

I'm not talking so much about moving programs over.
It more akin to the java world problem of MIDP vs J2SE.
In the embedded world you need a very modular system.
This includes the toolkit and the applications.
Large toolkits with rich api's and large apps end written on them end up
tightly intertwined.  A more realistic example would be to bring some
of the rich editing capability
in gimp to a embedded device that has a camera.

Open source does not help in this situation a whole lot. Its a design failure.
Also on the side of the gimp developers why should they refactor
their cool app so
bits and pieces can be reused ? For the entire development community a SDK that
works from the embedded devices up would be useful. But opensource by
itself cannot
get this sort of initiative to work. This holds for pretty much any
large complex code base.
In my opinion its why COM/CORBA/XPCOM etc are failures. Without
modular code component
frameworks fail since component frameworks fail no one writes modular code.
Certainly we have exceptions the Linux kernel is a example of a code base thats
moved to be fairly nicely modularized over time. But its a exception
not the rule.
GCC is trundling slowly down this path also.


> What is there out there to warn me that this windowing system doesn't
> fit the assumptions made by gdk?  Thus far, I've seen none, other than
> your response.  Worst of all is when management-types see the
> misinformation out there and come up with project schedules allowing for
> a "few days" to "migrate" a GTK program to DirectFB...
>
Its more of a internal issue. I had to do some horrid hacks to get
everything to work.
Gdk closely replicates the X11 api and for X11 at least its a fairly
thin wrapper around xlib.
To write applications you don't need this rich api.
My current work has a gdk like layer that replaces X11,glib,gdk,pango
etc and it runs about 200k
and is capable of running WebKit and supporting a rootless X11 server.
I'm not saying its in anyway equal to the rich frameworks but I am
saying that a basic framework
to run apps is certianly less than 1 meg.  We don't have this sort of
simple base to build on.
Everything on top of this could be a module.


> With all due respect, Mike - I think virtually all of the first-time
> gtk/x to gtk/dfb porters out there are going to think the same thing I
> did.  Perhaps your comment should be added at the front of the wiki in
> flaming orange.
>
I don't know about that :)

I guess I just got fed up with the way things work.
And just to explain a bit I worked for SavaJE and ported Swing to run
on a mobile phone.
That experience helped me realize that the way we build a lot of our
software now has caused us
to get stuck in a rut of ever bloating frameworks and apps.
GTK offered nothing new nor does QT etc etc.

I just reached the point that I was done with this style of
programming its endless cycle
and leads nowhere. Most of our apps today are not much better than the
ones from the 1980's.

Sure they are prettier and hardware improvements have allowed
expansion but we are not really going anywhere with human computer
interaction its the same model that Xerox used. We have failed to get
intrinsically better.
I'm not saying I have the answer but I do feel that until we move to
modular software we don't have a chance
to get better.  The answer is in my opinion requires  the ability to
really be able to synthesis software from modular components.
Declarative programming is also part of the solution. The key is that
a programmers intent needs to be preserved in the software. Maybe you
could call it Desire programming which is a step above Declarative.
We have failed to reach the point that a programmer can communicate
his desire to computer much less a user.


To use a chemistry example we are still basically putting together
molecules one element at a time. This approach will never grow to do
complex protein synthesis. So even though I may not know for sure what
the right
way is I'm pretty danged sure the current approach is a dead end.



> All that being said, as always Mike - your contributions are gratefully
> accepted and appreciated
>
>
>
> Mike Emmel wrote:
>
> >Semi Flame coming :)
> >
> >Gtk is not a cross platform widget library. Its been ported to some extent.
> >The use of native windows for widgets for example is a design flaw.
> >It also exposes a lot of concepts that make assumptions about the
> >underlying system the ability to embed
> >a widget from one process into another and keep above for example.
> >
> >DirectFB gets around these types of problems by having the concept of
> >capabilities that can be queried
> >at runtime and you can then consider fallbacks.
> >
> >Other widget libraries like WX widgets and even QT are more cross
> >platform friendly in design.
> >
> >Now in working on GTK/DirectFB I realized that DirectFB itself was not
> >as flexible as I believe it should be.
> >DirectFB should  be a base for any sort of multi application graphical
> >design including
> >one similar to X11.  Recent releases and concepts Denis is working on
> >are making DirectFB more flexible every day.  Eventually we should
> >have a windowing environment that fits the assumptions made by Gdk and
> >other approaches that I'm personally more interested in.
> >
> >Back on the Gtk side I think its time to consider a Gtk 3 series that
> >is designed around a small core that can
> >be implemented on top of a minimal rootless windowing environment with
> >the code repackaged as plugins.
> >I doubt that this will happen instead Gtk seems to be suffering the
> >same complexity creep that all the other application frameworks suffer
> >from.
> >
> >At the end of the day these large frameworks lose most of the benefits
> >provided by open source and your reduced to the ability to at best fix
> >a few superficial bugs.
> >
> >So I'm sorry if Gtk/DirectFB does net meet your needs but I'm done
> >with massive inflexible frameworks I believe that are not the right
> >way to build things if you really believe in open source. They have
> >brought in a horrible design concept from the closed source world.
> >
> >Flame off :)
> >
> >On Dec 5, 2007 7:37 AM, Denis Oliver Kropp <dok directfb org> wrote:
> >
> >
> >>Christopher Johnson wrote:
> >>
> >>
> >>>Unless I am grossly mistaken, any other behavior will create a serious
> >>>incompatibility between GTK+ backends.  I am currently struggling with
> >>>code that isn't getting events it expects (DirectFB 1.0.0 and GTK+
> >>>2.10.13).  Sounds like maybe Mike's explanation might cover my problems
> >>>and incompatibilities with GTK/X.
> >>>
> >>>
> >>If you're not interested in raw X11 events, but only GdkEvents, your code
> >>should work with GDKDirectFB, otherwise it's a bug and needs to be fixed.
> >>
> >>
> >>--
> >>Best regards,
> >>  Denis Oliver Kropp
> >>
> >>.------------------------------------------.
> >>| DirectFB - Hardware accelerated graphics |
> >>| http://www.directfb.org/                 |
> >>"------------------------------------------"
> >>
> >>
> >>
> >
> >
> >
>