FreeLists / openbeosnetteam / [openbeosnetteam] Re: Network preflet, the future?

["Philippe Houdoin" <philippe.houdoin@xxxxxxx>]

> > > BTW, here the latest layout I came off, after Axel give his 
> > > opinion
> > > monday:
> > > http://philippe.houdoin.free.fr/phil/beos/openbeos/network_kit/
> > > network_gui-04.png
> > 
> > Looks better although I miss the "Switch To" button a bit; I 
> > actually
> > thought to have the "Apply" button at the bottom, and the "Switch 
> > To"
> > button at the top. But do as you want :-)
> 
> I have the menu at the top myself as well. However, I think it is bad
> to have the New.../Copy.../Delete functions in that same menu. It 
> gives
> the menu a 'double function' (selection of a profile and editing), 
> which
> I think is a big no-no.

I agree here, I don't like it myself.
However, the profiles managment commands as buttons take too visible 
space, when it's not 
the most important operations the user will do thru this preflet, which 
are in my mind:
- set or modify setting(s) of current profile (will be the "default" 
one by... by default ;-) ) and apply them (or save them if)
- switch/make active another profile

Create a new profile, renaming it and delete one of them isn't the most 
used features, even if they are required...

> Another thing I'm not to fond of is the way Show listview. I tend to
> lean towards tabs, because they give a better overview of all the
> options,
> it also minimises the amount of mouse activity needed to switch to
> another
> page.

I agree again, but I try to leave Tabs options to settings add-on(s). 
Cascading popup menus don't hurt, from user interface point of view, 
that much compared to cascading tabs.

>  However, I do realise that if there are a lot of add-ins, the
> amount
> of tabs may become so big that the purpose of having tabs is 
> surpassed.
> But
> at the moment I lean towards the tab-approach.

Fair enought, but it's something easy to change in the future...

> I don't think our main ideas differ very much. And I presume you have
> written a lot more code than me. The thing is that we should decide 
> on which approach we should take. I personally stick to the General
> page.
> In a tabview this tab would be first anyway, would be on screen when 
> the
> user starts the preflet, and it will contain a general summary (the
> status
> listview). 

Whatever is the add-ons switching widget, tabs of popup menu or 
listview, 
having an overview/summary status of the stack displayed first at start 
sounds great to me too.

> But I'm leaving this decision to you. As soon as you've
> decided,
> I am more than willing in involving myself with writing the code.

We could split the work into two tasks:
- the preflet add-ons API, thru something along a 
NetworkPreferencesAddOn class. Its design should allow to 
  don't export anything else from the preflet (globals functions like 
boneyard_do_save().... glup :-( ), if possible.
- the preflet (aka add-ons host app) itself. It involve many gui design 
work I'll bet, and having more than one 
  graphical design is not forbidden here... until it's under src/tests/
kit/net/preflet/* tree ;-)

I'll try to throw some NetworkPreferencesAddOn interface I've in mind 
shortly...

-Philippe

--
Fortune Cookie Says:

Heavy, adj.:
        Seduced by the chocolate side of the force.