netbook irc meeting

[Marco Martin]

On Monday 21 September 2009, Aaron J. Seigo wrote:
> On September 20, 2009, Marco Martin wrote:
> > On Sunday 20 September 2009, Marco Martin wrote:
> > > On Thursday 17 September 2009, Marco Martin wrote:
> > > > Hi all,
> > > > since i want to do the netbook shell as good as possible, i'm
> > > > interested to hear opinions and directions from you guys =D
> > > >
> > > > i would like to have a little irc meeting about it, to discuss some
> > > > of the issues there still are  in the current implementation,
> > > > possible topics are: -point of the situation, what actually are the
> > > > issues :) -integration with the system, like with kwin, and how to
> > > > start a netbook session
> > > > -default applets layout, what to put in the containments
> > > > -look and feel: how should actually look from a designe pov
> > > > -priorities: what is really important for 4.4, what can be 4.5
> > > >
> > > > more implementation details, not really metting topics:
> > > > -how to loadthe default layout: hardcode/vs default config fie/vs
> > > > scripting -what are the ugly spots in the code and things like that
> > > >
> > > > could be done? what do you think?
> > > >
> > > > Cheers,
> > > > Marco Martin
> > >
> > > in the end being aaron and nuno-less there wasn't much going on,
> > > however me and arthur chatted a bit about the various parts for a bit,
> > > here is the unfiltered log that can at least make a recap of the topics
> > > if we can make a "good one" :)
> >
> > little synopsys, topics were mostly what we more urgently need for 4.4:
> > *Panel:
> >   -default applets: now there are  current window control, activitybar,
> > spacer, systray, search field for sal
>
> search field probably not needed now? (see below)
>
> (and you're missing clock there, no?)
>
> also, in systray there is: battery, networking, .. ?

yes, the clock of course and the systray would have battery, devicenotifier 
and networkmanager (when ready) in it

>
> >   - i would swap current window control and the search field
>
> swap position you mean? if so, why?

just to have the close window button in the same position in upper right 
corner as normal windows, but i don't tink is a really important thing, and 
since the present windows is triggered at the upper left corner it could make 
sense to leave the button that triggers the same effect near to it

> >   - connected to the ability to have multiple "pages" (just tought about
> > it now) a button after activitybar that creates a new newspaper activity
>
> this could also be in the newspaper page itself to save space in the
> activitybar?
in the toolbox maybe?
> >   - other thing not touched there but to be decided: panel autohide or
> > not?
>
> i like the current behaviour for the default..
>
> >   - search field for sal: since the sal has a search field by itself i
> >  would do:
> >      -make it no longer a popupapplet so i can access the dialog geometry
> >      -make the dialog be exactly superimposed to the sal internel search
> >  field to make it feel they are the "same thing"
>
> i don't think a separate applet for this is needed at all now, tbh. and if
> it's always in the panel, then we don't need the separate icon in the panel
> either. just focus the line edit when switching to it.

so leave just the search field in the middle of the sal? (and focus it as soon 
as the sal containment is activated)

> > *Newspaper
> >   -titles: on mouse over like applet handles or always there? (applet
> >  handles like would be waay simpler code, less clobbering with layouts)
>
> why would applet handles like be simpler? i'd think that always-there
> handles would be easier.

perhaps if i make the handles childs of the applet, yeah

> what are the design goals for the handles?

to do some things:
-button to close the applet,
-button to launch the associated application (done exactly to be there in the 
first place :))
-move the applet also when not in configure mode and plasma is not locked?
-a title (but perhaps just the applet name is not explanatory enough?)

> * provide access to close, maximize and configure. do we want a way to
> collapse an applet too? that's probably not strictly necessary.
>
> * finger friendly? (this may make it significantly harder to keep the
> spacing nice; perhaps there could be a size adjustment based on whether
> it's on a touch screen or not?)

yes, and for the panel behaviour and size too
(InputMethodConstraintEvent? :p)

> * widgets shouldn't move around whether the handle is visible or not
shouldn't be possible to move the widgets with the handles? hmm
> * should hide when not hovered or selected? perhaps the handles can always
> be there and only the control buttons fade in when a widget is hovered?
> interesting to see how http://www.google.com/ig does it, too.
yes, could be nice.
igoogle has also a maximize button that resize the applet to be mostly full 
screen..., perhaps is what we have with the associated applications?

Cheers,
Marco Martin