[haiku-development] Re: GSoC 2021 Introduction

  • From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 31 Mar 2021 15:29:26 +0000

31 mars 2021 17:13 "Khaled Emara" <mail@xxxxxxxxxxxxxxx> a écrit:

First of all, I apologize for creating a new thread. I had discovered
that I enabled digest mode, so I disabled it; which resulted in me not
receiving your replies. I actually had to read it through the archive.
I tried to restructure the email so that it would go through as a
reply; but since I don't know the In-Reply-To field, I'm not sure how
it will appear.

It did get delivered to the list, I think that's what matters.

Threading is convenient for archiving, but this list is sufficiently
low-traffic so this is not too much of a problem.

Probably not the complete thing, but maybe some parts of the work could
be doable? The tun and tap interface support for example

Yeah, I think this is doable and a good start. And as you remarked, it
would also be a good start for better networking support in QEMU.
Looks interesting to me. I will start working on a proposal.

And if it goes well, it may be possible to follow up with a paid contract 
funded by Haiku inc
outside of GSoC (we can't make guarantees about it at this point, but we 
have the funding and it
would not be the first time we hire a former GSoC student to allow them to 
continue their work).

If I may inquire; are you talking about the WireGuard implementation
or QEMU networking?

I am not a member of Haiku, inc so I can't speak for them, and I am only
a single member of the Haiku project, so I can't speak for everyone there
either, to decide what's appropriate as a paid contract and what isn't.

But personally, I can see both of these being useful.


Complex text rendering would be useful (but maybe not sufficient?)

to render arabic text and various other scripts, which would probably
allow more people to use Haiku as their main system. I think it has
potential to increase our reach to new markets (even if I'm not much
into marketing things) and allow more people to use and contribute to
Haiku.

From your remarks, it appears this has the priority. I think it's
sufficient, so long as you don't mix left-to-right and right-to-left
scripts. For this, maybe we can port and use Gnu's fribidi?

Fribidi is under the LGPL license, I think we would rather use ICU ubidi.h:
https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/ubidi_8h.html
(mainly because we already use ICU for other aspects of locale management)

But besides that, I think there are wider problems to consider: changes
to our public API so applications can get the info they need about the
text, possibly changes to our window layout system to put widgets at the
right place. I am not familiar with how this is usually handled on other
systems (assuming they do things in a way that is appropriate for users
of right to left languages).

There are also other loosely related topics, for example rewriting BTextView
to use ICU for linebreak detection. Right now it uses a custom algorithm that
does not work perfectly even for non-english, latin-alphabet languages.

-- 
Adrien.


Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 03-2021