Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, 2012-02-02 at 08:27 +0100, Stijn Hoop wrote: On Wed, 01 Feb 2012 17:00:30 -0700 Adam Williamson awill...@redhat.com wrote: I realize this isn't a very constructive mail, and the point has been raised before, but I'm hoping at some point the sheer weight of complaints will cause someone more creative than myself to actually come up with a notification system for GNOME 3 which satisfies the GNOME design team and *also* does not suck. Is there a bug we can vote on? I also agree 100% with this, I rather like gnome-shell except for this 'notification system'. I don't think voting is appropriate (FOSS is not a democracy but a meritocracy). The GNOME designers can be contacted in #gnome-design though, and they tend to listen to people presenting them constructive criticism or politely suggesting alternatives. You might want to get familiar with the goals of the notification system as designed first, so that you can suggest alternatives that actually solve the desired issues: https://live.gnome.org/GnomeShell/Design/#Notifications_and_messaging_tray https://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray http://blogs.gnome.org/mccann/2009/07/05/getting-the-message/ -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 05:26 +0100, Kevin Kofler wrote: Matthew Garrett wrote: Because it is the job of people who are proposing a spec to answer the objections of the people who perform critical analysis of the spec They did answer. You just didn't like their answer. Their answer was basically this is by design, there's no way this is gonna change. To which then it is a bad fit for us and we won't implement it is a perfectly fine reaction. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 17:00 -0700, Adam Williamson wrote: Yay cross-desktop maybe, but still a freaking disaster from a UI point of view, and the only thing I really dislike about GNOME 3 I don't think it's that bad, but that might just be me having different use patterns (for instance a common complain is that the message tray interferes with the active area of maximized terminals/xchat windows - I hardly ever maximize those windows, and didn't do so either in GNOME 2). I'm sure that a solution which addresses your issues without compromising on the design goals will be adopted in a heartbeat - feel free to get in contact with the gnome designers to provide constructive feedback (and no, you don't have to be creative to do that - that's their job after all ;-) Of course the implementation detail of which DBus protocol applications use to interact with the tray (Notify or NotifierIcon) is completely irrelevant for those UI problems - if it sucks for you now, implementing status notifiers in the message tray would suck just as badly. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 01:28 +0100, Kevin Kofler wrote: Florian Müllner wrote: No, but it would require that circle is drawn as circle and not a square (or just discarded without notice). The NotifyIcon spec explicitly allows either absurdity. If your icon theme thinks a square is a good way to represent the concept of a circle, I was talking about a supposed property called circle, not a property themedIcon with a value of circle. The spec actually contains language like this (quoting from memory, as the link to the draft on freedesktop.org is dead): Tooltip: a descriptive string which the implementation will display as a tooltip, or any other way it seems fit, or not at all Hint: if you don't want applications to assume a certain representation, you don't use element names which imply a representation. So rather than the example above, you should have used language like: Description: a string providing optional details about the item; implementations are free to not use the information, so applications MUST NOT rely on it But if you provide an element OverlayIcon, it'd be better rendered as overlayed icon and not as dancing penguins. Regards, Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 00:44 +0100, Kevin Kofler wrote: So the argument that you're refusing to implement a cross-desktop protocol in order to ban random applications from adding themselves to the panel is bogus. Nobody said that. Florian Müllner did: Not really. We didn't implement it because: - the spec is bad - it is a bad fit for the experience we want | You are right about requiring a Javascript extension to add items to the | top panel, but you are wrong about the reasoning - it is not because the | system tray looked out of place (which it does, but it is nevertheless | still supported in the message tray), but rather because the top panel | is considered system space, which means that we do not want random | applications to add anything to it. Or in other words: there is no system tray in the top bar. There are exactly two places applications can hook into: the application menu and the message tray. Extensions may be used to hack the designed user experience, which includes adding stuff to the top bar. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 01:16 +0100, Kevin Kofler wrote: Then your implementation in gnome-shell would just be half-assed and crappy, just like your implementation of the XEmbed-based spec is. Unlike the XEmbed-based spec, the status notifier spec actually allows apps to specify whether their icon is active or not, and a good implementation will show it in the panel if it is active and hide it behind a popup if it is not. I actually agree to that - if we used the notifier spec in the top bar, we would either compromise on the intended experience, or provide a crappy implementation. Or in other words: the spec is a poor fit for what we try to achieve, so it makes sense to not use it. Except that this feature only works that way in GNOME and nowhere else. It also makes some strong assumptions on how the message tray looks, which is exactly what the status notifier spec tries hard to avoid. I disagree that it implies how the message tray looks, but it does make strong assumption on its behavior - plus it allows applications to test for every optional capability to adjust its behavior to the environment it's run in. Apparently you think this is a bad thing - fine, don't implement it. But then don't bully us into implementing a spec which *we* consider bad because it avoids any such guarantees (not by mistake, but by design as you will agree) Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On 02/01/2012 01:04 PM, Kevin Kofler wrote: Matthias Clasen wrote: After the fruitless discussion on xdg-list, we decided that the spec was not going to help us in implementing the desired user experience. That's not up to you to decide. http://aseigo.blogspot.com/2008/12/free-dektop-notifications.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Let it go kevin ... I know there are a bunch of gnome happy users (and of course the devs), but there are probably less now than earlier ... A limited sample but everyone I know - all of whom were gnome users - no longer use gnome - they have all switched to either kde or xfce (each with its own issues to be sure). gnome may just kill itself off ... leave it in peace to die or grow in a direction that people will follow. So then the only question that remains is how those useful gnome apps will integrate on the popular DE's ... Market pressure will ensure that useful apps play nice on the dominant DE's ... whether its gnome or something else. so ... don't worry about it ... the market will dictate the right outcome ... :-) I think you might be consider working with app developers / library integrators instead on how to make their apps integrate better ... thunderbird for example could use a little help better integrating with kde desktop. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Feb 02, 2012 at 05:26:15AM +0100, Kevin Kofler wrote: Matthew Garrett wrote: Because it is the job of people who are proposing a spec to answer the objections of the people who perform critical analysis of the spec They did answer. You just didn't like their answer. The answer still resulted in a spec that permitted compliant implementations to have no practical interoperability. You can't force people to adopt a spec if they think it's a bad spec. Move on with life. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Dan Winship wrote: http://aseigo.blogspot.com/2008/12/free-dektop-notifications.html That's not a fair comparison: * The KDE Plasma Workspace actually *implements* the Galago (notification) spec now (and has done so for a while), as does Unity. KDE actually *cares* about interoperability with non-KDE software. (KDE has had its own KNotify protocol for years. The new protocol was needed *only* for interoperability with non-KDE software.) * According to that very link, it was Canonical who started the efforts on improving the spec and KDE who joined them as soon as they learned of them. In other words, the projects who objected to the spec as written were the ones who did the work on improving it! Neither Canonical nor KDE just demanded that GNOME made some arbitrary changes as a precondition to even discussing adoption of the spec any further (as YOU personally did for the status notifier spec). KDE's (and Canonical's) behavior for the Galago spec was productive, cooperative and seriously aiming at implementing it as soon as possible. GNOME's behavior for the status notifier spec was the exact opposite. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: I actually agree to that - if we used the notifier spec in the top bar, we would either compromise on the intended experience, or provide a crappy implementation. Or in other words: the spec is a poor fit for what we try to achieve, so it makes sense to not use it. How is the current experience any better? Both kdelibs and libappindicator fall back to the legacy XEmbed system tray spec if the desktop does not implement the status notifier spec, so the icons will not only be hidden (due to your bad UI design), but also look crappy. (The status notifier spec was written for a reason, XEmbed is just a horrible way to implement this feature.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On 2 February 2012 12:12, Kevin Kofler kevin.kof...@chello.at wrote: Stijn Hoop wrote: Is there a bug we can vote on? I also agree 100% with this, I rather like gnome-shell except for this 'notification system'. You seriously still think that GNOME will listen to its users??? You gotta be kidding! At some point this conversation went pear shaped in usefulness. Comments like this are not going to make it better. Let us all stop posting now and stop trying to one-up, be the last responder. Thank you Stephen -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, 2012-02-02 at 20:12 +0100, Kevin Kofler wrote: Stijn Hoop wrote: Is there a bug we can vote on? I also agree 100% with this, I rather like gnome-shell except for this 'notification system'. You seriously still think that GNOME will listen to its users??? You gotta be kidding! That one *is* trolling, Kevin. You're hitting the point of diminishing returns. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: I was talking about a supposed property called circle, not a property themedIcon with a value of circle. The spec actually contains language like this (quoting from memory, as the link to the draft on freedesktop.org is dead): Tooltip: a descriptive string which the implementation will display as a tooltip, or any other way it seems fit, or not at all Hint: if you don't want applications to assume a certain representation, you don't use element names which imply a representation. So rather than the example above, you should have used language like: Description: a string providing optional details about the item; implementations are free to not use the information, so applications MUST NOT rely on it But if you provide an element OverlayIcon, it'd be better rendered as overlayed icon and not as dancing penguins. The naming is such that it makes sense for a traditional system tray, but there can be other ways to visualize things (just as your message tray, the Plasma notifier and the traditional passive popups are very different ways to visualize the Galago notifications), so why should the spec preclude that? And the thing is, renaming Tooltip to Description will break all the existing implementations and provide no benefit whatsoever to the end user. It's just an internal identifier the user will never see. For all I care it could be called Charlie or Linus, as long as the spec says what it means. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthew Garrett wrote: The answer still resulted in a spec that permitted compliant implementations to have no practical interoperability. You keep repeating that, yet I still don't see ANYTHING backing that assertion. Interoperability depends only on the protocol (which is clearly specified), not on the visualization (which is not). You can't force people to adopt a spec if they think it's a bad spec. Not always true. See e.g. Samba. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 20:11 +0100, Kevin Kofler wrote: Florian Müllner wrote: I actually agree to that - if we used the notifier spec in the top bar, we would either compromise on the intended experience, or provide a crappy implementation. Or in other words: the spec is a poor fit for what we try to achieve, so it makes sense to not use it. How is the current experience any better? [...] XEmbed is just a horrible way to implement this feature. It is not implemented with XEmbed. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 20:17 +0100, Kevin Kofler wrote: And the thing is, renaming Tooltip to Description will break all the existing implementations and provide no benefit whatsoever to the end user. It's just an internal identifier the user will never see. For all I care it could be called Charlie or Linus, as long as the spec says what it means. It may be this, or that, or nothing at all is an odd definition of saying what it means. Especially if the name already has a particular meaning (which the spec has to *undefine* to allow alternative visualizations). Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Feb 2, 2012 at 8:19 PM, Kevin Kofler kevin.kof...@chello.at wrote: Matthew Garrett wrote: The answer still resulted in a spec that permitted compliant implementations to have no practical interoperability. You keep repeating that, yet I still don't see ANYTHING backing that assertion. Interoperability depends only on the protocol (which is clearly specified), not on the visualization (which is not). You can't force people to adopt a spec if they think it's a bad spec. Not always true. See e.g. Samba. Sorry but that's nonsense. Nobody was *forced* to implement samba. By whom? You might dislike samba (or the protocols it implements) but that does not mean that people where forced to implement it, they just did see value in doing so so they did it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Feb 02, 2012 at 08:19:44PM +0100, Kevin Kofler wrote: Matthew Garrett wrote: The answer still resulted in a spec that permitted compliant implementations to have no practical interoperability. You keep repeating that, yet I still don't see ANYTHING backing that assertion. Interoperability depends only on the protocol (which is clearly specified), not on the visualization (which is not). Ok. I can't guarantee that an OverlayIcon will be rendered. So since I can't rely on it, I can never use it to provide important information. And since the point of this specification is to provide information to the user, that means that the OverlayIconName field is effectively useless. If I do render an OverlayIconName and also pass a window ID, it's valid for clicking the icon to raise my application - but it's also valid for it to destroy my window and kill my connection to the server. I'm willing to bet actual, real money that there are applications currently using this specification that would be massively unusable under perfectly compliant implementations of this specification. But rather than have that discussion, the spec proposers simply asserted that the complete absence of any behavioural guarantees regarding visualisation was a feature. That's a pretty fundamental disagreement, and if that disagreement can't be overcome then you can't expect the spec to be adopted. You can't force people to adopt a spec if they think it's a bad spec. Not always true. See e.g. Samba. Samba is a project written specifically to interoperate with Windows, because the developers involved felt that interoperability was more important than the flaws in the SMB spec (to the extent that any such thing existed). Nobody forced them to do that. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On 02/03/2012 12:42 AM, Kevin Kofler wrote: Stijn Hoop wrote: Is there a bug we can vote on? I also agree 100% with this, I rather like gnome-shell except for this 'notification system'. You seriously still think that GNOME will listen to its users??? You gotta be kidding! You are not helping yourself at this point. You should stop now and let this go since you aren't persuading anyone. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: It is not implemented with XEmbed. If the user runs non-GNOME software which tries to bring up a system tray icon, it is. The icon will not only be hidden in your legacy compatibility grace popup, but also be rendered using XEmbed. As I explained, both kdelibs and libappindicator fall back to XEmbed if status notifier is not supported. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthew Garrett wrote: Samba is a project written specifically to interoperate with Windows, because the developers involved felt that interoperability was more important than the flaws in the SMB spec (to the extent that any such thing existed). My point is that interoperability between the Free desktops is more important than the flaws in any of the specs involved! Our applications are all going to run on the same machines, so we should strife for an integrated experience rather than gratuitous incompatibilities due to differences of opinion on the letter of a spec. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Feb 02, 2012 at 10:04:03PM +0100, Kevin Kofler wrote: Matthew Garrett wrote: Samba is a project written specifically to interoperate with Windows, because the developers involved felt that interoperability was more important than the flaws in the SMB spec (to the extent that any such thing existed). My point is that interoperability between the Free desktops is more important than the flaws in any of the specs involved! Our applications are all going to run on the same machines, so we should strife for an integrated experience rather than gratuitous incompatibilities due to differences of opinion on the letter of a spec. And the people working on Gnome feel that adopting a bad specification would cost more than enhancing this interoperability would provide. You can't force them to feel otherwise, so your options are either to modify the spec in such a way that everyone's happy or to just get on with the rest of your life. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Feb 2, 2012 at 9:59 PM, Kevin Kofler kevin.kof...@chello.at wrote: Florian Müllner wrote: It is not implemented with XEmbed. If the user runs non-GNOME software which tries to bring up a system tray icon, it is. The discussion was about GNOME shell's top bar. No application (GNOME, KDE, Unity or whatever) can add anything there (using XEmbed, NotifierIcon, libnotify or whatever). Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthew Garrett wrote: And the people working on Gnome feel that adopting a bad specification would cost more than enhancing this interoperability would provide. And that's exactly my complaint: GNOME doesn't give a darn about compatibility with other desktops and isn't willing to make ANY sacrifices for compatibility. ALL the recent work on interoperability came from the KDE camp (and/or, more recently, from Canonical). As a striking example, BOTH the Qt theme to look like GTK+ (QGtkStyle) and the GTK+ themes to look like Qt/KDE (gtk-qt-engine, oxygen-gtk etc.) come from the Qt/KDE camp, GNOME developers don't care at all about interoperability in either direction. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: The discussion was about GNOME shell's top bar. No application (GNOME, KDE, Unity or whatever) can add anything there (using XEmbed, NotifierIcon, libnotify or whatever). That's exactly the source of the complaint: Only stuff hardcoded inside gnome-shell (or written as a gnome-shell extension) can get the intended rendering, everything else (in particular, everything non-GNOME) is treated as a second-class citizen and filed into a trash drawer hidden most of the time. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: [0] http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html KDE might actually adopt dconf for KDE Frameworks 5, though this seems to be still under discussion: http://community.kde.org/KDE_Core/Platform_11/Settings Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Sat, 2012-01-28 at 00:03 +0100, Kevin Kofler wrote: Adam Williamson wrote: As far as I'm aware, Canonical were reasonably good about proposing the libindicator patches for upstream inclusion, but many upstream projects - especially those that are part of GNOME - weren't exactly rushing to adopt the patches. I think Canonical did try to implement libindicator support as a plugin for apps with sufficently sophisticated plugin frameworks, which obviously helps. That's really GNOME's fault. :-( Canonical explicitly designed libappindicator (which is the library applications are expected to use, it uses libindicator behind the scenes; there's also libindicate which is for communication apps to notify new messages and such, confusing, isn't it?) to be interoperable with KDE's status notifier spec, and thus applications supporting libappindicator will also integrate better into the KDE Plasma workspaces than applications still stuck on the legacy XEmbed-based system tray protocol and/or using a GNOME-only gnome-shell extension. But GNOME is giving the finger to cross-desktop protocols and refusing to implement them. GNOME never gave an opinion on the spec, we gave an opinion on the library, which was really just a huge pile of bugs (I know, they patched a bunch of the applications I maintain, and I get to receive a large number of crashers because of it). It's too bad that our maintainers for the affected packages are often one and the same as the GNOME maintainers and thus Fedora is mostly siding with GNOME on this and refusing to carry those patches, hurting all non-GNOME desktops, not just Unity. I refuse to carry the patches because libappindicator is far too buggy to be widely deployed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Bastien Nocera wrote: GNOME never gave an opinion on the spec, we gave an opinion on the library, which was really just a huge pile of bugs (I know, they patched a bunch of the applications I maintain, and I get to receive a large number of crashers because of it). But I don't see any movement from the GNOME side on developing a less buggy library implementing the spec nor on fixing the bugs in libappindicator, so GNOME is ignoring the spec. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: I can not comment on the quality of the library, but GNOME did comment on the spec[0] (or rather: several gnomers did) - there were a couple of objections, none of which have been addressed in the spec as far as I can tell. The objections weren't addressed because they objected to the very point of the spec, making it impossible to address them without defeating the purpose of the spec. One main design goal of the spec was that it should NOT be the app's job to decide how exactly the icon will look, but the shell's. And it makes sense: Look at how gnome-shell deprecated the system tray entirely because it looked totally out of place there, and is forcing everyone who wants an icon in the panel to implement a GNOME-specific shell extension in JavaScript. Yet Plasma can deliver the same integrated look (supplying its own monochrome icons and displaying its own Plasma-themed menus) for system tray icons using the new status notifier spec (and the D-Bus menu spec for the menus, though the status notifier spec predates the D-Bus menu spec and thus also allows for displaying the menu in process). How would you be able to adjust the presentation to the shell's design if the app tells you that it wants some overlay placed at offset (5,7) of the icon as Dan Winship requested?! Such a request just makes no sense whatsoever because the app doesn't (and shouldn't!) even know how the icon and the overlay look like! Offset (5,7) may work great with the desktop shell and theme you tested with, but cover the most important part of the icon elsewhere! Yet when Aaron Seigo and Marco Martin explained exactly that, the discussion just dried off and GNOME decided to ignore the spec, when actually its design would also make status notifiers much more useful for gnome-shell than the XEmbed junk. The status notifier spec was started by KDE and adopted by Canonical, it was the opposite for the D-Bus menu spec. In both cases, KDE/Plasma and Canonical/Unity cooperate nicely, only GNOME keeps doing its own, incompatible thing. Cross-desktop status notifiers and native Plasma widgets (plasmoids) can sit right next to each other in the Plasma system tray and look and feel the same, why can't gnome-shell offer the same integrated experience rather than deprecating everything other than gnome-shell-only extensions? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wed, 2012-02-01 at 18:03 +0100, Kevin Kofler wrote: Bastien Nocera wrote: GNOME never gave an opinion on the spec, we gave an opinion on the library, which was really just a huge pile of bugs (I know, they patched a bunch of the applications I maintain, and I get to receive a large number of crashers because of it). But I don't see any movement from the GNOME side on developing a less buggy library implementing the spec nor on fixing the bugs in libappindicator, so GNOME is ignoring the spec. After the fruitless discussion on xdg-list, we decided that the spec was not going to help us in implementing the desired user experience. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthias Clasen wrote: After the fruitless discussion on xdg-list, we decided that the spec was not going to help us in implementing the desired user experience. That's not up to you to decide. The spec is a cross-desktop spec already implemented by KDE Plasma and Unity. Sometimes you have to interoperate even with a protocol you don't like! Do you think SMB/CIFS is a great protocol? Yet we have Samba, and for a good reason! Interoperability doesn't always mean YOUR spec will be the one getting adopted by everyone. (That's exactly the frustrating thing about GNOME's current approach to interoperability: They always want to force THEIR standards onto everyone. And that's when they even remember other desktop environments exist in the first place.) I have also explained in my reply to Florian why the discussion on the XDG list was fruitless and why that spec would actually HELP implement the desired user experience in gnome-shell, if you were open to cross-desktop protocols instead of forcing the native GJS extensions only dogma. And independently of what gnome-shell supports, your applications will also run on plenty of non-GNOME workspaces (KDE Plasma, Unity, Xfce, LXDE, proprietary operating systems; and yes, users WILL run them on all those platforms), so supporting only what gnome-shell supports does a disservice to your users. At least Plasma and Unity users would benefit from you adopting libappindicator in your applications; for the other platforms, it will either also help or just not make a difference. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Sat, 2012-01-28 at 00:03 +0100, Kevin Kofler wrote: That's really GNOME's fault. :-( Canonical explicitly designed libappindicator (which is the library applications are expected to use, it uses libindicator behind the scenes; there's also libindicate which is for communication apps to notify new messages and such, confusing, isn't it?) to be interoperable with KDE's status notifier spec, and thus applications supporting libappindicator will also integrate better into the KDE Plasma workspaces than applications still stuck on the legacy XEmbed-based system tray protocol and/or using a GNOME-only gnome-shell extension. But GNOME is giving the finger to cross-desktop protocols and refusing to implement them. It's too bad that our maintainers for the affected packages are often one and the same as the GNOME maintainers and thus Fedora is mostly siding with GNOME on this and refusing to carry those patches, hurting all non-GNOME desktops, not just Unity. Kevin, I am not going to comment on the incendiary language here (I know you are pretty tone-deaf in email). But to blame us for not embracing a spec after our comments on it were completely ignored seems a little unfair, to say the least. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 18:25 +0100, Kevin Kofler wrote: The objections weren't addressed because they objected to the very point of the spec, making it impossible to address them without defeating the purpose of the spec. One main design goal of the spec was that it should NOT be the app's job to decide how exactly the icon will look, but the shell's. I don't think anyone made an argument for letting apps decide how exactly the icon will look (which is basically what XEmbed does, and everyone agrees that it's crap), but rather to avoid the other extreme of giving the shell complete power of what to display (and even whether to display anything at all). As is, applications can only hope that the shell will use enough of the data it provides to convey the information as intended, but there are no guarantees or ways to query the shell's capabilities. But I don't want to reopen that xdg discussion; I just wanted to clarify that GNOME did not ignore the spec, but refused to adopt it because it was deemed insufficient. We'll have to agree to disagree on whether the reasons brought forward justify the non-adoption. I have no problem with your opinion that the NotifierIcon spec is a good spec, but I do take issue on blaming GNOME for not adopting a spec we consider bad - after all, enforcing adoption of technology is not what freedesktop.org is supposed to be about[0] ;-) And it makes sense: Look at how gnome-shell deprecated the system tray entirely because it looked totally out of place there, and is forcing everyone who wants an icon in the panel to implement a GNOME-specific shell extension in JavaScript. You are right about requiring a Javascript extension to add items to the top panel, but you are wrong about the reasoning - it is not because the system tray looked out of place (which it does, but it is nevertheless still supported in the message tray), but rather because the top panel is considered system space, which means that we do not *want* random applications to add anything to it. So even if we had adopted NotifierIcons for the top bar (which was considered), it would still have been reserved for a small set of processes (mostly gnome-settings-daemon). Given that design restriction, it becomes very much irrelevant whether the implementation uses cross-desktop technology or not. Cross-desktop status notifiers and native Plasma widgets (plasmoids) can sit right next to each other in the Plasma system tray and look and feel the same, why can't gnome-shell offer the same integrated experience rather than deprecating everything other than gnome-shell-only extensions? Because the integrated experience means that there is a fixed set of system items with a defined order. Extensions can be used to hack the intended experience (which includes adding non-official icons in the top bar), but it's nothing we want normal applications to do. Applications are encouraged to interact with the message tray (== the autohiding bottom panel) via freedesktop notifications (yay, cross-desktop! ;-) Florian [0] http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wed, Feb 01, 2012 at 06:25:05PM +0100, Kevin Kofler wrote: The objections weren't addressed because they objected to the very point of the spec, making it impossible to address them without defeating the purpose of the spec. A spec that allows two conformant implementations to differ to such a degree that it's impossible for an application to work sensibly in both implementations is a *bad* *spec*. The only argument anyone had against that was Oh, nobody would implement the spec in that way, which is another huge blaring warning that it's a bad spec. There was a simple and straightforward way of handling this, which was to rewrite the problematic parts of the specification in order to constrain implementations. But nobody bothered, and so it continues to be a bad spec. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 22:18 +0100, Kevin Kofler wrote: So the argument that you're refusing to implement a cross-desktop protocol in order to ban random applications from adding themselves to the panel is bogus. No, the argument for refusing to implement the protocol is that the spec is bad. I was merely pointing out that *if* we used the protocol in the top bar, it would have been as an implementation detail with no benefit to applications (e.g. no way for applications to provide options to override that behavior as you imply) Because the integrated experience means that there is a fixed set of system items with a defined order. Including a bluetooth icon on a machine which does not even have bluetooth hardware? This is just beyond silly! *sigh* You are trolling. Notification messages and status notifier icons are totally independent concepts with totally different use cases and totally different practical uses. They are separate protocols for a reason. Notifications (also called passive popups) are for one-off messages you want to show to the user to inform them of something transient. Status notifiers are for status icons the user wants to permanently keep an eye on, such as network connectivity (which in fact you do realize needs a status icon, or you wouldn't have hardcoded it in your shell). Except that applications can set a 'resident' hint on notifications, in which case a representive icon is kept in the message tray, from which the notification can be recalled; together with the ability to provide actions on notifications, the experience is not different from status icons. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthew Garrett wrote: A spec that allows two conformant implementations to differ to such a degree that it's impossible for an application to work sensibly in both implementations is a *bad* *spec*. The only argument anyone had against that was Oh, nobody would implement the spec in that way, which is another huge blaring warning that it's a bad spec. There was a simple and straightforward way of handling this, which was to rewrite the problematic parts of the specification in order to constrain implementations. But nobody bothered, and so it continues to be a bad spec. It's not a bad spec, it's a future-safe spec! It does not make sense to specify things which do not NEED to be specified. It needlessly constrains future implementations which may be (and possibly NEED to be) totally different. The spec cannot mandate that some action makes the icon blink because that assumes that there's an icon in the first place and that the hardware allows making it blink. What about non-visual representations, e.g. for users who cannot see those small icons for whatever reason, and/or on hardware which doesn't even have a display in the first place? (That example was brought up by the KDE developers in the XDG thread.) It's not the spec's business to make your shell not suck, it's the shell developers' business! And why do we have to specify common sense? It was obvious to everyone involved that the bad implementation would be bad. Are you going to require a spec on drawing circles to specify that the circumference of the circle must be between 355/113-2^-21 and 355/113 times its diameter? ^^ Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
drago01 wrote: On Wed, Feb 1, 2012 at 10:18 PM, Kevin Kofler kevin.kof...@chello.at wrote: Florian Müllner wrote: I don't think anyone made an argument for letting apps decide how exactly the icon will look (which is basically what XEmbed does, and everyone agrees that it's crap), but rather to avoid the other extreme of giving the shell complete power of what to display (and even whether to display anything at all). As is, applications can only hope that the shell will use enough of the data it provides to convey the information as intended, Thus the shell should do that. How hard can it be? If that is the intend of the spec then why not explicitly state it in there? Instead of having some unwritten rules that app authors depend on. To reuse your words how hard can that be? What is the point of specifying that the shell [shall] use enough of the data [the application] provides to convey the information as intended? It's obvious! (And it's all that CAN be specified, since the goal of the spec is explicitly NOT to specify HOW that data shall be displayed.) Well because the app provides an interface to the user and it has to somehow be able to know what the user actually sees. Why does the app need to worry whether the user will see an icon with the locked overlay located in the bottom-right corner, in the top-left corner, monochromatic and translucent over the entire icon, located next to the icon in a vertical list, or even something completely different from an overlay icon but still conveying the concept of being locked? It's the workspace shell's business, not the app's business. Lets say your app opens a dialog and the window manager is free to just not display it. Does that make any sense? Yet that's exactly what happens if you use the notification (message) spec GNOME wants apps to use instead of the status notifier spec. Your notification might get completely silenced. And FWIW, sometimes that's actually what the user WANTS. Plasma also allows the user to forcefully hide status notifier icons (they will show up in a popup you can open through an arrow next to the system tray instead of the system tray itself) even when the icon actually wants to be shown. (There are 3 options: automatic, i.e. do what the app wants, obviously the default; always shown; always hidden.) It's part of empowering the user (a concept GNOME is missing completely, sadly). So the argument that you're refusing to implement a cross-desktop protocol in order to ban random applications from adding themselves to the panel is bogus. Nobody said that. Florian Müllner did: | You are right about requiring a Javascript extension to add items to the | top panel, but you are wrong about the reasoning - it is not because the | system tray looked out of place (which it does, but it is nevertheless | still supported in the message tray), but rather because the top panel | is considered system space, which means that we do not want random | applications to add anything to it. So even if we had adopted | NotifierIcons for the top bar (which was considered), it would still | have been reserved for a small set of processes (mostly | gnome-settings-daemon). Given that design restriction, it becomes very | much irrelevant whether the implementation uses cross-desktop technology | or not. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On 2012-02-01 14:49, Florian Müllner wrote: Except that applications can set a 'resident' hint on notifications, in which case a representive icon is kept in the message tray, from which the notification can be recalled; together with the ability to provide actions on notifications, the experience is not different from status icons. Not different...except that you can't see or interact with the icon in question unless you perform a distractive action (move your mouse to bottom-right corner or trigger the overview). Doesn't exactly fit in with the 'distraction-free computing' idea if you have to cycle through the overview every five minutes to check if a notification icon changed while you weren't paying attention. The whole GNOME 3 notification area is something of a bizarre netherland: there doesn't seem any logic to its existence. Unlike traditional notification areas it's not tethered to a panel, a concept users generally understand. It's just this kind of ethereal (non-)presence which sort of reserves the bottom right hand corner of your screen (and hence, really, the entire bottom portion of it, since if you try to interact with anything there you'll forever be triggering the notification area accidentally) but sort of doesn't, because it's not always visible. It's an odd bit of UI altogether. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: No, the argument for refusing to implement the protocol is that the spec is bad. I was merely pointing out that *if* we used the protocol in the top bar, it would have been as an implementation detail with no benefit to applications (e.g. no way for applications to provide options to override that behavior as you imply) Then your implementation in gnome-shell would just be half-assed and crappy, just like your implementation of the XEmbed-based spec is. Unlike the XEmbed-based spec, the status notifier spec actually allows apps to specify whether their icon is active or not, and a good implementation will show it in the panel if it is active and hide it behind a popup if it is not. (That's exactly what Plasma does.) You have both an area in the panel where the icon could be shown (themed to look the same as the icons which are already there, that's exactly why the spec allows the shell to theme the icons!) and a popup where it could be shelved in when inactive. Now the spec does allow you (by design) to decide you know better and always hide the icon behind the popup, it would just be lame, but apps would still be no worse off than now, where they automatically fall back to the old XEmbed- based spec, to which you give the same treatment. But in any case, that doesn't address the issue of GNOME application developers rejecting patches to support the spec in their applications, which was the issue that started this subthread. GNOME applications aren't only used on gnome-shell. On mié, 2012-02-01 at 22:18 +0100, Kevin Kofler wrote: Including a bluetooth icon on a machine which does not even have bluetooth hardware? This is just beyond silly! *sigh* You are trolling. How is that trolling? Some icons are just useless in some situations. (And even if you can autodetect whether a bluetooth controller is present, you still cannot know whether the user actually owns anything it can pair with, so that is not a solution either.) There's also the accessibility icon which will be totally useless for most users. Why does it take third-party extensions to get rid of those useless icons? It just doesn't make sense. Except that applications can set a 'resident' hint on notifications, in which case a representive icon is kept in the message tray, from which the notification can be recalled; together with the ability to provide actions on notifications, the experience is not different from status icons. Except that this feature only works that way in GNOME and nowhere else. It also makes some strong assumptions on how the message tray looks, which is exactly what the status notifier spec tries hard to avoid. There is no place in the Plasma notifier where one would put an icon (in fact, the Plasma notifier IS an icon in the system tray, and the notifications pile up in the icon's popup). There is support for persistent notifications, but they are really persistent, i.e. they keep showing (as notifications) until you click them away. To my knowledge, no non-GNOME desktop implements the resident notifications you describe. And it's still a different concept from the status notifier icons, even if it might be possible to abuse it to work approximately the same way. If it were the same concept, why implement a different incompatible spec rather than the one at least 2 other desktop environments implement? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: No, but it would require that circle is drawn as circle and not a square (or just discarded without notice). The NotifyIcon spec explicitly allows either absurdity. If your icon theme thinks a square is a good way to represent the concept of a circle, that's an issue you need to take up with your icon theme author. ;-D The fact that if you ask for an icon named circle, you should get a visualization which conveys the concept of a circle (whether it is really an *icon* or something else, as long as it clearly conveys the *concept*) is both obvious and outside of the scope of the spec. As for just discarding the icon without notice, that necessarily has to be allowed because the USER could have asked for that. The user could even have deleted the system tray widget entirely, or placed it somewhere hidden. (Outside of the GNOME world, software tends to actually listen to its users!) Now if the implementation ALWAYS just discards the icon and ignores both the application's and the user's requests, that would indeed suck as an implementation, but again, that's obvious! (Why would you implement the spec in the first place if you discard all the data you get? OF COURSE you're expected to provide the data to the user one way or the other unless the user explicitly asked you not to.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthew Garrett wrote: I'm on multiple spec bodies. If someone proposed an ammendment that allowed two conforming implementations to be entirely incompatible, and then argued that this was future proofing, they'd be laughed at. The constraints actually relevant for compatibility are all specified very clearly! E.g., there are some D-Bus methods, there is a string which takes an icon name etc. Your implementation can look entirely different (that's the point!), but it will still be COMPATIBLE. And why do we have to specify common sense? It was obvious to everyone involved that the bad implementation would be bad. Are you going to require a spec on drawing circles to specify that the circumference of the circle must be between 355/113-2^-21 and 355/113 times its diameter? ^^ The purpose of a spec is to *ensure* interoperability between different implementations. Any spec that relies on common sense is a bad spec. So you WOULD specify the value of pi in your spec?! ^^ And the spec as is DOES ensure interoperability. It does not ensure visual uniformity, by design. (Neither does the message-based notification spec GNOME implements and recommends, by the way. The GNOME 3 message tray, the Plasma notifier and the more traditional passive popup implementations used elsewhere all implement the notification spec, yet look VERY different.) And finally, even if the spec really were as badly written as you claim, it would still be very much possible to interoperate with the actual implementations. Samba was written without any spec at all, and unlike Samba you even have the source code of the applications and workspaces you'd interoperate with. So the quality of the spec is a very poor argument for not being interoperable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Feb 02, 2012 at 01:51:55AM +0100, Kevin Kofler wrote: Matthew Garrett wrote: I'm on multiple spec bodies. If someone proposed an ammendment that allowed two conforming implementations to be entirely incompatible, and then argued that this was future proofing, they'd be laughed at. The constraints actually relevant for compatibility are all specified very clearly! E.g., there are some D-Bus methods, there is a string which takes an icon name etc. Your implementation can look entirely different (that's the point!), but it will still be COMPATIBLE. It can be completely unusable. There's no way to design an application that will work with all valid implementations. The purpose of a spec is to *ensure* interoperability between different implementations. Any spec that relies on common sense is a bad spec. So you WOULD specify the value of pi in your spec?! ^^ No, because it's adequately specified elsewhere. A correct implementation of this spec isn't. And the spec as is DOES ensure interoperability. It does not ensure visual uniformity, by design. (Neither does the message-based notification spec GNOME implements and recommends, by the way. The GNOME 3 message tray, the Plasma notifier and the more traditional passive popup implementations used elsewhere all implement the notification spec, yet look VERY different.) Yes, but it's not about visual uniformity. It's about ensuring that information is presented. And finally, even if the spec really were as badly written as you claim, it would still be very much possible to interoperate with the actual implementations. Samba was written without any spec at all, and unlike Samba you even have the source code of the applications and workspaces you'd interoperate with. So the quality of the spec is a very poor argument for not being interoperable. If the point is interoperability then just propose a version of the spec that actually guarantees useful interoperability. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthew Garrett wrote: It can be completely unusable. There's no way to design an application that will work with all valid implementations. Sure there is. Just provide the data and let the implementation worry about how it is displayed. Yes, but it's not about visual uniformity. It's about ensuring that information is presented. The fact that the information is provided to be presented and not ignored is blatantly obvious to everyone other than you, the GNOME developers. If the point is interoperability then just propose a version of the spec that actually guarantees useful interoperability. If you think the version as written does not guarantee interoperability, why don't YOU propose a version which you think does? Canonical had no problems implementing KDE's spec as is. You are the ones who think it's poorly written. (Of course, the modified spec should still be compatible with the existing implementations and should still comply with the non-goal of enforcing visual uniformity! The changes GNOME demanded on the XDG list failed on both counts.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Feb 02, 2012 at 02:21:01AM +0100, Kevin Kofler wrote: If you think the version as written does not guarantee interoperability, why don't YOU propose a version which you think does? Because it is the job of people who are proposing a spec to answer the objections of the people who perform critical analysis of the spec. It's not Gnome's job to write a specification for something that KDE wants. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On 02/01/2012 05:00 PM, Adam Williamson wrote: On 2012-02-01 11:39, Florian Müllner wrote: Because the integrated experience means that there is a fixed set of system items with a defined order. Extensions can be used to hack the intended experience (which includes adding non-official icons in the top bar), but it's nothing we want normal applications to do. Applications are encouraged to interact with the message tray (== the autohiding bottom panel) via freedesktop notifications (yay, cross-desktop! ;-) Yay cross-desktop maybe, but still a freaking disaster from a UI point of view, and the only thing I really dislike about GNOME 3 (when I was forced to drop to Xfce for a couple of days last week, the old-school notifications were the only things I preferred). That sometimes-hidden, erratically-triggered notification area *never* seems to do what I actually want it to do. It shows up when I don't want it, it doesn't show up when there's something on it I probably actually needed to see, the icons on it fly around like space invaders and take two or hree clicks to get rid of, transmission 'torrent completed' notifications stack to the moon and back...it's just not nice. I realize this isn't a very constructive mail, and the point has been raised before, but I'm hoping at some point the sheer weight of complaints will cause someone more creative than myself to actually come up with a notification system for GNOME 3 which satisfies the GNOME design team and *also* does not suck. Me too. I can't stand that bottom corner area. I can't stand how they fly around left and right like they are dodging my mouse. Do I right click left click... some stick around forever... Seriously annoying. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthew Garrett wrote: Because it is the job of people who are proposing a spec to answer the objections of the people who perform critical analysis of the spec They did answer. You just didn't like their answer. It's the GNOME developers who stopped replying. The KDE developers were willing to clarify their spec, but not to make incompatible changes with no practical benefits (such as renaming Movie to Animation in an identifier) nor to specify rendering (which is a non-goal of the spec), up to the most minute detail even (e.g. the position of the overlay on an icon), as the GNOME developers demanded (not requested, or they wouldn't have run away when the KDE developers explained why they cannot make those changes). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wed, 01 Feb 2012 17:00:30 -0700 Adam Williamson awill...@redhat.com wrote: I realize this isn't a very constructive mail, and the point has been raised before, but I'm hoping at some point the sheer weight of complaints will cause someone more creative than myself to actually come up with a notification system for GNOME 3 which satisfies the GNOME design team and *also* does not suck. Is there a bug we can vote on? I also agree 100% with this, I rather like gnome-shell except for this 'notification system'. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
See https://bugzilla.redhat.com/show_bug.cgi?id=693233 (pkgreview for nux) for some slightly more recent status details. At the end of November I actually did some /very/ rough packaging of unity (at the time I actually wanted unity-2d but it already required unity then as was pointed out, and didn't quite get that far...) I just put the srpm's at http://petersen.fedorapeople.org/unity/ if anyone wants to try and play with them - I never actually even tried to test them! but they might save someone a bit of time rather than having to start all over again from scratch, even though they still surely need plenty of work to be properly packaged. So if someone wants to pick them up and get them ready for Fedora that would be great. (I think Hicham also did some packaging earlier last April/May: http://hicham.fedorapeople.org/unity-packaging/ but that is of course rather more out of date now.) Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
- Original Message - On Wednesday 25 January 2012 19:05:37 Manuel Escudero wrote: And also I've been told this desktop is available for ArchLinux now as well... As for this facts I was wondering how feasible is to port Unity to Fedora as well The last I heard from the Arch packaging efforts was that Unity won't be an officially supported package until it no longer depends on non-upstream patches to GTK+ and friends. The same seems to be true for OpenSuse: Since we're replacing some of the core components of openSUSE (ex: GTK+, gnome-session) the priority is important. (pasted from your link) I don't think I'm going out on a limb if I say that this doesn't look like Unity will hit Fedora repos anytime soon. You may look at repos.fedorapeople.org, though. As far as I remember Adam Williamson once looked at the feasibility of packaging Unity for Fedora. Don't know what was the result, though. Maybe he can elaborate on that. I tried Unity 2D, the QML version - it's much more easier to package for Fedora, I was nearly done but Unity then introduced a lot of new G* dependencies and I didn't want to step into our desktop lands (but I suppose the are not using these deps, so it shouldn't be a big problem). So I can try to give it another round. R. Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Fri, 2012-01-27 at 04:16 -0500, Jaroslav Reznik wrote: - Original Message - On Wednesday 25 January 2012 19:05:37 Manuel Escudero wrote: And also I've been told this desktop is available for ArchLinux now as well... As for this facts I was wondering how feasible is to port Unity to Fedora as well The last I heard from the Arch packaging efforts was that Unity won't be an officially supported package until it no longer depends on non-upstream patches to GTK+ and friends. The same seems to be true for OpenSuse: Since we're replacing some of the core components of openSUSE (ex: GTK+, gnome-session) the priority is important. (pasted from your link) I don't think I'm going out on a limb if I say that this doesn't look like Unity will hit Fedora repos anytime soon. You may look at repos.fedorapeople.org, though. As far as I remember Adam Williamson once looked at the feasibility of packaging Unity for Fedora. Don't know what was the result, though. Maybe he can elaborate on that. I tried Unity 2D, the QML version - it's much more easier to package for Fedora, I was nearly done but Unity then introduced a lot of new G* dependencies and I didn't want to step into our desktop lands (but I suppose the are not using these deps, so it shouldn't be a big problem). If it's not in Fedora, you can package it if you need it. You certainly don't need to ask the Desktop team anything (and a bunch of us have proven packager so we can help with updates, if GNOME does end up using those dependencies). So I can try to give it another round. R. Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
- Original Message - On Fri, 2012-01-27 at 04:16 -0500, Jaroslav Reznik wrote: - Original Message - On Wednesday 25 January 2012 19:05:37 Manuel Escudero wrote: And also I've been told this desktop is available for ArchLinux now as well... As for this facts I was wondering how feasible is to port Unity to Fedora as well The last I heard from the Arch packaging efforts was that Unity won't be an officially supported package until it no longer depends on non-upstream patches to GTK+ and friends. The same seems to be true for OpenSuse: Since we're replacing some of the core components of openSUSE (ex: GTK+, gnome-session) the priority is important. (pasted from your link) I don't think I'm going out on a limb if I say that this doesn't look like Unity will hit Fedora repos anytime soon. You may look at repos.fedorapeople.org, though. As far as I remember Adam Williamson once looked at the feasibility of packaging Unity for Fedora. Don't know what was the result, though. Maybe he can elaborate on that. I tried Unity 2D, the QML version - it's much more easier to package for Fedora, I was nearly done but Unity then introduced a lot of new G* dependencies and I didn't want to step into our desktop lands (but I suppose the are not using these deps, so it shouldn't be a big problem). If it's not in Fedora, you can package it if you need it. You certainly don't need to ask the Desktop team anything (and a bunch of us have proven packager so we can help with updates, if GNOME does end up using those dependencies). Yeah, I know, of course. Just heard that time that some Red Hatters/ Fedora guys ere going to work on it too. Now I'm checking the stuff again, refreshing package reviews etc. The truth is I gave it up due to completely non-distribution friendly approach in Unity upstream (aka no upstream tarballs, just Ubuntu packages...). Btw. thanks for help offer, R. So I can try to give it another round. R. Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
What's actually missing (minus the q bindings for g libs under review): * [1] https://launchpad.net/canonical-multitouch/utouch-geis * [2] https://launchpad.net/nux depends on [2] And it seems it now depends on g* Unity Core (not sure now). So even QML version packaging becomes even more complicated... R. - Original Message - - Original Message - On Fri, 2012-01-27 at 04:16 -0500, Jaroslav Reznik wrote: - Original Message - On Wednesday 25 January 2012 19:05:37 Manuel Escudero wrote: And also I've been told this desktop is available for ArchLinux now as well... As for this facts I was wondering how feasible is to port Unity to Fedora as well The last I heard from the Arch packaging efforts was that Unity won't be an officially supported package until it no longer depends on non-upstream patches to GTK+ and friends. The same seems to be true for OpenSuse: Since we're replacing some of the core components of openSUSE (ex: GTK+, gnome-session) the priority is important. (pasted from your link) I don't think I'm going out on a limb if I say that this doesn't look like Unity will hit Fedora repos anytime soon. You may look at repos.fedorapeople.org, though. As far as I remember Adam Williamson once looked at the feasibility of packaging Unity for Fedora. Don't know what was the result, though. Maybe he can elaborate on that. I tried Unity 2D, the QML version - it's much more easier to package for Fedora, I was nearly done but Unity then introduced a lot of new G* dependencies and I didn't want to step into our desktop lands (but I suppose the are not using these deps, so it shouldn't be a big problem). If it's not in Fedora, you can package it if you need it. You certainly don't need to ask the Desktop team anything (and a bunch of us have proven packager so we can help with updates, if GNOME does end up using those dependencies). Yeah, I know, of course. Just heard that time that some Red Hatters/ Fedora guys ere going to work on it too. Now I'm checking the stuff again, refreshing package reviews etc. The truth is I gave it up due to completely non-distribution friendly approach in Unity upstream (aka no upstream tarballs, just Ubuntu packages...). Btw. thanks for help offer, R. So I can try to give it another round. R. Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Fri, 2012-01-27 at 06:28 -0500, Jaroslav Reznik wrote: Yeah, I know, of course. Just heard that time that some Red Hatters/ Fedora guys ere going to work on it too. Now I'm checking the stuff again, refreshing package reviews etc. The truth is I gave it up due to completely non-distribution friendly approach in Unity upstream (aka no upstream tarballs, just Ubuntu packages...). My take - at the time I was doing it, we were actually fairly close, just got stalled on the nux package review and then I lacked time. I'm not aware of anything that would completely roadblock getting Unity in Fedora. There was no need for a variant GTK+, at least when I was looking at it (and to the best of my knowledge). The issue which required a patched glib was also resolved, I believe. The remaining area where non-upstreamed patches were 'required' wasn't really a requirement; these were patches to support Ubuntu's libindicator indicators. Unity will work without these, it's just not exactly as upstream intends the experience to be. As far as I'm aware, Canonical were reasonably good about proposing the libindicator patches for upstream inclusion, but many upstream projects - especially those that are part of GNOME - weren't exactly rushing to adopt the patches. I think Canonical did try to implement libindicator support as a plugin for apps with sufficently sophisticated plugin frameworks, which obviously helps. There may have been changes since the last time I looked at things, of course. Note that I only ever did this as a personal side project. Even though I'm @redhat.com it's not a Red Hat project, it's not supported or paid by RH. It also has no kind of 'official' standing within Fedora, it's not like I proposed it as a feature and got anyone else to sign off on it. I just upped and started packaging things, entirely on my own initiative. I don't consider my efforts to have any more status than anyone else's. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Adam Williamson wrote: As far as I'm aware, Canonical were reasonably good about proposing the libindicator patches for upstream inclusion, but many upstream projects - especially those that are part of GNOME - weren't exactly rushing to adopt the patches. I think Canonical did try to implement libindicator support as a plugin for apps with sufficently sophisticated plugin frameworks, which obviously helps. That's really GNOME's fault. :-( Canonical explicitly designed libappindicator (which is the library applications are expected to use, it uses libindicator behind the scenes; there's also libindicate which is for communication apps to notify new messages and such, confusing, isn't it?) to be interoperable with KDE's status notifier spec, and thus applications supporting libappindicator will also integrate better into the KDE Plasma workspaces than applications still stuck on the legacy XEmbed-based system tray protocol and/or using a GNOME-only gnome-shell extension. But GNOME is giving the finger to cross-desktop protocols and refusing to implement them. It's too bad that our maintainers for the affected packages are often one and the same as the GNOME maintainers and thus Fedora is mostly siding with GNOME on this and refusing to carry those patches, hurting all non-GNOME desktops, not just Unity. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Dne 26.1.2012 02:05, Manuel Escudero napsal(a): I don't know if you're aware of this or not, but a user managed to port Ubuntu's Unity to OpenSUSE 12.1 as you can see here: http://en.opensuse.org/openSUSE:GNOME_Ayatana And also I've been told this desktop is available for ArchLinux now as well... As for this facts I was wondering how feasible is to port Unity to Fedora as well (Now that we have OpenSUSE RPM packages of the Unity sources and deps available to play with) and if someone is interested in trying to bring the Unity Desktop to Fedora If no one is, I was wondering where is a good place to start trying to do it so I can try it myself and then maybe I gather some other interested ones... -- Manuel Escudero Linux User #509052 Twitter: @Jmlevick http://twitter.com/Jmlevick Blogger: Blog Xenode http://xenodesystems.blogspot.com/ PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7 Xenode Systems - xenodesystems.com http://www.xenodesystems.com/ - Conéctate a Tu Mundo I like gnome3, however I really love the HUD idea recently announced by Mark Shuttleworth. Vit [1] http://www.markshuttleworth.com/archives/939 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wednesday 25 January 2012 19:05:37 Manuel Escudero wrote: And also I've been told this desktop is available for ArchLinux now as well... As for this facts I was wondering how feasible is to port Unity to Fedora as well The last I heard from the Arch packaging efforts was that Unity won't be an officially supported package until it no longer depends on non-upstream patches to GTK+ and friends. The same seems to be true for OpenSuse: Since we're replacing some of the core components of openSUSE (ex: GTK+, gnome-session) the priority is important. (pasted from your link) I don't think I'm going out on a limb if I say that this doesn't look like Unity will hit Fedora repos anytime soon. You may look at repos.fedorapeople.org, though. As far as I remember Adam Williamson once looked at the feasibility of packaging Unity for Fedora. Don't know what was the result, though. Maybe he can elaborate on that. Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On 01/26/2012 02:05 AM, Manuel Escudero wrote: I don't know if you're aware of this or not, but a user managed to port Ubuntu's Unity to OpenSUSE 12.1 as you can see here: http://en.opensuse.org/openSUSE:GNOME_Ayatana And also I've been told this desktop is available for ArchLinux now as well... As for this facts I was wondering how feasible is to port Unity to Fedora as well (Now that we have OpenSUSE RPM packages of the Unity sources and deps available to play with) and if someone is interested in trying to bring the Unity Desktop to Fedora If no one is, I was wondering where is a good place to start trying to do it so I can try it myself and then maybe I gather some other interested ones... -- Manuel Escudero Linux User #509052 Twitter: @Jmlevick http://twitter.com/Jmlevick Blogger: Blog Xenode http://xenodesystems.blogspot.com/ PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7 Xenode Systems - xenodesystems.com http://www.xenodesystems.com/ - Conéctate a Tu Mundo I remember Adam W took a look at this a while ago. Not sure where he ended up with it. [1] [1] http://www.happyassassin.net/2010/12/03/unity-on-fedora-possibly/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Jan 26, 2012 at 8:21 AM, Lars Seipel lars.sei...@googlemail.com wrote: The last I heard from the Arch packaging efforts was that Unity won't be an officially supported package until it no longer depends on non-upstream patches to GTK+ and friends. The same seems to be true for OpenSuse: Since we're replacing some of the core components of openSUSE (ex: GTK+, gnome-session) the priority is important. (pasted from your link) I don't think I'm going out on a limb if I say that this doesn't look like Unity will hit Fedora repos anytime soon. You may look at repos.fedorapeople.org, though. required patches to gtk and core gnome components that are not acceptable to upstream are basically a non-starter. It maybe possible to get some variant of Unity packaged and operational without those patches. But such a version might suffer some operational loss compare to the one offered by Ubuntu. I'm not sure its in anyone's best interest for us to offer a version we know is crippled just to say we were offering it at all. I don't think that's fair to users nor to the developers. And I'm not particularly thrilled when I see other distributors making the choice to ship crippled variants of competitor's offerings, so I wouldn't want Fedora to do it. The reality is, Unity and its Canonical developed dependency stack is not designed our constructed as a distribution neutral offering. Canonical has made some choices in how these bits of code are developed that assume tight integration with the Ubuntu distribution specifically, making it difficult for any other traditional distributor to include it as an offering without make some sort of special exception in some regard. It's not even in Debian yet in any capacity and that should speak volumes right there. If Unity was constructed as a neutral upstream project, it should be very easy for Debian to scoop it up and make small changes to the existing packaging and rebuild it..as a reversal of the more common approach on how Ubuntu merges from Debian. But it hasn't happened, and its not clear when it will happen. I would find it deeply amusing and highly ironic if Fedora or OpenSuse got officially maintained packages up and running in official repos ahead of Debian. That being said, I'll cheerfully review any new packages needed to get Unity packages into Fedora. Just ping me. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, 2012-01-26 at 10:15 -0900, Jef Spaleta wrote: required patches to gtk and core gnome components that are not acceptable to upstream are basically a non-starter. It maybe possible to get some variant of Unity packaged and operational without those patches. But such a version might suffer some operational loss compare to the one offered by Ubuntu. I'm not sure its in anyone's best interest for us to offer a version we know is crippled just to say we were offering it at all. I don't think that's fair to users nor to the developers. And I'm not particularly thrilled when I see other distributors making the choice to ship crippled variants of competitor's offerings, so I wouldn't want Fedora to do it. The app menu work that has recently landed in GTK+ is partially an effort to get some of these patches upstream. Hopefully, unity will be ported to use the upstreamed API at some point. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Jef Spaleta wrote: required patches to gtk and core gnome components that are not acceptable to upstream are basically a non-starter. Well, we could do what openSUSE did and just ship this in an unofficial repo with patched GTK+/GNOME packages. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Jan 26, 2012 at 1:59 PM, Kevin Kofler kevin.kof...@chello.at wrote: Jef Spaleta wrote: required patches to gtk and core gnome components that are not acceptable to upstream are basically a non-starter. Well, we could do what openSUSE did and just ship this in an unofficial repo with patched GTK+/GNOME packages. Is that the royal 'we'? Surely any individual or group can go ahead and chew on this outside the fedora submission process. I'd never want to give anyone the idea that would be somehow forbidden. If the patches are really needed (and I'm not actually sure they are critical for operation versus minor functionality enhancements) then someone could certainly roll their own packages and never get them into Fedora proper and still have the effort be worthwhile. In the same way spot heroically beats on chromium packages outside the standard repository collection Fedora provides. There is certainly nothing precedent setting in needing to do this sort of packaging outside the main repository. I just want to make sure its understood that there could be some stumbling blocks or compromises which have to be made going from 3rd party repo into the submission process. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
I don't think I'm going out on a limb if I say that this doesn't look like Unity will hit Fedora repos anytime soon. You may look at repos.fedorapeople.org, though. As far as I remember Adam Williamson once looked at the feasibility of packaging Unity for Fedora. Don't know what was the result, though. Maybe he can elaborate on that. See https://bugzilla.redhat.com/show_bug.cgi?id=693233 (pkgreview for nux) for some slightly more recent status details. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
