Posted
over 2 years
ago
Since it is not so easy to organize in-person events currently, this year
coding sprint will be online.
In order to accomodate everyone, it will last for two weeks, and you are free
to join (or leave) at any time.
The event is open to everyone who
... [More]
wants to work on Haiku or any related software
project: write new applications, port existing applications, update already
ported applications, no matter if it’s your own or someone else’s. And of course
it’s also possible to dig deeper into Haiku internals and fix some bugs there.
The event overlaps with Hacktoberfest, so you can also take part into that if
you want to.
Event Dates: 2021-10-18 - 2021-10-31
[Less]
|
Posted
over 2 years
ago
by
leavengood
Haiku, Inc. is proud to announce that we have hired existing contributor waddlesplash to work on general Haiku improvement full-time. The contract was signed on Monday, August 23, 2021 and waddlesplash plans to start work tomorrow.
In the past Haiku
... [More]
, Inc. has hired contributors as contractors for specific projects, such as the package system or working on WebKit and our WebPositive browser, but this is the first time someone has been hired for a more open-ended position for general improvements. We expect waddlesplash can help on thorny issues which our volunteer contributors have had trouble fixing, he can help move reviews through in Gerrit, and hopefully he can take on some bigger projects which require more time investment, like accelerated GPU graphics support.
There will still be plenty of fun and interesting projects for our volunteer contributors, but we hope this will help keep the project moving forward even when volunteers are not as active.
With all that said, we need your support! If you believe in what Haiku is building, and you would like to see the Haiku R1 release sooner, please donate to help support paying for waddlesplash’s work! Haiku, Inc. currently has a runway to pay waddlesplash for about a year and a half, but we need to increase our yearly donation target from about $10,000 per year to $80,000 to make this sustainable long term. More donations also mean we could hire even more people to work on Haiku.
You can set up a one-time or recurring donation though PayPal, Liberapay, or Flattr. We also accept checks mailed directly to Haiku, Inc. Details about all these options can be found on the Haiku, Inc. donation page. We plan to increase the options for donations in the next few weeks, likely by adding GitHub Sponsors as another donation platform, and maybe some others.
Let us all welcome waddlesplash in his new role and see what great things can happen! [Less]
|
Posted
over 2 years
ago
by
pulkomandy
Hi there, let’s do another activity report! You may have noticed that there were a lot of news
since the previous one, but here’s a recap in case you missed it: a new beta release, the
celebration of the 20th birthday of the Haiku project, the end of
... [More]
Google Summer of Code (final
evaluations are being filled in as I write this), and also news from the promotion team which was
re-launched a few months ago and is working on various things (read their own report for more details).
What’s nice for me is that this was all already covered by various articles, which means I can focus
on what I know best, and take a look at what’s happening in the git repository with the code.
This report covers hrev55224-55342.
Buildsystem
jessicah modified some Jamfiles to enable rpath when linking host tools during the Haiku build.
rpath is a field in ELF executables that allows to store a library search path. With this enabled,
it is much easier to run the generated tools directly on the host system. Previously, using
“jam run command” would be needed to set up the correct environment, now you can just run “command”
directly.
Semion Dimov and Przemysław Buczkowski fixed various issues that prevented building Haiku on MacOS
and on “Apple Silicon” ARM64 machines.
User interface
madmax fixed the font overlay system, so that if there are missing characters in a font, a small
rectangle is drawn as a replacement. Not only this lets the user know that there should be some
text, but it also fixes some confusion in WebKit font rendering, where the code does not expect
characters to just completely disappear.
John Scipione fixed some rendering glitches in Tracker when using “mini” icons.
PulkoMandy fixed the scrollbar and status bar size in ShowImage (based on previous work by Nephele
to make them scale with the rest of the UI)
mmu_man and PulkoMandy fixed some problems with DPMS setting, that would either blink the screen
off and on at every workspace change, or just fail to turn on the screen at all on app_server start.
PulkoMandy and KapiX added support for underlined text in app_server (using the B_UNDRESCORE_FACE
font face flag). This allowed to merge an old patch from Sambuddha Basu which underlines the hyperlinks
in AboutSystem credits text. PulkoMandy also added the needed menu in StyledEdit to allow underlined
text there.
X512 fixed a missing overflow check in app_server which would result in memory corruption and crashes
if trying to allocate too large bitmaps.
PulkoMandy fixed the computation of window preferred sizes, where in some cases, the height and
width could be mixed up, resulting in a window that would always want to be perfectly square, as well
as some confusion between the minimum and maximum size in layout computations.
Code cleanups
Coldfirex fixed typos in some comments, as well as problems in use of the va_start and va_end macros
in various system components and applications. He also updated the list of PCI and USB device IDs
(used to show the devices with a readable name instead of just a numeric identifier) and reviewed
and fixed several issues from the latest scan of Haiku sources by PVS studio.
This also led to identifying that Haiku FTPD server was a very old fork of the one in FreeBSD, and
it has now been synchronized with the current FreeBSD implementation.
PulkoMandy fixed the handling of HTTP errors in the package kit when a download fails because of an
error on the server’s end. This could result in corrupt file being stored on disk, and then reused
in the next run to attempt to resume the download, resulting in quite confusing behavior.
AlwaysLivid removed unused copies of libunwind and libcxxrt that were present in Haiku git repository,
replaced plain BAlert used as about boxes with proper BAboutBoxes in various servers and applications,
and clarified copyright and licensing on some files in the process.
Some documentation updates from Leorize’s work during GSoC 2020 were merged, documenting various
parts of the HTTP client API in Haiku.
PulkoMandy fixed an off-by-one error in the code checking the validity of kernel and user space
address ranges in the syscall interface. The code would require that one byte after the end of
the range must also be valid memory. He also fixed problems in the implementation of XSI semaphores
that were found while running a system call fuzzer by thosewhowork.
Localization
madmax fixed the BCountry class to return the country name (without language or other indications)
as expected.
PulkoMandy added a GetPreferredLanguage method to BCountry, which can be used to attempt to guess
the language to use based on rough user localization. He also fixed a problem in the localization
of DeskCalc, where the translation of button labels would prevent the buttons from working.
mt added localization to the Shelf and Nebula screensavers, and improved the one in CharacterMap.
Installation process
AlwaysLivid improved some text in FirstBootPrompt when build without the Haiku branding.
Jessicah made sure that Installer works when using a fresh (never booted) disk image as an
installation source, as it would result in some missing directories in the installed system.
Kernel and Drivers
David Sebek debugged and finalized the implementation of fstrim, the tool used to free unused sectors
on SSDs and improve performances. The tool previously was available only for RAM disks and SD cards,
now it also works on SATA and NVMe disks.
korli imported some network driver patches from FreeBSD 13.
Lt-Henry rewrote parts of the USB/Bluetooth/I2C HID parser to use C++ containers instead of manually
managing memory with malloc and realloc. This opens the way to improving the parser to handle some
missing cases, and in particular fix support for keyboards with N-key rollover, which are currently
not compatible with Haiku.
Ports to non-x86 architectures
The patches for the RISC-V port submitted by X512 are being merged, thanks to kallisti5 who reviewed
them and made some coding style cleanups before the patches could be accepted. This is a large patch
set, so the code review is still ongoing and some changes need more discussion than others. The
changes not only add RISC-V support, but also improve the portability of the OS in general, add
new drivers or update existing ones to work in different contexts, etc.
tqh also started submitting his ongoing work to get an ARM64 version of Haiku up and running.
HaikuDepot
Andrew Lindesay continues to improve HaikuDepot, this month with live updates of the package
state during installation, switch to a new API to communicate with the HaikuDepot web server,
and improved the shutdown process of the application.
Applications
HaikuWebKit received a major update, fixing many bugs and bringing it more in line with modern web
standards. There are still a lot of problems to solve, however.
Zotyamester added an eject button to eject CDs and DVDs from MediaPlayer.
PulkoMandy improved the size computation of People window, making sure there is no scrollbar and
the whole list of attributes is visible, unless it can’t fit on screen.
Jessicah made the 16 base colors in Terminal customizable, so that light and dark color schemes
can automatically configure them as appropriate to have readable text in all cases. [Less]
|
Posted
over 2 years
ago
by
ritz
Hey everyone! Since the GSoC period is nearing its end therefore here’s the final report on my GSoC project Coding Style Checker Bot.
Project Description:
Haiku has its own coding guidelines which describe how the code should be formatted. There is a
... [More]
tool (haiku-format tool) for reformatting or checking if code follows these guidelines, but it has to be compiled on the developer machine and then run manually. My project was to create a Coding Style Checker bot that runs haiku-review tool on files submitted as a patchset in our code review system and posts the report in the patchset comments.
Work done:
Added tools to the general-worker
PR: https://github.com/haiku/infrastructure/pull/69
I have added the following to general-worker inside infrastructure repo
jq
clang-format
git-clang-format
So now we can use these tools in the general-worker based images in the pipeline.
Adding source code for gerrit-resource
PR: https://github.com/haiku/infrastructure/pull/71
My Fork: https://github.com/HrithikKumar49/concourse-resources
My Docker Image: https://hub.docker.com/r/bluedocks/gerrit-resource
Using this repo, we can build and push gerrit-resource docker image which can be used as a resource in any concourse pipeline. It helps in triggering the pipeline every time a patchset is created. Currently, it needs to be built and pushed to the official haiku docker repository. The repo itself needs to be added in the haiku GitHub organisation as well. Although, anyone can try out the docker image on my account if needed.
Adding Gerrit Checker bot pipeline
PR: https://github.com/haiku/infrastructure/pull/70
This PR is to add the pipeline which can trigger and post the results of haiku-format tool run on the changed files in the patchset. End to end, it is working fine in my local development environment.
Future:
Since the haiku-format tool isn’t reliable yet, the bot can’t be deployed yet. I will be looking forward to the day it will be deployed and used by developers, making their lives easy. As I am amidst my degree and will be taking courses like Operating Systems, DBMS etc. in the near future, so I will try to use my then gained knowledge in contributing to this project in my spare time.
I also hope that with this GSoC project it will open up more opportunities to create patchset triggered pipelines for Gerrit and to add various features to the bot/create new bots.
Some of the ideas that community and I came up with, which can be implemented to the Gerrit Checker bot in the future (when haiku-review tool would be trustable and bot would finally be deployed):
Add a link to the results in the patchset comments
Add a button/command that would run haiku-format tool on the files that were reported as unformatted by the bot
Command that invokes bot and runs haiku-format tool to the said files in the command and shows the result in the patchset comments. Further, it can provide an option to create a new patchset with the said formatted files.
We can even leverage gerrit-resource to create a bot which will check build status of the patchsets and report it back. This could replace the existing madmax’s bot.
If you guys have other ideas, you can post it in the comments, so it can all be in one place.
Final words:
I had a great time working on this project. Thanks to this project I have learned and worked on various technologies and languages like Concourse CI, Golang, Docker, Shell script, YAML, REST API etc.
Finally, I would like to thank this amazing community and my mentors Alexander von Gluck and Suhel Mehta for helping me in this project.
Have a great day!
Introductory blog
Progress 1
Progress 2
Progress 3 [Less]
|
Posted
over 2 years
ago
by
jadedctrl
GSoC’s coming to an end, so it’s time for a final update: An overview of
what I’ve been working on this summer.
Project
My project was to “modernize” and write a libpurple add-on for
Caya, a multi-protocol chat program.
Ultimately, I hard-forked Caya
... [More]
into
Chat-O-Matic at the request of a
previous maintainer― with the name being suggested by win8linux. :-)
“Modernization” here means three things: Allowing multiple accounts in use
at once, re-orienting the program to support multi-user chats, and giving
add-ons some more flexibility.
Work done
To start off, here’s a before-and-after picture. (Aren’t I lucky this is the
sorta project where progress can be shown through screenshots?)
… and an obligatory note: You can find sources and all commits on
GitHub. Everything
between c6c1bb3
and
6e67401
are commits pertaining to this project.
I’ll sum up some of the bigger points I’ve addressed over the summer.
General
“Multiples” were made of a few things― multi-account support, multi-user chats,
and multiple protocols per-addon.
With a new focus on rooms, rather than one-on-one chats, the door to a few
more features was opened: chat commands, moderation, subjects, room
logging, and better notifications.
Management and loading of accounts was also overhauled to be a little more
friendly, in that they can now be disabled and re-enabled at a whim, rather
than requiring a restart― and they spam with more status notifications, which
is always reassuring to see.
UI
The UI has been changed a good bit, mainly to accommodate the new focus on
multi-user rooms― most obviously join/create/invite dialogues were added,
the room-list became the focus rather than the contacts list, and a user-list
is added to each chat.
Several parts of the GUI have been readjusted for multi-account support, like
an accounts drop-down menu in particular dialogues or account-selection in the
status area (bottom-left corner).
The design’s also been changed to take after
Vision. The UI is single-window,
an Accounts menu takes place of the Server menu… you can probably see the
resemblance.
Other general changes include moderation items, nick/subject changes through
the GUI, and receiving of formatted messages (foreground color or font-face).
Add-ons
General changes impacted the add-on
messages API―
several new messages have been added, and others had to be changed to
distinguish between chats and users or for semantic reasons.
The GUI templating system was generalized, expanding how settings dialogues were
populated into some other areas. Add-ons can also specify custom pop-up menu
items, commands, etc.
But the dust has settled, and at this point, the API is stable: I won’t be
making any compatibility-breaking changes in the foreseeable future (only
additive ones), and have started
better documenting it.
libpurple
libpurple is a chat library used by Pidgin, another
multi-protocol chat client.
Writing a libpurple add-on was one of my main goals for GSoC, and there is now
a full-featured libpurple add-on included with the program. Most things you’d
expect are supported― chat commands, room invitations, contact management,
etc. Common Notify and Request UI ops (GUI notifications/dialogues) are
supported, as well.
libpurple protocols can be used just like any other, and look the same from
the user’s perspective.
IRC
During the last couple weeks, I spent some time writing a native IRC add-on.
It supports all of Chat-O-Matic’s features, including auto-join, contacts,
and text color/face-formatting.
Funnily enough, this means there are now two protocols that can be used
either through libpurple or through native add-ons― XMPP and IRC plugins are
included with libpurple, and XMPP and IRC add-ons are included with
Chat-O-Matic. Take your pick!
I’d recommend sticking with the native add-ons, as they can take advantage of
some of Chat-O-Matic’s features better than libpurple, but if you’re not having
luck with one, you could always give the other a try. No harm done. :P
Undone work
A couple things I planned on doing in my proposal and introduction didn’t come
to pass, mainly in relation to libpurple plugins. Originally, I planned on
removing the native XMPP add-on in favor of libpurple’s built-in― but my
perspective here has changed.
When I first set out on this project, I saw libpurple as a main driver for
protocol support, but I’m realizing that might not be a good role for it.
libpurple plugins just can’t have the integration of native add-ons, nor can
they be used on x86 systems (at least for now)― and in some cases they are
inadequate (one example being
purple-matrix).
My new perspective on the relation between libpurple and native add-ons is this:
libpurple is good to use for particularly difficult or niche protocols (like
purple-discord), but native
add-ons might generally be preferred. libpurple is a back-up and a convenience,
not a basket to put every egg into.
That’s my take on it, at least.
Future work
There’s still work to be done on Chat-O-Matic, like file-transfers,
replacing the BTextView-based chat buffer with a more modern view, libpurple
support for ChatBuddies and more UI ops, etc.
Personally, my next priority is going to be a Matrix add-on, which was one of my
primary motivators for this project in the first place. … Though I might take a
bit of a break before getting started. :P
Trying Chat-O-Matic
Having dogfooded Chat-O-Matic as my only IRC/XMPP/Discord client for the past
couple weeks I think it’s fair to say it’s in a usable state. It should be safe
to try, and I sure hope it won’t bite. If you’d like to have a go, you can build
it from source.
As far as packages go, I’m hoping to have a recipe committed to HaikuPorts soon
(where it’ll be available as chat_o_matic), but for now you could use the
x86_64 HPKG built for the
v0.0.1 release.
See the README for prerequisites.
Final note
I’ve had fun the past couple of months, and I’ve learned a lot I’d like to
apply elsewhere. I had trouble using add-ons with another project before
GSoC, for instance… and after working with them so much recently, I don’t
think it’ll give me as much trouble. :P
I’ve worked with a couple really nice codebases this summer― mainly Caya’s―
and it’s been a good time. Thanks for all the feedback and friendliness,
especially from my mentors!
Sorry for the block of text, though, it’s a little much. I guess it didn’t end
up being so “quick.”
Cheers!
Introduction
Update 1
Update 2
[Less]
|
Posted
over 2 years
ago
by
saloni
GSoC 2021 Improvements to Haiku-format Final update
It has rightly been said - “All good things come to an end”. Google Summer of Code too was one of the good experiences I’ve had, in the sense that I didn’t know anything about the Open Source world.
... [More]
It provided the exact platform that I needed to kickstart my open source contributions.
About my project:
Haiku has its own coding standards which describe how the code should be formatted. Haiku-format is a tool that reformats code according to Haiku coding style but it is not giving desired results. So, we need to format the code such that when this code is run on Haiku the coding style of code gets updated according to haiku guidelines, but it has to be compiled on the developer machine and then run manually.
The tool ' haiku-format ' can be used to check the format according to guidelines which will be integrated with concourse to automate the process of checking coding style.
What we achieved?
I started with the input preferences directory and started solving the issues according to haiku guidelines. Following erros were solved:
Preserve the indentation of comments
Removal of braces for multiline control statements
Line break after return type in function definitions
Unusual indentation of BLayoutBuilder block
Extra space before ++ operator in for loop
Tabs are converted into spaces
Remove extra spacing for std::nothrow.
' : ' should come on its own line and initializers in following lines
Empty functions to inline
Along with the errors in input directory, same errors persist in other directories too. So they also got solved. With these major bugs got solved and the clang-format further doesn’t lead to break the code or build anymore.
But where’s the code?
S/N
What I did?
Merge Request or Code Link
1.
Removes extra space between new and (std::nothrow)
https://github.com/viveris/llvm-project/commit/e7062af694d377f000fecd5259a0cbf093abbdeb)
2.
' : ' should come on its own line and initializers in following lines
https://github.com/viveris/llvm-project/commit/df2208a9e66f87a1bd6f0bd68ed973ace901427b
3.
Empty functions to inline
https://github.com/viveris/llvm-project/commit/df2208a9e66f87a1bd6f0bd68ed973ace901427b
4.
Preserve indentation of comments
https://github.com/viveris/llvm-project/commit/f85ea5013b42a3dd2e983e1912d52c83e917e01b https://github.com/viveris/llvm-project/commit/51b07e72dea5ce2db8be569ab2f47c86b7ea0bf7
5.
Removal of braces for multiline control statements
https://github.com/viveris/llvm-project/commit/ea033bd4925eb9551d2d40625b490f82c98f5196
6.
Line break after return type in function definitions
https://github.com/viveris/llvm-project/commit/220a2bbe6bdf23c291cd3f5205cfdadf05622a9b
7.
Unusual whitespace for multiline for loop
https://github.com/viveris/llvm-project/commit/6fd97f0d9705d9597d09abdad3742d52de124ae2
8.
Unusual indentation of BLayoutBuilder block
https://github.com/saloniig/llvm-project/commit/c63b4b2d001406ca178bbdd02a5b3da8866f459d
9.
Tabs are converted into spaces
https://github.com/saloniig/llvm-project/commit/efb5ae15b5a19b23f54b717925a07592085f2911
10.
Input preferences: test reformatting with haiku-format
https://review.haiku-os.org/c/haiku/+/3826
11.
Updates code according to haiku guidelines with clang-format
https://review.haiku-os.org/c/haiku/+/4098
12.
Updates code according to haiku guidelines with haiku-format-10.x
https://review.haiku-os.org/c/haiku/+/4325
What’s next?
Time and again, I’ve written about my love for open source software and the freedom it brings. I’ve decided that I’ll continue contributing to open source in my spare time. I’ll keep contributing to these projects because the codebase is really interesting and that they’ve provided me the stepping stones into the open source world.
What we under-estimated?
I wrote in my proposal that to solve input directory errors which was supposed to be done before the first evaluation but I did the mistake of under-estimating how much time it takes to produce efficient result. This work takes a lot of time because it needs a complete understanding of how the llvm code works. But Pulkomandy and Preetpal explained me how the code works. As there was number of files, it was difficult to figure out which file should contain the solution of the problem
Next problem which I face was solving the unusual indentation of BLayoutBuilder block. As it was almost impossible for the clang-format to do this. Another one was tabs were converted into spaces.
The basic idea was :
indented 1 tab: qualifiers (volatile, virtual, static)
indented 3 tabs: type of fields and return type of functions
indented 2 tabs: function or field name
These take alot of time and patience. Even sometimes I messed up with github branches but Pulkomandy always patiently explained me and corrected my mistakes.
I have learnt so many new things in these months about haiku and git.
Work to do:
I have setup a base for us to work upon this but this needs testing on other directories that are pending. As much I have tested the major errors have been solved and there might be some minor errors which will not break code.
Final Note
All in all, this journey of GSoC has been one of the most beautiful ones when it comes to my career. It was a really wholesome experience with the whole community. I’d like to extend my gratitude to each and every person involved with me over this journey.
A special thanks to my mentors Preetpal Kaur and Adrien Destugues. They mentored me really well and was always ready to help. Thank you for being patient with me and clarifying my doubts.
Also, a big thanks to owenca and Suhel for helping and clarifying my doubts. Thank you Haiku members and Google supporting open source software for providing students like me with this opportunity.
Weekly Blogs:
https://hackace2.wordpress.com/category/gsoc/ [Less]
|
Posted
over 2 years
ago
by
animortis
Dedication asks each of its adherents to have faith even as time and energy pass through from one year to the next. Dedication brings with it a variety of challenges, but also rewards. Dedication is something most people claim to have, but few
... [More]
readily exhibit it in the face of adversity. As of today, Aug. 18, 2021, the Haiku Project is celebrating two decades of dedication, marking the 20th anniversary of the founding of the Haiku operating system and the start of this ride to save, maintain, and expand upon the BeOS legacy it spawned from.
Many things have changed since that Aug. 18, 2001 mailing list message bringing together the teams that would found what was originally called OpenBeOS. The first version released eight months later was even just called “app_server prototype 5.” In 2004, the name permanently changed to Haiku to avoid any conflict with the remaining trademarks on BeOS.
Since then, Haiku has seen four release candidate alpha releases and another three release candidate beta releases, with the latest coming out just a few weeks ago.
Haiku remains one of the few remaining non-Unix open-source operating systems available today. It has gone beyond just maintaining binary compatibility with old BeOS code to becoming a powerful, workable operating system of its own.
It wouldn’t be possible to get to where we are today without the generous contributions of those who have donated over the years, as well as the hard work and dedication the contributors, developers and volunteers have put into the Project over the last two decades.
So say a verse celebrating Haiku! And to the next 20 years!
We’d like to announce that Haiku merchandise will be available sometime in September, with special-edition 20th Anniversary merchandise available for purchase for a limited time when ordering goes online. More details will be announced on the website, so stay tuned.
Contributors are always welcome. For more information, visit https://www.haiku-os.org/community/getting-involved/.
For the curious, you can have a look through some of the important milestones in the Project’s history here.
We’ll end with a visual juxtaposition to show just how far we’ve come; on the left is a very early picture of the OpenBeOS shell, on the right is a more recent image of Haiku with a few apps running.
[Less]
|
Posted
over 2 years
ago
by
animortis
Few components of Haiku are as important to the operating system and its functionality as the preferred web browser and internal project: WebPositive.
In recent days, some users have expressed concern about a “disappearing text” bug, where some text
... [More]
on web pages will disappear for undetermined reasons. This issue is now fixed, but highlights the reason why WebPositive is so important.
The history of WebPositive is as intricately woven into Haiku as BeOS was, and has served as a major effort for all the programmers and users of the operating system even as other web browsers are successfully ported, work for a little while, then, unfortunately, lose functionality and are abandoned.
Developer PulkoMandy, whose real name is Adrien Destugues, lives in France and has been a key developer for Haiku and WebPositive since joining the team in 2009.
WebPositive, sometimes called “Web+,” uses the WebKit1 engine. This engine was originally ported from KDE’s KHTML by Apple for their Safari browser and later brought into Google’s Chrome, Samsung’s phone browsers and more.
“Few other browser engines have such portability and utility,” PulkoMandy said.
Haiku developer Ryan Leavengood started efforts to port the engine to create WebPositive in 2008. In 2009, WebPositive won a slot as part of the Google Summer of Code, and student developer Maxime Simon was able to get the browser in a “mostly usable” state while developer Stephan Aßmus (stippi) built the browser framework itself.
When PulkoMandy was hired, first as a paid developer before switching over as a volunteer to work on the WebKit port under WebPositive, there wasn’t a ton of new development going on with the software.
WebPositive wasn’t the only browser for Haiku, but with the additional portability and power of the WebKit1 engine as it existed at the time, the team decided to build it into WebPositive and make it the official browser for the OS.
“Right as I started my contract, Google announced that they would be forking the WebKit project and created Blink, the engine now used in their Chrome browser,” PulkoMandy said in an email interview. “After studying the state of our port, we decided that it made more sense for us to remain with the original WebKit which was closer to what we wanted to do.”
And so the work of keeping WebPositive updated began. To his surprise, every change modified how the OS worked, too. Applications that used SSE2 instructions like WebKit could crash if there wasn’t enough alignment for the stack all the way down the OS.
“An unexpectedly low-level problem to hit when working on a web browser,” he said.
Since then, most of the development in regards to WebPositive is porting: building new versions of WebKit into WebPositive in a way that the software continues to work while squashing any translation bugs that come up for an entirely unique operating system.
“Maybe surprisingly, I actually did very few changes myself to WebKit core and the web-related parts in the last few years,” he said. “My work is simply getting the latest version of WebKit from the official repository, merging it with our version, and solving any git conflicts and compiler errors that result.”
Any of the issues that come up can usually be managed pretty easily, he said. The challenge for the future is moving the WebKit engine up to a more powerful version and maximizing its usability within Haiku itself.
“There is nothing really challenging in that, anyone with some knowledge of C++ can do it. From time to time, there is a refactor that requires rewriting or reworking some parts of the Haiku specific code. The main challenge is to keep doing this regularly (every month or so), otherwise we end up with thousands and thousands of things to merge, and it requires months of work to get through it all.”
The hard work of volunteers like Rajagopalan, jua, KapiX, nephele, kallisti5, jessicah, shisui, nielx, korli and madmax have made a huge difference, too. PulkoMandy likened his work to just the tip of their iceberg.
“I think both of these are a bit ‘under the hood’ changes,” he said. “There could be many things to do on WebKit in terms of relatively easy to implement features (gamepads support for HTML5 games, geolocation for websites which can use that, …). Not to mention all the work needed on the web browser itself, which has a quite minimal user interface at the moment.”
PulkoMandy expressed hope that others would be able to come in and provide more development for additional features, like porting the browser to WebKit2, improving drawing performance, improving beyond bug fixes, and even more into the future.
WebKit2 would significantly improve stability, for example. Though this presents a considerable challenge, as replacing any major software component could be, it is feasible.
WebPositive currently matches Haiku’s version, and the latest stable version was released with Beta 3 on the 25th of July, 2021.
Contributors are always welcome to help not only tackle many of the problems facing WebPositive today, but to expand it into the future as the primary browser of Haiku. Goals include further stability and rendering improvements, JavaScript compatability improvements, plus a plug-in and add-on system.
For those who wish to contribute, visit the forums or the “Get Involved” page at https://www.haiku-os.org/community/getting-involved/. [Less]
|
Posted
over 2 years
ago
by
jt15s
Hello all! This is the third update from the Haiku Promotion Team.
Beta3 Released
As you have noticed, Beta3 has been released! Huge shout out to kallisti5, who was the release coordinator for Beta3. Making a major release of Haiku is a daunting task
... [More]
to all involved!
New Team Members
Since I last wrote in March this year, we welcomed the following members to the Team:
animortis
AlwaysLivid
jeremyf
Switching to IRC/Matrix
It was brought to our attention that the way the Promotion Team communicated was not a very transparent one – we communicated through a group private message on the Haiku forums. Thus, the decision was made to switch to IRC/Matrix, because it is a trusted technology, and it can be accessed from all major platforms including Haiku. Now, anyone can see what we are discussing and working on and can participate in our discussions! If you wish to join, we have a discussion room at #haiku-promo on OFTC, with bridges to Matrix.
Promotion Team Kanban
We were also informed that our Kanban, quite paradoxically, did not work on Haiku. We are still considering options to switch, including trying out a solution from Atlassian, or using the existing Haiku development tracker. We will post on this blog once a decision has been made.
Social Media Accounts
You may have seen that we have requested access to the Haiku Twitter and LinkedIn accounts. We believe that the accounts have become a lot like RSS feeds, which, is not inherently bad, but for an open-source project like ours with users and developers asking for help on social media platforms, we could do a lot better. We will keep you updated once the policies for the accounts have been finalised and we start posting on the accounts.
Haiku’s 20th Anniversary
Now that Beta3 is released, the next big event on the cards is our 20th Anniversary! If you go to the history page on this website, you can see that we started on the 18th of August 2001.
We will need someone to design 20th Anniversary graphics for us, so if you are up to the task, don’t hesitate to send me a PM on the forums or post in the IRC/Matrix room.
Currently, we have merchandise planned for this special occasion (we should have more news to share on that soon), but any ideas for events or other items for purchase are welcomed.
Looking ahead to Beta4
After Beta3, there will be Beta4. Why are we thinking of Beta4 so soon, you might ask? Well, the time after a major release is often a time when activity tends to slump for a bit. We want to keep that momentum going, so we are thinking of what we can do for the next major release.
We are considering putting on spotlight on many of Haiku’s built-in apps. Many of them have been neglected for years and need a developer’s TLC (tender, loving care). For example, the Mail app uses an older protocol, and the UI needs some improvement! To do this, we will put out Calls for Contributions, blog posts that let people know what needs work.
Additionally, there are many things that have been on our “wish list” for a while that need contributors. A single-sign-on system for all of Haiku’s web services (i.e., Trac, Gerrit, forums) is something that we have wanted for a long time. Furthermore, we still need to migrate from Pootle to another web translation service since Pootle is no longer maintained. We also need a major reorganisation of our website and documentation, as the organisation of our documentation is quite confusing. We will most likely put out Calls for Contributions for these, wherever applicable.
A tentative release date set on Trac is the 31st of January 2022. This is a tentative release date meaning that it is subject to change. Beta3 had the initial tentative date of sometime in April, however it was released on the 25th of July (or 26th depending on where you live in the world). It is the aim of the Haiku Project to have a major release at least once a year.
Additionally, there will be more tickets that will be assigned to Beta4; we have 688 active tickets in the R1 milestone so expect plenty more tickets to be added!
If you have anything you want to see in Beta4, a Beta4 wish list thread has been started on the forums so feel free to post there.
Closing Words
As always, if you have any feedback or suggestions for the Promotion Team don’t hesitate to contact us via IRC/Matrix, or post in the forums under the Marketing category. Stay safe! [Less]
|
Posted
over 2 years
ago
by
saloni
This blog will contain all the information about what I have done till now.
I started with the input preferences directory and started solving the issues according to haiku guidelines.
A few changes have been made to clang-format. This work takes a
... [More]
lot of time because it needs a complete understanding of how the llvm code works. As there was number of files, it was difficult to figure out which file should contain the solution of the problem but PulkoMandy really helps me alot.
While working on this project I learn new things which were really good!
Preserve the indentation of comments
In the Haiku coding style, comments are sometimes indented one level more than the code (when they refer to the line above them) but clang-format doesn’t accept these one level indented comments and change their indentation to previous line indentation
if (a)
return ;
// Comment to remain as it is
else {
return;
}
So, this comment was previously getting equal to indentation of return statement. Then, I write some code which checks the indentation of previous line and compares with the original line and formats according.
Please have a review
After this I added a functionality that this code should only work when “haiku” is passed as argument because some people may not want that for their project.
Please have a review
Removal of braces for multiline control statements
According to haiku guidelines, if there is single line control statement then the braces should be removed otherwise not.
if (acceptFirstClickBox) {
acceptFirstClick
= acceptFirstClickBox->Value() == B_CONTROL_ON;
}
In the above case clang-format was removing the braces for such conditions. So, I got a patchset from llvm which I firstly set as the base code for this.
Base code
After that some changes were made and the redundant braces remover code was removed.
Revert the redundant code
After that finally, the final commit was made which removes the extra changes and sets the correct indentation mode matching with Haiku.
Please have a review
Line break after return type in function definitions
Functions with one arguments were not properly detected. But the functions with no or more than one argument, code formatted correctly.
void
MouseView::MouseUp(BPoint) {
fButtons = 0;
Invalidate(_ButtonsRect());
fOldButtons = fButtons;
}
In this above example the clang format was not breaking after the return type with one argument but when I passed no or more than 1 argument it breaks correctly, This issue took alot of time as firstly I tried with different configuration but nothing works then I supposed that any function needs to be called for the break after return type but found nothing.
Then I tried with llvm latest code also but even then it doesn’t formatted correctly. After that, I came to know that this was a problem in llvm code and was mising this specific case. At,last I write the code for this specific case in the isFunctionDeclarationName function.
Please have review
Ongoing review
Unusual indentation of BLayoutBuilder block
The block was getting formatted incorrectly
BLayoutBuilder::Group<>(this, B_VERTICAL)
.AddGroup(B_HORIZONTAL)
.SetInsets(B_USE_WINDOW_SPACING, B_USE_WINDOW_SPACING,
B_USE_WINDOW_SPACING, 0)
.Add(fSettingsView)
.End()
.Add(new BSeparatorView(B_HORIZONTAL))
.AddGroup(B_HORIZONTAL)
.Add(fDefaultsButton)
.Add(fRevertButton)
.AddGlue()
.End();
The clang-format formats this block such that the indentation level of all these lines become equal which was against Haiku guidelines. So according to the community this block needs special handling. The options was:
Have some very specific code to detect the use of BLayoutBuilder and the specific indentation it needs
Annotate the sourcecode with some comments to tell clang-format to not touch this part of the code.
As the haiku code contains number of such block, so it will become messy to use clang-format off. So, I just proceed with first option.
As, I was not familiar with how the indentation of this block is to be done as differnt file was following different rule so, I planned a meeting with Preetpal in which she explains me the process for this block and I write some code for this which correctly indented this block even after giving any incorrect indentation.
Please have a review
Then one issue remained unsolved in which the .SetInsets line was exceeding the column limit i.e. 80 according to Haiku guidelines. This line was not getting properly breaked and merged. After spending time with the code looking into this issue I found that when I changed this block LineComment block the block was getting formatted correctly as expected.
I looked into this to find such condition and change it according to the requirements but found nothing.
So, now I am working on this to write some code that will call required functions to format it correctly. I made some changes and write some code but it breaks at some point. I am looking for it and is working side by side on it.
Extra space before ++ operator in for loop
In for loop the extra space was added before the ++ operator.
for (itr = fMouseSettingsObject.begin(); itr != fMouseSettingsObject.end();
++itr)
Then, I take a look at files and see the configurations and made the changes for Haiku.
Please have a review
But the PulkoMandy suggested me that there can be much better option than this and suggested me to look into ContinuationIndentor.cpp file which will contain some function which is violating our defined options style configuration which were
UseTab set to UT_Always so even if it tries to do alignment, it
should be using only tabs.
set bracket style to BAS_DontAlign so it should not be aligning things this way.
But we both look into it and tried to find appropriate function but till now got nothing. It’s a WIP task and working on that also.
Tabs are converted into spaces
Output of Haiku-format is converting tabs into spaces :
private:
BString fTitle;
BBitmap* fPrimaryIcon;
bool fSelected;
whereas the expected output is :
private:
BString fTitle;
BBitmap* fPrimaryIcon;
bool fSelected;
The basic idea is :
indented 1 tab: qualifiers (volatile, virtual, static)
indented 3 tabs: type of fields and return type of functions
indented 2 tabs: function or field name
I have writted the code for it that need some changes which is under progress.
You can find the sources on Github and my weekly blogs here.
Thankyou :) [Less]
|