Linked by Thom Holwerda on Mon 14th Mar 2011 18:59 UTC
Talk, Rumors, X Versus Y And over the weekend, the saga regarding Canonical, GNOME, and KDE has continued. Lots of comments all over the web, some heated, some well-argued, some wholly indifferent. Most interestingly, Jeff Waugh and Dave Neary have elaborated on GNOME's position after the initial blog posts by Shuttleworth and Seigo, providing a more coherent look at GNOME's side of the story.
Thread beginning with comment 466082
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Duck and Cover
by _txf_ on Mon 14th Mar 2011 21:07 UTC in reply to "RE: Duck and Cover"
_txf_
Member since:
2008-03-17

Dave is saying, in a slightly humorous way, that "Notifications don't use D-Bus" is not a proper problem statement. I completely agree.


Except that wasn't the problem and nobody ever said that it was. The problem was Xembed (which was unflexible and designed for a different era). The solution was to use dbus for ipc (would he rather people reimplement a new ipc just for systrays!?).

Reply Parent Score: 3

RE[3]: Duck and Cover
by Kitty on Mon 14th Mar 2011 21:51 in reply to "RE[2]: Duck and Cover"
Kitty Member since:
2005-10-01

Gnome shell seems to have tackled the problem of notification and tray area from the functional point of view, not just the technical one.

Thus not "xembed is unflexible, a dbus protocol to signal application status would be better if coupled with a new tech for notify icons and menus"

But "why is an application putting an icon in tray? Is it sending a notification the user must interact with? is it a system-wide status signal and control point? What kind of actions would be possible in a transient notification, which should always be accessible? What about urgency level affecting the display?"

From this derived the basic mismatch you can read about in the discussion, with Gnome coders dubious about a pure transmission method that poses no ipothesis on the interaction on the receiving part, whereas they seemed to think the coupling important for the redesign of the whole.
And KDE devs stating that yes, the data was just being sent and totally decoupled from the presentation... so much that there's no indication whatsoever of what the user-facing application can or should do with tha data it receives.
Frankly, both aspects seem worthy of work to me, on different levels, but I'm sure it's a prerogative of the Gnome shell coders to deem that the tech proposal was not solving the UX design problems they were interested in wrt the tray - at least at the moment. And what should have they done with a tech they had no practical interest in, if not let it be until they could contribute with real case requirements?

Reply Parent Score: 2

RE[3]: Duck and Cover
by dneary on Tue 15th Mar 2011 10:41 in reply to "RE[2]: Duck and Cover"
dneary Member since:
2011-03-15

"Dave is saying, in a slightly humorous way, that "Notifications don't use D-Bus" is not a proper problem statement. I completely agree.


Except that wasn't the problem and nobody ever said that it was. The problem was Xembed (which was unflexible and designed for a different era). The solution was to use dbus for ipc (would he rather people reimplement a new ipc just for systrays!?).
"

The problem was "there are too many applications creating icons in the systray/creating custom panel applets, they all behave in slightly different & inconsistent ways, and there is no straightforward way for an application developer to indicate the state of his application across different desktop environments without redoing a bunch of work".

XEmbed is an implementation detail.

Cheers,
Dave.

Reply Parent Score: 1

RE[4]: Duck and Cover
by _txf_ on Tue 15th Mar 2011 11:09 in reply to "RE[3]: Duck and Cover"
_txf_ Member since:
2008-03-17

The problem was "there are too many applications creating icons in the systray/creating custom panel applets, they all behave in slightly different & inconsistent ways, and there is no straightforward way for an application developer to indicate the state of his application across different desktop environments without redoing a bunch of work".

XEmbed is an implementation detail.


Certainly that is the case, it doesn't matter what the old implementation was Xembed etc. the thing was every app decided how their icon was drawn in the systray instead of the shell choosing what was the best representation.

It should be up to the DE to choose how this information is displayed to the user be that using a systray, floating icons, whatever. The spec as I understand it left that completely open enabling people maximum flexibility (and hopefully enable cool stuff in the process) instead of a rigid systray2 approach.

Reply Parent Score: 2

RE[4]: Duck and Cover
by segedunum on Tue 15th Mar 2011 17:30 in reply to "RE[3]: Duck and Cover"
segedunum Member since:
2005-07-06

XEmbed is an implementation detail.

An implementation detail that happens to be very important for users, because XEmbed is widely agreed to have a great deal of things wrong with it.

The question is, what replaces it? Does it get replaced by something that desktops and applications can agree on and communicate through and work with or do we go the traditional Unix and CDE route with a a ton of fragmentation that provides no benefits to anyone?

You know fine well why Aaron specifically mentioned D-Bus in what he wrote. Do we really need to go over why D-Bus was initiated and what benefits common communication between differing applications and desktops brings to users?

I think you're just digging a bigger hole here Dave, and it's sad to see.

Reply Parent Score: 5