New properties for StatusNotifierItem: (Not|Only)ShowIn (2/3)

[Ted Gould]

On Thu, 2011-02-03 at 09:19 -0800, Aaron J. Seigo wrote:
>> What we'd like to add is two properties that are
>> lists of strings: NotShowIn and OnlyShowIn.  These would work exactly
>> the same as the same properties in Desktop files where an application
>> could say "NotShowIn=["Unity Launcher"]" and ensure that they'd never
>> end up with that item used as a quicklist. 
> 
> this makes for a great hack to customize apps for a specific shell. 
> unfortunately for the app developer (and their users) when that shell
> is replaced, then things go to hell all over again.

Well, exactly.  I think that if you're using this feature you're
expecting to be very closely tied with a specific visualization and you
need to expect things to break when that changes.  It's not robust in
that regard.  And I imagine as things like Unity change it would first
advertise it self as "Unity Launcher" and then "Unity Launcher 2" so it
wouldn't get anyone who customized for "Unity Launcher".

We can't expect to be robust for customized results over time, but
providing a way for people who want to tweak specific visualizations
with known short term results should be possible.

On Thu, 2011-02-03 at 10:43 -0800, Aaron J. Seigo wrote:
> On Thursday, February 3, 2011, Ted Gould wrote:
> >  people wanting different menus on the panel vs. on the launcher.
> 
> crazy idea: different menus from the same SNI for different (well-defined in 
> the spec) contexts? if the SNI only provides a "generic" menu, use that 
> everywhere. if they provide a "launcher" menu, use that for launchers? we'd 
> need a set of menu contexts (generic or primary controller, launcher, ..?)

That seems to me to be attaching the spec more directly to specific
visualizations.  Which, honestly, I'd like to discourage overall.

> > So the specific case was with Tomboy where in the
> > menu on the panel they wanted to have a "Quit" button but the launcher
> > menu automatically has a close (through the WM) and they didn't want
> > both.
> 
> sounds like we need/want action-level metadata.

In this example, yes that would work.  But I think that this starts to
become fidgety where we're basically doing the same Not/Only thing on a
per-menu item basis.  Since this is a DBus interface, I think I'd rather
have complete implementations and if the back end wants to make those
the same set of objects DBus is none the wiser.

> > Also, in our specific case there are more restrictions on the
> > menus in the launcher (no submenus) so if an app wanted to use those
> > they wouldn't want it to appear in the launcher.
> 
> this can be determined with a heuristic?

You don't know what people would want to do when the submenu was
removed.  In some cases you might want to do something like:

Menu 1
------
Menu 2
Sub 1
Sub 2
------
Menu 3

In others you might just want to remove Menu 2 entirely.  I think it's
better left to the design of the application which features are
important to leave in or remove in a reduced functionality environment.

> > I would imagine that for most applications if they were going to use
> > this feature they would be building more than one Item.  They'd build
> > one for a very specific visual target and then another that is a generic
> > item for all other visualizations.
> 
> assuming they know of the available visualizations (and their design 
> guidelines), also create a generic one and then actually get the 
> visualization-specific ones right (esp over time -> what happens when the 
> visualization changes design in some way?). it's a lot of overhead for the 
> developer and very prone to breakage over time.
> 
> any time we've put visualization control in app developer hands things get 
> messy very quickly over the years due to these issues :(
> 
> for Canonical, you have Unity today but in 5 years what will you have? maye 
> something different. it's probably better not to get a whole bunch of app code 
> specific to today's Unity design that in N years you're going to have to 
> either provide legacy support for (probably with hacks) or which will result 
> in having to re-work all those apps .. again.
> 
> for KDE, it's even trickier: we don't have just one to-market product to 
> support. different vendors ship Plasma in different forms and configurations, 
> so we have to deal with "instant legacy" whenever these kinds of features are 
> introduced.

I guess I look at this similar to writing assembly code.  Do we allow
developers to write assembly if needed?  Yes, we do.  Is it discouraged?
Yeah.  Why?  Because it's hard to maintain and debug and port to
additional architectures.  But, sometimes you need that level of
optimization and you'd feel pretty lost without having it when you
needed it.

Certainly customized designs for specific visualizations increase
development time, maintenance cost and testing.  That doesn't mean that
we shouldn't make it impossible if that level of optimization is
required.

		--Ted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110203/a34fdb36/attachment.sig