[haiku-development] Re: R1/a4 initial planning
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 24 Feb 2012 17:40:06 +0100
Niels Sascha Reedijk wrote:
> On Fri, Feb 24, 2012 at 3:55 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > Jürgen Wall wrote:
> >> Just to throw in an idea, wouldn't it make sense to have someone analyze
> >> the requirements and efforts of such an API transition in a CSoC task?
> >> This task would enclose analysis of the Haiku API and the QT API
> >> delivering a rough plan how to map/adapt/replace parts.
> >> It'd be kind of an applicability research task.
> >
> > AFAIK such a task wouldn't be allowed as a GSoC project. While a project
> > may include complementary tasks like requirements analysis, documentation,
> > testing, etc. the main task is supposed to be coding. A practical approach
> > would be fine, though, like:
> >
> > * Complete the Qt port (disclaimer: I don't have any idea what's the
> > current state).
> > * Add extensions to/on top of the Qt API to provide Haiku specific
> > functionality for attributes, resources, inter-app communication,
> > translators, etc.
> > * As a proof of concept, port StyledEdit to the extended Qt API.
>
> Wouldn't it make the whole project more compelling it step 2 would be
> to write a Haiku backend for Qt that uses the libbe <-> app_server API
> to interact with the app_server? So a deeper integration as it were...
While that would be a useful optimization, in the short term I'd be much more
interested in the feasibility aspect. Like how well the Haiku specific
extensions can be made, how much work porting a Haiku application to the Qt API
is and how well the result works, etc. I think it will already be plenty of
work to get results in that respect.
CU, Ingo
Other related posts:
