FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Kubuntu Development

 
 
LinkBack Thread Tools
 
Old 05-27-2010, 07:48 PM
Harald Sitter
 
Default KDE and Ubuntu SoundMenu

Hello!

At the recently held KDE Multimedia + Edu sprint in Switzerland we came to
discuss the new concept of a soundmenu, as described at [1].

The general consensus was that the present KDE MM developers do think the idea
of having a central place to control all sound related informations and
operations is a very good one, and something we could very well want to have
implemented upstream instead having a Kubuntu specific version. Especially
since this would also imply doing enhancements to existing specifications that
are already used in KDE software.

We are at this point however not sure that the same UI representation proposed
for Ubuntu should be applied as-is to KDE software. So it is very much desired
to get discussion going with regards to the API and how to implement it in KDE
software.

Please see this mail as a conversation starter, I also CC'd affected parties
on our end (KDE Multimedia, Amarok, Plasma), so that everyone is on the same
page here.

[1] https://wiki.kubuntu.org/SoundMenu

regards,
Harald
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-27-2010, 08:06 PM
"Roderick B. Greening"
 
Default KDE and Ubuntu SoundMenu

Excellent.

We actually prefer it when upstream is able to run with an idea, and we
certainly have the ability to help flesh it out.

The web page you are looking at actually is for the Ubuntu Sound Menu, and not
a KDE specific item. Unfortunately, sub-pages of http://wiki.kubuntu.org/* maps
directly to http://wiki.ubuntu.com/*, which is why you see this, and hence the
confusion.

For any KDE/Kubuntu specific items, we usually will prefix pages with KDE or
Kubuntu or K to make it more obvious that it is for the 'K' family

I expect that there are a lot of ideas generated in the Ubuntu Sound Menu that
we could easily move forward with upstream in KDE, and others which simply
make no sense.

We'd love to see how you envision this, and what we may do to help make this a
reality for all KDE users.

Cheers,

Rod.

> Hello!
>
> At the recently held KDE Multimedia + Edu sprint in Switzerland we came to
> discuss the new concept of a soundmenu, as described at [1].
>
> The general consensus was that the present KDE MM developers do think the
> idea of having a central place to control all sound related informations
> and operations is a very good one, and something we could very well want
> to have implemented upstream instead having a Kubuntu specific version.
> Especially since this would also imply doing enhancements to existing
> specifications that are already used in KDE software.
>
> We are at this point however not sure that the same UI representation
> proposed for Ubuntu should be applied as-is to KDE software. So it is very
> much desired to get discussion going with regards to the API and how to
> implement it in KDE software.
>
> Please see this mail as a conversation starter, I also CC'd affected
> parties on our end (KDE Multimedia, Amarok, Plasma), so that everyone is
> on the same page here.
>
> [1] https://wiki.kubuntu.org/SoundMenu
>
> regards,
> Harald
_______________________________________
Roderick B. Greening, B.Sc.
Paradise, NL Canada
E-mail/MSN: roderick.greening@gmail.com
LP: launchpad.net/~roderick-greening
Wiki: wiki.ubuntu.com/rgreening
Blog: roderick-greening.blogspot.com
Twitter: twitter.com/rgreening
Identica: identi.ca/rgreening

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-28-2010, 12:09 AM
Tres Finocchiaro
 
Default KDE and Ubuntu SoundMenu

For what it's worth, from the already existing drawings, I like the microphone showing when VOIP is active, but I'd be afraid that not all devices accessing the microphone would know to active it to the tray like that.* Perhaps the API would handle that?


If the microphone doesn't show -- for example when using Audacity -- is a expandable/collapsible section possible for microphone adjustments or would that be overkill?

I'd like to add that my favorite feature of the volume icon is the mouse wheel support!* Keeping the mouse wheel for louder/quieter is a major plus!* I find myself trying to use the mouse wheel on Windows all the time!


My least favorite part of the volume area is turning on/off visible channels and when the menu gets stuck open and won't go away (will file a bug if I can predictably reproduce).

-Tres


On Thu, May 27, 2010 at 4:06 PM, Roderick B. Greening <roderick.greening@gmail.com> wrote:

Excellent.



We actually prefer it when upstream is able to run with an idea, and we

certainly have the ability to help flesh it out.



The web page you are looking at actually is for the Ubuntu Sound Menu, and not

a KDE specific item. Unfortunately, sub-pages of http://wiki.kubuntu.org/* maps

directly to http://wiki.ubuntu.com/*, which is why you see this, and hence the

confusion.



For any KDE/Kubuntu specific items, we usually will prefix pages with KDE or

Kubuntu or K to make it more obvious that it is for the 'K' family



I expect that there are a lot of ideas generated in the Ubuntu Sound Menu that

we could easily move forward with upstream in KDE, and others which simply

make no sense.



We'd love to see how you envision this, and what we may do to help make this a

reality for all KDE users.



Cheers,



Rod.



> Hello!

>

> At the recently held KDE Multimedia + Edu sprint in Switzerland we came to

> discuss the new concept of a soundmenu, as described at [1].

>

> The general consensus was that the present KDE MM developers do think the

> idea of having a central place to control all sound related informations

> and operations is a very good one, and something we could very well want

> to have implemented upstream instead having a Kubuntu specific version.

> Especially since this would also imply doing enhancements to existing

> specifications that are already used in KDE software.

>

> We are at this point however not sure that the same UI representation

> proposed for Ubuntu should be applied as-is to KDE software. So it is very

> much desired to get discussion going with regards to the API and how to

> implement it in KDE software.

>

> Please see this mail as a conversation starter, I also CC'd affected

> parties on our end (KDE Multimedia, Amarok, Plasma), so that everyone is

> on the same page here.

>

> [1] https://wiki.kubuntu.org/SoundMenu

>

> regards,

> Harald

_______________________________________

Roderick B. Greening, B.Sc.

Paradise, NL Canada

E-mail/MSN: roderick.greening@gmail.com

LP: launchpad.net/~roderick-greening

Wiki: wiki.ubuntu.com/rgreening

Blog: roderick-greening.blogspot.com

Twitter: twitter.com/rgreening

Identica: identi.ca/rgreening




--

kubuntu-devel mailing list

kubuntu-devel@lists.ubuntu.com

Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel




--
- Tres.Finocchiaro@gmail.com

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-28-2010, 05:59 PM
"Aaron J. Seigo"
 
Default KDE and Ubuntu SoundMenu

let the cross posting begin!

On May 27, 2010, Harald Sitter wrote:
> At the recently held KDE Multimedia + Edu sprint in Switzerland we came to
> discuss the new concept of a soundmenu, as described at [1].

it's excellent to hear that the dev sprint is paying off, as they always seem
to do!

> [1] https://wiki.kubuntu.org/SoundMenu

personally, i think the idea is a fine one. it essentially merges the Now
Playing applet with the sound control application (kmix, in the case of KDE).

the details of what features to support for the audio app, i'll leave up to
the audio app devs (e.g. amarok, et al), but from the Plasma perspective:

one thing that jumps out at me about this page is that it goes into a lot of
detail about visual design. this is fine for a specific final implementation
(e.g. a gnome-panel applet or a Plasmoid), but it would be helpful to us as
implementors / adopters if such visual design information was separated from
representation and mechanics (such as the dbus API parts) and if the
visualization details were further divided into "expectations audio players
can rely on" (such as having play/pause, next and prev controls, and with no
assertion that they are buttons ..) and implementation specific notes such as
font faces and sizes or that the play/pause control is a button with a
specific icon.

this will allow us to:

* implement the mechanism separately and ensure cross-environment compliance
by having a clearly defined target to work towards to be able to test against

* provide a UI that meets the set of contracted requirements audio players
require

* be flexible in implementation specific representation without having to
compromise spec compliance

* be able to continue to adapt our visual design over the coming years without
feeling compelled to revise or abandon the functional aspects of the spec


i like the idea of using Status Notifiers paired with mpris for this as it
obviates the need for too much new specification and application
implementation. it also increases the odds of adoption, while providing a "for
free" fallback: when there isn't a sound menu implementation around, then the
system tray icon (or however the status notifier is being visualized), the
status notifier can be shown.

this does have an interesting implication for the status notifier spec,
however: we will need some extra information about the notifier to decide what
to do with it. essentially, we will require the ability to go from "here is a
notifier item" to "and it has an mpris interface, and we have a sound menu, so
integrate it into the sound menu instead".

one (perhaps overly simplistic?) idea would be to add an optional "extra
hints" mapping to the status notifier spec. this would be used to transport
things like "mpris" => "org.mpris.amarok", as well as similar future
expansions of visualization handling based on hints. status notifier items
would not be required to provide any such hints, and visualizations would be
free to do with them as they would like to. we would need to keep a catalog of
well-known keys (e.g. "mpris") in the spec, however, to ensure consistency.
thoughts?

on the KDE implementation side: we already have DataEngines for both status
notifier items and mpris (part of the "now playing" engine) that ship as part
of the default KDE Plasma workspace bundle. what would be needed is:

* writing a Plasmoid that combines the current kmix notifier item (basically,
the volume controller and a sensible context menu) with elements from the Now
Playing Plasmoid. kmix's full mixer window could remain a stand alone app
called from the plasmoid when needed. an alternative would be to take the Now
Playing Plasmoid and add audio level controls to it, esentially turning it
into the "Sound Menu".

* add te resulting Plasmoid to the default system tray Plasmoid set (along
with Battery, Notifications, etc); this is a one-liner, so is more of a detail
than anything else.

is there anyone in Amarok, Ayatana, Kubuntu, $OTHER_PROJECT_COMMUNITY who
would be willing to step up and take on the work to realize the Plasmoid? that
would greatly help ensure adoption. the Plasma team would be happy to support
the effort, so you wouldn't be "all on your own", but we're already fairly
strapped for manpower with what is already on our plates (what's new, right?




p.s. can we please stop calling status notifiers "app indicators" in technical
documentation? (as opposed to user communication or marketing, which is rather
separate.) we already have a name for them that makes perfect sense for
technical reasons, and it would be nice to keep technical discussion
consistent and clear to maximize effectivity.

p.p.s. since when were "app indicators" an invention of Ted Gould? nothing
against Ted himself and certainly the work on app indicators has improved what
it is built on, but unless the goal is to continue to create social strain and
channel conflict (and i can't imagine that it is), Canonical and its community
may do well to consider how both attribution and downstream code forks are
handled. it's an ongoing issue that creates bariers which are unecessary,
unhelpful and avoidable .. and which i personally run into too often. (a
polite way of saying: "You all are helping create problems that I end up
having to deal with."

before anyone gets defensive about it, i understand it's likely often
completely unintentional or even a result of "pragmatism forced our hand". and
please understand that i'm just a messenger here, observing what is quite
evidently a common result in the broader F/OSS community due to how things are
currently (and historically) handled.

as a concrete and constructive suggestion, saying things like, "We would like
to provide a unified music player experience on the Ubuntu platform therefore
we strongly urge application developers to follow this spec." gives the
impression that the idea is that app devs should be targetting Ubuntu and
meshing with Ubuntu as the target platform, with the underlying implication of
"who cares about anything else f/oss out there". (those are very Redmonian or
Cupertonian sorts of lines, so the innevitable reactions are to be expected
... ) maybe something like, ""We would like to provide a unified music player
experience in Ubuntu, and therefore we strongly urge the F/OSS desktop
community to embrace this spec so that we can achieve that goal." would help
us all get closer to the shared goals we have quicker and with less gnashing
of teeth.

that may seem like "twiddling the words", but as someone who has been somewhat
successful in helping achieve adoption of a number of shared technologies over
the years (as well as having failed at times!), i can only say that it really
matters. whether it "should" or not is pretty irrelevant; that's like arguing
whether or not gravity is a good idea since it gets in the way of humanity's
dream of flying. it is how it is, it's not worth trying to "fix" since we
can work with it quite effectively.

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 

Thread Tools




All times are GMT. The time now is 01:11 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org