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. For most users DHCP is the way to go and they will never ever need to see the network preferences application, some power users will want the application to offer every possible feature, so my work for Haiku sums up to: āHow to create a network preferences application that is at the same time, easy to use and consistent to the overall Haiku end-user experience and yet offers all the features an advanced user might expect?ā. I hope people here will help me find this answer and that by the end of the summer, we have a network preferences application that we can all be proud of.
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. The final result doesnāt reassemble a bit what I imagined when writing my application - but itās much better than the latter. The major difference is in the approach - thereās not much reassemblence left with the old Beās SoftwareWallet design. Even though their idea was quite intuitive and useful, there were many things that ācould have been done betterā. Thanks to DarkWyrm and Waldemar for making me understand this better!
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. Also whether and how to use the Haiku USB stack under R5 is an interesting question. Instead of telling the story individually it probably makes more sense to sum everything up in a post for everyone to read. I'll try to show what is currently implemented and working and where missing parts or possible problems could arise.
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.
Quick Updates
r20100-r20200- Updates to Mesa 6.5.2 and binutils 2.17
- Consoled debugging of app server, input server and the registrar
- CPU initialisation fixes
- Introduction of the UserlandFS
Quick Updates
20000-20100- Addition of class screensavers
- Customisable CFLAGS
- Useful URI to application redirects
- Syscall benchmarks and results
Quick Updates
19900-20000- Introduction of USBKit reimplementation
- Interesting local message passing optimisations
- VMWare vmdk tools
- vmdk image generator
- vmdk jam target: haiku-vmware-image
