[interfacekit] Re: Interface Kit/app_server

what can be done is, make beapi just like normal. then make a native port of
GTK or whatever it is, but dont wrap it around anything - make it so it will
run natively.  honestly , be went a little too far with threading in the
beapi seems like.

----- Original Message -----
From: "Erik Jakowatz" <erik@xxxxxxxxxxxxxx>
To: "Mike Jarosch" <mjarosch@xxxxxxxxxxxx>
Sent: Wednesday, September 12, 2001 11:54 AM
Subject: [interfacekit] Re: Interface Kit/app_server


>
> Mike,
>
> > It is the Interface Kit and app_server that create the multi-threaded
aspect
> > of BeOS.  The kernel supports multiple threads, but doesn't require
them.
>
> You have a point here ...
>
> > I'm saying use the embeded version of GTK+ to build the app_server and
then
> > build the Interface Kit on top of the GTK+ api.
>
> ... but herein lies the problem.  Existing apps expect the Interface Kit
> to be multi-threaded, and restructuring either GTK+ to be multithreaded
> or the BeAPI to be single-threaded (but act multi-threaded) will be a
> *major* headache.
>
> > I can see your point as well.  Whatever you decide will be the best
option
> > for OpenBeOS and the community as a whole.
>
> I've proposed to the team that we look into creating our design such
> that various APIs can be either multi-threaded or single-threaded, which
> would make it much easier to bolt on GTK+/Qt as nearly native APIs;
> i.e., they wouldn't sit on top of the Interface Kit and vice versa.
> Hard to say how difficult that will be at this point, though.
>
> > I am mainly a c programmer, with some c++ experience.  Anything I can do
to
> > contribute just let me know.
> >
> > Have to run,
> > Mike
> >
> > ----- Original Message -----
> > From: "Erik Jakowatz" <erik@xxxxxxxxxxxxxx>
> > To: <mjarosch@xxxxxxxxxxxx>
> > Sent: Tuesday, September 11, 2001 4:16 AM
> > Subject: Re: Interface Kit/app_server
> >
> > > Hey, Mike!
> > >
> > > I've heard some similar ideas with regards to porting Qt, and while
both
> > > ideas have a great deal of merit (for the very reasons you list), the
> > > devil is in the details, as they say. ;)  It's my fear that the
combined
> > > effort necessary to hammer either API into working shape with regards
to
> > > BeOS's multithreading model and write a BeAPI compatibility layer
would
> > > equal or (more likely) exceed that of a "from scratch" implementation.
> > > There is a team of people who have been laboring for well over a year
to
> > > port GTK+ to BeOS -- with some success, I might add -- but even their
> > > efforts fall short of accomplishing what you suggest here.  Given the
> > > need to move as quickly as possible in order to bolster the developer
> > > and user communities' confidence, I would really hate to go down that
> > > path only to discover that it a) isn't going to work, b) requires
> > > immense amounts of work or c) is a non-optimal solution for some other
> > > reason.  The main issue, as I see it, is that GTK+ is designed for an
> > > environment where the windowing system is synchronous within a given
> > > application, and adapting this to the BeOS "every window has its own
> > > thread" model will, in all likelihood, be very difficult.
> > >
> > > None of this is to say, however, that I'm completely closed to the
idea.
> > >  If you, or someone else, can flesh out how to work around those
> > > devilish details in a reasonable way, I'd be very interested, as I'm
> > > sure the rest of the team would be.  We'll take whatever real
shortcuts
> > > we can! ;)  Even if it turns out to not be feasible, I'm interested in
> > > the possibility of trying to structure the app_server in such a way
that
> > > APIs designed for synchronous, single-thread environments (such as
GTK+
> > > and Qt) could be easily supported, thereby making it much easier to
port
> > > the APIs in the first place.  Then we could have our cake and eat it,
> > > too! =)
> > >
> > > Having said all that, the team can still use help; are you interested?
> > > What sort of skill set do you have?
> > >
> > > Thanks!
> > >
> > > e
> > >
> > > >Hello,
> > > >
> > > >I had an idea about the reimplementation of the Interface Kit , but I
> > > don't know if it is possible, so I thought I would send it you and see
> > > what you thought, since you are the lead of the Interface Kit.
> > > >
> > > >My idea is to implement the app_server using GTK+/DirectFB.  Expose
> > > GTK+ as an available API, then build the Interface/App Kit on top of
> > > this library.  This gives the following advantages:
> > > >    1) A large portion of the work is already done
> > > >    2) Developer now have the option of 2 languages to build
> > > applications and bringing other languages to BeOS becomes easier
because
> > > they can interface the c library instead of the c++ library wrapped in
a
> > > c library.
> > > >    3) A large collection of GTK+ apps become easier to port.
> > > >    4) You have a large body of developers/support/testers already in
> > > place working on GTK+ for Gnome.
> > > >
> > > >I know that this is a broad description and there are lots of details
> > > missing, but I think this is a viable option.
> > > >
> > > >Let me know what you think,
> > > >Mike
> > >
> > > Data is not information, and information is not knowledge: knowledge
is
> > > not understanding, and understanding is not wisdom.
> > > - Philip Adams
> > >
>

Other related posts: