Hi, > * I presume we want the 'interfaces' and 'services' settings, > currently stored in /boot/common/settings/network, to be > contained in those profiles. However, the net_server is only > aware of these files. > I presume we want to extend the net_server to support profiles, > and then let the preflet configure/activate them? IIRC, the initial plan was to use a /boot/common/settings/network/current symlink to the active profile stored under /boot/common/settings/network/profiles/<profile_name>. But since these old days, we now have a net_server which handle applying user-configured settings, maybe it's easier to make net_server profiles-aware than playing with a symlink. > * Also, am I correct that nothing in the current source is > actually writing to /boot/common/settings/network/interfaces > yet? The Interfaces add-on should do it, as it reuse (steal ;-)) most of the actual Network preflet code to do it. See here: http://dev.haiku-os.org/browser/haiku/trunk/src/tests/kits/net/preflet/InterfacesAddOn/EthernetSettingsView.cpp#L304 But maybe it's broken. > Preflet UI: > * Pressing the Configure button for an Interface pops up a > similar window as the current Network preflet. > Would it be ok to show the content of that window as part > of the new preflet window instead of opening a new window? +1 In fact, long time ago when I started this "new" :-) preflet what I had in mind was using an OutlineListView for interfaces, with configuration view as child, in order to avoid popup and clobbering the interface list. However, keep in mind that currently the configuration is simple, but with wireless interfaces and eventually bluetooth ones too such configuration could quickly become more complex. > * Personally, I prefer tabs over the popup menu used to switch between interfaces > and services configuration views, what is the general opinion on this? I must confess that Haiku's tabs were ugly at the time I modelled this window, so I've followed the MacOS X design then. Now our tabs looks great, and if each "tab" could host a more complex (and eventually dynamic) sub-configuration layout, thanks to Layout API, we don't need that much tabs, Interfaces, Wireless & Services comes to my mind mostly. Bye, Philippe.