[openbeosnetteam] Re: network preferences app

on Sat, Mar 16 14:37, David Reid was heard to have remarked:
>> >> Now, we need to decide what it should look like and tell him.
>> >
>> >Part of the problem of making a network configuration gui is make both
>> >simple for newbe user *and* powerfull for... well, power-users :-)
>> >I guess looking at what other OSes offer on this topic could be a good
>> >idea.
>> >MacOS X is known to have a great one, BTW.
>>
>> Hmm... I'll take a look at the MacOS X one; I seem to recall it looked
>> much like the older TCP/IP control panel from OpenTransport, and I've
>> seen a few instances where it hid useful options (no way to access
>> them).
>
>Can someone post some screen shots? I've never seen it and don't have OSX
>here!

My roommate has an OS X computer, but I don't have access
privileges.  Here are some screen shots from the net:
http://www.stanford.edu/group/itss/macstanford/osx-ethernet.html
http://help.earthlink.net/techsupport/xmldocs/macintosh/os_x/operating_system/2930.help.html

I do like the idea of having the "Interfaces" panel actually show most
of the settings for that interface (rather than having to drill down
an extra button & window to see them).  It would also be nice to
include all the information available, although maybe with a "user"
and "administrator" mode, so only necessary choices are available in
"user" mode.  The rest are just text, rather than text input boxes.

>> >> Have people seen the boneyard one? If not maybe someone (Philippe)
>> >>can stick some images up. Discussion is required as we're not likely
>> >>to get this changed in a hurry once it's done.
>> >
>> >Okay, for the ones who never see Boneyard, the BONE Configuration
>> >preference app:
>> >
>> >[snip]
>> >
>> >In fact, Boneyard is heavily add-ons based, one per tab, the boneyard
>> >binary focus only to offer the configuration set/get support routines
>> >and the graphical shell for each add-on (one by tab).
>>
>> The skeleton I had written is the same way.  All it implements is:
>>
>> create window
>> scan add-ons directory
>>    for each add-on, load it's BView
>>    create a BTab from the BView and add it to the window
>> Add buttons for "Save" "Cancel" and "Restart Network"
>
>Hmm, interesting. have you looked at the code in place for the kernel stuff?
>We should make sure this will work as so far all the code is C, not C++. We
>may have to add a new module that provides this - though that's not a big
>problem and in fact gives us extra flexability.

Sorry... I was planning on having Preferences add-ons, rather than
using the same binary as the kernel modules.  Although, if we wanted,
we could write an add-on that would function as both, and link it from
one place to the other.  (I think I only have one or two add-on hooks,
and the kernel would just use different hooks and code in the same
binary.)  On the other hand, it may just be easier to have a
"Interfaces", "Services", "Sharing", "Identity" and maybe "Dial-Up".

>> When "Save" is pressed, notify each add-on to update the global
>> preferences object (BMessage, currently) with its' info, then saves
>> the preferences object to file.  [This may change to saving
>> preferences, then notifying each add-on]
>
>Well, in the new stack you'll just open a socket, call the correct ioctl's
>and the stack will take care of the rest. I think the stack should even
>write it to disk. Or should it? When we start the server ifconfig will be
>called to set the devices up, so I guess the answer is no.

Actually, I was thinking of this in the same way as the current (R5)
prefs work -- you save the settings (if you want), and then you later
tell the stack to reset itself.  This way, you can batch up your
changes, then execute them at once.  Also, this works better with the
idea of network profiles, as it would allow you to change all of them
at once.  Basically, I'd like the network apps to be able to get the
current values at startup, but allow the user to change them and save
the changes to file before sending them back to the stack.

>> Also, each time a tab [add-on] is displayed (selected), it needs to
>> check the global preferences in case some of it's settings have been
>> changed by another module.  Each app should update it's preferences
>> values to the global prefs object on modification (rather than on save).
>
>These would just be files on the disk, though we'll need some way of locking
>them to preserve correct data. Hopefully BFS will get locking working for
>our eventual solution.

Well, what if we have a central file (like settings/network) that
contains info from a number of different apps.  Also, what about
saving different network profiles, and being able to switch between
them?  (Say, "office" and "home" or "wireless" and "dial-up"?)  I
think we should try to have a single preferences file with sections
for each configuration element.  In any case, I'd prefer to abstract
the add-ons from the configuration storage/stack configuration, so we
can change things later and all we have to update is the Network
Preferences app.  Particularly if other people start writing Network
add-ons as well.

>> When "Restart Network" is pressed, it tells the network stack to
>> re-read it's preferences.
>
>Yes.

In the meantime, however, the stack should keep going with it's
current settings, while the Network panel can be displaying a
different set of "work-in progress" information.  Trying to work on
all the information while it's live leads to a process of things
changing underneath you, like in WinXP.  When the Preferences app
starts up, it should read in the current preferences and let the
add-ons work on it from there.  I'm not sure if it's practical (or
desirable) to be able to get the current configuration from the
stack.  Maybe a 4th main button that says "Load Current Status" or
something?

-- 
Evan Knop <argent@xxxxxxxxxxx>      http://lore.dartmouth.edu/~argent/

"Everything should be made as simple as possible, but not simpler."
- Albert Einstein

Other related posts: