[openbeosnetteam] Re: network preferences app

on Fri, Mar 15 16:37, Philippe Houdoin was heard to have remarked:
>> I've managed to get someone to agree to do the gui stuff for our 
>preferences
>> app! Yay!
>
>That great!

If I may ask, who is it?  I used to be assigned to the Network Prefs
app, but I dropped off the face of the earth for a little while, and
I've been waiting for things to stabilise before I write much of the
network prefs.  I'd be happy to send along what I have to the next
person, and work with them on writing it.  [I'm not a huge fan of
GUIs, and I'd rather work on getting our current stack configurable
when I get a chance.  I'm also willing to play "code nanny" if I can
manage to convince sourceforge that should be able to check out the
OpenBeOS under my id.]

Currently, all I have is basically the boneyard skeleton, and some
ideas about how to maintain the preferences (on disk, with modules
being able to save either to the main prefs file or do their own
thing).

>> 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).

On the other hand, we should strive to avoid doing anything like the
Windows XP network controls -- they magically change on you and don't
let you get back to the old state.  Also, they seem to want to bridge
every interface to every other one, or else do NAT on that interface.
Aargh!

>> 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"

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]

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).

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

>Boneyard is not very *clean*, but it's easily upgradable, and that, 
>it's really cool.
>One feature we should think about from start: we don't what future 
>network technology would emerge and need to be configurable...

One reason I like the add-ons idea is that *all* the network settings
can be in the same place.  Even the ones that don't really care about
our network stack settings.  Want to control Apache or Samba from the
Network settings app?  Just write an add-on that, on "save"
notification, writes the appropriate httpd.conf or smb.conf.  Also,
the "Services" panel for Boneyard looks like a GUI interface to
inetd.conf -- we already have places where we could use this sort of
approach.

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

"Out of register space (ugh)"
- vi

Other related posts: