7:05 p.m.
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"
3:21 a.m.
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
11:21 a.m.
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
1:15 p.m.
On Thu, Jan 26, 2012 at 8:21 AM, Lars Seipel <lars.seipel(a)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
3:29 p.m.
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.
5:15 p.m.
On Thu, Jan 26, 2012 at 1:59 PM, Kevin Kofler <kevin.kofler(a)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
9:26 p.m.
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.
4:04 a.m.
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
3:16 a.m.
----- 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4:54 a.m.
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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
5:28 a.m.
----- 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(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
6:20 a.m.
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(a)lists.fedoraproject.org
> > > https://admin.fedoraproject.org/mailman/listinfo/devel
>
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4:16 p.m.
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
5:03 p.m.
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
6:01 a.m.
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.
7:05 a.m.
On mié, 2012-02-01 at 12:01 +0000, 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).
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.
Florian
[0] http://lists.freedesktop.org/archives/xdg/2010-January/011228.html
11:25 a.m.
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
12:39 p.m.
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
3:18 p.m.
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?
but there are no guarantees or ways to query the shell's
capabilities.
Because the application should not have to worry about it.
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"
Implementing the spec is needed for your application to work properly on
everyone else's desktops, and everyone else's applications to work properly
on your desktop.
- after all, "enforcing" adoption of technology is not
what
freedesktop.org is supposed to be about[0] ;-)
[0] http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html
Bad example. Configuration file storage is not a communication protocol. The
status notifier protocol is a protocol for communication between the
applications and the workspace, and thus a communication protocol to the
same extent as HTTP, FTP, SMB etc.
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.
Newsflash: KDE *also* deprecated the use of the system tray by random
applications by default! However:
* Some users WANT to have the OPTION of having an icon for a specific
application there. I know GNOME hates options, but not everyone agrees with
that. So several applications do have a preference to show a system tray
icon even if it is disabled by default, and change requests such as
https://bugzilla.redhat.com/show_bug.cgi?id=761640 are just rude. (And yes,
I know XChat is still using the crappy legacy XEmbed protocol. And by the
way, I no longer comaintain or use XChat, so for all I personally care you
can cripple it all you want, but that doesn't make it any less stupid to do
so.)
* Not any cross-desktop program is a regular application. There can also be
cross-desktop system utilities. Think, e.g., of hardware enablement: gnome-
shell currently has a hardcoded Bluetooth icon (and in fact requires an
extension to get rid of it), what if there's a completely new hardware
technology coming up which warrants an icon just as much? Why does
everything have to be rewritten and hardcoded into gnome-shell (as was done
for network management, bluetooth etc.)? Another example is imsettings,
which not only had to be rewritten as a gnome-shell extension, but was not
even allowed onto the default Fedora desktop (the misnamed GNOME "Desktop"
live image) because the extension was not yet merged into upstream gnome-
shell!
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.
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!
I'm really fed up of GNOME's "one size fits it all" mentality.
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! ;-)
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).
But the idea that every user will always need the exact same hardcoded set
of status icons in the panel is extremely simplistic and flawed, or we
wouldn't have the bazillion gnome-shell extensions adding or removing those
icons.
I'm totally fed up of how GNOME is trying to dictate to all applications how
they can or should behave and refusing to interoperate with any
specification which doesn't follow their restrictive "design". GNOME is not
a universe of its own, there will always be non-GNOME applications running
under GNOME, and GNOME applications running under other environments.
Kevin Kofler
3:45 p.m.
On Wed, Feb 1, 2012 at 10:18 PM, Kevin Kofler <kevin.kofler(a)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?"
> but there are no guarantees or ways to query the shell's
capabilities.
Because the application should not have to worry about it.
Well because the app provides an interface to the user and it has to
somehow be able to know what the user actually sees.
Lets say your app opens a dialog and the window manager is free to
just not display it. Does that make any sense?
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.
5:44 p.m.
drago01 wrote:
On Wed, Feb 1, 2012 at 10:18 PM, Kevin Kofler
<kevin.kofler(a)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
4:01 a.m.
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
3:49 p.m.
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
6:09 p.m.
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
6:16 p.m.
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
4:02 a.m.
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
1:11 p.m.
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
1:38 p.m.
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
2:59 p.m.
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
3:37 p.m.
On Thu, Feb 2, 2012 at 9:59 PM, Kevin Kofler <kevin.kofler(a)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
3:47 p.m.
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
6 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:08 p.m.
On Wed, 2012-02-01 at 17:00 -0700, 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.
Amen!
The notification area is my biggest grief with gnome-shell as well,
sadly.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
9:43 p.m.
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.
1:27 a.m.
On Wed, 01 Feb 2012 17:00:30 -0700
Adam Williamson <awilliam(a)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
2:02 a.m.
On Thu, 2012-02-02 at 08:27 +0100, Stijn Hoop wrote:
On Wed, 01 Feb 2012 17:00:30 -0700
Adam Williamson <awilliam(a)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
1:18 p.m.
On 2 February 2012 12:12, Kevin Kofler <kevin.kofler(a)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
1:18 p.m.
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
2:37 p.m.
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
3:58 a.m.
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
5:41 p.m.
Florian Müllner wrote:
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
2:43 p.m.
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 | mjg59(a)srcf.ucam.org
4 p.m.
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
4:18 p.m.
On mié, 2012-02-01 at 23:00 +0100, Kevin Kofler wrote:
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?
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.
Florian
6:28 p.m.
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
3:59 a.m.
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
1:17 p.m.
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
1:44 p.m.
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
5:51 p.m.
On Wed, Feb 01, 2012 at 11:00:52PM +0100, Kevin Kofler wrote:
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!
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.
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.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:51 p.m.
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
7:02 p.m.
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 | mjg59(a)srcf.ucam.org
7:21 p.m.
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
9:31 p.m.
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 | mjg59(a)srcf.ucam.org
10:26 p.m.
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
3:57 a.m.
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
9:12 a.m.
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 | mjg59(a)srcf.ucam.org
1:19 p.m.
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
2:04 p.m.
On Thu, Feb 2, 2012 at 8:19 PM, Kevin Kofler <kevin.kofler(a)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.
2:21 p.m.
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 | mjg59(a)srcf.ucam.org
3:04 p.m.
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
3:27 p.m.
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 | mjg59(a)srcf.ucam.org
3:38 p.m.
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
11:03 a.m.
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
11:29 a.m.
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.
12:04 p.m.
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
6:39 a.m.
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
8:23 a.m.
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
1:06 p.m.
Dan Winship wrote:
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
11:33 a.m.
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.
11:35 a.m.
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/
4460
days inactive
4467
days old
71 comments
22 participants
participants (22)
-
Adam Williamson -
Bastien Nocera -
Brendan Jones -
Dan Winship -
drago01 -
Florian Müllner -
Genes MailLists -
Jaroslav Reznik -
Jef Spaleta -
Jens-Ulrik Petersen -
Kevin Kofler -
Lars Seipel -
Manuel Escudero -
Mathieu Bridon -
Matthew Garrett -
Matthias Clasen -
Nathanael D. Noblet -
Rahul Sundaram -
Simo Sorce -
Stephen John Smoogen -
Stijn Hoop -
Vít Ondruch