[openbeosnetteam] Re: network preferences app

Evan!

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

My apologies - didn't realise anyone was working on it (guess because yuo've
been so quiet :))

The other guy is Andrew McColl (leader of the preferences team) so I'm sure
he'd love to hear from you.

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

OK.

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

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

Yes, +1000 on that.

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

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

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

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

Yes.

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

This sounds cool :)

david

Other related posts: