- Contract weekly report #61
- Tracker-Layout has landed!
- Contract weekly report #60
- Contract weekly report #59
- Contract weekly report #58
- Contract weekly report #57
- 'Tis the season for debugging
- Contract weekly report #56 - Media fixes and more!
- Contract weekly report #55 - GCI and more
- Contract weekly report #54
Settings, BeOS style
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. :)
Those of us who have used BeOS/ZETA in the past know the goodness of how extended attributes are for certain file types. The approach of having emails messages and contact information in individual files with attributes makes your data very portable and accessible even at the file manager (Tracker) level. You can, for example, switch your email client, and still have access to all your emails and contacts, as the data remains always the same.
There are some applications that take attributes a bit further in quite innovative ways. A good example that I always use is the IM Kit, which uses People files to store all IM contact info and to show online/offline status. This is a very intuitive way of presenting information related to any given contact, and it is exposed in such a way that it can be accessed at the basic file manager level as well as from applications.
By now you may be asking: what does all this have to do with Andre's post? Well, I have many times I asked myself: why not use a People file approach for settings files?
For example, let's take a network configuration: to create a network connection, you open a People-like app where you can choose the NIC, connection type (DHCP or fixed IP), and enter info like name for the connection, DNS and other various network settings. When you save the configuration, you are actually creating a network connection file (stored in a "networks" folder?) that holds all the information that you entered in attributes. This file could be accessed both directly from Tracker and/or a summary-like pref applet that would list and give access to all the existing connections in your system.
I think there would be many advantages to this approach from a user POV. First, it is more intuitive, as the network connections are exposed to the user in the form of files that can be opened and changed from Tracker. Network connections can also be easily moved from one system to the next; it would even be possible, for example, to email a network connection file to someone else for troubleshooting. Additionally, power users could use queries to poll the status of network connections, or connections associated with any given setting stored as an attribute (for example, all connections using a certain NIC). And, in the same way as IM Kit, different icons themselves could be used to show the different types of connections (ethernet or wireless) and their status (enabled or disabled), making it all even more visually intuitive.
I think this approach could be used for other settings too, like email accounts. How much easier and intuitive would it be to the user if he/she could backup and restore email accounts by just copying a few settings files and dropping them in the "email" folder!
I have no doubt that I may be missing some obvious pitfalls to this approach, and you are welcome to point them out to me. But I am sure you can still get the gist of what I am aiming at. Admittedly, maybe this is R2 stuff, but I thought I would anyway post about it, even if it's just as a way not to forget about it. :)