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

[Ted Gould]

Aaron,

I feel like you're saying: "if we don't provide a way to do this
developers won't do it."  And what I'm trying to say is: "designers are
going to want to do this whether we provide a way or not."

I think we have a choice, we allow them a way to explicitly specify it
or they reverse engineer the heuristics we use to be able to control
them.  The case of the reverse engineering the heuristics we end up in a
less sustainable situation, and in a situation where we can't cleanly
upgrade those along with missing the opportunity to warn developers in
the documentation of the cost of the choices they're making.

So, in summary, I think that designers are going to want to match
specific visualizations irrelevant of the cost of doing so.  We need to
provide a clean way for them to do that.  This is the one that I'm
proposing, but my concern is more that they have a way to explicitly
provide which visualization that they're over-optimizing for.

		--Ted

On Thu, 2011-02-03 at 22:01 -0800, Aaron J. Seigo wrote:
> 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.
> 


-------------- 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/20110204/de52b65a/attachment.sig