Nabble - Free Desktop - xdg

Re: Actions extensions in File Manager

2009-11-28T04:26:27Z

----- "David Faure" <faure@...> wrote:
>
> Why not use "Desktop Action", even if it's not in the spec anymore?

Well, this was my first thought also. But I do worry about the
reasons behind the removal:
- if authors (hey, are you here ?) believed this group won't be
used, it could make sense to not overload a spec with it ; and
it makes sense today to reintroduce it
- if there was another reason, it seems to me that it could be
important to know it before taking a different decision

Does this imply that :
- we have an 'Actions' key in 'Desktop Entry' group, which
defines an ordered list of actions as
Actions=action1;action2;
- and a 'Desktop Action <action>' which describes the action
itself,
- where actions not referenced in the 'Actions' list are just
ignored ?

However, at least Nautilus-Actions extension defines that an
action may have several profiles. Each profile is supposed to
apply to different conditions, so that a same action may
behave differently depending of the current environment.

This is why I need also something as:
- in 'Desktop Action' group, a 'Profiles' key which defines
an ordered list of profiles
- a 'Desktop Profile <action_profile>' group which describes
the profiles itself,
- where profiles not referenced in the 'Profiles' list are just
ignored.

> This would make the format somewhat compatible with KDE servicemenus,
> although
> we have to agree on where to install them and how to flag them as
> servicemenus
> (the answers to these two questions are currently kde-specific for
> servicemenus).
>

In my first alpha code, I'm searching for desktop files in
XDG_DATA_DIRS/file-manager-actions/, though I'm conscious this is
not the path used by Konqueror Service Menus according to [1]

It would not be difficult to have a list of search paths in
addition to XDG_DATA_DIRS "standards" (usages ?).

Regards
Pierre

[1] http://developer.kde.org/documentation/tutorials/dot/servicemenus.html
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Actions extensions in File Manager

2009-11-28T03:30:56Z

On Friday 27 November 2009, Pierre Wieser wrote:
> Maybe the authors of Desktop Entry spec may give us some rationales
> about the 'Desktop Action' disappearance ?

I would very much like to know as well.

> Nonetheless, I'm afraid that I'll have to write my own extension
> spec, hoping that other file managers will take benefit of it...:(

Why not use "Desktop Action", even if it's not in the spec anymore?
This would make the format somewhat compatible with KDE servicemenus, although
we have to agree on where to install them and how to flag them as servicemenus
(the answers to these two questions are currently kde-specific for
servicemenus).

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Actions extensions in File Manager

2009-11-27T04:31:59Z

----- "Ted Gould" <ted@...> wrote:

> On Thu, 2009-11-26 at 14:30 +0100, Pierre Wieser wrote:
> > However, these two threads refer to a 'Desktop Action' which
> > was present in current 0.9.4 spec, but has disappeared from
> > latest 1.1. Does this mean the 'Desktop Action' entry has been
> > obsoleted ?
>
> More specifically, it was deleted in the 0.9.6 version as it was in
> 0.9.5. I am too curious about these, as I was looking at trying
> something similar for a couple messaging menu features. I'd much
> prefer
> to use something standard.
>
> One thing that seems to be lacking is there is not ShownIn/NotShownIn
> keys for the actions. It would seem like that'd be useful for them.
>
> --Ted

Humm.. As I understand the "Extending the format" paragraph,
it appears to me that only new keys (or extended semantics for
existing keys, I imagine) in 'Desktop Entry' group would require
a more or less formal group discussion.

Having 'X-Product' groups and your own keys in these is already
accepted by the spec.

Maybe the authors of Desktop Entry spec may give us some rationales
about the 'Desktop Action' disappearance ?

Nonetheless, I'm afraid that I'll have to write my own extension
spec, hoping that other file managers will take benefit of it...:(

Regards
Pierre
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Fwd: Actions extensions in File Manager

2009-11-27T03:59:35Z

On Friday, 2009-11-27, Ted Gould wrote:

Good question, since it seems it had already been implemented by at least two
file managers.
Maybe there is a commit log detailing the removal reasoning?

> One thing that seems to be lacking is there is not ShownIn/NotShownIn
> keys for the actions. It would seem like that'd be useful for them.

Wouldn't that already be covered by the respective value of the desktop file
itself?
I.e. if the application shows up in the launcher menu, why would its action
not show up in the file manager or vice versa?

Cheers,
Kevin

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (197 bytes) Download Attachment

Re: Fwd: Actions extensions in File Manager

2009-11-26T21:02:00Z

On Thu, 2009-11-26 at 14:30 +0100, Pierre Wieser wrote:
> However, these two threads refer to a 'Desktop Action' which
> was present in current 0.9.4 spec, but has disappeared from
> latest 1.1. Does this mean the 'Desktop Action' entry has been
> obsoleted ?

More specifically, it was deleted in the 0.9.6 version as it was in
0.9.5. I am too curious about these, as I was looking at trying
something similar for a couple messaging menu features. I'd much prefer
to use something standard.

One thing that seems to be lacking is there is not ShownIn/NotShownIn
keys for the actions. It would seem like that'd be useful for them.

--Ted

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (204 bytes) Download Attachment

Fwd: Actions extensions in File Manager

2009-11-26T05:30:25Z

----- "Kevin Krammer" <kevin.krammer@...> a écrit :

>
> While this might not entirely be the same thing, a quick check of my
> local
> archive of this list found two related sounding threads:
>
> http://lists.freedesktop.org/archives/xdg/2006-February/006094.html
> http://lists.freedesktop.org/archives/xdg/2006-June/006612.html
>
> Not sure whether this kind of action handling is deprecated or an
> orthogonal
> concept but it might make sense to at least have a look it :)
>
> Cheers,
> Kevin
>

Hi Kevin,

Oop's, my own searches were obviously just too fast. Thanks for
these links I've conscientiously bookmarked.

Yes, this sounds very close of what we do in Nautilus. Though I
understand that these only refer to mimetype-based actions,
where N-A actions have some more conditions.

However, these two threads refer to a 'Desktop Action' which
was present in current 0.9.4 spec, but has disappeared from
latest 1.1. Does this mean the 'Desktop Action' entry has been
obsoleted ?

Regards
Pierre
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Fwd: Actions extensions in File Manager

2009-11-26T04:06:07Z

Hi Pierre,

On Thursday, 2009-11-26, Pierre Wieser wrote:
> Hi guys,
>
> I'm the Nautilus-Actions (N-A) maintainer.
> N-A is an extension to Nautilus, the Gnome file manager,
> which allows (advanced) users to add their own actions
> in the context menu.
>
> This is so very similar to Konqueror Service Menus and
> thunar-actions-plugin.

While this might not entirely be the same thing, a quick check of my local
archive of this list found two related sounding threads:

http://lists.freedesktop.org/archives/xdg/2006-February/006094.html
http://lists.freedesktop.org/archives/xdg/2006-June/006612.html

Not sure whether this kind of action handling is deprecated or an orthogonal
concept but it might make sense to at least have a look it :)

Cheers,
Kevin

--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (197 bytes) Download Attachment

Fwd: Actions extensions in File Manager

2009-11-26T03:44:28Z

Hi guys,

I'm the Nautilus-Actions (N-A) maintainer.
N-A is an extension to Nautilus, the Gnome file manager,
which allows (advanced) users to add their own actions
in the context menu.

This is so very similar to Konqueror Service Menus and
thunar-actions-plugin.

While N-A actions used to be stored in GConf system, which
is the general Gnome system for configuration storage, I'm
currently working on making use of desktop entry files.

I know Konqueror Service Menus already makes use of desktop
files ([1]), as Thunar does, or is going to do, in Xfce.

Do you think it would be possible, and profitable for our
users, to be able to share actions between Xfce-KDE-Gnome ?
(this would probably imply having common search path, common
interpretation of extension keys, and so on...)

Actually, I've already started to work with Jelle de Jong
(Xfce), and Michael Pyne (KDE) suggested me to ping this list.

Is this list the correct place to host such a discussion ?
Or should this list only receive some sort of regular
progress points ?
Or does this list not care at all of such a topic ?

A very first draft of draft is available at [2].

Thanks in advance for your opinions
Regards
Pierre

[1] http://developer.kde.org/documentation/tutorials/dot/servicemenus.html
[2] http://www.nautilus-actions.org/?q=node/375
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Third draft of Free Music Player Specifications ready

2009-11-18T06:08:51Z

Jeff Mitchell wrote:

> Hello,
>
> I've implemented suggestions from those that responded to the second
> draft and updated the document to a third draft, available here:
>
> http://gitorious.org/~jefferai/xdg-specs/jefferais-xdg-specs/blobs/d3fef64aa1e2e0528b991b0313fd5b68d78761bd/specifications/FMPSpecs/specification.txt
>
> I'll be on vacation for two weeks starting Wed. and won't have access to
> email, so if you comment on the spec during that time and don't hear
> back from me/don't see updates, don't worry...

Just a reminder -- I'll be out of touch for two weeks. If you have
issues or concerns with this draft please comment while I'm gone so we
can move quicklyish when I get back.

Thanks,
Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (203 bytes) Download Attachment

KDE, Gnome and "Public Infrastructure"

2009-11-14T16:52:15Z

On Mon, Nov 9, 2009 at 4:05 PM, Thiago Macieira <thiago@...> wrote:
>
> As for your argument on "living on the same apartment", I disagree a bit. I
> think we're still at the "same building" stage, where we share our piping,
> heating, electricity, we cooperate in the building council, but we haven't yet
> moved into the same unit.

I'm afraid you are condemned to live in the same unit. At least if you
want more applications to move in. :-)

>
> Another way to see it is from the "Innovator's Solution" book. The author
> expresses a theory in which companies and entities go through cycles of
> interdependency and modularity. I think that applies to us: we're still in the
> state of interdependency, where the product is "not good enough" yet and we
> need a high level of flexibility and the ability to make non-standard
> interfaces, in order to stay competitive.
>

KDE and GNOME are definitely acting like companies, there are a lot of
competitive feelings involved. The problem is, that you are not only
trying to build different cars, but also your own roads. This won't
turn out well.

"[...] uncoordinated markets driven by parties working in their own
self interest are unable to provide these goods in desired
quantities." (http://en.wikipedia.org/wiki/Public_good)

Norbert
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

"distro" devrooms at FOSDEM, possible non-linux devroom

2009-11-14T09:56:10Z

Hi there.
This year FOSDEM orgs tried to group all the distros devroom in
specific rooms, to try to free up slots for other projects.

Last year I tried to set up a non-linux OS devroom for other OSes like
AROS, Haiku, ReactOS, Minix... but couldn't get a slot.
I think it should be possible this year.

In any case, it should be interesting to see cross-distro talks, likely
FreeDesktop.org should be represented there.
http://fosdem.org/2010/distrominiconf

As for the non-linux room if we get one, it'd be still interesting to
discuss which recommendations each OS is willing to follow.
Interestingly also, several OSes (Haiku and now AROS) started porting
Gallium3D for ex.

François.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Desktop Entry Standard: Path key

2009-11-13T15:05:02Z

On Tuesday 01 July 2008, David Faure wrote:

> On Monday 30 June 2008, Brian J. Tarricone wrote:
> > Haha, I'd call that "good design," not a hack: isn't the best way to
> > extend a format to find a way to do so while remaining compatible with
> > it?
>
> Yes, exactly. And this syntax allows for more modifiers to be added in the
> future. KDE support [$i] for "immutable" (i.e. cannot be overridden by a
> local file), and [$d] for "deleted" (when a local file wants to mark a key
> from a global file as being deleted, not just set to empty) Those can be
> combined like [$ei], [$di] etc.
> [$e] also supports shell commands, like Host[$e]=$(hostname)
>
> I'm not asking for all those features to be in the spec (although I
> wouldn't mind that either :), I'm just showing why this solution is nice:
> it's extendable for other things in the future, by providing a location
> where to put key-specific (or group-specific, using [group][$i]) flags.
>
> The issue of backwards compatibility remains, though, current non-kde
> implementations cannot handle Path[$e]=$HOME/Documents. However KDE 3
> already generated such files, so the simplest course of action would be to
> just add support for it in the spec, and see interoperability increase
> over time, while other implementations start supporting this.

Ping?
Is this something we can hope to see in the desktop entry standard and in
other implementations of it?

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Third draft of Free Music Player Specifications ready

2009-11-13T10:59:04Z

Hello,

I've implemented suggestions from those that responded to the second
draft and updated the document to a third draft, available here:

http://gitorious.org/~jefferai/xdg-specs/jefferais-xdg-specs/blobs/d3fef64aa1e2e0528b991b0313fd5b68d78761bd/specifications/FMPSpecs/specification.txt

I'll be on vacation for two weeks starting Wed. and won't have access to
email, so if you comment on the spec during that time and don't hear
back from me/don't see updates, don't worry...

--Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (269 bytes) Download Attachment

Re: Second Draft of Free Music Player Specifications ready

2009-11-06T14:49:40Z

Peter van Hardenberg wrote:

> On Thu, Nov 5, 2009 at 2:29 PM, Jeff Mitchell <mitchell@...
> <mailto:mitchell@...>> wrote:
>
>
> OK, so you're thinking:
>
> FMPS_Rating (canonical user-defined rating)
> FMPS_Rating_Critic_Ralph=Gleason
> FMPS_Rating_Critic_Metacritic
> <snip>
>
> Sounds good to me.
>
>
> Yes, except FTMPS_Rating_Critic_Ralph=Gleason would violate the rule below.
>
>
> > I like where this is going. I'm thinking something like -- any keys in
> > the form FMPS_Rating{_*} must be in the range of 0.0 - 1.0.

I don't follow:

FMPS_Rating:0.95
FMPS_Rating_Critic_Ralph=Gleason:0.85
FMPS_Rating_Critic_Metacritic:0.82

Is there some violation there?

> Looking at http://wiki.musicbrainz.org/Picard_Tag_Mapping suggests that
> for MP3
> leaving a space would be more common, and for Vorbis, using an underscore.
>
> For MP4 we already have a namespace tool, so it would probably be
> something like:
> ----:org.kde.taglib:RATING as per the unit tests.

I can live with that, except I believe org.freedesktop.fmps (or
org.freedesktop.xdg.fmps) would be more appropriate. I would imagine the
latter as it's more fully-descriptive.

--Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (203 bytes) Download Attachment

Re: Second Draft of Free Music Player Specifications ready

2009-11-05T13:36:51Z

Peter van Hardenberg wrote:

> I'd still really like to see the so-called canonical rating take the root of
> the rating namespace. This is, I think, more self-documenting; when in
> doubt, read the least specialized rating. I suppose there may also be
> applications out there which would want to set the rating automatically.
> These would be "canonical" (within the context of this discussion), but
> not "user".
>
>
> FMPS_Rating_User (canonical rating, set by user)
> FMPS_Rating_Critic_Ralph=Gleason
> FMPS_Rating_Critic_Metacritic
> FMPS_Rating_Algorithm_Supercool (collaborative)
> FMPS_Rating_Algorithm_AmarokAutorating (player-specific)

OK, so you're thinking:

FMPS_Rating (canonical user-defined rating)
FMPS_Rating_Critic_Ralph=Gleason
FMPS_Rating_Critic_Metacritic
<snip>

Sounds good to me.

> I like where this is going. I'm thinking something like -- any keys in
> the form FMPS_Rating{_*} must be in the range of 0.0 - 1.0.

Yes, this should be explicitly mentioned.

> One issue we haven't discussed here is how to approach the varying
> styles used in different tag formats. I'd prefer it if we followed local
> conventions. For example, APE and Vorbis comment tags are
> usually CAPSSMUSHEDTOGETHER, whereas ASF is NameSpace/TagName.

I can live with local conventions, but for ease of readability for
someone actually trying to modify their tags by hand -- plus ease of
parsing -- I'd prefer to keep the underscores. So FMPS_Rating on MP3 and
FMPS_RATING on Vorbis work?

> It's worth mentioning that MUSICBRAINZ has claimed its own namespace and
> we should probably follow their lead with that.

Yes, I was planning on that for ASF (just haven't written that in yet).

> I would suggest we include an Appendix section which would give the
> recommended forms for currently available tag formats and advise
> implementors to try to follow local conventions and to propose
> unspecified forms to the XDG list for adoption by the group.

That sounds good.

--Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (269 bytes) Download Attachment

Re: Second Draft of Free Music Player Specifications ready

2009-11-04T19:27:44Z

Daniel Stone wrote:

> On Wed, Nov 04, 2009 at 09:21:13AM -0500, Jeff Mitchell wrote:
>> However, those four little letters "TLDR" established you not as a less
>> experienced person simply asking a question but as a jackass who is
>> wasting everyone's time by commenting on a spec that he couldn't be
>> bothered to read that deals with metadata specifications that he already
>> admitted he's not savvy about.
>
> I read the 'TL;DR' in his original email as being a one-sentence précis
> of the paragraph above: a lightning summary for people who couldn't be
> bothered to read his email properly. So you may have quite radically
> misunderstood his point there ...
>
> TL;DR: The abuse may have been unwarranted.

I don't buy it. Nor do I accept your conclusion of "abuse".

Let's move on. There's a spec to discuss.

--Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (203 bytes) Download Attachment

Re: Second Draft of Free Music Player Specifications ready

2009-11-04T17:54:22Z

On Wed, Nov 04, 2009 at 09:21:13AM -0500, Jeff Mitchell wrote:
> However, those four little letters "TLDR" established you not as a less
> experienced person simply asking a question but as a jackass who is
> wasting everyone's time by commenting on a spec that he couldn't be
> bothered to read that deals with metadata specifications that he already
> admitted he's not savvy about.

I read the 'TL;DR' in his original email as being a one-sentence précis
of the paragraph above: a lightning summary for people who couldn't be
bothered to read his email properly. So you may have quite radically
misunderstood his point there ...

TL;DR: The abuse may have been unwarranted.

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

attachment0 (204 bytes) Download Attachment

Re: Second Draft of Free Music Player Specifications ready

2009-11-04T06:26:54Z

Philipp Wolfer wrote:
> I'm not sure if I understood Tom's comment as it was intended, but I
> see a valid point here:
>
> In every section 1.1, 1.2 and 1.3 there are notes about storing the
> tags as UTF-8 and subsections about storing the tag in ID3 and Vorbis
> Comments. Since those rules should apply for all tags it would be good
> to extract them into a separate Implementation section. This would
> make it easier to extend it to other tagging formats.

This wasn't what Tom was suggesting, but it is indeed a good idea to
consolidate those commonalities into an implementation section. It helps
improve cleanliness, although doesn't really have anything to do with
extending to other tagging formats.

What Tom was suggesting was to remove the bits that cover how to
implement the spec in MP3 and Vorbis and consolidate them in some way
that's not clear. This makes no sense. If the various tags all had
support for this stuff built-in, there'd be no need to even be having
this discussion on finding a workable way to store these values. So you
need to have the spec discuss how to actually implement these values in
the context of what is available with the various tag formats (MP3 using
frame X, Vorbis using normal comments, eventually MP4 using atom Y, and
so on).

The values themselves (and the identifiers) are standardized across the
tag formats, which is the best we can do; but you certainly need to
specify where in each tag format to store them.

--Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (203 bytes) Download Attachment

Re: Second Draft of Free Music Player Specifications ready

2009-11-04T06:21:13Z

Tom Haste wrote:

>> 2009/11/4 Jeff Mitchell <mitchell@... <mailto:mitchell@...>>
>>
>> Tom Haste wrote:
>> > Sigh. Im going to unsubscribe from the xdg list, as it always
>> dives into
>> > snarky comments. Im not going to bother sending this to the list as
>> > well. All I was simply asking, in a light and querying manner, was if
>> > the 2 sections could be left out. Instead of informing me (if it was
>> > such a SIMPLE issue it wouldnt take long to explain) ], you've
>> gone and
>> > made a fairly rude comment in a public forum about me and my SIMPLE
>> > query. Feel free to reply to me and the list if you would like to
>> > explain in a simple and understanding way that merging the 2 concepts
>> > into 1 is such a rediculous idea.
>> >
>> > But again, refer to my first statement, as I will not be recieving it.
>>
>> TL;DR
>>
>> --Jeff
> Let me simplify it for you;
>
>
> Fuck you.
>
>
> Sincerly,
> Toma.

OK. Since you obviously can't grasp it yourself, I'll provide the
explanation.

In your original email to the list, you asked if it wouldn't be better
to make a specific change, which you qualified by "Im not entirely savvy
in this area, but it would seem like something that would be better to
have across the board."

No problems there. Totally reasonable thing to ask, especially for
someone not so familiar with the tag specifications as you said you are.

However, those four little letters "TLDR" established you not as a less
experienced person simply asking a question but as a jackass who is
wasting everyone's time by commenting on a spec that he couldn't be
bothered to read that deals with metadata specifications that he already
admitted he's not savvy about.

That you then followed this up with a direct command (no "wouldn't it be
better" or "I suggest" in it) that doesn't actually help or contribute
to the specification (and in fact is flat-out wrong) makes it all the
more irritating.

I've spent a lot of time getting various people together from all sorts
of projects to work on this, as well as spent a lot of time writing the
first two drafts. So excuse me if I ask a jackass (see above) with
nothing to contribute (which will be explained in my response to
Philipp's email) to stay out of the discussion.

"Fuck you" was classy, though. Real classy.

--Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (203 bytes) Download Attachment

Re: Second Draft of Free Music Player Specifications ready

2009-11-04T06:11:30Z

On Wed, Nov 4, 2009 at 2:33 PM, Jeff Mitchell <mitchell@...> wrote:

> Tom Haste wrote:
>> Howdy,
>>
>> Is there anyway of unifying and some-what future-proofing the MP3/Vorbis
>> sections? What if some other codec becomes popular and uses some sort of
>> other method? Im not entirely savvy in this area, but it would seem like
>> something that would be better to have across the board. I guess with
>> the current layout additional subsections could be added later.
>>
>> TLDR; Lose mp3/vorbis specific bits, change spec to cover both in 1 swoop.
>
> Since you a) didn't bother to read it, and b) don't know what you're
> talking about, please refrain from sticking your nose into discussions
> where you can contributing nothing useful.

I'm not sure if I understood Tom's comment as it was intended, but I
see a valid point here:

In every section 1.1, 1.2 and 1.3 there are notes about storing the
tags as UTF-8 and subsections about storing the tag in ID3 and Vorbis
Comments. Since those rules should apply for all tags it would be good
to extract them into a separate Implementation section. This would
make it easier to extend it to other tagging formats.

Otherwise good work on the specification so far. I've a few points I
want to address, but I will comment later when I have more time.

Philipp
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Second Draft of Free Music Player Specifications ready

2009-11-04T05:33:51Z

Tom Haste wrote:
> Howdy,
>
> Is there anyway of unifying and some-what future-proofing the MP3/Vorbis
> sections? What if some other codec becomes popular and uses some sort of
> other method? Im not entirely savvy in this area, but it would seem like
> something that would be better to have across the board. I guess with
> the current layout additional subsections could be added later.
>
> TLDR; Lose mp3/vorbis specific bits, change spec to cover both in 1 swoop.

Since you a) didn't bother to read it, and b) don't know what you're
talking about, please refrain from sticking your nose into discussions
where you can contributing nothing useful.

Thanks,
Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (203 bytes) Download Attachment

Re: Second Draft of Free Music Player Specifications ready

2009-11-03T19:54:29Z

Howdy,

Is there anyway of unifying and some-what future-proofing the MP3/Vorbis sections? What if some other codec becomes popular and uses some sort of other method? Im not entirely savvy in this area, but it would seem like something that would be better to have across the board. I guess with the current layout additional subsections could be added later.

TLDR; Lose mp3/vorbis specific bits, change spec to cover both in 1 swoop.

Toma

2009/11/4 Jeff Mitchell <mitchell@...>

Hello,

The second draft of the Free Music Player Specifications is ready. A few
words before the link.

First, for those new to the discussion, an archive of previous emails in
the discussion can be found at

http://groups.google.com/group/fmps/topics

The group is read-only, and per agreement with those involved (that
replied) further discussion will take place on xdg@...

I want to thank Milosz Derezynski and Peter van Hardenberg, who replied
to the first draft with suggestions.

Now, some comments about this second draft.

It was suggested that instead of both integer and float values, one or
the other should be picked. It made sense to have floats in all but one
instance (user playcounts), so floats is what I went with. Overall this
decreases the spec's complexity a good amount.

I attempted to clarify things where confusion seemed to exist in
replies; for instance, Milosz's suggestion that it be encouraged that
applications should treat values as they are whenever possible, even if
in some cases they need to round them to display them to the user (for
instance, in a graphical fashion).

I cleaned up the filesystem directive section at Peter's request; it's
indeed simpler (and probably quicker) to just check each directory for a
fmps_ignore file than to check it for text values inside that file and
react appropriately.

I looked at Performer Roles on the MusicBrainz site at Milosz's request,
and decided to keep them in the spec for now. The main reason is that
while MusicBrainz supports MP3 and VorbisComments formats, it has no
capability to support performer roles for WMA or MP4 formats, whereas
there is no reason why support for these formats could not be included
in this specification. Another reason is that the FMPS spec defines
using comments (TXXX for MP3) which eases processing as TXXX is easily
supported by almost any tagging library. By contrast, for MP3 at least,
parsing the TMCL list can be difficult.

That all said, here's the second draft of the spec:

http://gitorious.org/~jefferai/xdg-specs/jefferais-xdg-specs/blobs/mediaspecs/specifications/FMPSpecs/specification.txt

--Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Second Draft of Free Music Player Specifications ready

2009-11-03T18:23:42Z

Peter van Hardenberg wrote:
> Hi all,
>
> Sorry I didn't get a chance to respond again to the last version of the
> thread. Thanks for posting a second draft of the specs. They're shaping
> up nicely and this version is a good improvement.

No problem.

> Deciding on floats for rating seems like mostly a good decision. If a
> number is > 0 and < 1 it's a pretty safe conclusion that it's a float
> rating. On the other hand, it means any track rated maximally will be a
> "1", which is widely used as a very low value. Perhaps the solution
> there is to say that the float value must include a decimal point and a
> zero to eliminate ambiguity of interpretation.

Good idea. I'll put that in the next draft.

> I'd like to voice some concern about writing two forms of rating to the
> file. Also, though Amarok tracks two forms of rating, I don't think the
> current automatic vs user distinction makes sense. For example, if I
> introduce automatic rating to Songbird through an extension, I don't
> think it would be good for me to overwrite the existing Amarok inserted
> value created by a different algorithm. If you feel strongly about
> including it, perhaps instead of using two specific forms of rating
> (auto and user), we could consider arbitrary types of rating.

<snip>

I have an alternate proposal, based off of yours: what if the automatic
ratings were identified by the algorithm used. The algorithm could
include User as the canonical rating, and Critic ratings -- I really
like that idea and could see interesting uses for it -- as human brains
are an algorithm unto themselves. Then algorithms could be identified by
name. That way, if two players wanted to collaborate on a rating
algorithm, they could easily interoperate; otherwise, no one will
(hopefully) clobber each other. So you'd end up with something like:

FMPS_Rating_User (canonical rating, set by user)
FMPS_Rating_Critic_Ralph=Gleason
FMPS_Rating_Critic_Metacritic
FMPS_Rating_Algorithm_Supercool (collaborative)
FMPS_Rating_Algorithm_AmarokAutorating (player-specific)

Of course, nothing stops one from putting in a frame like

> Amarok_AutomaticRating
> Songbird_AutomaticRating
> Songbird_Rating_User:pvh
> Songbird_Rating_Metacritic

but one could be assured that if it starts with FMPS, it adheres to the
spec.

Thoughts?

--Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (269 bytes) Download Attachment

Re: Second Draft of Free Music Player Specifications ready

2009-11-03T13:37:18Z

Hi all,

Sorry I didn't get a chance to respond again to the last version of the thread. Thanks for posting a second draft of the specs. They're shaping up nicely and this version is a good improvement.

Deciding on floats for rating seems like mostly a good decision. If a number is > 0 and < 1 it's a pretty safe conclusion that it's a float rating. On the other hand, it means any track rated maximally will be a "1", which is widely used as a very low value. Perhaps the solution there is to say that the float value must include a decimal point and a zero to eliminate ambiguity of interpretation.

I'd like to voice some concern about writing two forms of rating to the file. Also, though Amarok tracks two forms of rating, I don't think the current automatic vs user distinction makes sense. For example, if I introduce automatic rating to Songbird through an extension, I don't think it would be good for me to overwrite the existing Amarok inserted value created by a different algorithm. If you feel strongly about including it, perhaps instead of using two specific forms of rating (auto and user), we could consider arbitrary types of rating.

For example, the syntax could be something along the lines of:

FMPS_Rating
or for more specific kinds of rating
FMPS_Rating_Automatic
or
FMPS_Rating_Critic
or
FMPS_Rating_User:pvh

Perhaps;

FMPS_Rating
Amarok_AutomaticRating
Songbird_AutomaticRating
Songbird_Rating_User:pvh
Songbird_Rating_Metacritic

and so on. I think having a single canonical rating would be a big advantage, even if there are other values present.

-pvh

On Tue, Nov 3, 2009 at 1:07 PM, Jeff Mitchell <mitchell@...> wrote:

Hello,

The second draft of the Free Music Player Specifications is ready. A few
words before the link.

First, for those new to the discussion, an archive of previous emails in
the discussion can be found at

http://groups.google.com/group/fmps/topics

The group is read-only, and per agreement with those involved (that
replied) further discussion will take place on xdg@...

I want to thank Milosz Derezynski and Peter van Hardenberg, who replied
to the first draft with suggestions.

Now, some comments about this second draft.

It was suggested that instead of both integer and float values, one or
the other should be picked. It made sense to have floats in all but one
instance (user playcounts), so floats is what I went with. Overall this
decreases the spec's complexity a good amount.

I attempted to clarify things where confusion seemed to exist in
replies; for instance, Milosz's suggestion that it be encouraged that
applications should treat values as they are whenever possible, even if
in some cases they need to round them to display them to the user (for
instance, in a graphical fashion).

I cleaned up the filesystem directive section at Peter's request; it's
indeed simpler (and probably quicker) to just check each directory for a
fmps_ignore file than to check it for text values inside that file and
react appropriately.

I looked at Performer Roles on the MusicBrainz site at Milosz's request,
and decided to keep them in the spec for now. The main reason is that
while MusicBrainz supports MP3 and VorbisComments formats, it has no
capability to support performer roles for WMA or MP4 formats, whereas
there is no reason why support for these formats could not be included
in this specification. Another reason is that the FMPS spec defines
using comments (TXXX for MP3) which eases processing as TXXX is easily
supported by almost any tagging library. By contrast, for MP3 at least,
parsing the TMCL list can be difficult.

That all said, here's the second draft of the spec:

http://gitorious.org/~jefferai/xdg-specs/jefferais-xdg-specs/blobs/mediaspecs/specifications/FMPSpecs/specification.txt

--Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

--
Peter van Hardenberg
Victoria, BC, Canada
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut

--
Peter van Hardenberg
Victoria, BC, Canada
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Second Draft of Free Music Player Specifications ready

2009-11-03T13:07:44Z

Hello,

The second draft of the Free Music Player Specifications is ready. A few
words before the link.

First, for those new to the discussion, an archive of previous emails in
the discussion can be found at

http://groups.google.com/group/fmps/topics

The group is read-only, and per agreement with those involved (that
replied) further discussion will take place on xdg@...

I want to thank Milosz Derezynski and Peter van Hardenberg, who replied
to the first draft with suggestions.

Now, some comments about this second draft.

It was suggested that instead of both integer and float values, one or
the other should be picked. It made sense to have floats in all but one
instance (user playcounts), so floats is what I went with. Overall this
decreases the spec's complexity a good amount.

I attempted to clarify things where confusion seemed to exist in
replies; for instance, Milosz's suggestion that it be encouraged that
applications should treat values as they are whenever possible, even if
in some cases they need to round them to display them to the user (for
instance, in a graphical fashion).

I cleaned up the filesystem directive section at Peter's request; it's
indeed simpler (and probably quicker) to just check each directory for a
fmps_ignore file than to check it for text values inside that file and
react appropriately.

I looked at Performer Roles on the MusicBrainz site at Milosz's request,
and decided to keep them in the spec for now. The main reason is that
while MusicBrainz supports MP3 and VorbisComments formats, it has no
capability to support performer roles for WMA or MP4 formats, whereas
there is no reason why support for these formats could not be included
in this specification. Another reason is that the FMPS spec defines
using comments (TXXX for MP3) which eases processing as TXXX is easily
supported by almost any tagging library. By contrast, for MP3 at least,
parsing the TMCL list can be difficult.

That all said, here's the second draft of the spec:

http://gitorious.org/~jefferai/xdg-specs/jefferais-xdg-specs/blobs/mediaspecs/specifications/FMPSpecs/specification.txt

--Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (203 bytes) Download Attachment

Re: _NET_WM_STATE

2009-11-02T02:39:29Z

On Wednesday 28 of October 2009, Brian J. Tarricone wrote:

> On 10/28/2009 05:16 AM, Fabien Meghazi wrote:
> > Hi all,
> >
> > It seems that at least one atom should be added to the list of
> > _NET_WM_STATE
> >
> > Namely : _NET_WM_STATE_MINIMIZED
> >
> > See https://bugs.launchpad.net/ubuntu/+source/wmctrl/+bug/260875
> >
> > I guess a _NET_WM_STATE_ICONIFIED would be welcome too.
> >
> > What do you think ?

There is a special list for the EWMH spec,
http://mail.gnome.org/mailman/listinfo/wm-spec-list .

There have been already several discussions on the list about a special flag
for minimized windows, but never with a conclusion because of disagreements
on exact semantics. You can try your luck and bring it up again. There are
one or two bugreports in KDE bugzilla that would be fixed by introducing such
flag too.

> _NET_WM_STATE_HIDDEN serves this purpose. The bug you reference is
> marked invalid and references _HIDDEN. There is no semantic difference
> between hidden, minimized, and iconified.

Then the bug resolution itself is invalid. The parts from the spec quoted
there themselves claim otherwise.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12 tel: +420 284 084 672
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: _NET_WM_STATE

2009-10-29T09:20:31Z

On Thu, Oct 29, 2009 at 9:12 AM, Fabien Meghazi <agr@...> wrote:

>> _NET_WM_STATE_HIDDEN serves this purpose. The bug you reference is
>> marked invalid and references _HIDDEN. There is no semantic difference
>> between hidden, minimized, and iconified.
>
> I'm confused here.
>
> If I understand correctly, you say that _NET_WM_STATE_HIDDEN serves
> the purpose of minimizing window.
>
> When using this in a terminal window
>
> wmctrl -r :ACTIVE: -b add,hidden
>
> the terminal window should be minimized. But it does not (while wmctrl
> does it's job correctly).
>
> So if I understand you correctly, the bug is in metacity ? It does not
> minimize windows when receiving _NET_WM_STATE_HIDDEN ??
>
>

I'd say the bug is wmctrl not using XIconifyWindow [1] but perhaps
that is out of scope for what it is trying to do.

[1] http://tronche.com/gui/x/xlib/ICC/client-to-window-manager/XIconifyWindow.html

--
Travis Watkins
http://www.realistanew.com
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: _NET_WM_STATE

2009-10-29T07:12:59Z

> _NET_WM_STATE_HIDDEN serves this purpose. The bug you reference is
> marked invalid and references _HIDDEN. There is no semantic difference
> between hidden, minimized, and iconified.

I'm confused here.

If I understand correctly, you say that _NET_WM_STATE_HIDDEN serves
the purpose of minimizing window.

When using this in a terminal window

wmctrl -r :ACTIVE: -b add,hidden

the terminal window should be minimized. But it does not (while wmctrl
does it's job correctly).

So if I understand you correctly, the bug is in metacity ? It does not
minimize windows when receiving _NET_WM_STATE_HIDDEN ??

--
Fabien Meghazi

Website: http://www.amigrave.com
Email: agr@...
IM: amigrave@...
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: _NET_WM_STATE

2009-10-28T09:40:27Z

On 10/28/2009 05:16 AM, Fabien Meghazi wrote:

> Hi all,
>
> It seems that at least one atom should be added to the list of _NET_WM_STATE
>
> Namely : _NET_WM_STATE_MINIMIZED
>
> See https://bugs.launchpad.net/ubuntu/+source/wmctrl/+bug/260875
>
> I guess a _NET_WM_STATE_ICONIFIED would be welcome too.
>
> What do you think ?

_NET_WM_STATE_HIDDEN serves this purpose. The bug you reference is
marked invalid and references _HIDDEN. There is no semantic difference
between hidden, minimized, and iconified.

-brian
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

_NET_WM_STATE

2009-10-28T05:16:52Z

Hi all,

It seems that at least one atom should be added to the list of _NET_WM_STATE

Namely : _NET_WM_STATE_MINIMIZED

See https://bugs.launchpad.net/ubuntu/+source/wmctrl/+bug/260875

I guess a _NET_WM_STATE_ICONIFIED would be welcome too.

What do you think ?

--
Fabien Meghazi

Website: http://www.amigrave.com
Email: agr@...
IM: amigrave@...
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Moved to git: xdg-user-dirs, default-icon-theme, xdgmime, shared-mime-info

2009-10-12T09:49:45Z

On Mon, 2009-10-12 at 10:18 -0600, Aaron J. Seigo wrote:

> On October 12, 2009, Jannis Pohlmann wrote:
> > I totally agree, all of these specs should be hosted on fd.o, but this
> > was discussed over and over again and none of the administrative people
> > ever commented on any of the requests to improve things and make the
> > fd.o spec "approval" and maintenance process more transparent. That's
> > why some of them ended up on gitorious (temporarily).
>
> exactly; i'd be MORE than happy to see the repo on fd.o. the only reason it
> isn't is that getting an account with fd.o so you can put your clones up where
> we can all get to them in one place is far too hard. having things like merge
> requests is a wonderful bonus as well, but not a deal breaker. having a high
> barrier to entry is, however.
>
> that said, we can in the meantime we can improve the spec process which means
> better meta-documentation for them, keeping them centralized, etc. that's far
> more important than where they are for the moment.

You can put your clones wherever you want, on gitorious, github, or your
KDE public_html folder. But the master repo for the specs absolutely has
to be on fd.o.

Where they are is important because Vincent just added git support to
the update.py script that keeps the specs up-to-date on the website. The
specs are checked out from git.fd.o.

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Moved to git: xdg-user-dirs, default-icon-theme, xdgmime, shared-mime-info

2009-10-12T09:18:35Z

On October 12, 2009, Jannis Pohlmann wrote:
> I totally agree, all of these specs should be hosted on fd.o, but this
> was discussed over and over again and none of the administrative people
> ever commented on any of the requests to improve things and make the
> fd.o spec "approval" and maintenance process more transparent. That's
> why some of them ended up on gitorious (temporarily).

exactly; i'd be MORE than happy to see the repo on fd.o. the only reason it
isn't is that getting an account with fd.o so you can put your clones up where
we can all get to them in one place is far too hard. having things like merge
requests is a wonderful bonus as well, but not a deal breaker. having a high
barrier to entry is, however.

that said, we can in the meantime we can improve the spec process which means
better meta-documentation for them, keeping them centralized, etc. that's far
more important than where they are for the moment.

--
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

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (204 bytes) Download Attachment

Re: Moved to git: xdg-user-dirs, default-icon-theme, xdgmime, shared-mime-info

2009-10-12T09:01:38Z

On Mon, 12 Oct 2009 16:53:32 +0100
Bastien Nocera <hadess@...> wrote:

> Why would we want the master git repo to be hosted on gitorious? fd.o
> already provides the ability to host git repos...

Is there any useful documentation on who is responsible for the
repository administration and granting commit permissions? Requesting
commit access via bugzilla is a fairly bad substitute for the repo
management functionality gitorious provides.

I totally agree, all of these specs should be hosted on fd.o, but this
was discussed over and over again and none of the administrative people
ever commented on any of the requests to improve things and make the
fd.o spec "approval" and maintenance process more transparent. That's
why some of them ended up on gitorious (temporarily).

- Jannis

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (204 bytes) Download Attachment

Re: Moved to git: xdg-user-dirs, default-icon-theme, xdgmime, shared-mime-info

2009-10-12T08:53:32Z

On Mon, 2009-10-12 at 09:48 -0600, Aaron J. Seigo wrote:

> On October 7, 2009, Alexander Larsson wrote:
> > http://cgit.freedesktop.org/xdg/default-icon-theme/
>
> while the other three are pure software repositories, but this one contains a
> specification. it would be great if it could join other specifications that
> are alive and in use in one git repo that:
>
> * is more freely accessible to all
> * can be found next to all the other specs
> * can provide metadata as to who is using it and since when
>
> would it be alright with you (and those working on the icon specs) if i added
> them to http://gitorious.org/xdg-specs/ which would then be where future work
> on them takes place? i'm quite happy to do the work of adding it to that repo,
> documenting which projects are using it since when, etc., but i don't want to
> create a dead fork either. whomever needs commit access to the specs can have
> it as well ...

Why would we want the master git repo to be hosted on gitorious? fd.o
already provides the ability to host git repos...

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Moved to git: xdg-user-dirs, default-icon-theme, xdgmime, shared-mime-info

2009-10-12T08:48:51Z

On October 7, 2009, Alexander Larsson wrote:
> http://cgit.freedesktop.org/xdg/default-icon-theme/

while the other three are pure software repositories, but this one contains a
specification. it would be great if it could join other specifications that
are alive and in use in one git repo that:

* is more freely accessible to all
* can be found next to all the other specs
* can provide metadata as to who is using it and since when

would it be alright with you (and those working on the icon specs) if i added
them to http://gitorious.org/xdg-specs/ which would then be where future work
on them takes place? i'm quite happy to do the work of adding it to that repo,
documenting which projects are using it since when, etc., but i don't want to
create a dead fork either. whomever needs commit access to the specs can have
it as well ...

--
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

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

signature.asc (204 bytes) Download Attachment