On Friday the 18th of May, 19:00 GMT (21:00 in Amsterdam, 20:00 in London), I'd like the documentation team to meet. This meeting is for all the people interested in the API documentation, whether or not you are actually planning on contributing or not. We would like to hear as much different opinions as possible.
The meeting will be on IRC, on freenode irc.freenode.net), in the channel #haiku-doc. This space is open for everyone.
Finally back with a proper development environment.
Seizing the opportunity of having some free time, I finished implementing the user interface and prepared everything for package file parsing. Since I have yet to analyze the .pkg format throughout, I’d rather have everything prepared for this to come. From what I see from the materials sent by Ryan, the format itself doesn’t seem to be as complicated, but there are still quite some unknowns.
In his Popular Network Preferences applications and comments blog post, GSoC student Andre Alves Garzia gives a great comparative overview of network preferences apps in OS X, Ubuntu, Windows and ZETA, as a means to look for the ideal approach for Haiku.
Andre's post actually reminded me of a few ideas that I had quite some time ago about a BeOS-like way for handling network/email/printer settings (in ZETA, back in the days when I was using it), that I think would still apply for Haiku. I don't know if they are within the scope of what Andre is doing and, not being an engineer, I don't either have a clue whether these ideas can be implemented or not. But I will present them anyway, even at the risk of exposing my sheer ignorance. :)
The idea today is to compare and comment on popular network preferences apps. I’ll pick Mac OS X, Windows, Zeta and Linux and comment on what we can learn from each and think about how can we design a successful network preferences application for Haiku. I will not focus on the eye candy or widgets, the focus is on the user experience and features.
Lots of shots of different OSes and some opinions by yours truly.
After reading the main part of the USB specs, I moved on to the UHCI driver specs this week-end. I can now say, that implementing the isochronous part to the UHCI driver is a lot easier than I thought, and I guess Micheal can confirm. While reading the UHCI specs I followed Micheal’s code, and I have some questions about it, but I’ll write him an email for that. By the way, is R1 intended only for x86?
Hello All,
My name is Andre Garzia and I live in Brazil. I am one of the summer of code students that will be working with Haiku. My project is the Network Preferences Application. I do most of my work on macs, most of my work is related to custom servers or web apps. I have a hobby which is to collect operating systems and machines and network them all. Right now I have couple macs (both classic and mac os x), linux, solaris, zeta, haiku, windows mobile, newtons and a magic cap machine, all networked, so I’ve felt the pain and joy of configuring different kinds of machines with different needs.
Who would have thought that something like me being chosen as a student for GSoC would actually happen. But it did. Blissfully indeed.
Anyway, designing a good user interface is not as easy as it seems. The truth is, not even for a second did I think it was, really. On my project road map, I’ve set designing the installer UI as my first task. Following the discussions with the Usability Team, a satisfactory concept came to life.
This article contains outdated information, please read with caution. Mainly in the second half of the last year the Haiku USB stack has matured a great deal. Not only has it stabilized a bit, it has also seen the addition of an EHCI driver to support USB 2.0 devices. A rewritten UHCI driver and a new implementation of the USBKit library are other steps to a complete stack. The reason to write about that is the following: An increasing number of people apparently get interested in the progress of Haiku USB and they start to ask questions about the completeness and usability of the stack.
I’ve been reading some more code and I’m getting more confident with it.
Basically data transfer is done with memcpy.
In the ehci controller, registers are mapped every time a controller is found. This is done in the controller constructor.
As the ehci specs says: Register Space. Implementation-specific parameters and capabilities, plus operational control and status registers. This space, normally referred to as I/O space, must be implemented as memory-mapped I/O space.
I said it already, but I’m going to say it a million of times, I’ve never EVER would expected to work on such a project for the Google Summer of Code, I actually didn’t even think I would get in the soc. But anyway, here I am… so let’s begin!
Last night after I got bored reading the Kernel Kit section of the Be Book (it was about threads and related functions), I opened my shell and I dived right into the USB stack code.
