Dan Williams wrote:
obvious to everyone - assuming that everyone understands something the
same way is about the worst way to write a specification. You need to
explicitly state what that understanding is, otherwise it's not a
specification, it's a vague idea and everyone will have a
Rahul Sundaram wrote:
If a single desktop environment wants to just implement something, they
can go ahead and do so but that doesn't make it a real specification. For
other desktop environments to adopt it, it needs to be a collaborative and
shared effort. Part of that is addressing
Rahul Sundaram wrote:
There is no need to assume that clarifying something requires changing
existing code and changing existing code doesn't necessarily require
breaking compatibility
Have you seen the changes they requested?
http://lists.freedesktop.org/archives/xdg/2010-January/011228.html
Hi
On Sat, Mar 8, 2014 at 12:55 PM, Kevin Kofler kevin.kof...@chello.atwrote:
Rahul Sundaram wrote:
If a single desktop environment wants to just implement something, they
can go ahead and do so but that doesn't make it a real specification.
For
other desktop environments to adopt it,
Rahul Sundaram wrote:
Yes and I am convinced that not enough effort was taken to address the
concerns expressed. This is probably lost opportunity already but one
could strive to do better on future specs.
So you think the KDE developers should have renamed those D-Bus methods and
signals,
On Sat, Mar 8, 2014 at 7:45 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Rahul Sundaram wrote:
Yes and I am convinced that not enough effort was taken to address the
concerns expressed. This is probably lost opportunity already but one
could strive to do better on future specs.
So you
On 8 March 2014 17:55, Kevin Kofler kevin.kof...@chello.at wrote:
To properly integrate with the other desktops, GNOME has no other choice but
to implement that spec
I'm not sure that's a terribly convincing argument.
Richard
--
devel mailing list
devel@lists.fedoraproject.org
drago01 wrote:
You make it sound like Dan's review only talks about names. But that's
not the case.
The main author of the spec made a revision in which he integrated some of
the suggestions:
http://lists.freedesktop.org/archives/xdg/2010-January/011246.html
(even one of the name changes,
drago01 wrote:
Its not about complaining can you stop your they vs. us attitude?
The spec have been put up for review
and issues where found and the ones that wrote the spec refused to
address them in a meaningful way (or not at all).
That's just not true. A revision was uploaded. The GNOME
Hi
On Sat, Mar 8, 2014 at 4:24 PM, Kevin Kofler wrote:
* Wayland rendering the legacy XEmbed-based spec (that has been used as the
interoperability lingua franca so far, despite having been deprecated
by
both sides of the equation) entirely obsolete
instead, and thus restarting the
Am 07.03.2014 18:16, schrieb Dan Williams:
On Fri, 2014-03-07 at 00:18 +0100, Kevin Kofler wrote:
* change requests that would have broken compatibility with the existing
implementations of the protocol already in wide use for little to no
practical benefit, such as nitpicking about the
On Fri, Mar 7, 2014 at 12:22 PM, Reindl Harald wrote:
in case of changes gaining less to zero - YES
If a single desktop environment wants to just implement something, they can
go ahead and do so but that doesn't make it a real specification. For
other desktop environments to adopt it, it
Am 07.03.2014 18:33, schrieb Rahul Sundaram:
On Fri, Mar 7, 2014 at 12:22 PM, Reindl Harald wrote:
in case of changes gaining less to zero - YES
If a single desktop environment wants to just implement something, they can
go ahead and do so but that doesn't
make it a real
Hi
On Fri, Mar 7, 2014 at 12:59 PM, Reindl Harald wrote:
i know that all and aware that it is not perfect but if others adopt
something existing and already widely used they hardly can demand to
change all existing code
There is no need to assume that clarifying something requires
I wrote:
PS:
I wrote:
--+--
GTK+ (2 or 3) | You must use Canonical's libappindicator, which
is
| interoperable with the KDE implementation. It is
| already packaged in
On Thu, Mar 6, 2014 at 5:30 AM, Kevin Kofler kevin.kof...@chello.at wrote:
PS:
I wrote:
--+---
GTK+ (2 or 3) | You must use Canonical's libappindicator, which is
| interoperable with the KDE
On Thu, 2014-03-06 at 00:07 +0100, Kevin Kofler wrote:
That was the excuse for not supporting the spec in GNOME Shell:
http://lists.freedesktop.org/archives/xdg/2010-January/011228.html
A very bad excuse, considering that, as I pointed out, the spec GNOME
proposes using instead (the Galago
Matthias Clasen wrote:
Please stop rewriting history. The spec was proposed, flaws were pointed
out in the review, and there was no willingness to address those flaws
in any meaningful way.
The purported flaws were of 2 kinds:
* claims of underspecification that are irrelevant in practice
drago01 wrote:
Legacy icons are not limited to 24x24 pixels that's a myth.
In practice, they are. Ask Martin Gräßlin and/or Aaron Seigo for details.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of
On Fri, Mar 7, 2014 at 12:18 AM, Kevin Kofler kevin.kof...@chello.at wrote:
Matthias Clasen wrote:
Please stop rewriting history. The spec was proposed, flaws were pointed
out in the review, and there was no willingness to address those flaws
in any meaningful way.
The purported flaws were
Hi,
Please read this e-mail carefully and thouroughly, as interoperability of
your package (including and especially non-KDE packages!) with upcoming KDE
Plasma Workspaces releases depends on it!
The next major release of the KDE Plasma Workspaces (i.e. KDE 5, more
correctly referred to as
PS:
I wrote:
Qt 5 QSystemTrayIcon | You should not have to do anything special. Support
| for the new protocol will come in upstream Qt 4.5
Sorry, I mean 5.4 (of course not 4.5).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
On Wed, 2014-03-05 at 20:04 +0100, Kevin Kofler wrote:
--+-
GTK+ (2 or 3) | You must use Canonical's libappindicator, which is
| interoperable with the KDE implementation. It is
Matthias Clasen wrote:
Of course, you can also just stop using status icons and instead inform
the user with notifications when something requires his immediate
attention. That will work under any desktop.
I forgot to point out that libappindicator also supports automatic fallback
to the
Matthias Clasen wrote:
Of course, you can also just stop using status icons and instead inform
the user with notifications when something requires his immediate
attention. That will work under any desktop.
I should also warn that while notifications (Galago spec [1]) will *work* on
most
On Wed, Mar 5, 2014 at 11:44 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Matthias Clasen wrote:
Of course, you can also just stop using status icons and instead inform
the user with notifications when something requires his immediate
attention. That will work under any desktop.
I should
26 matches
Mail list logo
