[interfacekit] Re: Interface Kit/app_server

In retrospect, the "thread-per-window" policy seems like it may have
been overkill.  Still, that's what apps are written to, so that'll be
our primary implementation target.  What I'd like to look at doing is
creating a separate interface to app_server which supports multiple
windows within a single thread.  I have no idea how difficult this will
be, but I think this will be the way to go.  I don't like the idea of
other APIs just writing to the frame buffer all willy-nilly.  Besides,
if this was a reasonably do-able proposition, I think this is the way
the existing GTK+ and Qt ports would be doing it already.  app_server is
the gatekeeper to the GUI; we just need to make it more friendly for
synchronous APIs.  Or at least not hostile.

e

Yuri Titov wrote:
> 
> 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: