Hello, first of all I wish you a Merry Christmas! My name is ranjun shi, I come from China, and I am now in the first year of graduate school. I have studied C language and participated in NXP smart car competitions during my undergraduate course. Currently learning C++. What else do I need to learn or prepare before I can join the 2022 gsoc plan.
Hi Jun, thanks for your interest in Haiku, as the holidays are around it could be that the main mentors will respond later.
ok , thanks!
I can contribute to the community in any form
My developer skills are nil, so I’m not a member for the GSoC mentors, but I’m sure they will respond sooner or later.
EDIT you could also ask around on IRC, channel haiku can be found on OFTC server
thank you very much!
By the way, what are IRC and OFTC. Haven’t learned about it before.
IRC is a chat protocol, it is still used much, but mainly by a nice audience of software developers.
OFTC is a specific irc server, you can read about them here: https://www.oftc.net/
Haiku is available on that server in the #haiku channel.
Hello, thanks for your interest in Haiku!
First of all, you should (if not already done) read the pages in www.haiku-os.org/community/gsoc
Have you looked at the ideas list? Is there one of the ideas that look more interesting to you?
There are several ways to discuss with the community, this forum is an option, as well as the IRC chat (already mentioned above) and the mailing lists.
To get started with development, the first step is determining how you prefer to work, for example installing Haiku natively on a dedicated machine, or building it from Linux and running it in a virtual machine. Depending on what you plan to work on, and your available hardware, one solution will be easier than another
Thank you for your reply, I will learn about the content you mentioned, and I will reply to you in time when I understand
ok,thanks! that sounds great to me！
Hello PulkoMandy! I think the idea of Better XMPP instant messaging client for Haiku is very interesting. How should I start contributing to this idea. What can I do with c++ or c
Work on an XMPP client is happening here: https://github.com/haikuarchives/renga
You can compile this project and run it. And join the Renga XMPP chatroom to meet the other developers of it.
There is a list of tickets already created with several ideas, and several aspects that can be worked on:
- Improving support for “XMPP compliance suite”: these are the recommendation from the XMPP community for what a good client should be able to do,
- Looking at the tickets marked “vision feature parity”: these correspond to features available in Vision (the IRC client for Haiku) but not yet in Renga. I hope we can encourage people to consider migration to XMPP once these problems are solved, or maybe use Renga as the default way to access IRC (through an XMPP gateway) on Haiku,
- Various other tickets related to user experience (user interface improvements), extra XMPP functionality that can be useful or fun, etc,
- And of course XMPP is a large project with a lot more than instant messaging, so otehr things could be explored too
Another option is https://github.com/JadedCtrl/Chat-O-Matic which is a multi-protocol client, competing with Renga with a bit different goals (supporting many common chat protocols). Personally I think an XMPP specific client will allow to develop much more functionality, where a multi-protocol client risks being limited by trying to fit all chat protocols into the same client, and using the “least common denominator” subset of features. I could be wrong, however, and as you can see, Chat-O-Matic was in fact largely developed during last year GSoC. I will let @jaidedcd introduce the project and tell what the plans for it are
@PulkoMandy did a good introduction (thanks ), and plans are pretty similar to Renga’s:
- UI improvements (for example, making the chat view a little more modern)
- Improve Purple support (dealing with C, mainly just filling in hook functions)
- Improve XMPP and IRC compliance
- Add other protocols
There is truth to the “least common denominator” problem, but I think the current approach is a fair compromise: Assume protocols can do high-level things (and if not, let the add-on fake it), and give add-ons a good deal of flexibility to mess with the UI if they want to.