Hi all,
First of all, I would like to apologize for opening a new topic, but I
wasn't signed on the list, so I can't really reply to the original
thread, Unity For Fedora (As in OpenSUSE or Arch)[1] by Manuel
Escudero.
I would like to clarify a few things:
* Unity is not available for openSUSE
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
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
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
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
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
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
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.
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
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
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
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
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
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!
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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,
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
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
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
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
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
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.
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
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
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
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
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
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
- 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
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
- 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
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
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
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
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
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
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
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
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
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
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
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
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
65 matches
Mail list logo
