Hi,<div><br></div><div>As an opinion related to the topic (to appindicator or not to appindicator/to systray or not to systray):</div><div>I don't know whether this is feasible or not (in some languages it is, in others it is not), but why not support legacy tray items with custom appindicators? </div>
<div>As there is legacy systray support in the Unity top panel, I guess we know about all the GtkStatusIcon ... can't we find the menus and actions associated with them ? </div><div>There are some cases for systray apps:</div>
<div>1) The app does something on left-click, and shows a menu on right click -> in this case, the menu should be migrated to an application indicator, which has an additional item before/after the menu items for the left-click functionality.</div>
<div>2) The app has separate actions for left and righ-click -> application indicator with two items (not fully compliant to HIG, but remember, this is a fallback solution)</div><div>3) The same case as in 1), only the buttons are switched (rare case, but happens) : leftclick shows menu, right-click takes a specific action.</div>
<div><br></div><div>To visually fit, I guess it is possible to draw any icon from the "fallback tray" in monochrome, so that way it would be "sort of" consistent (as icons designed to be monochrome are far better then desaturated icons) visually, and behavior-wise too, as you could use the left-right-up-down keys to navigate in menus/switch between indicators ...</div>
<div><br></div><div>Robert</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Thu, Apr 14, 2011 at 5:21 PM, Barry Warsaw <span dir="ltr"><<a href="mailto:barry@ubuntu.com">barry@ubuntu.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Apr 14, 2011, at 09:49 AM, Scott Kitterman wrote:<br>
<br>
>Unless it's a package developed specifically for Ubuntu, it's really not a<br>
>bug in the package from an upstream perspective.  Some upstreams will choose<br>
>to support Ubuntu specific requirements and others won't.  For those that<br>
>don't, either users will lose out on functionality or we'll have to develop<br>
>and maintain Ubuntu specific patches.<br>
<br>
</div>I think this is a really important perspective to maintain, and not just in<br>
this specific case.  We want to innovate in Ubuntu and encourage apps and<br>
tools to support those Ubuntu innovations.  From an upstream's perspective<br>
though, Ubuntu is often just one of many platforms they have to support.<br>
Sometimes they'll make a special case for a particular platform (e.g. Windows<br>
or OS X), but it can be a tougher decision to support a special case of a<br>
special case (i.e. Linux -> Ubuntu).<br>
<br>
I encountered a similar situation recently with the impact of multiarch on<br>
upstream Python, an issue I'll write more about later.  But in those cases<br>
where we are innovating and encouraging upstream adoption, I think we need to<br>
do more to better communicate those changes, and provide longer periods of<br>
compatibility, or commit to developing and carrying Ubuntu specific changes<br>
for a potentially long time.  It's a difficult balance between pushing things<br>
forward and maintaining a good and consistent user experience.<br>
<br>
Cheers,<br>
<font color="#888888">-Barry<br>
</font><br>--<br>
ubuntu-devel mailing list<br>
<a href="mailto:ubuntu-devel@lists.ubuntu.com">ubuntu-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a><br>
<br></blockquote></div><br></div>