Re: adding dead space to floating panels

[Mark McLoughlin <mark skynet ie>]

Hi Dave,

On Sun, 2003-01-19 at 07:02, Dave Bordoley wrote:

> Hi Mark,
> 
> Many of them are well known among the ui team, the most obvious of which
> is the dependence of context menus for customization of the panels
> (which is why floating panels seem to have problems in this respect).

	Sure, I just want to make sure that its not just the ui team that know
about these issues - I need to know about them too, so that I can mull
over them and maybe get around to fixing them.

> Another issues imo includes the existance of too many different types of
> panels. I believe Calum had proposed their only being one panel type
> which changed behaviors based on where the user positioned it. 

	I totally agree and I'm working on it a the moment ...

> I'll
> probably catch some flack here, but i personally wouldn't mind there
> only being one type of panel all together (edge panels). Of course such
> a change would probably cause a mass uprising.

	:-) Yeah, that would cause some "problems". I'm trying to simplify the
model, though. There should be two panel types only -
expanded/un-expanded (or maximised/un-maximised - whatever the preferred
term would be) - and you should be able to toggle between these states.
You get a "floating" panel by dragging it out from the edge of the
screen, you get a "corner" panel by putting it in the corner or center
of the edge of the screen and you get a "sliding" panel by putting it
anywhere else on the edge of the screen.

	Of course, the user doesn't know about these panel types - all the user
knows about is the expanded/un-expanded toggle and the position of the
panel on the screen.

> Other issues:
> 
> Many panel applets really should be included in the system notification
> area, these include
> 
> 1. The clock
> 2. Wireless link monitor
> 3. Modem lights (really should just be the equivalent of a minimized
> dial-up connection window imho)
> 4. Volume control
> 5. Battery monitor
> 
> and i'm sure others as well fall into this category. There is precedent
> for this in both windows and on the mac.

	I agree with most of these (except the clock), but its not a ui issue
with floating panels ... are these logged as bugs against those applets
?


	Digressing - when making these into applets, how are these supposed to
work? I was working on one last week and I ended up making it a program
(e.g. gnome-foo-monitor) which does the monitoring and sticks an icon in
the tray. It connects to the session manager to be re-spawned so that if
it dies it re-appears and gets saved as part of your session. But if we
have 6/7 of these, where do we put them so that the can be added to the
tray?

	* Each one installs a .desktop file and we present a list of the
available ones from a preferences dialog for the tray ?

	* Each one installs a .desktop file and we have a new "Monitors"
sub-menu in the Applications menu ? Urgggh, that sucks ...

	* Each one is a bonobo component and, like in the first suggestion, we
list the available ones in the preferences dialog and the tray handles
the re-spawning itself ?

	Personally, I think the first one makes the most sense.

> This post on the usability list covers this topic fairly well:
> http://mail.gnome.org/archives/usability/2002-October/msg00265.html
> 
> Than of course there is the elusive user object model that nils and seth
> have commented on before. In relation to this i find it strange that it
> is not possible to drag a link to file from the panel to the trash can
> (yes i do realize that there are implementation details). Furthermore
> links on the panel act completely different from the links on the
> desktop (they have different context menus, require different clicking
> behavior etc.)

	I've never looked at this type of stuff too carefully. My advise, is
that each one of these behaviours that you expect should be logged as a
bug so it can be discussed. I don't see how its a floating panel ui
issue either, though ... :-)

> Let me make it clear that i am not trying to criticize you or anyone
> else. These problems have long existed in gnome (since I first started
> using it with 1.2) and in all fairness the 2.x panel is far superior to
> the the 1.4 panel in terms of usability.

	Of course, I don't take this stuff personally :-) I'd be the first one
to swear loudly about certain aspects of the panel behaviour. I just
need to be sure I know which aspects the ui team are swearing about ...

Cheers,
Mark.