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

[Aaron J. Seigo]

On Thursday, February 3, 2011, Ted Gould wrote:
> 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. 

when there are ways to avoid that scenario, how does it not strike you as a 
rediculously bad design for 3rd party developers? unless you aren't targetting 
3rd party developers, of course *shrug*

> 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.

if you are designing and developing the entire system yourself from top to 
bottom, this can work. if you have 3rd party developers involved, this is an 
amazingly bad idea.

why? because the 3rd party app and the shell do not have the same timelines. 
unless every app and every shell release on the same day with the same UI 
support, it gets increasingly chaotic over time.

it's also the definition of "non-portable" at the UI level; as someone with no 
vested interest in a specific platform, i have no interest in that.

> 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.

but Not/Only which list specific visualizations is not tieing it to specific 
visualizations?  c'mon :)

generic profiles of "this is appropriate for launchers", "this is a full 
featured menu" (or whatever divisions we decide to come up with) would not be 
visualization specific in the least. it would be defining use cases for 
application developers to fill with visualizations selecting which one(s) 
match their display needs. and then any number of visualizations can take 
advantage of that work and app developers can rest easy that their hard work 
isn't going to get torn up 2 years from now (ditto for users, who are even 
more powerless in this)

> > > 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:

ah, so you don't want to just hide them but also perhaps manipulate them. 
which would be solvable with the multiple menus approach.

> > 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. 

it's not discouraged at all. it's there for use when the problem requires it. 
other tools are there for when the problem doesn't require it.

in this case, the tool isn't needed as long as we design SNI with consistent 
principles. what you want is not impossible with a clear data/visualization 
division. it just takes more up-front design thinking.

in the long run it will save oodles of app developer time and UI 
inconsistencies down the road. measure twice, cut once.

> 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.

we should if it will lead to abuse of the system and waste of developer 
resources (not to mention apps that only work nicely on one vendor's 
software). there are better ways to achieve the desired results that do not 
violate the data/visualization barrier.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- 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/9931c5ae/attachment.sig