Re: Video standards

[Pekka Paalanen]

On Thu, 11 Apr 2024 22:22:01 -0300
salsaman  wrote:

> Sorry for the delay, there was a lot to respond to, most of it not relevant
> to the XDG discussion. I suggest we limit discussion on the mailing list to
> whatever is relevant. Pekka, if you want to continue this discussion, then
> we can chat in private off the mailing list.
> 

Sorry from my behalf as well, I've been spread too thin lately.

> 
> On Mon, 8 Apr 2024 at 08:42, Pekka Paalanen 
> wrote:
> 
> > On Fri, 5 Apr 2024 19:16:55 -0300
> > salsaman  wrote:
> >  
> > > On Fri, 5 Apr 2024 at 12:57, Pekka Paalanen <
> > pekka.paala...@haloniitty.fi>
> > > wrote:
> > >  
> > > > On Fri, 5 Apr 2024 08:28:27 -0300
> > > > salsaman  wrote:
> > > >  
> > > > > I don't think you are paying enough attention to the main points. Ir  
> > is  
> > > > not  
> > > > > simply a case of extending the fourcc values to include more. If I  
> > didn't  
> > > > > make it clear enough, the whole fourcc system is obscure, inadequate,
> > > > > ambiguous. The only reason ever to use it would be when you don't  
> > have  
> > > > meta  
> > > > > data and you are forced to encode the format in the first 4 bytes.  


> Now to get back to my proposal , all I am suggesting is an agreed upon set
> of constants. It shouldn't stop anyone from doing anything they would
> normally do; what I am suggesting now is that projects that want to provide
> full interoperability provide an API to convert between project constants
> and XDG constants.  My preference would be to implement the conversions as
> macros in a compatibility header to avoid having to link with libraries.
> Then it is a simple matter of, if I wanted to send metadata to Wayland, I
> translate to XDG constants using my compatibility macro, then from XDG
> constants to Wayland values using the Wayland XDG compatibility API. libav
> can implement their own compatibility header, or someone could contribute a
> patch. Pipewire can make an XDG compat header and now suddenly all these
> apps and frameworks become compatible with each other ! Due to the network
> effect, each new project which participates increases the number of
> possibilities exponentially.

...

> 
> None of that will change, all I am suggesting is adding glue to help the
> building blocks gel together better.
> All pf this is optional, nobody will be forced to include this project <->
> XDG compatibiliity but as more projects join the advantages of
> participating increase.
> 
> Just to reiterate - nothing internal to a projecr need change in any way,
> Projects participate by publishing exrenal APIs for two way conversion.
> We are talking only about constant enumerations. The meanings will be
> defined with reference to existing standards, so XDG_VIDEO_GAMMA_BT709
> could have value 2, and it is defined as representing the gamma transfer
> function specified in the bt709 standard.
> 
> Then suppose in my project I have WEED_GAMMA_BT709 with value 3, then I
> make a comoat macro for gamma XDG_GAMMA_TO_PROJECT(gamma_type, which given
> value 2, returns 3, and the corresponding PROJECT_GAMMA_TO_XDG converts 3
> to 2.
> 
> It's that simple.

Right, as long as the things are enumerated rather than numeric, and
the common enumerations are each for strictly orthogonal aspects of
color encoding. It gets complicated when one enumeration combines
things A and B, and another enumeration combines things B and C
instead.

What about all the practicalities for allowing lots of programs to
interoperate:

- Defining an API or IPC protocol between programs so that they can
  actually pass messages and images from one to another?

- How to find available sources and sinks in a system?

- How to decide where to connect, which program feeds into which program?

- How to negotiate a common set of image parameters so that both sides
  of a connection can handle them?


> > > >  
> > > > > Colorimetry is only relevant when displaying on a monitor. In the  
> > video  
> > > > > world we just have red, green and blue (plus alpha, y, u and v).  
> > These  
> > > > are  
> > > > > just labels for the colour channels, mapping them to bit formats.  
> > > >
> > > > That is a very surprising opinion. Have you worked on HDR imagery?
> > > > Or wide color gamut?
> > > >  
> > >
> > > As I have mentioned several times, these are display output parameters,
> > >  The only details which are relevant are the yuv/rgb conversion constants
> > > and the gamma transfer values, With those I can convert berween any two
> > > formats, which is all that is necessary for the steps between decoding  
> > and  
> > > encoding / display.  
> >
> > I am puzzled. Let's say we have BT.601 525-line video, and it needs to
> > be re-coded for a BT.2020 container. The yuv/rgb conversion matrices
> > are different, sure. But the primaries are different as well. If you
> > ignore the difference in primaries, does that not result in unnaturally
> > color saturated image when the video is eventually 

Re: Is there a way to detect if the System is XDG independently of the environment variables?

[Simon McVittie]

On Fri, 29 Mar 2024 at 14:48:35 -0230, Jesús Gómez wrote:
> I understand that the XDG_* environment variables are options for the users to
> customize their system, but the lack of them doesn't mean that the system is
> not following XDG.

Correct. If none of the XDG environment variables are set, they all have
documented fallbacks (with the possible exception of XDG_RUNTIME_DIR,
which behaves rather differently, and so there is not necessarily any
single correct fallback).

> I've been thinking about this, and the more I read the specifications, it 
> seems
> to me that "Systems" don't have that responsibility and it is just an decision
> of the applications to follow the specifications or not.

Where you say "applications", strictly speaking it's more like
"applications and libraries", but otherwise yes.

On Linux, I'd say that well-behaved applications and libraries should
use the XDG paths, unless they have reasons not to. For example, older
applications and libraries often have a traditional/legacy path that
they prefer to use, and that can be a valid reason - but even then, it
can make sense to use the XDG paths in addition to a traditional/legacy
path, like the way git supports both $XDG_CONFIG_HOME/git/config and
the more traditional ~/.gitconfig.

On other open source Unix platforms (*BSD, Hurd, etc.) the same behaviour
as Linux makes sense. Ditto on proprietary Unix platforms, if any are still
practically relevant.

In fact, I'd go so far as to say that the only platforms where the
XDG paths would *not* be appropriate are the ones that have their own
well-known directory layout - such as Windows, the macOS/iOS/etc. family,
and Android - on which the right paths to use are the ones that you can
discover from appropriate OS APIs.

Good examples to follow on this include GLib, Qt and SDL, all of which
have their own "give me the right path for..." APIs with separate code
paths for at least Unix (XDG) and Windows.

On Wed, 10 Apr 2024 at 21:02:13 -0230, Jesús Gómez wrote:
> """ Your process runs in a system following XDG if the environment variable
> XDG_CONFIG_DIRS is defined OR the folder /etc/xdg exists.  """

No, please don't assume that. If there has not yet been any need to
configure XDG apps/libraries on a system-wide basis, then /etc/xdg might
not exist at all.

smcv

Re: Is there a way to detect if the System is XDG independently of the environment variables?

[Jesús Gómez]

A direct message informed me that FreeBSD would use `/usr/local/etc/xdg` as
the default for `$XDG_CONFIG_DIRS`.

Does anybody know how they make applications that strictly follow the XDG
Base Directory specifications work fine in their system? Is FreeBSD
guaranteeing the existence of the $XDG_CONFIG_DIRS?

I've been searching for inspiration in some open code bases, and so far,
the default is FIXED in the code to `/etc/xdg`. Two examples are Emacs xdg
library[1] and java-xdg[2].

Besides this, do you think it is a sane heuristic to check for
$XDG_CONFIG_DIRS or /etc/xdg as explained previously?

[1]
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/xdg.el?id=0fab2649e288c7a350018293443e709eba6b0fe2#n131
[2]
https://github.com/omajid/xdg-java/blob/a6cab0e204190d65632d9f4d073093aeda074c9c/src/main/java/org/freedesktop/BaseDirectory.java#L107

El mié, 10 abr 2024 a la(s) 9:02 p.m., Jesús Gómez (jgo...@gmail.com)
escribió:

> I'm going to make a claim.
>
> """ Your process runs in a system following XDG if the environment
> variable XDG_CONFIG_DIRS is defined OR the folder /etc/xdg exists.  """
>
> Two things are essential to make that claim.  The name of the folder uses
> the term `xdg`.  This is different than the rules mentioning `/usr/share`
> or the folders at $HOME (e.g. $HOME/.config) in 2 aspects: 1, folders like
> `/usr/share` are not unique to systems following the XDG convention; 2, the
> folders at $HOME could not exists at first, and still be in a system
> following the conventions and so, the process could create those folders in
> the first place.
>
> A test like this (if the assumptions I made are valid) could be used by
> applications like Clojure (my current interest) to switch between
> supporting or not XDG.
>
> But first, I would like to verify that this claim makes sense to you. I
> would appreciate any feedback you can give me.
>
>
> El vie, 29 mar 2024 a la(s) 2:48 p.m., Jesús Gómez (jgo...@gmail.com)
> escribió:
>
>> Hi.
>>
>> I understand that the XDG_* environment variables are options for the
>> users to customize their system, but the lack of them doesn't mean that the
>> system is not following XDG.
>>
>> I've been thinking about this, and the more I read the specifications, it
>> seems to me that "Systems" don't have that responsibility and it is just an
>> decision of the applications to follow the specifications or not.
>>
>> I'm thinking this because of the Clojure CLI tool.  I've been discussing
>> about this with the maintainers and there are 2 options:
>>
>> 1. Or Clojure could detect that the system is following the XDG
>> specifications (even when no XDG environment variables are in place).
>> 2. Define a flag at any time (installation, execution, packaging, etc., I
>> think they will decide that part) for following these specs.
>>
>> I think the more probable path is the flag, and it corresponds with the
>> idea that the System doesn't have a responsibility to express whether it
>> follows or not the specifications; but still, given only curiosity, I would
>> still like to know if the Systems can publish that or if an application can
>> detect that.
>>
>> Thank you!
>>
>

Re: Is there a way to detect if the System is XDG independently of the environment variables?

[Jesús Gómez]

I'm going to make a claim.

""" Your process runs in a system following XDG if the environment variable
XDG_CONFIG_DIRS is defined OR the folder /etc/xdg exists.  """

Two things are essential to make that claim.  The name of the folder uses
the term `xdg`.  This is different than the rules mentioning `/usr/share`
or the folders at $HOME (e.g. $HOME/.config) in 2 aspects: 1, folders like
`/usr/share` are not unique to systems following the XDG convention; 2, the
folders at $HOME could not exists at first, and still be in a system
following the conventions and so, the process could create those folders in
the first place.

A test like this (if the assumptions I made are valid) could be used by
applications like Clojure (my current interest) to switch between
supporting or not XDG.

But first, I would like to verify that this claim makes sense to you. I
would appreciate any feedback you can give me.


El vie, 29 mar 2024 a la(s) 2:48 p.m., Jesús Gómez (jgo...@gmail.com)
escribió:

> Hi.
>
> I understand that the XDG_* environment variables are options for the
> users to customize their system, but the lack of them doesn't mean that the
> system is not following XDG.
>
> I've been thinking about this, and the more I read the specifications, it
> seems to me that "Systems" don't have that responsibility and it is just an
> decision of the applications to follow the specifications or not.
>
> I'm thinking this because of the Clojure CLI tool.  I've been discussing
> about this with the maintainers and there are 2 options:
>
> 1. Or Clojure could detect that the system is following the XDG
> specifications (even when no XDG environment variables are in place).
> 2. Define a flag at any time (installation, execution, packaging, etc., I
> think they will decide that part) for following these specs.
>
> I think the more probable path is the flag, and it corresponds with the
> idea that the System doesn't have a responsibility to express whether it
> follows or not the specifications; but still, given only curiosity, I would
> still like to know if the Systems can publish that or if an application can
> detect that.
>
> Thank you!
>

Re: In search for a better way to handle GPU offloading

[Jonas Ådahl]

On Wed, Apr 10, 2024 at 02:46:30PM +0200, Werner Sembach wrote:
> Hi all,
> 
> I'm task to evaluate a better way to handle GPU offloading then it's
> currently done on Linux with environment variables.
> 
> The Goal is to have some kind of GUI editable database/config file where the
> user can add and remove binaries/programs.
> 
> For this I would like to push
> https://gitlab.freedesktop.org/glvnd/libglvnd/-/merge_requests/224 and
> https://gitlab.freedesktop.org/glvnd/libglvnd/-/merge_requests/228 as it
> seems to be a good basis for exactly this. However the discussion on them is
> stale, not because of technical difficulties, but because of lack of
> interest it seems.

I'm not convinced a specialized format stored somewhere is necessarily a
good idea in how to achieve this. A really global list would have to be
managed by root, and would it be a configuration file stored somewhere
in $HOME, it would now be inaccessible to sandboxed applications.

For OpenGL/Vulkan clients using Wayland I imagine something that doesn't
use environment variables can be achieved using the linux_dmabuf
protocol, which has the concept of "preferred main device". If
applications are configured in whatever way, and if there is integration
with the Wayland compositor, perhaps this way is a better option.

It'll leave compositors and desktop environments more free to make
decisions how to present and store user preferences, which I think makes
much more sense than a text file and matching rules on
/proc//cmdline, which seems really terrible from a UX perspective.

I realize X11 is a different story, I suspect something similar to the
Wayland protocol would need to be invented there to achieve something
similar, but I don't really know the details about how X11+EGL and GLX
works.


Jonas

> 
> Are there other people here interested in this topic?
> 
> Best regards,
> 
> Werner Sembach
> 

In search for a better way to handle GPU offloading

[Werner Sembach]

Hi all,

I'm task to evaluate a better way to handle GPU offloading then it's currently 
done on Linux with environment variables.


The Goal is to have some kind of GUI editable database/config file where the 
user can add and remove binaries/programs.


For this I would like to push 
https://gitlab.freedesktop.org/glvnd/libglvnd/-/merge_requests/224 and 
https://gitlab.freedesktop.org/glvnd/libglvnd/-/merge_requests/228 as it seems 
to be a good basis for exactly this. However the discussion on them is stale, 
not because of technical difficulties, but because of lack of interest it seems.


Are there other people here interested in this topic?

Best regards,

Werner Sembach

Re: A spec to set default terminal applications?

[Vladimir Kudrya]

Hi everyone!

It once had a good momentum, major issues addressed. The request is 
still open, what's next?


On 01/12/2023 01.34, Vladimir Kudrya wrote:


FYI, The proposed xdg-terminal-exec 
 now relies on 
stock desktop entries, the shell implementation is optimized, 
experimental cache support is in the works.


The spec proposal is updated 
.

Clojure is working on better supporting XDG base directory rules

[Jesús Gómez]

Hello.

I just wanted to mention that the Clojure project had recently accepted to
work on enhancing its support to XDG base directory rules, as described in
their ticket TDEPS-262[1]

Thanks to this list, I've received some good information (but as direct
messages) that helped me make the case and some other good
considerations[2] for the eventual patch.

So, please use this message as a heads-up, and I will use it as a thread
for later discussion while working on it.

[1] https://clojure.atlassian.net/browse/TDEPS-262

Re: Video standards

[Pekka Paalanen]

On Fri, 5 Apr 2024 19:16:55 -0300
salsaman  wrote:

> On Fri, 5 Apr 2024 at 12:57, Pekka Paalanen 
> wrote:
> 
> > On Fri, 5 Apr 2024 08:28:27 -0300
> > salsaman  wrote:
> >  
> > > I don't think you are paying enough attention to the main points. Ir is  
> > not  
> > > simply a case of extending the fourcc values to include more. If I didn't
> > > make it clear enough, the whole fourcc system is obscure, inadequate,
> > > ambiguous. The only reason ever to use it would be when you don't have  
> > meta  
> > > data and you are forced to encode the format in the first 4 bytes.  
> >
> > Right. You must be talking about some other fourcc system. There are
> > many of them, and some combine multiple orthogonal things into a single
> > enumeration, which then becomes very difficult to extend and work with.
> >
> > drm_fourcc.h is not one of those.
> >  
> 
> I am talking about any system which tries to enumerate palettes (pixel
> formats) in four bytes in a non sequential way.
> In my own system (Weed) for example, all RGB palettes are in the range 1 -
> 511, yuv palettes are 512 - 1023, alpha are 1024 +

Interesting use of the term "palette". I've never heard of it being
used synonymous to pixel format. The only usage of "palette" I've
seen so far in the context of digital imagery is a mapping from
color-index values to color channel value tuples, a form of look-up
table.

With such profound disconnect on terminology, it is no wonder we
cannot seem to be able to communicate efficiently. Forgive me the
lengthy writings below, I'm just trying to avoid misunderstandings. You
and I obviously have very different underlying assumptions of what we
are even doing.

> In fact this header is enough to define every possible palette, there are
> standard enumerations for the most commonly used palettes, and
> advanced palettes allows for the composition of new ones. In there also I
> have symbolic names for gamma types and yuv details,
> 
> interlacing and flags for pre-posr alpha are kept in another header,
> 
> 
> 
> 
> >
> > Metadata is always necessary anyway, either implied or explicit.
> >  
> 
> Exactly, so I don't know why you keep mentioning fourcc as if it were some
> kind of complete solution.

It's not complete. It's a building block.

drm_fourcc.h is a very widely used standard, so it would be better to
build on it than to replace it. drm_fourcc.h pixel format system does
not conflict with the addition of metadata.

It is very common to allocate image buffers using specific pixel format
and format modifier (and width, height, stride), because those are
necessary for computing the amount of memory needed for an image. Other
metadata does not affect the amount of memory, or the layout of the
memory, so it is natural to keep this and the other metadata
independent of each other.

It has also been very common to have all the other metadata implicit,
especially colorimetry. For computer graphics, that has been the sRGB
assumption. As long as the assumption was good enough, no other
metadata was needed, and as a result the ecosystem is well developed to
communicate and use pixel formats and more recently also format
modifiers which are crucial for hardware accelerated graphics and video.

Therefore, we have a huge amount of infrastructure that can handle
pixel formats, either drm_fourcc.h or equivalent. If we were to switch
to a fundamentally different pixel format system, all that
infrastructure would need to be replaced. That's unlikely to happen.
What would happen is that if something uses a different pixel format
system, it will just end up being converted to and from drm_fourcc.h.
It adds overhead and room for mistakes, and it is possibly a
fundamentally imperfect translation, while the benefits I have not yet
understood.

This is why I am so keenly interested in what problem you have set out
to solve by introducing a new pixel format system. The benefits need to
be considerable to exceed the disadvantages.

I see the ability to combine independent building blocks to build a
complete image description as an advantage, because there will always
be something new in the future to add, that has previously been either
ignored, assumed, or not known of.

> >  
> > > Colorimetry is only relevant when displaying on a monitor. In the video
> > > world we just have red, green and blue (plus alpha, y, u and v). These  
> > are  
> > > just labels for the colour channels, mapping them to bit formats.  
> >
> > That is a very surprising opinion. Have you worked on HDR imagery?
> > Or wide color gamut?
> >  
> 
> As I have mentioned several times, these are display output parameters,
>  The only details which are relevant are the yuv/rgb conversion constants
> and the gamma transfer values, With those I can convert berween any two
> formats, which is all that is necessary for the steps between decoding and
> encoding / display.

I am puzzled. Let's say we have BT.601 525-line video, and it needs to
be re-coded for a 

Re: Video standards

[salsaman]

On Fri, 5 Apr 2024 at 12:57, Pekka Paalanen 
wrote:

> On Fri, 5 Apr 2024 08:28:27 -0300
> salsaman  wrote:
>
> > I don't think you are paying enough attention to the main points. Ir is
> not
> > simply a case of extending the fourcc values to include more. If I didn't
> > make it clear enough, the whole fourcc system is obscure, inadequate,
> > ambiguous. The only reason ever to use it would be when you don't have
> meta
> > data and you are forced to encode the format in the first 4 bytes.
>
> Right. You must be talking about some other fourcc system. There are
> many of them, and some combine multiple orthogonal things into a single
> enumeration, which then becomes very difficult to extend and work with.
>
> drm_fourcc.h is not one of those.
>

I am talking about any system which tries to enumerate palettes (pixel
formats) in four bytes in a non sequential way.
In my own system (Weed) for example, all RGB palettes are in the range 1 -
511, yuv palettes are 512 - 1023, alpha are 1024 +

In fact this header is enough to define every possible palette, there are
standard enumerations for the most commonly used palettes, and
advanced palettes allows for the composition of new ones. In there also I
have symbolic names for gamma types and yuv details,

interlacing and flags for pre-posr alpha are kept in another header,




>
> Metadata is always necessary anyway, either implied or explicit.
>

Exactly, so I don't know why you keep mentioning fourcc as if it were some
kind of complete solution.


>
> > Colorimetry is only relevant when displaying on a monitor. In the video
> > world we just have red, green and blue (plus alpha, y, u and v). These
> are
> > just labels for the colour channels, mapping them to bit formats.
>
> That is a very surprising opinion. Have you worked on HDR imagery?
> Or wide color gamut?
>

As I have mentioned several times, these are display output parameters,
 The only details which are relevant are the yuv/rgb conversion constants
and the gamma transfer values, With those I can convert berween any two
formats, which is all that is necessary for the steps between decoding and
encoding / display.




>
> > The values I mentioned are all necessary if you want to convert from one
> > colourspace to another. For example if I decode a video frame and the pix
> > format is YUV420P then to convert it to RGBA to display via openGL, I
> need
> > to know the YUV subspace (bt709 or itu601) and whether the values are
> > clamped or full range. Then I apply the standard conversion factors (Kr =
> > 0.2126, Kb = 0.0722 for bt709). This cannot be derived from the fourcc
> > (generally). No doubt there is a standard definition of definition of the
> > R,G,B primaries, but that isnr a concern.  I just feed the values into an
> > openGL texture buffer, and SDL buffer, a gdkpixbuf, QImage or whatever
> and
> > ask for it to be displayed. Now in an application I may optionally offer
> > the user filters to adjust the white balance, contrast, display gamma
> etc.
> > but that is outside of the scope of what I am proposing.
>
> Yes, those are all important properties, and not enough.
>
> Let's just say that the final display output is out of scope, what else is
missing ?
Pre / post alpha is required for conversion between formats, I hadn't
mentioned that because I was trying to avoid going into every little detail.




> > And no, it is not a case of "adding another standard" and confusing
> things,
> > there is no standard.
>
> There are standards. ITU-T H.273, coding-independent code points, for
> example. That combines well with drm_fourcc.h. Also ICC combines well
> with drm_fourcc.h. This works, because drm_fourcc.h does not attempt to
> define anything outside of the memory layout and abstract channels.
>
> Sorry what I meant is there are standards on paper, but there is no
standard set of enumerations (implementation vs specification).
Instead we have multiple implementations, each with their own definitions.
In fact somewhere above I actually linked to the ITU709 standard.




> > I just had a look at pipewire, there is nothing bad about it per se, they
> > mention their palette values are based on gstreamer. So fine, we have yet
> > another library specific set of definitions.
> >
> > It's like I am trying to invent Esperanto, and all you can say is"oh
> > you don't like English, well have you considered speaking German instead
> ?"
>
> That does seem like an apt analogue.
>
> >
> > Well that is it, I am done. I was asked how XDG video could be useful. I
> > explained the shortcomings of what exists currently, and outlined various
> > ways in which having a standard could be useful.
>
> Sorry, but I haven't understood what gap there is that would need to be
> filled with yet another pixel format enumeration. Or is it perhaps the
> same gap that we are filling in Wayland?
>
> Yes, yet another standard (implementarion), but a common standard that
everyone agrees on, That is the entire basis 

Re: Video standards

[Pekka Paalanen]

On Fri, 5 Apr 2024 08:28:27 -0300
salsaman  wrote:

> I don't think you are paying enough attention to the main points. Ir is not
> simply a case of extending the fourcc values to include more. If I didn't
> make it clear enough, the whole fourcc system is obscure, inadequate,
> ambiguous. The only reason ever to use it would be when you don't have meta
> data and you are forced to encode the format in the first 4 bytes.

Right. You must be talking about some other fourcc system. There are
many of them, and some combine multiple orthogonal things into a single
enumeration, which then becomes very difficult to extend and work with.

drm_fourcc.h is not one of those.

Metadata is always necessary anyway, either implied or explicit.

> Colorimetry is only relevant when displaying on a monitor. In the video
> world we just have red, green and blue (plus alpha, y, u and v). These are
> just labels for the colour channels, mapping them to bit formats.

That is a very surprising opinion. Have you worked on HDR imagery?
Or wide color gamut?

> The values I mentioned are all necessary if you want to convert from one
> colourspace to another. For example if I decode a video frame and the pix
> format is YUV420P then to convert it to RGBA to display via openGL, I need
> to know the YUV subspace (bt709 or itu601) and whether the values are
> clamped or full range. Then I apply the standard conversion factors (Kr =
> 0.2126, Kb = 0.0722 for bt709). This cannot be derived from the fourcc
> (generally). No doubt there is a standard definition of definition of the
> R,G,B primaries, but that isnr a concern.  I just feed the values into an
> openGL texture buffer, and SDL buffer, a gdkpixbuf, QImage or whatever and
> ask for it to be displayed. Now in an application I may optionally offer
> the user filters to adjust the white balance, contrast, display gamma etc.
> but that is outside of the scope of what I am proposing.

Yes, those are all important properties, and not enough.

> And no, it is not a case of "adding another standard" and confusing things,
> there is no standard.

There are standards. ITU-T H.273, coding-independent code points, for
example. That combines well with drm_fourcc.h. Also ICC combines well
with drm_fourcc.h. This works, because drm_fourcc.h does not attempt to
define anything outside of the memory layout and abstract channels.

> I just had a look at pipewire, there is nothing bad about it per se, they
> mention their palette values are based on gstreamer. So fine, we have yet
> another library specific set of definitions.
> 
> It's like I am trying to invent Esperanto, and all you can say is"oh
> you don't like English, well have you considered speaking German instead ?"

That does seem like an apt analogue.

> 
> Well that is it, I am done. I was asked how XDG video could be useful. I
> explained the shortcomings of what exists currently, and outlined various
> ways in which having a standard could be useful.

Sorry, but I haven't understood what gap there is that would need to be
filled with yet another pixel format enumeration. Or is it perhaps the
same gap that we are filling in Wayland?

We need to communicate a lot more about images than what pixel formats
ever could. We are building that definition based on existing standards
defining their own aspects: drm_fourcc.h, H.273 / ICC, and then adding
what's missing like the how or if alpha channel is baked into RGB (the
two ways to pre-multiply). Since these are all well-defined and
orthogonal, there is no problem combining them.

Wayland also already provides ways to handle some things, like pixel
aspect ratio, so we don't want to define another conflicting way to
define the same thing. That means the solution for Wayland is probably
not applicable somewhere else, and vice versa.


Thanks,
pq


pgpJzBEpY2E6m.pgp
Description: OpenPGP digital signature

Re: Video standards

[salsaman]

I don't think you are paying enough attention to the main points. Ir is not
simply a case of extending the fourcc values to include more. If I didn't
make it clear enough, the whole fourcc system is obscure, inadequate,
ambiguous. The only reason ever to use it would be when you don't have meta
data and you are forced to encode the format in the first 4 bytes.

Colorimetry is only relevant when displaying on a monitor. In the video
world we just have red, green and blue (plus alpha, y, u and v). These are
just labels for the colour channels, mapping them to bit formats.

The values I mentioned are all necessary if you want to convert from one
colourspace to another. For example if I decode a video frame and the pix
format is YUV420P then to convert it to RGBA to display via openGL, I need
to know the YUV subspace (bt709 or itu601) and whether the values are
clamped or full range. Then I apply the standard conversion factors (Kr =
0.2126, Kb = 0.0722 for bt709). This cannot be derived from the fourcc
(generally). No doubt there is a standard definition of definition of the
R,G,B primaries, but that isnr a concern.  I just feed the values into an
openGL texture buffer, and SDL buffer, a gdkpixbuf, QImage or whatever and
ask for it to be displayed. Now in an application I may optionally offer
the user filters to adjust the white balance, contrast, display gamma etc.
but that is outside of the scope of what I am proposing.

And no, it is not a case of "adding another standard" and confusing things,
there is no standard.

I just had a look at pipewire, there is nothing bad about it per se, they
mention their palette values are based on gstreamer. So fine, we have yet
another library specific set of definitions.

It's like I am trying to invent Esperanto, and all you can say is"oh
you don't like English, well have you considered speaking German instead ?"

Well that is it, I am done. I was asked how XDG video could be useful. I
explained the shortcomings of what exists currently, and outlined various
ways in which having a standard could be useful.

But if there is no will for this, then I am not going to waste any more of
my time on this. My own standards work very well for my own purposes, and
if I ever wanted to use pipewire for example, I can simply add the
constants to my compatibility header.


Cheers.
G,




On Fri, 5 Apr 2024 at 06:34, Pekka Paalanen 
wrote:

> On Thu, 4 Apr 2024 17:13:40 -0300
> salsaman  wrote:
>
> > Hi,
> > the problem with the drm.h header is, it is complicated, still needs
> > interpretation, and it lacks some commonly used formats, (e.g YUVAp)
>
> They accept additions, if the additions serve userspace
> interoperability. There is no requirement to actually use the format in
> the kernel.
>
> Pixel formats are complicated, yes. There are too many pixel format
> enumerations, every one differently defined, sure. I wouldn't add yet
> another system of definitions.
>
> > Also it doesn't address the gamma value (linear, sRGB, bt701), or the yuv
> > subspace, (eg Y'CbCr vs bt701), the yuv ramge (16 - 240. 16 - 235 =
> clamped
> > / mpeg. 0 - 255 unclamped, full, jpeg range) or uv sampling position, e.g
> > center, top_left)
>
> My opinion is that that none of that is relevant to a pixel format.
> These are additional information that must be decoupled from the pixel
> format to avoid a combinatorial explosion of the format enumeration,
> which is already massive even without them. A pixel format only
> describes a part of the memory layout: which set of bits forms a raw
> channel value of a pixel, and what are the channel names. Giving any
> further meaning to those raw values is for other metadata.
>
> What about colorimetry? Primaries and white point, dynamic range, plus
> the difference between encoding colorimetry (container color volume)
> and the usable/used colorimetry (target color volume, which is present
> in e.g. HDR static metadata typical for BT.2100/PQ signals in the form
> of the Mastering Display Color Volume).
>
> What about the assumed viewing environment, if we want to go from just
> stimulus towards appearance?
>
> > I can see that having some common definitions would be useful for
> > exchanging data between applications. Eg  my app gets a frame buffer and
> > metadata XDG_VIDEO_PALETTE_RGB24, XDG_VIDEO_GAMMA_LINEAR
> > then I know unambiguously that this is planar RGB 8:8:8 (so forget
> little /
> > big endian) and that the values are encoded with linear (not sRGB) gamma.
>
> > If you want to be more specific with palettes, then you could do so, but
> it
> > might require defining metadata structs,
>
> > I'll try to explain the rationale a bit. In the audio world it is quite
> > common for apps to send audio from one to another. Generally speaking
> they
> > would send or receive via an audio server, e.g pulseaudio, jack.
> > Now imagine the same for video,
>
> This sounds like Pipewire. One would develop Pipewire API to carry the
> necessary metadata. One 

Re: Video standards

[Pekka Paalanen]

On Thu, 4 Apr 2024 17:13:40 -0300
salsaman  wrote:

> Hi,
> the problem with the drm.h header is, it is complicated, still needs
> interpretation, and it lacks some commonly used formats, (e.g YUVAp)

They accept additions, if the additions serve userspace
interoperability. There is no requirement to actually use the format in
the kernel.

Pixel formats are complicated, yes. There are too many pixel format
enumerations, every one differently defined, sure. I wouldn't add yet
another system of definitions.

> Also it doesn't address the gamma value (linear, sRGB, bt701), or the yuv
> subspace, (eg Y'CbCr vs bt701), the yuv ramge (16 - 240. 16 - 235 = clamped
> / mpeg. 0 - 255 unclamped, full, jpeg range) or uv sampling position, e.g
> center, top_left)

My opinion is that that none of that is relevant to a pixel format.
These are additional information that must be decoupled from the pixel
format to avoid a combinatorial explosion of the format enumeration,
which is already massive even without them. A pixel format only
describes a part of the memory layout: which set of bits forms a raw
channel value of a pixel, and what are the channel names. Giving any
further meaning to those raw values is for other metadata.

What about colorimetry? Primaries and white point, dynamic range, plus
the difference between encoding colorimetry (container color volume)
and the usable/used colorimetry (target color volume, which is present
in e.g. HDR static metadata typical for BT.2100/PQ signals in the form
of the Mastering Display Color Volume).

What about the assumed viewing environment, if we want to go from just
stimulus towards appearance?

> I can see that having some common definitions would be useful for
> exchanging data between applications. Eg  my app gets a frame buffer and
> metadata XDG_VIDEO_PALETTE_RGB24, XDG_VIDEO_GAMMA_LINEAR
> then I know unambiguously that this is planar RGB 8:8:8 (so forget little /
> big endian) and that the values are encoded with linear (not sRGB) gamma.

> If you want to be more specific with palettes, then you could do so, but it
> might require defining metadata structs,

> I'll try to explain the rationale a bit. In the audio world it is quite
> common for apps to send audio from one to another. Generally speaking they
> would send or receive via an audio server, e.g pulseaudio, jack.
> Now imagine the same for video, 

This sounds like Pipewire. One would develop Pipewire API to carry the
necessary metadata. One could choose to follow something massive like
ITU-T H.274, or maybe follow what we are brewing for Wayland.

To my understanding, Pipewire is already becoming very common among
desktop environments for routing audio and video streams between
applications and system components and devices.


Thanks,
pq


pgpYhSI46yoBC.pgp
Description: OpenPGP digital signature

Re: Video standards

[salsaman]

I missed out a link in an earlier email, this is the dbus player control
which I mentioned:
https://www.freedesktop.org/wiki/Specifications/mpris-spec/


A dbus <---> OSC endpoint could actually make this super useful, perhaps I
will do that when I have some time,


On Thu, 4 Apr 2024 at 21:57, salsaman  wrote:

> Just to re emphasise, the nearest we have presently are AV_PIXFMT_*  which
> are library specific values, and lack some important values
> (there is no yuv888 packed for example), And the drm,h file is based on
> monitor standards, and also lacks values like 'R', 'G', 'B', 'A' *
>
> I think we can agree there is a gap that could be filled by an agreed set
> of definitions. I dont mean technical definitions, we can just point to the
> standards
>  e.g https://glenwing.github.io/docs/ITU-R-BT.709-1.pdf
> and an enumeration XDG_VIDEO_GAMMA_BT709 (== XDG_VIDEO_GAMMA_ITU709)
>
> G,
>
> * (also I would dispute their ambiguous yuv411 definition - if it were
> yuv411p I would agree, otherwise it could be the camera format UYYVYY
> packed).
>
> On Thu, 4 Apr 2024 at 18:40, salsaman  wrote:
>
>> I'll try to explain the rationale a bit. In the audio world it is quite
>> common for apps to send audio from one to another. Generally speaking they
>> would send or receive via an audio server, e.g pulseaudio, jack.
>> Now imagine the same for video, let us suppose you have an app that
>> generates video effects from audio. Now you want to send the output to
>> another app, let's say you have a super optimised openGL video player.
>> You could imagine connecting the 2 apps via dbus for example. The first
>> app, the generator, sends a frame sync signal each time a frame is
>> produced, and includes a pointer to the frame buffer, and the frame size.
>> But how does it describe the format of the frame pixel data ? Is it RGB24
>> ? yuv420p ? if it is rgb, is it sRGB gamma or linear ?
>> Well, you could maybe guess the first 4 bytes are a fourcc code. Then you
>> write a lot of code to parse the 4cc and figure out what it might be,
>> Or the easier way, you query the app and it responds with XDG constants.
>>
>> G,
>>
>> On Thu, 4 Apr 2024 at 17:13, salsaman  wrote:
>>
>>> Hi,
>>> the problem with the drm.h header is, it is complicated, still needs
>>> interpretation, and it lacks some commonly used formats, (e.g YUVAp)
>>> Also it doesn't address the gamma value (linear, sRGB, bt701), or the
>>> yuv subspace, (eg Y'CbCr vs bt701), the yuv ramge (16 - 240. 16 - 235 =
>>> clamped / mpeg. 0 - 255 unclamped, full, jpeg range) or uv sampling
>>> position, e.g center, top_left)
>>>
>>> I can see that having some common definitions would be useful for
>>> exchanging data between applications. Eg  my app gets a frame buffer and
>>> metadata XDG_VIDEO_PALETTE_RGB24, XDG_VIDEO_GAMMA_LINEAR
>>> then I know unambiguously that this is planar RGB 8:8:8 (so forget
>>> little / big endian) and that the values are encoded with linear (not sRGB)
>>> gamma.
>>>
>>> If you want to be more specific with palettes, then you could do so, but
>>> it might require defining metadata structs,
>>>
>>> For example for my own standard (Weed effects) I have:
>>>
>>> // max number of channels in a palette
>>>
>>>
>>>
>>> #ifndef WEED_MAXPCHANS
>>> #define WEED_MAXPCHANS 8
>>> #endif
>>>
>>> // max number of planes in a palette
>>>
>>>
>>>
>>> #ifndef WEED_MAXPPLANES
>>> #define WEED_MAXPPLANES 4
>>> #endif
>>>
>>> #define WEED_VCHAN_end  0
>>>
>>> #define WEED_VCHAN_red  1
>>> #define WEED_VCHAN_green2
>>> #define WEED_VCHAN_blue 3
>>>
>>> #define WEED_VCHAN_Y512
>>> #define WEED_VCHAN_U513
>>> #define WEED_VCHAN_V514
>>>
>>> #define WEED_VCHAN_alpha1024
>>>
>>> #define WEED_VCHAN_FIRST_CUSTOM 8192
>>>
>>> #define WEED_VCHAN_DESC_PLANAR  (1 << 0) ///< planar type
>>>
>>>
>>>
>>> #define WEED_VCHAN_DESC_FP  (1 << 1) ///< floating point
>>> type
>>>
>>>
>>> #define WEED_VCHAN_DESC_BE  (1 << 2) ///< pixel data is big
>>> endian (within each component)
>>>
>>>
>>>
>>> #define WEED_VCHAN_DESC_FIRST_CUSTOM(1 << 16)
>>>
>>> typedef struct {
>>>   uint16_t ext_ref;  ///< link to an enumerated type
>>>
>>>
>>>
>>>   uint16_t chantype[WEED_MAXPCHANS]; ///  e.g. {WEED_VCHAN_U,
>>> WEED_VCHAN_Y, WEED_VCHAN_V, WEED_VCHAN_Y)
>>>
>>>
>>>   uint32_t flags; /// bitmap of flags, eg. WEED_VCHAN_DESC_FP |
>>> WEED_VCHAN_DESC_PLANAR
>>>
>>>
>>>   uint8_t  hsub[WEED_MAXPCHANS];  /// horiz. subsampling, 0 or 1 means
>>> no subsampling, 2 means halved etc. (planar only)
>>>uint8_t  vsub[WEED_MAXPCHANS];  /// vert subsampling
>>>
>>>
>>>
>>>   uint8_t npixels; ///< npixels per macropixel: {0, 1} == 1
>>>
>>>
>>>
>>>   uint8_t bitsize[WEED_MAXPCHANS]; // 8 if not specified
>>>   void *extended; ///< pointer to app defined data
>>>
>>>
>>>
>>> } weed_macropixel_t;
>>>
>>> Then I can describe all my palettes like:
>>> 

Re: Video standards

[salsaman]

Just to re emphasise, the nearest we have presently are AV_PIXFMT_*  which
are library specific values, and lack some important values
(there is no yuv888 packed for example), And the drm,h file is based on
monitor standards, and also lacks values like 'R', 'G', 'B', 'A' *

I think we can agree there is a gap that could be filled by an agreed set
of definitions. I dont mean technical definitions, we can just point to the
standards
 e.g https://glenwing.github.io/docs/ITU-R-BT.709-1.pdf
and an enumeration XDG_VIDEO_GAMMA_BT709 (== XDG_VIDEO_GAMMA_ITU709)

G,

* (also I would dispute their ambiguous yuv411 definition - if it were
yuv411p I would agree, otherwise it could be the camera format UYYVYY
packed).

On Thu, 4 Apr 2024 at 18:40, salsaman  wrote:

> I'll try to explain the rationale a bit. In the audio world it is quite
> common for apps to send audio from one to another. Generally speaking they
> would send or receive via an audio server, e.g pulseaudio, jack.
> Now imagine the same for video, let us suppose you have an app that
> generates video effects from audio. Now you want to send the output to
> another app, let's say you have a super optimised openGL video player.
> You could imagine connecting the 2 apps via dbus for example. The first
> app, the generator, sends a frame sync signal each time a frame is
> produced, and includes a pointer to the frame buffer, and the frame size.
> But how does it describe the format of the frame pixel data ? Is it RGB24
> ? yuv420p ? if it is rgb, is it sRGB gamma or linear ?
> Well, you could maybe guess the first 4 bytes are a fourcc code. Then you
> write a lot of code to parse the 4cc and figure out what it might be,
> Or the easier way, you query the app and it responds with XDG constants.
>
> G,
>
> On Thu, 4 Apr 2024 at 17:13, salsaman  wrote:
>
>> Hi,
>> the problem with the drm.h header is, it is complicated, still needs
>> interpretation, and it lacks some commonly used formats, (e.g YUVAp)
>> Also it doesn't address the gamma value (linear, sRGB, bt701), or the yuv
>> subspace, (eg Y'CbCr vs bt701), the yuv ramge (16 - 240. 16 - 235 = clamped
>> / mpeg. 0 - 255 unclamped, full, jpeg range) or uv sampling position, e.g
>> center, top_left)
>>
>> I can see that having some common definitions would be useful for
>> exchanging data between applications. Eg  my app gets a frame buffer and
>> metadata XDG_VIDEO_PALETTE_RGB24, XDG_VIDEO_GAMMA_LINEAR
>> then I know unambiguously that this is planar RGB 8:8:8 (so forget little
>> / big endian) and that the values are encoded with linear (not sRGB) gamma.
>>
>> If you want to be more specific with palettes, then you could do so, but
>> it might require defining metadata structs,
>>
>> For example for my own standard (Weed effects) I have:
>>
>> // max number of channels in a palette
>>
>>
>>
>> #ifndef WEED_MAXPCHANS
>> #define WEED_MAXPCHANS 8
>> #endif
>>
>> // max number of planes in a palette
>>
>>
>>
>> #ifndef WEED_MAXPPLANES
>> #define WEED_MAXPPLANES 4
>> #endif
>>
>> #define WEED_VCHAN_end  0
>>
>> #define WEED_VCHAN_red  1
>> #define WEED_VCHAN_green2
>> #define WEED_VCHAN_blue 3
>>
>> #define WEED_VCHAN_Y512
>> #define WEED_VCHAN_U513
>> #define WEED_VCHAN_V514
>>
>> #define WEED_VCHAN_alpha1024
>>
>> #define WEED_VCHAN_FIRST_CUSTOM 8192
>>
>> #define WEED_VCHAN_DESC_PLANAR  (1 << 0) ///< planar type
>>
>>
>>
>> #define WEED_VCHAN_DESC_FP  (1 << 1) ///< floating point type
>>
>>
>>
>> #define WEED_VCHAN_DESC_BE  (1 << 2) ///< pixel data is big
>> endian (within each component)
>>
>>
>>
>> #define WEED_VCHAN_DESC_FIRST_CUSTOM(1 << 16)
>>
>> typedef struct {
>>   uint16_t ext_ref;  ///< link to an enumerated type
>>
>>
>>
>>   uint16_t chantype[WEED_MAXPCHANS]; ///  e.g. {WEED_VCHAN_U,
>> WEED_VCHAN_Y, WEED_VCHAN_V, WEED_VCHAN_Y)
>>
>>
>>   uint32_t flags; /// bitmap of flags, eg. WEED_VCHAN_DESC_FP |
>> WEED_VCHAN_DESC_PLANAR
>>
>>
>>   uint8_t  hsub[WEED_MAXPCHANS];  /// horiz. subsampling, 0 or 1 means no
>> subsampling, 2 means halved etc. (planar only)
>>uint8_t  vsub[WEED_MAXPCHANS];  /// vert subsampling
>>
>>
>>
>>   uint8_t npixels; ///< npixels per macropixel: {0, 1} == 1
>>
>>
>>
>>   uint8_t bitsize[WEED_MAXPCHANS]; // 8 if not specified
>>   void *extended; ///< pointer to app defined data
>>
>>
>>
>> } weed_macropixel_t;
>>
>> Then I can describe all my palettes like:
>> advp[0] = (weed_macropixel_t) {
>> WEED_PALETTE_RGB24,
>> {WEED_VCHAN_red, WEED_VCHAN_green, WEED_VCHAN_blue}
>>   };
>>
>>  advp[6] = (weed_macropixel_t) {
>> WEED_PALETTE_RGBAFLOAT,
>> {WEED_VCHAN_red, WEED_VCHAN_green, WEED_VCHAN_blue, WEED_VCHAN_alpha},
>> WEED_VCHAN_DESC_FP, {0}, {0}, 1, {32, 32, 32, 32}
>>   };
>>
>>  advp[7] = (weed_macropixel_t) {
>> WEED_PALETTE_YUV420P,
>> {WEED_VCHAN_Y, WEED_VCHAN_U, WEED_VCHAN_V},
>> 

Re: Video standards

[salsaman]

I'll try to explain the rationale a bit. In the audio world it is quite
common for apps to send audio from one to another. Generally speaking they
would send or receive via an audio server, e.g pulseaudio, jack.
Now imagine the same for video, let us suppose you have an app that
generates video effects from audio. Now you want to send the output to
another app, let's say you have a super optimised openGL video player.
You could imagine connecting the 2 apps via dbus for example. The first
app, the generator, sends a frame sync signal each time a frame is
produced, and includes a pointer to the frame buffer, and the frame size.
But how does it describe the format of the frame pixel data ? Is it RGB24 ?
yuv420p ? if it is rgb, is it sRGB gamma or linear ?
Well, you could maybe guess the first 4 bytes are a fourcc code. Then you
write a lot of code to parse the 4cc and figure out what it might be,
Or the easier way, you query the app and it responds with XDG constants.

G,

On Thu, 4 Apr 2024 at 17:13, salsaman  wrote:

> Hi,
> the problem with the drm.h header is, it is complicated, still needs
> interpretation, and it lacks some commonly used formats, (e.g YUVAp)
> Also it doesn't address the gamma value (linear, sRGB, bt701), or the yuv
> subspace, (eg Y'CbCr vs bt701), the yuv ramge (16 - 240. 16 - 235 = clamped
> / mpeg. 0 - 255 unclamped, full, jpeg range) or uv sampling position, e.g
> center, top_left)
>
> I can see that having some common definitions would be useful for
> exchanging data between applications. Eg  my app gets a frame buffer and
> metadata XDG_VIDEO_PALETTE_RGB24, XDG_VIDEO_GAMMA_LINEAR
> then I know unambiguously that this is planar RGB 8:8:8 (so forget little
> / big endian) and that the values are encoded with linear (not sRGB) gamma.
>
> If you want to be more specific with palettes, then you could do so, but
> it might require defining metadata structs,
>
> For example for my own standard (Weed effects) I have:
>
> // max number of channels in a palette
>
>
>
> #ifndef WEED_MAXPCHANS
> #define WEED_MAXPCHANS 8
> #endif
>
> // max number of planes in a palette
>
>
>
> #ifndef WEED_MAXPPLANES
> #define WEED_MAXPPLANES 4
> #endif
>
> #define WEED_VCHAN_end  0
>
> #define WEED_VCHAN_red  1
> #define WEED_VCHAN_green2
> #define WEED_VCHAN_blue 3
>
> #define WEED_VCHAN_Y512
> #define WEED_VCHAN_U513
> #define WEED_VCHAN_V514
>
> #define WEED_VCHAN_alpha1024
>
> #define WEED_VCHAN_FIRST_CUSTOM 8192
>
> #define WEED_VCHAN_DESC_PLANAR  (1 << 0) ///< planar type
>
>
>
> #define WEED_VCHAN_DESC_FP  (1 << 1) ///< floating point type
>
>
>
> #define WEED_VCHAN_DESC_BE  (1 << 2) ///< pixel data is big
> endian (within each component)
>
>
>
> #define WEED_VCHAN_DESC_FIRST_CUSTOM(1 << 16)
>
> typedef struct {
>   uint16_t ext_ref;  ///< link to an enumerated type
>
>
>
>   uint16_t chantype[WEED_MAXPCHANS]; ///  e.g. {WEED_VCHAN_U,
> WEED_VCHAN_Y, WEED_VCHAN_V, WEED_VCHAN_Y)
>
>
>   uint32_t flags; /// bitmap of flags, eg. WEED_VCHAN_DESC_FP |
> WEED_VCHAN_DESC_PLANAR
>
>
>   uint8_t  hsub[WEED_MAXPCHANS];  /// horiz. subsampling, 0 or 1 means no
> subsampling, 2 means halved etc. (planar only)
>uint8_t  vsub[WEED_MAXPCHANS];  /// vert subsampling
>
>
>
>   uint8_t npixels; ///< npixels per macropixel: {0, 1} == 1
>
>
>
>   uint8_t bitsize[WEED_MAXPCHANS]; // 8 if not specified
>   void *extended; ///< pointer to app defined data
>
>
>
> } weed_macropixel_t;
>
> Then I can describe all my palettes like:
> advp[0] = (weed_macropixel_t) {
> WEED_PALETTE_RGB24,
> {WEED_VCHAN_red, WEED_VCHAN_green, WEED_VCHAN_blue}
>   };
>
>  advp[6] = (weed_macropixel_t) {
> WEED_PALETTE_RGBAFLOAT,
> {WEED_VCHAN_red, WEED_VCHAN_green, WEED_VCHAN_blue, WEED_VCHAN_alpha},
> WEED_VCHAN_DESC_FP, {0}, {0}, 1, {32, 32, 32, 32}
>   };
>
>  advp[7] = (weed_macropixel_t) {
> WEED_PALETTE_YUV420P,
> {WEED_VCHAN_Y, WEED_VCHAN_U, WEED_VCHAN_V},
> WEED_VCHAN_DESC_PLANAR, {1, 2, 2}, {1, 2, 2}
>   };
>
> IMO this is way superior to fourcc and if you were to supplement this with
> gamma, interlace, yuv subspace, yuv clamping and yuv sampling, then you
> would have a very comprehensive definition for any type of video frame.
>
> G.
>
>
>
> On Thu, 4 Apr 2024 at 08:52, Pekka Paalanen 
> wrote:
>
>> On Wed, 3 Apr 2024 21:51:39 -0300
>> salsaman  wrote:
>>
>> > Regarding my expertise, I was one of the developers most involved in
>> > developing the "livido" standard which was one of the main topics of the
>> > Piksel Festivals held in Bergen, Norway.
>> > In the early days (2004 - 2006) the focus of the annual event was
>> precisely
>> > the formulation of free / open standards, in this case for video
>> effects.
>> > Other contributors included:
>> >  Niels Elburg, Denis "Jaromil" Rojo, Tom Schouten, Andraz Tori, Kentaro
>> > Fukuchi and Carlo 

Re: Video standards

[salsaman]

Hi,
the problem with the drm.h header is, it is complicated, still needs
interpretation, and it lacks some commonly used formats, (e.g YUVAp)
Also it doesn't address the gamma value (linear, sRGB, bt701), or the yuv
subspace, (eg Y'CbCr vs bt701), the yuv ramge (16 - 240. 16 - 235 = clamped
/ mpeg. 0 - 255 unclamped, full, jpeg range) or uv sampling position, e.g
center, top_left)

I can see that having some common definitions would be useful for
exchanging data between applications. Eg  my app gets a frame buffer and
metadata XDG_VIDEO_PALETTE_RGB24, XDG_VIDEO_GAMMA_LINEAR
then I know unambiguously that this is planar RGB 8:8:8 (so forget little /
big endian) and that the values are encoded with linear (not sRGB) gamma.

If you want to be more specific with palettes, then you could do so, but it
might require defining metadata structs,

For example for my own standard (Weed effects) I have:

// max number of channels in a palette



#ifndef WEED_MAXPCHANS
#define WEED_MAXPCHANS 8
#endif

// max number of planes in a palette



#ifndef WEED_MAXPPLANES
#define WEED_MAXPPLANES 4
#endif

#define WEED_VCHAN_end  0

#define WEED_VCHAN_red  1
#define WEED_VCHAN_green2
#define WEED_VCHAN_blue 3

#define WEED_VCHAN_Y512
#define WEED_VCHAN_U513
#define WEED_VCHAN_V514

#define WEED_VCHAN_alpha1024

#define WEED_VCHAN_FIRST_CUSTOM 8192

#define WEED_VCHAN_DESC_PLANAR  (1 << 0) ///< planar type



#define WEED_VCHAN_DESC_FP  (1 << 1) ///< floating point type



#define WEED_VCHAN_DESC_BE  (1 << 2) ///< pixel data is big
endian (within each component)



#define WEED_VCHAN_DESC_FIRST_CUSTOM(1 << 16)

typedef struct {
  uint16_t ext_ref;  ///< link to an enumerated type



  uint16_t chantype[WEED_MAXPCHANS]; ///  e.g. {WEED_VCHAN_U, WEED_VCHAN_Y,
WEED_VCHAN_V, WEED_VCHAN_Y)


  uint32_t flags; /// bitmap of flags, eg. WEED_VCHAN_DESC_FP |
WEED_VCHAN_DESC_PLANAR


  uint8_t  hsub[WEED_MAXPCHANS];  /// horiz. subsampling, 0 or 1 means no
subsampling, 2 means halved etc. (planar only)
   uint8_t  vsub[WEED_MAXPCHANS];  /// vert subsampling



  uint8_t npixels; ///< npixels per macropixel: {0, 1} == 1



  uint8_t bitsize[WEED_MAXPCHANS]; // 8 if not specified
  void *extended; ///< pointer to app defined data



} weed_macropixel_t;

Then I can describe all my palettes like:
advp[0] = (weed_macropixel_t) {
WEED_PALETTE_RGB24,
{WEED_VCHAN_red, WEED_VCHAN_green, WEED_VCHAN_blue}
  };

 advp[6] = (weed_macropixel_t) {
WEED_PALETTE_RGBAFLOAT,
{WEED_VCHAN_red, WEED_VCHAN_green, WEED_VCHAN_blue, WEED_VCHAN_alpha},
WEED_VCHAN_DESC_FP, {0}, {0}, 1, {32, 32, 32, 32}
  };

 advp[7] = (weed_macropixel_t) {
WEED_PALETTE_YUV420P,
{WEED_VCHAN_Y, WEED_VCHAN_U, WEED_VCHAN_V},
WEED_VCHAN_DESC_PLANAR, {1, 2, 2}, {1, 2, 2}
  };

IMO this is way superior to fourcc and if you were to supplement this with
gamma, interlace, yuv subspace, yuv clamping and yuv sampling, then you
would have a very comprehensive definition for any type of video frame.

G.



On Thu, 4 Apr 2024 at 08:52, Pekka Paalanen 
wrote:

> On Wed, 3 Apr 2024 21:51:39 -0300
> salsaman  wrote:
>
> > Regarding my expertise, I was one of the developers most involved in
> > developing the "livido" standard which was one of the main topics of the
> > Piksel Festivals held in Bergen, Norway.
> > In the early days (2004 - 2006) the focus of the annual event was
> precisely
> > the formulation of free / open standards, in this case for video effects.
> > Other contributors included:
> >  Niels Elburg, Denis "Jaromil" Rojo, Tom Schouten, Andraz Tori, Kentaro
> > Fukuchi and Carlo Prelz.
> > I've also been involved with and put forward proposals for common
> command /
> > query / reply actions (Open Media Control). To the extent that these
> > proposals have not gained traction, I don't ascribe this to a failing in
> > the proposals, but rather to a lack of developer awareness.
> >
> > Now regarding specific areas, I went back and reviewed some of the
> > available material at  https://www.freedesktop.org/wiki/Specifications/
> >
> > free media player specifications
> > https://www.freedesktop.org/wiki/Specifications/free-media-player-specs/
> > metadata standards for things like comments and ratings - talks mainly
> > about audio but describes video files also
> >
> > I am not a big fan of dbus, but this looks fine, it could be used for
> video
> > players. I'd be happier if it were a bit more abstracted and not tied to
> a
> > specific implementation (dbus). I could suggest some enhancements but I
> > guess this is a dbus thing and not an xdg thing.
>
> Thanks, these sound like they do not need to involve Wayland in any
> way, so they are not on my plate.
>
> > IMO what would be useful would be to define a common set of constants,
> most
> > specifically related to frame pixel fornats
> > The 2 

Re: Video standards

[Pekka Paalanen]

On Wed, 3 Apr 2024 21:51:39 -0300
salsaman  wrote:

> Regarding my expertise, I was one of the developers most involved in
> developing the "livido" standard which was one of the main topics of the
> Piksel Festivals held in Bergen, Norway.
> In the early days (2004 - 2006) the focus of the annual event was precisely
> the formulation of free / open standards, in this case for video effects.
> Other contributors included:
>  Niels Elburg, Denis "Jaromil" Rojo, Tom Schouten, Andraz Tori, Kentaro
> Fukuchi and Carlo Prelz.
> I've also been involved with and put forward proposals for common command /
> query / reply actions (Open Media Control). To the extent that these
> proposals have not gained traction, I don't ascribe this to a failing in
> the proposals, but rather to a lack of developer awareness.
> 
> Now regarding specific areas, I went back and reviewed some of the
> available material at  https://www.freedesktop.org/wiki/Specifications/
> 
> free media player specifications
> https://www.freedesktop.org/wiki/Specifications/free-media-player-specs/
> metadata standards for things like comments and ratings - talks mainly
> about audio but describes video files also
> 
> I am not a big fan of dbus, but this looks fine, it could be used for video
> players. I'd be happier if it were a bit more abstracted and not tied to a
> specific implementation (dbus). I could suggest some enhancements but I
> guess this is a dbus thing and not an xdg thing.

Thanks, these sound like they do not need to involve Wayland in any
way, so they are not on my plate.

> IMO what would be useful would be to define a common set of constants, most
> specifically related to frame pixel fornats
> The 2 most common in use are fourCC and avformat

Wayland protocol extensions and I suppose also Wayland compositors
internally standardise on drm_fourcc.h formats. Their authoritative
definitions are in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h
and they are not intentionally mirroring any other fourcc coding.

These are strictly pixel formats, and do not define anything about
colorimetry, interlacing, field order, frame rate, quantization range,
or anything else.

> Consider a frame in UYVY fornat
> 
> fourCC values:
> 
>  #define MK_FOURCC(a, b, c, d) (((uint32_t)a) | (((uint32_t)b) << 8) \
>| (((uint32_t)c) << 16) | (((uint32_t)d) <<
> 24))
> 
> MK_FOURCC('U', 'Y', 'V', 'Y')
> but also
> MK_FOURCC('I', 'U', 'Y', 'B')
> the same but with interlacing
> MK_FOURCC('H', 'D', 'Y', 'C')
> same but bt709 (hdtv) encoding
> 
> so this requires interpretation by sender / receiver - a simpler way could
> be with constants
> 
> - probably the nearest we have are ffmpeg / libav definitions, but this is
> the wrong way around, a lib shouldn't define a global standard, the
> standard should come first and the lib should align to that.
> 
> We have AV_PIX_FMT_UYVY422 which was formerly PIX_FMT_UYVY422
> and AVCOL_TRC_BT709, which is actually the gamma transfer function, There
> is no equivalent bt709 constant fot bt709 yuv / rgb, instead this exists as
> a matrix.
> 
> Now consider how much easier it would be to share data if we had the
> following constants enumerated:
> 
> *XDG_VIDEO_PALETTE_UYVY*
> *XDG_VIDEO_INTERLACE_TOP_FIRST*
> *XDG_VIDEO_YUV_SUBSPACE_BT709*
> *XDG_VIDEO_GAMMA_SRGB*
> 
> (this is an invented example, not intended to be a real example).
> 
> There is a bit more too it but that should be enough to give a general idea.

Where should this be used?


Thanks,
pq


pgpoEcw0uwabR.pgp
Description: OpenPGP digital signature

Re: Video standards

[salsaman]

Regarding my expertise, I was one of the developers most involved in
developing the "livido" standard which was one of the main topics of the
Piksel Festivals held in Bergen, Norway.
In the early days (2004 - 2006) the focus of the annual event was precisely
the formulation of free / open standards, in this case for video effects.
Other contributors included:
 Niels Elburg, Denis "Jaromil" Rojo, Tom Schouten, Andraz Tori, Kentaro
Fukuchi and Carlo Prelz.
I've also been involved with and put forward proposals for common command /
query / reply actions (Open Media Control). To the extent that these
proposals have not gained traction, I don't ascribe this to a failing in
the proposals, but rather to a lack of developer awareness.

Now regarding specific areas, I went back and reviewed some of the
available material at  https://www.freedesktop.org/wiki/Specifications/

free media player specifications
https://www.freedesktop.org/wiki/Specifications/free-media-player-specs/
metadata standards for things like comments and ratings - talks mainly
about audio but describes video files also

I am not a big fan of dbus, but this looks fine, it could be used for video
players. I'd be happier if it were a bit more abstracted and not tied to a
specific implementation (dbus). I could suggest some enhancements but I
guess this is a dbus thing and not an xdg thing.

IMO what would be useful would be to define a common set of constants, most
specifically related to frame pixel fornats
The 2 most common in use are fourCC and avformat

Consider a frame in UYVY fornat

fourCC values:

 #define MK_FOURCC(a, b, c, d) (((uint32_t)a) | (((uint32_t)b) << 8) \
   | (((uint32_t)c) << 16) | (((uint32_t)d) <<
24))

MK_FOURCC('U', 'Y', 'V', 'Y')
but also
MK_FOURCC('I', 'U', 'Y', 'B')
the same but with interlacing
MK_FOURCC('H', 'D', 'Y', 'C')
same but bt709 (hdtv) encoding

so this requires interpretation by sender / receiver - a simpler way could
be with constants

- probably the nearest we have are ffmpeg / libav definitions, but this is
the wrong way around, a lib shouldn't define a global standard, the
standard should come first and the lib should align to that.

We have AV_PIX_FMT_UYVY422 which was formerly PIX_FMT_UYVY422
and AVCOL_TRC_BT709, which is actually the gamma transfer function, There
is no equivalent bt709 constant fot bt709 yuv / rgb, instead this exists as
a matrix.

Now consider how much easier it would be to share data if we had the
following constants enumerated:

*XDG_VIDEO_PALETTE_UYVY*
*XDG_VIDEO_INTERLACE_TOP_FIRST*
*XDG_VIDEO_YUV_SUBSPACE_BT709*
*XDG_VIDEO_GAMMA_SRGB*

(this is an invented example, not intended to be a real example).

There is a bit more too it but that should be enough to give a general idea.

G,






On Wed, 3 Apr 2024 at 08:12, Pekka Paalanen 
wrote:

> On Thu, 28 Mar 2024 19:19:33 -0300
> salsaman  wrote:
>
> > There are two hardware settings from the monitor that overlap video,
> these
> > are
> > - monitor aspect ratio
> > - monitor pixel aspect ratio
> > These are both useful when rendering video. The first defines how much
> > stretch or letterbocing to apply, the second defines non square pixels,
> > which is goof to know if you want to render fixed size objects (a circle
> > for example). Knowing the monitor size in RGB or Y plane pixels can also
> be
> > useful to define a max or min resize limit (whether it is min or max
> > depends on the desired display quality level)
>
> Thanks. I was trying to ask what kind of video standards you have
> experience and expertise in?
>
> I'm also interested in what kind of standards you see as missing. The
> Wayland extension aims to cover everything display related. I'm sure
> video file format specifications do their job.
>
> What would be left to define?
>
> What goals would there be?
>
> I suppose individual APIs like Pipewire might be lacking something, but
> that's a Pipewire API rather than an XDG standard. Or do we need an XDG
> standard to be used as the design guide and reference for APIs?
>
>
> Thanks,
> pq
>
> > On Thu, 28 Mar 2024 at 19:05, salsaman  wrote:
> >
> > > colour management and hdr mostly intersect with three areas of video:
> > > pixel formats, yuv <-> rgb conversions and gamma transfer functions.
> > > For example
> > > xdg_pixformat_yuv121010
> > > xdg_subspace_bt2020
> > > xdg_gamma_bt2020
> > >
> > > just off the top of my head, these arent intended to be actual
> suggestions
> > >
> > >
> > > On Thu, 28 Mar 2024 at 18:57, salsaman  wrote:
> > >
> > >> In addition, I am not sure if there are xdg standards for audio, but I
> > >> would suggest video and follow similar hierarchies, and that both
> could be
> > >> classed under a more generic xdg multimedia standard.
> > >>
> > >>
> > >> On Thu, 28 Mar 2024 at 18:48, salsaman  wrote:
> > >>
> > >>> Hi, IMO hardware related would be more appropriate under display
> > >>> standards
> > >>> Video standards could be more software related, 

Re: Video standards

[Pekka Paalanen]

On Thu, 28 Mar 2024 19:19:33 -0300
salsaman  wrote:

> There are two hardware settings from the monitor that overlap video, these
> are
> - monitor aspect ratio
> - monitor pixel aspect ratio
> These are both useful when rendering video. The first defines how much
> stretch or letterbocing to apply, the second defines non square pixels,
> which is goof to know if you want to render fixed size objects (a circle
> for example). Knowing the monitor size in RGB or Y plane pixels can also be
> useful to define a max or min resize limit (whether it is min or max
> depends on the desired display quality level)

Thanks. I was trying to ask what kind of video standards you have
experience and expertise in?

I'm also interested in what kind of standards you see as missing. The
Wayland extension aims to cover everything display related. I'm sure
video file format specifications do their job.

What would be left to define?

What goals would there be?

I suppose individual APIs like Pipewire might be lacking something, but
that's a Pipewire API rather than an XDG standard. Or do we need an XDG
standard to be used as the design guide and reference for APIs?


Thanks,
pq

> On Thu, 28 Mar 2024 at 19:05, salsaman  wrote:
> 
> > colour management and hdr mostly intersect with three areas of video:
> > pixel formats, yuv <-> rgb conversions and gamma transfer functions.
> > For example
> > xdg_pixformat_yuv121010
> > xdg_subspace_bt2020
> > xdg_gamma_bt2020
> >
> > just off the top of my head, these arent intended to be actual suggestions
> >
> >
> > On Thu, 28 Mar 2024 at 18:57, salsaman  wrote:
> >  
> >> In addition, I am not sure if there are xdg standards for audio, but I
> >> would suggest video and follow similar hierarchies, and that both could be
> >> classed under a more generic xdg multimedia standard.
> >>
> >>
> >> On Thu, 28 Mar 2024 at 18:48, salsaman  wrote:
> >>  
> >>> Hi, IMO hardware related would be more appropriate under display
> >>> standards
> >>> Video standards could be more software related, and provide common
> >>> definitions, for example , allowing exchange of information between
> >>> applications which produce or consume video frames or streams of frames.
> >>> Some examples I can think of might be
> >>>  xdg_colorspace_RGB,
> >>>  xdg_colorspace_YUV
> >>>
> >>> xdg_pixfmt_RGB24
> >>> xdg_pixfmt_YUV420p
> >>> etc
> >>>
> >>>  xdg_gamma_linear
> >>>  xdg_gamma_sRGB
> >>>
> >>> xdg_video_width
> >>> xdg_video_height
> >>>
> >>> I could provide a more full list, but I think if it goes along this
> >>> route. the starting point has to be what are we setting out to achieve 
> >>> with
> >>> the standards / definitions, and provide a range of speculative use cases.
> >>>
> >>> Gabriel (salsaman)
> >>>
> >>>
> >>> On Thu, 28 Mar 2024 at 06:07, Pekka Paalanen <  
> >>> pekka.paala...@haloniitty.fi> wrote:  
> >>>  
>  On Wed, 27 Mar 2024 11:45:00 -0300
>  salsaman  wrote:
>   
>  > ISTR that the xdg video standards were never defined, If you need any
>  > advice or assistance with this, I would be happy to act in an
>  > advisory capacity if that is called for. I have over 20 years  
>  experience of  
>  > developing Free Software video and have been an active participant in
>  > developing other video / effects standards. I have been a bit our of  
>  the  
>  > spotlight recently as I have been busy architecting and implementing  
>  the  
>  > core components of the upcoming next gen LiVES 4,0 video application  
>  plus  
>  > its accompanying state-of-the-art effects standard)  
> 
>  Hi,
> 
>  what kind of video standards would that be?
> 
>  I'm wondering if it would have anything to do with Wayland color
>  management and HDR:
> 
>  https://gitlab.freedesktop.org/pq/color-and-hdr
> 
>  https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183
> 
>  https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
> 
>  Would there need to be any XDG standards to support color managed HDR
>  desktops, or is the window system support enough?
> 
>  I have not much in my mind, but then I've been staring only at the
>  window system interactions, and haven't seen what else the desktop
>  ecosystem or applications might need.
> 
>  Recommended display calibration and measurement procedures maybe?
> 
>  Desktop viewing environment standards?
> 
>  Viewing environment measurement?
> 
>  They could be as straightforward as referring to a freely available
>  ITU-R or SMPTE papers or others, if there are suitable ones.
> 
> 
>  Thanks,
>  pq
>   
> >>>  



pgpp9JR6KBTue.pgp
Description: OpenPGP digital signature

Re: New maintainer for XDG specs

[90]

28 March 2024 at 04:35, "Matthias Klumpp"  wrote:

> 
> Absolutely, and I agree, there is things to improve for sure! Filing a
> 
> MR, or at least an issue would be a great first step, If none exists
> 
> already. I think making improvements there is also something we should
> 
> be able to get consensus on fairly well :-)
> 

Fantastic. For the time being, I've gone ahead and opened up an issue in order 
to hopefully encourage further discussion and suggestions on what to add to and 
improve for the BDS.
https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/129

Kind regards,
90

Is there a way to detect if the System is XDG independently of the environment variables?

[Jesús Gómez]

Hi.

I understand that the XDG_* environment variables are options for the users
to customize their system, but the lack of them doesn't mean that the
system is not following XDG.

I've been thinking about this, and the more I read the specifications, it
seems to me that "Systems" don't have that responsibility and it is just an
decision of the applications to follow the specifications or not.

I'm thinking this because of the Clojure CLI tool.  I've been discussing
about this with the maintainers and there are 2 options:

1. Or Clojure could detect that the system is following the XDG
specifications (even when no XDG environment variables are in place).
2. Define a flag at any time (installation, execution, packaging, etc., I
think they will decide that part) for following these specs.

I think the more probable path is the flag, and it corresponds with the
idea that the System doesn't have a responsibility to express whether it
follows or not the specifications; but still, given only curiosity, I would
still like to know if the Systems can publish that or if an application can
detect that.

Thank you!

Re: Video standards

[salsaman]

There are two hardware settings from the monitor that overlap video, these
are
- monitor aspect ratio
- monitor pixel aspect ratio
These are both useful when rendering video. The first defines how much
stretch or letterbocing to apply, the second defines non square pixels,
which is goof to know if you want to render fixed size objects (a circle
for example). Knowing the monitor size in RGB or Y plane pixels can also be
useful to define a max or min resize limit (whether it is min or max
depends on the desired display quality level)

On Thu, 28 Mar 2024 at 19:05, salsaman  wrote:

> colour management and hdr mostly intersect with three areas of video:
> pixel formats, yuv <-> rgb conversions and gamma transfer functions.
> For example
> xdg_pixformat_yuv121010
> xdg_subspace_bt2020
> xdg_gamma_bt2020
>
> just off the top of my head, these arent intended to be actual suggestions
>
>
> On Thu, 28 Mar 2024 at 18:57, salsaman  wrote:
>
>> In addition, I am not sure if there are xdg standards for audio, but I
>> would suggest video and follow similar hierarchies, and that both could be
>> classed under a more generic xdg multimedia standard.
>>
>>
>> On Thu, 28 Mar 2024 at 18:48, salsaman  wrote:
>>
>>> Hi, IMO hardware related would be more appropriate under display
>>> standards
>>> Video standards could be more software related, and provide common
>>> definitions, for example , allowing exchange of information between
>>> applications which produce or consume video frames or streams of frames.
>>> Some examples I can think of might be
>>>  xdg_colorspace_RGB,
>>>  xdg_colorspace_YUV
>>>
>>> xdg_pixfmt_RGB24
>>> xdg_pixfmt_YUV420p
>>> etc
>>>
>>>  xdg_gamma_linear
>>>  xdg_gamma_sRGB
>>>
>>> xdg_video_width
>>> xdg_video_height
>>>
>>> I could provide a more full list, but I think if it goes along this
>>> route. the starting point has to be what are we setting out to achieve with
>>> the standards / definitions, and provide a range of speculative use cases.
>>>
>>> Gabriel (salsaman)
>>>
>>>
>>> On Thu, 28 Mar 2024 at 06:07, Pekka Paalanen <
>>> pekka.paala...@haloniitty.fi> wrote:
>>>
 On Wed, 27 Mar 2024 11:45:00 -0300
 salsaman  wrote:

 > ISTR that the xdg video standards were never defined, If you need any
 > advice or assistance with this, I would be happy to act in an
 > advisory capacity if that is called for. I have over 20 years
 experience of
 > developing Free Software video and have been an active participant in
 > developing other video / effects standards. I have been a bit our of
 the
 > spotlight recently as I have been busy architecting and implementing
 the
 > core components of the upcoming next gen LiVES 4,0 video application
 plus
 > its accompanying state-of-the-art effects standard)

 Hi,

 what kind of video standards would that be?

 I'm wondering if it would have anything to do with Wayland color
 management and HDR:

 https://gitlab.freedesktop.org/pq/color-and-hdr

 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183

 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14

 Would there need to be any XDG standards to support color managed HDR
 desktops, or is the window system support enough?

 I have not much in my mind, but then I've been staring only at the
 window system interactions, and haven't seen what else the desktop
 ecosystem or applications might need.

 Recommended display calibration and measurement procedures maybe?

 Desktop viewing environment standards?

 Viewing environment measurement?

 They could be as straightforward as referring to a freely available
 ITU-R or SMPTE papers or others, if there are suitable ones.


 Thanks,
 pq

>>>

Re: Video standards

[salsaman]

colour management and hdr mostly intersect with three areas of video:
pixel formats, yuv <-> rgb conversions and gamma transfer functions.
For example
xdg_pixformat_yuv121010
xdg_subspace_bt2020
xdg_gamma_bt2020

just off the top of my head, these arent intended to be actual suggestions


On Thu, 28 Mar 2024 at 18:57, salsaman  wrote:

> In addition, I am not sure if there are xdg standards for audio, but I
> would suggest video and follow similar hierarchies, and that both could be
> classed under a more generic xdg multimedia standard.
>
>
> On Thu, 28 Mar 2024 at 18:48, salsaman  wrote:
>
>> Hi, IMO hardware related would be more appropriate under display standards
>> Video standards could be more software related, and provide common
>> definitions, for example , allowing exchange of information between
>> applications which produce or consume video frames or streams of frames.
>> Some examples I can think of might be
>>  xdg_colorspace_RGB,
>>  xdg_colorspace_YUV
>>
>> xdg_pixfmt_RGB24
>> xdg_pixfmt_YUV420p
>> etc
>>
>>  xdg_gamma_linear
>>  xdg_gamma_sRGB
>>
>> xdg_video_width
>> xdg_video_height
>>
>> I could provide a more full list, but I think if it goes along this
>> route. the starting point has to be what are we setting out to achieve with
>> the standards / definitions, and provide a range of speculative use cases.
>>
>> Gabriel (salsaman)
>>
>>
>> On Thu, 28 Mar 2024 at 06:07, Pekka Paalanen <
>> pekka.paala...@haloniitty.fi> wrote:
>>
>>> On Wed, 27 Mar 2024 11:45:00 -0300
>>> salsaman  wrote:
>>>
>>> > ISTR that the xdg video standards were never defined, If you need any
>>> > advice or assistance with this, I would be happy to act in an
>>> > advisory capacity if that is called for. I have over 20 years
>>> experience of
>>> > developing Free Software video and have been an active participant in
>>> > developing other video / effects standards. I have been a bit our of
>>> the
>>> > spotlight recently as I have been busy architecting and implementing
>>> the
>>> > core components of the upcoming next gen LiVES 4,0 video application
>>> plus
>>> > its accompanying state-of-the-art effects standard)
>>>
>>> Hi,
>>>
>>> what kind of video standards would that be?
>>>
>>> I'm wondering if it would have anything to do with Wayland color
>>> management and HDR:
>>>
>>> https://gitlab.freedesktop.org/pq/color-and-hdr
>>>
>>> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183
>>>
>>> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
>>>
>>> Would there need to be any XDG standards to support color managed HDR
>>> desktops, or is the window system support enough?
>>>
>>> I have not much in my mind, but then I've been staring only at the
>>> window system interactions, and haven't seen what else the desktop
>>> ecosystem or applications might need.
>>>
>>> Recommended display calibration and measurement procedures maybe?
>>>
>>> Desktop viewing environment standards?
>>>
>>> Viewing environment measurement?
>>>
>>> They could be as straightforward as referring to a freely available
>>> ITU-R or SMPTE papers or others, if there are suitable ones.
>>>
>>>
>>> Thanks,
>>> pq
>>>
>>

Re: Video standards

[salsaman]

In addition, I am not sure if there are xdg standards for audio, but I
would suggest video and follow similar hierarchies, and that both could be
classed under a more generic xdg multimedia standard.


On Thu, 28 Mar 2024 at 18:48, salsaman  wrote:

> Hi, IMO hardware related would be more appropriate under display standards
> Video standards could be more software related, and provide common
> definitions, for example , allowing exchange of information between
> applications which produce or consume video frames or streams of frames.
> Some examples I can think of might be
>  xdg_colorspace_RGB,
>  xdg_colorspace_YUV
>
> xdg_pixfmt_RGB24
> xdg_pixfmt_YUV420p
> etc
>
>  xdg_gamma_linear
>  xdg_gamma_sRGB
>
> xdg_video_width
> xdg_video_height
>
> I could provide a more full list, but I think if it goes along this
> route. the starting point has to be what are we setting out to achieve with
> the standards / definitions, and provide a range of speculative use cases.
>
> Gabriel (salsaman)
>
>
> On Thu, 28 Mar 2024 at 06:07, Pekka Paalanen 
> wrote:
>
>> On Wed, 27 Mar 2024 11:45:00 -0300
>> salsaman  wrote:
>>
>> > ISTR that the xdg video standards were never defined, If you need any
>> > advice or assistance with this, I would be happy to act in an
>> > advisory capacity if that is called for. I have over 20 years
>> experience of
>> > developing Free Software video and have been an active participant in
>> > developing other video / effects standards. I have been a bit our of the
>> > spotlight recently as I have been busy architecting and implementing the
>> > core components of the upcoming next gen LiVES 4,0 video application
>> plus
>> > its accompanying state-of-the-art effects standard)
>>
>> Hi,
>>
>> what kind of video standards would that be?
>>
>> I'm wondering if it would have anything to do with Wayland color
>> management and HDR:
>>
>> https://gitlab.freedesktop.org/pq/color-and-hdr
>>
>> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183
>>
>> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
>>
>> Would there need to be any XDG standards to support color managed HDR
>> desktops, or is the window system support enough?
>>
>> I have not much in my mind, but then I've been staring only at the
>> window system interactions, and haven't seen what else the desktop
>> ecosystem or applications might need.
>>
>> Recommended display calibration and measurement procedures maybe?
>>
>> Desktop viewing environment standards?
>>
>> Viewing environment measurement?
>>
>> They could be as straightforward as referring to a freely available
>> ITU-R or SMPTE papers or others, if there are suitable ones.
>>
>>
>> Thanks,
>> pq
>>
>

Re: Video standards

[salsaman]

Hi, IMO hardware related would be more appropriate under display standards
Video standards could be more software related, and provide common
definitions, for example , allowing exchange of information between
applications which produce or consume video frames or streams of frames.
Some examples I can think of might be
 xdg_colorspace_RGB,
 xdg_colorspace_YUV

xdg_pixfmt_RGB24
xdg_pixfmt_YUV420p
etc

 xdg_gamma_linear
 xdg_gamma_sRGB

xdg_video_width
xdg_video_height

I could provide a more full list, but I think if it goes along this  route.
the starting point has to be what are we setting out to achieve with the
standards / definitions, and provide a range of speculative use cases.

Gabriel (salsaman)


On Thu, 28 Mar 2024 at 06:07, Pekka Paalanen 
wrote:

> On Wed, 27 Mar 2024 11:45:00 -0300
> salsaman  wrote:
>
> > ISTR that the xdg video standards were never defined, If you need any
> > advice or assistance with this, I would be happy to act in an
> > advisory capacity if that is called for. I have over 20 years experience
> of
> > developing Free Software video and have been an active participant in
> > developing other video / effects standards. I have been a bit our of the
> > spotlight recently as I have been busy architecting and implementing the
> > core components of the upcoming next gen LiVES 4,0 video application plus
> > its accompanying state-of-the-art effects standard)
>
> Hi,
>
> what kind of video standards would that be?
>
> I'm wondering if it would have anything to do with Wayland color
> management and HDR:
>
> https://gitlab.freedesktop.org/pq/color-and-hdr
>
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183
>
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
>
> Would there need to be any XDG standards to support color managed HDR
> desktops, or is the window system support enough?
>
> I have not much in my mind, but then I've been staring only at the
> window system interactions, and haven't seen what else the desktop
> ecosystem or applications might need.
>
> Recommended display calibration and measurement procedures maybe?
>
> Desktop viewing environment standards?
>
> Viewing environment measurement?
>
> They could be as straightforward as referring to a freely available
> ITU-R or SMPTE papers or others, if there are suitable ones.
>
>
> Thanks,
> pq
>

Re: New maintainer for XDG specs

[Aleix Pol]

Hi Matthias!
Congrats, it's good to see you here taking care of such an important
part of our ecosystem!

Best,
Aleix

On Wed, Mar 27, 2024 at 9:45 AM Daniel Stone  wrote:
>
> Hi all,
> After a bit of a period of inactivity, Matthias Klumpp has agreed to help 
> update and maintain the XDG specs, including the menu and icon-theme specs in 
> particular.
>
> If you have any suggestions or anything you want addressed, please discuss it 
> on the list, or file an issue or merge request.
>
> Thanks to Matthias for stepping up, as well as to Bastien Nocera and David 
> Faure in particular for all their work over the years to get us to this point.
>
> Cheers,
> Daniel

Video standards

[Pekka Paalanen]

On Wed, 27 Mar 2024 11:45:00 -0300
salsaman  wrote:

> ISTR that the xdg video standards were never defined, If you need any
> advice or assistance with this, I would be happy to act in an
> advisory capacity if that is called for. I have over 20 years experience of
> developing Free Software video and have been an active participant in
> developing other video / effects standards. I have been a bit our of the
> spotlight recently as I have been busy architecting and implementing the
> core components of the upcoming next gen LiVES 4,0 video application plus
> its accompanying state-of-the-art effects standard)

Hi,

what kind of video standards would that be?

I'm wondering if it would have anything to do with Wayland color
management and HDR:

https://gitlab.freedesktop.org/pq/color-and-hdr
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14

Would there need to be any XDG standards to support color managed HDR
desktops, or is the window system support enough?

I have not much in my mind, but then I've been staring only at the
window system interactions, and haven't seen what else the desktop
ecosystem or applications might need.

Recommended display calibration and measurement procedures maybe?

Desktop viewing environment standards?

Viewing environment measurement?

They could be as straightforward as referring to a freely available
ITU-R or SMPTE papers or others, if there are suitable ones.


Thanks,
pq


pgpk9SktzVd3R.pgp
Description: OpenPGP digital signature

Re: New maintainer for XDG specs

[Matthias Klumpp]

Am Mi., 27. März 2024 um 15:45 Uhr schrieb salsaman :
> On Wed, 27 Mar 2024 at 10:47, 90  wrote:
>> [...]
>> Hi, Matthias. Thank you for stepping in.
>>
>> Would you consider taking any suggestions for potentially 
>> improving/overhauling and even finalising the XDG Base Directory 
>> specification to provide something of a proper standard for applications to 
>> follow more consistently? As much as I love the spirit of that spec, I can't 
>> help but feel like there are still some flaws to address, particularly when 
>> it comes to things like XDG_RUNTIME_DIR's (frankly kind of insane) 
>> requirements and the somewhat nebulous nature of XDG_CONFIG_DIRS and 
>> XDG_DATA_DIRS.

Absolutely, and I agree, there is things to improve for sure! Filing a
MR, or at least an issue would be a great first step, If none exists
already. I think making improvements there is also something we should
be able to get consensus on fairly well :-)

> ISTR that the xdg video standards were never defined, If you need any advice 
> or assistance with this, I would be happy to act in an advisory capacity if 
> that is called for. I have over 20 years experience of developing Free 
> Software video and have been an active participant in developing other video 
> / effects standards. I have been a bit our of the spotlight recently as I 
> have been busy architecting and implementing the core components of the 
> upcoming next gen LiVES 4,0 video application plus its accompanying 
> state-of-the-art effects standard)

That would be highly valuable, concrete feedback from users of a
potential specification change/addition is great! (Also, LiVES brings
back memories! I used it in high school, back then there was barely
any video editor available on Linux)

Best,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: New maintainer for XDG specs

[Matthias Klumpp]

Hello everyone!

Thank you Daniel for the introduction! :-)
Many of you probably already know me, I've been involved with
Freedesktop for more than a decade, working on PackageKit, maintaining
AppStream and doing a whole bunch of work in related places. If you
are in the Debian world, you might have seen me there as well, working
on Debian itself as well as derivatives of it. You might have also met
me in person at Akademy, GUADEC or FOSDEM!

I am very excited to move things forward and to continue to make
Freedesktop a place where we can collaborate on a strong foundation
for the free desktop, and where people can find documentation on how
to create applications that target most desktop environments or how to
base new DEs on our existing infrastructure.

For the specification repositories and code, do not expect any quick
changes. I do not want to interrupt anyone's work and will observe
what is going on first, to get a clearer picture of who is doing what
kind of work at the moment.
I do hope to move some discussions forward and at least give feedback
on pending MRs though.

For making changes to the specifications, I will also not merge things
that have not reached consensus yet or have no implementation. For
that, I have already reached out informally to KDE and GNOME to get
more eyes on XDG and maybe even dedicated people to connect
Freedesktop discussions to the right engineers within their projects
to comment on. But I think I can do that more formally now.
I also want to reach out to other desktops to get them more involved
with Freedesktop and to give them a voice as well.
I am involved with both KDE and GNOME, so I can't play favours ;-)

In addition to that, I also want to find many of the quasi-standards
that have developed over time and bring them into the specifications
properly (one example would be the naming conventions for symbolic
icons). Those will be easy to review and merge, so if you know any of
them please create a MR!

Any and all help and feedback is highly appreciated! If there is
anything you always wanted to do, or if there's anything I should have
a look at, do not hesitate to contact me. Especially do not hesitate
to contact me if you think anything is not going well, or if you think
I made a mistake/ignored you - issues should be dealt with
immediately, and not be hidden.

Let's see what we can create together!

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: New maintainer for XDG specs

[salsaman]

On Wed, 27 Mar 2024 at 10:47, 90  wrote:

> > Hi all,
> > After a bit of a period of inactivity, Matthias Klumpp has agreed to
> help update and maintain the XDG specs, including the menu and icon-theme
> specs in particular.
> >
> > If you have any suggestions or anything you want addressed, please
> discuss it on the list, or file an issue or merge request.
> >
> > Thanks to Matthias for stepping up, as well as to Bastien Nocera and
> David Faure in particular for all their work over the years to get us to
> this point.
> >
> > Cheers,
> > Daniel
>
> Hi, Matthias. Thank you for stepping in.
>
> Would you consider taking any suggestions for potentially
> improving/overhauling and even finalising the XDG Base Directory
> specification to provide something of a proper standard for applications to
> follow more consistently? As much as I love the spirit of that spec, I
> can't help but feel like there are still some flaws to address,
> particularly when it comes to things like XDG_RUNTIME_DIR's (frankly kind
> of insane) requirements and the somewhat nebulous nature of XDG_CONFIG_DIRS
> and XDG_DATA_DIRS.
>
> Kind regards,
> 90
>

ISTR that the xdg video standards were never defined, If you need any
advice or assistance with this, I would be happy to act in an
advisory capacity if that is called for. I have over 20 years experience of
developing Free Software video and have been an active participant in
developing other video / effects standards. I have been a bit our of the
spotlight recently as I have been busy architecting and implementing the
core components of the upcoming next gen LiVES 4,0 video application plus
its accompanying state-of-the-art effects standard)
-- 
Gabriel Finch, a.k.a Salsaman, a.k.a DJ/VJ Salsa
sals...@gmail.com
*@whatsapp: +55 81 9971 97823 *

General manager, E-stud-1.0 Productions, Brazil.
(custom audio / video composition, mastering, and distribution)

Lead developer, the LiVES project, http://lives-video.com, UK / Europe.
(a tool for VJs and Digital Video Artists)

Contact for tailored audio / video solutions; live events / presentations,
research and consultancy regarding the interface between art and technology/
20+ year track record, with proven results. Master in Applied IT, certified
audio production engineer

Atendimento inglês e português.

https://soundcloud.com/salsa-man-1
https://www.youtube.com/c/salsaman
https://github.com/salsaman

Re: New maintainer for XDG specs

[90]

> Hi all,
> After a bit of a period of inactivity, Matthias Klumpp has agreed to help 
> update and maintain the XDG specs, including the menu and icon-theme specs in 
> particular.
> 
> If you have any suggestions or anything you want addressed, please discuss it 
> on the list, or file an issue or merge request.
> 
> Thanks to Matthias for stepping up, as well as to Bastien Nocera and David 
> Faure in particular for all their work over the years to get us to this point.
> 
> Cheers,
> Daniel

Hi, Matthias. Thank you for stepping in.

Would you consider taking any suggestions for potentially improving/overhauling 
and even finalising the XDG Base Directory specification to provide something 
of a proper standard for applications to follow more consistently? As much as I 
love the spirit of that spec, I can't help but feel like there are still some 
flaws to address, particularly when it comes to things like XDG_RUNTIME_DIR's 
(frankly kind of insane) requirements and the somewhat nebulous nature of 
XDG_CONFIG_DIRS and XDG_DATA_DIRS.

Kind regards,
90

New maintainer for XDG specs

[Daniel Stone]

Hi all,
After a bit of a period of inactivity, Matthias Klumpp has agreed to help 
update and maintain the XDG specs, including the menu and icon-theme specs in 
particular.

If you have any suggestions or anything you want addressed, please discuss it 
on the list, or file an issue or merge request.

Thanks to Matthias for stepping up, as well as to Bastien Nocera and David 
Faure in particular for all their work over the years to get us to this point.

Cheers,
Daniel

Re: Inquiry regarding XDG Base Directory Specification and daemon processes running as root (2nd Attempt)

[90]

11 March 2024 at 19:00, "Bollinger, John"  wrote:

> 
> I think you're overthinking it.
> 
> At any given time, the BDS conformance of any process, whatever its role, 
> should be evaluated in terms of *its own* environment.  Even if that didn't 
> make abundant sense, there really isn't any other viable alternative for a 
> specification relying so fundamentally on environment variables.
> 
> System services are no exception. Consider that even if a service could 
> determine the value of, say, the XDG_CACHE_HOME variable of a client process, 
> chances are poor that the service could access the designated directory even 
> if it wanted to do.  And it would be an enormous security vulnerability if it 
> could and did.
> 
> Bear in mind also that even different processes running strictly by, as, and 
> for a particular user don't have to have the same values for their 
> BDS-relevant environment variables.  In this sense too, BDS is inescapably a 
> per-process specification.

Gotcha. That is a bit annoying then for things like SSH and VNC servers, whose 
server processes look for per-user configuration for the user being accessed 
through those server protocols.

I suppose, then, that the next best thing would just be to provide as much 
configurability for the server programs in order to specify alternative 
file/dir paths for per-user configuration, i.e. also looking for a 
~/.config/vnc/passwd file as opposed to only ~/.vnc/passwd. Of course, this 
would mean that such paths would have to be hard-coded, however it wouldn't be 
too difficult to delegate such server config to a shell script or the like 
running with elevated privileges, i.e. through sudo, in order to then have an 
environment variable value to reference from the running login shell.

I appreciate the response. Kind regards.

Re: Inquiry regarding XDG Base Directory Specification and daemon processes running as root (2nd Attempt)

[Bollinger, John]

Hello Hi,

I think you're overthinking it.

At any given time, the BDS conformance of any process, whatever its role, 
should be evaluated in terms of *its own* environment.  Even if that didn't 
make abundant sense, there really isn't any other viable alternative for a 
specification relying so fundamentally on environment variables.

System services are no exception. Consider that even if a service could 
determine the value of, say, the XDG_CACHE_HOME variable of a client process, 
chances are poor that the service could access the designated directory even if 
it wanted to do.  And it would be an enormous security vulnerability if it 
could and did.

Bear in mind also that even different processes running strictly by, as, and 
for a particular user don't have to have the same values for their BDS-relevant 
environment variables.  In this sense too, BDS is inescapably a per-process 
specification.


Best,

John Bollinger



From: xdg  on behalf of 90 
Sent: Monday, March 11, 2024 1:16 PM
To: xdg@lists.freedesktop.org 
Subject: Inquiry regarding XDG Base Directory Specification and daemon 
processes running as root (2nd Attempt)

[You don't often get email from hi@90.gripe. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

Caution: External Sender. Do not open unless you know the content is safe.


Seeing as last month's inquiry from me went unanswered - probably not helped by 
the fact that I accidentally sent it to the mailing list twice at that moment - 
I would like to make another attempt at asking it. Advice on how to go about 
such implementations for XDGBDS compliance in this case would be greatly 
appreciated. Quoted below:

> In recent times, I've gotten quite heavily interested and invested into the 
> XDGBDS and compliance with it across various pieces of software, and have 
> even gone around to a couple of project to either propose compromises for 
> adoption — for projects which have refused in the past to adopt it - or 
> outright contribute it myself via patches and the like. However, a problem 
> has come up with this endeavour which I would like to ask for some insight on.
>
> As you may know, some programs on Unix-like operating systems consist of both 
> a client component typically run by the current user and a server component, 
> typically a daemon, which may or may not be invoked by a different user such 
> as 'root'. In those cases, it usually isn't possible for this other user to 
> determine environment variables set by the user for which BDS compliance is 
> desired. One could, in theory, scan through the entire process tree and look 
> for the highest-level processes being run by the compliant user before 
> reading the environment of those processes and checking for the relevant XDG_ 
> variables, but I imagine that this would be rather fickle and error-prone. 
> Hence, I wondered if anyone had some other idea in mind as to how full 
> compliance may be achieved for such server software involving daemons. How 
> might one go about this in a reasonable manner?

Kind regards.



Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer

Inquiry regarding XDG Base Directory Specification and daemon processes running as root (2nd Attempt)

[90]

Seeing as last month's inquiry from me went unanswered - probably not helped by 
the fact that I accidentally sent it to the mailing list twice at that moment - 
I would like to make another attempt at asking it. Advice on how to go about 
such implementations for XDGBDS compliance in this case would be greatly 
appreciated. Quoted below:

> In recent times, I've gotten quite heavily interested and invested into the 
> XDGBDS and compliance with it across various pieces of software, and have 
> even gone around to a couple of project to either propose compromises for 
> adoption — for projects which have refused in the past to adopt it - or 
> outright contribute it myself via patches and the like. However, a problem 
> has come up with this endeavour which I would like to ask for some insight on.
> 
> As you may know, some programs on Unix-like operating systems consist of both 
> a client component typically run by the current user and a server component, 
> typically a daemon, which may or may not be invoked by a different user such 
> as 'root'. In those cases, it usually isn't possible for this other user to 
> determine environment variables set by the user for which BDS compliance is 
> desired. One could, in theory, scan through the entire process tree and look 
> for the highest-level processes being run by the compliant user before 
> reading the environment of those processes and checking for the relevant XDG_ 
> variables, but I imagine that this would be rather fickle and error-prone. 
> Hence, I wondered if anyone had some other idea in mind as to how full 
> compliance may be achieved for such server software involving daemons. How 
> might one go about this in a reasonable manner?

Kind regards.

Re: Add "call" category to notification spec

[Guido Günther]

Hi,
On Sun, Mar 10, 2024 at 12:21:46PM -0600, Jared Toomey wrote:
> Hello all,
> 
> I would like to start a discussion for adding a "call" category and
> relevant subcategories to the freedesktop notification-spec:
> (specifications.freedesktop.org/notification-spec/latest/ar01s06.html).

I suggested something like that a while back:

https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/50

Cheers,
 -- Guido

> 
> There's no appropriate standard category for an incoming call. 
> The mobile Wayland shell Phosh calls `feedbackd` to trigger haptic
> feedback and play notification sounds depending on the current profile.
> It checks the notification category to trigger the correct feedback.
> 
> The XMPP client Dino uses generic category "im" for calls, which is not
> in Phosh's hardcoded list of categories that trigger feedback.
> As a result, there is no sound or vibration for incoming calls.
> 
> Tweaking Phosh to trigger `phone-incoming-call` feedback for the 
> "im" category allows Dino to trigger the ringtone and vibration.
> This is just a hack; any other apps using the "im" category more
> appropriately would trigger a full ringtone instead of a short alert.
> 
> I'd imagine many other apps could take advantage of a calls category.
> It is an easy way to integrate feedbackd on mobile Linux.
> 
> GNOME has made "x-gnome.call.unanswered" for missed calls, though I'm
> not sure what the logic there is; seems "im" would suit that type of
> notification. It may be worth standardizing as well I suppose.
> 
> Kind regards,
> 
> Jared Toomey
> 

Add "call" category to notification spec

[Jared Toomey]

Hello all,

I would like to start a discussion for adding a "call" category and
relevant subcategories to the freedesktop notification-spec:
(specifications.freedesktop.org/notification-spec/latest/ar01s06.html).

There's no appropriate standard category for an incoming call. 
The mobile Wayland shell Phosh calls `feedbackd` to trigger haptic
feedback and play notification sounds depending on the current profile.
It checks the notification category to trigger the correct feedback.

The XMPP client Dino uses generic category "im" for calls, which is not
in Phosh's hardcoded list of categories that trigger feedback.
As a result, there is no sound or vibration for incoming calls.

Tweaking Phosh to trigger `phone-incoming-call` feedback for the 
"im" category allows Dino to trigger the ringtone and vibration.
This is just a hack; any other apps using the "im" category more
appropriately would trigger a full ringtone instead of a short alert.

I'd imagine many other apps could take advantage of a calls category.
It is an easy way to integrate feedbackd on mobile Linux.

GNOME has made "x-gnome.call.unanswered" for missed calls, though I'm
not sure what the logic there is; seems "im" would suit that type of
notification. It may be worth standardizing as well I suppose.

Kind regards,

Jared Toomey

Inquiry regarding XDG Base Directory Specification and root-level daemon processes

[90]

Hello there. In recent times, I've gotten quite heavily interested and invested 
into the XDGBDS and compliance with it across various pieces of software, and 
have even gone around to a couple of project to either propose compromises for 
adoption — for projects which have refused in the past to adopt it — or 
outright contribute it myself via patches and the like. However, a problem has 
come up with this endeavour which I would like to ask for some insight on.

As you may know, some programs on Unix-like operating systems consist of both a 
client component typically run by the current user and a server component, 
typically a daemon, which may or may not be invoked by a different user such as 
'root'. In those cases, it usually isn't possible for this other user to 
determine environment variables set by the user for which BDS compliance is 
desired. One could, in theory, scan through the entire process tree and look 
for the highest-level processes being run by the compliant user before reading 
the environment of those processes and checking for the relevant XDG_ 
variables, but I imagine that this would be rather fickle and error-prone. 
Hence, I wondered if anyone had some other idea in mind as to how full 
compliance may be achieved for such server software involving daemons. How 
might one go about this in a reasonable manner?

Kind regards,
90

Inquiry regarding XDG Base Directory Specification and root-level daemon processes

[90]

Hello there. In recent times, I've gotten quite heavily interested and invested 
into the XDGBDS and compliance with it across various pieces of software, and 
have even gone around to a couple of project to either propose compromises for 
adoption — for projects which have refused in the past to adopt it — or 
outright contribute it myself via patches and the like. However, a problem has 
come up with this endeavour which I would like to ask for some insight on.

As you may know, some programs on Unix-like operating systems consist of both a 
client component typically run by the current user and a server component, 
typically a daemon, which may or may not be invoked by a different user such as 
'root'. In those cases, it usually isn't possible for this other user to 
determine environment variables set by the user for which BDS compliance is 
desired. One could, in theory, scan through the entire process tree and look 
for the highest-level processes being run by the compliant user before reading 
the environment of those processes and checking for the relevant XDG_ 
variables, but I imagine that this would be rather fickle and error-prone. 
Hence, I wondered if anyone had some other idea in mind as to how full 
compliance may be achieved for such server software involving daemons. How 
might one go about this in a reasonable manner?

Kind regards,
90
https://90.gripe

Re: Deep Linking for the free desktop

[Soni L.]

With regards to Atom feeds:

The difference between a link type and a data type is that a data type 
transfers data (e.g. a response's body) to another app, while a link 
type transfers the link itself.


Further - and more importantly, if you use content negotiation to detect 
a browser (in order to show an actual webpage), then you cannot open the 
link in a feed reader. Your only option is to make a link that nobody 
can share (because you can't know if your friend has a feed reader 
installed), and then have everyone share the website. At that point, why 
even have a feed? it's not like web browsers would tell you about the 
feed either (anymore).


It's true that Atom feeds allow/recommend to include a link back to the 
feed in the feed itself, which works around the problem of "the response 
body isn't a link", but it just falls apart with content negotiation/the 
desire to have the same link work on both.


On 2024-02-23 11:34, Elsie Hupp wrote:

I have an iPhone (which I dutifully hate), and part of how deep-linking URL 
handlers work is that there is a popup prompt directly *asking the user* 
whether they want to allow a particular app to open the URL, with options like 
“Yes”, “No”, “Always”, and “Never”, more or less in the same way that the 
operating system prompts the user whether or not they want to allow an 
application to receive the pasted contents of the clipboard.

In other words, I assume the way deep-linking URL handlers would work in an XDG 
setting would be with Flatpak portals, which are generally implemented with 
this sort of prompt.

As for things like Atom feeds… wouldn’t these have a MIME type? If so, wouldn’t 
this already be handled by a given web browser’s MIME type handling? In the 
context of Flatpak portals, then, I assume there is already something along the 
lines of which application should be summoned to handle a given data type and 
whether it should be able to do so without user confirmation (i.e. 
“Yes”/“No”/“Always”/“Never”).

Anyway, yes, Flatpak is an XDG standard, but they might have their own mailing 
list that might be more useful for requesting a feature such as this:

https://lists.freedesktop.org/mailman/listinfo/flatpak

Hope this is helpful!

Elsie Hupp

> On Feb 12, 2024, at 8:35 AM, Soni L.  wrote:
> 
> what would deep linking (like the android/ios feature) look like for the free desktop?
> 
> obviously the android/ios feature is explicitly designed to restrict the kinds of apps that can be deep link handlers (so e.g. only the official twitter app can handle twitter links), which seems very anti-free desktop. so what would a free desktop alternative look like?
> 
> the point of deep links is that the same link works both in the browser and in an app.
> 
> also, would it be possible to extend them to, say, atom feeds? those traditionally only open in an app, but it'd be neat if they could also open in the browser.
> 
> (disclaimer: we make fedilinks https://fedilinks.org/ and it is our goal to become this, our goal is to be "deep linking for the free desktop". but alternative proposals are welcome.)

Re: Deep Linking for the free desktop

[Elsie Hupp]

I have an iPhone (which I dutifully hate), and part of how deep-linking URL 
handlers work is that there is a popup prompt directly *asking the user* 
whether they want to allow a particular app to open the URL, with options like 
“Yes”, “No”, “Always”, and “Never”, more or less in the same way that the 
operating system prompts the user whether or not they want to allow an 
application to receive the pasted contents of the clipboard.

In other words, I assume the way deep-linking URL handlers would work in an XDG 
setting would be with Flatpak portals, which are generally implemented with 
this sort of prompt.

As for things like Atom feeds… wouldn’t these have a MIME type? If so, wouldn’t 
this already be handled by a given web browser’s MIME type handling? In the 
context of Flatpak portals, then, I assume there is already something along the 
lines of which application should be summoned to handle a given data type and 
whether it should be able to do so without user confirmation (i.e. 
“Yes”/“No”/“Always”/“Never”).

Anyway, yes, Flatpak is an XDG standard, but they might have their own mailing 
list that might be more useful for requesting a feature such as this:

https://lists.freedesktop.org/mailman/listinfo/flatpak

Hope this is helpful!

Elsie Hupp

> On Feb 12, 2024, at 8:35 AM, Soni L.  wrote:
> 
> what would deep linking (like the android/ios feature) look like for the free 
> desktop?
> 
> obviously the android/ios feature is explicitly designed to restrict the 
> kinds of apps that can be deep link handlers (so e.g. only the official 
> twitter app can handle twitter links), which seems very anti-free desktop. so 
> what would a free desktop alternative look like?
> 
> the point of deep links is that the same link works both in the browser and 
> in an app.
> 
> also, would it be possible to extend them to, say, atom feeds? those 
> traditionally only open in an app, but it'd be neat if they could also open 
> in the browser.
> 
> (disclaimer: we make fedilinks https://fedilinks.org/ and it is our goal to 
> become this, our goal is to be "deep linking for the free desktop". but 
> alternative proposals are welcome.)

Deep Linking for the free desktop

[Soni L.]

what would deep linking (like the android/ios feature) look like for the 
free desktop?


obviously the android/ios feature is explicitly designed to restrict the 
kinds of apps that can be deep link handlers (so e.g. only the official 
twitter app can handle twitter links), which seems very anti-free 
desktop. so what would a free desktop alternative look like?


the point of deep links is that the same link works both in the browser 
and in an app.


also, would it be possible to extend them to, say, atom feeds? those 
traditionally only open in an app, but it'd be neat if they could also 
open in the browser.


(disclaimer: we make fedilinks https://fedilinks.org/ and it is our goal 
to become this, our goal is to be "deep linking for the free desktop". 
but alternative proposals are welcome.)

xdg-utils 1.2.1 Release

[Simon Lees]

Hi All,

xdg-utils 1.2.1 contains three bugfixes found following the 1.2.0 release:
* xdg-icon-resource: Fix for incorrect syntax
* documentation: Proper quoting of _MANUALPAGE and _USAGE sections.
* The version was not bumped from 1.2.0_beta in the internal scripts.

For a full list of changes checkout the changelog 
https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/v1.2.1/ChangeLog?ref_type=tags 



https://gitlab.freedesktop.org/xdg/xdg-utils/-/releases/v1.2.1
https://gitlab.freedesktop.org/xdg/xdg-utils/-/archive/v1.2.1/xdg-utils-v1.2.1.tar.bz2

--

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


OpenPGP_signature.asc
Description: OpenPGP digital signature

xdg-utils 1.2.0 Release

[Simon Lees]

Hi All,

xdg-utils 1.2.0 contains contributions from over 20 people (thankyou) 
some of the highlights are listed below.


* better support for Plasma6, Deepin, LXQt
* partial support for WSL / flatpak's
* Numerous other fixes and improvements

For a full list of changes checkout the changelog 
https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/v1.2.0/ChangeLog?ref_type=tags



https://gitlab.freedesktop.org/xdg/xdg-utils/-/releases/v1.2.0
https://gitlab.freedesktop.org/xdg/xdg-utils/-/archive/v1.2.0/xdg-utils-v1.2.0.tar.bz2


As a side note could someone with wiki permissions please update 
https://www.freedesktop.org/wiki/Software/xdg-utils/ to point to the new 
gitlab releases page.


Thanks

--
Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


OpenPGP_signature.asc
Description: OpenPGP digital signature

External thumbnailer spec

[lnee_94]

The proposal is an extension to the desktop entry spec, which would allow for 
an external program mark itself to be called when a thumbnail is needed.Things 
needed:
A different type of say thumbnailer.
An Exec that has the file to be thumbnailed as the %u or %U if there are many.
A way to disable a thumbnailer this could be done by having a downstream 
desktop entry have Disabled=true

The thumbnailer would add a thumbnail using 
https://www.freedesktop.org/wiki/Specifications/thumbnails/ to the cache and 
then loaded

publickey - lnee_94@protonmail.com - 0xF0B5584A.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: A spec to set default terminal applications?

[Vladimir Kudrya]

FYI, The proposed xdg-terminal-exec 
 now relies on stock 
desktop entries, the shell implementation is optimized, experimental 
cache support is in the works.


The spec proposal is updated 
.


On 14/10/2023 23.33, Vladimir Kudrya wrote:

Hi. Let's dust off this thread.

I'm starting to transition xdg-terminal-exec to use stock entries 
filtered by "TerminalEmulator" in Categories key.


On 31/08/2018 16.35, Jan Tojnar wrote:
Reusing `Categories` key would be nice, but we would still need 
`category-defaults.list` for actually choosing the default 
representant for each category, would not we?


Caching is a good point, we would need to create some mechanism no 
matter which solution we choose – for instance, if some of the 
actions were optional, they would probably need to be cached as well.


On Fri, 31 Aug, 2018 at 2:54 PM, PCMan  wrote:

Hi again,
There is another way to make this xdg terminal exec stuff more
standard compliant by reusing XDG menu spec.
https://specifications.freedesktop.org/menu-spec/latest/apas02.html
We can parse all desktop entry files and collect every one with
Category=TerminalEmulator to generate a list of terminal emulators.
This way we don't have to manually maintain a terminal.list file.
Of course parsing all of the *.desktop files is slow so we will need
something like "update-mime-database" to generate the list.

To provide desktop entry files for those apps which are not shipped
with their own, we can install desktop files for them.
set XDG_DATA_DIRS=/usr/share/terminal-emulators:$XDG_DATA_DIRS

And just add our own desktop entry files in
/usr/share/terminal-emulators/*.desktop for those terminals which do
not have desktop entries.
So we don't need to invent another spec to manage the terminals.

Regards

On Fri, Aug 31, 2018 at 8:46 PM PCMan  wrote:


 Hello,
 Just took a look at xdg-terminal-exec and I liked the idea.
 Actually I figured out something similar previously but did not 
write any code.
 There is, however, one thing I'd like to propose to make the spec 
more complete.

 Use the Desktop Entry Actions.

https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#extra-actions 



 Then, for each desktop entry file of a terminal emulator, we define
 some standard actions:
 * OpenDirInWindow: a command to open a dir in a new tab
 * OpenDirInTab: a command to open a dir in a new tab
 * ExecInWindow: a command to run a program in a new window
 * ExecInTab: a command to run a program in a new tab

 When the "InTab" actions are not defined in the desktop entry file,
 fallback to the "InWindow" version.
 This should cover most of the common operations when we need a 
terminal window.


 For example, we can write xterm.desktop like this
 [Desktop Entry]
 Name=Gnome Terminal
 Exec=gnome-terminal
 Actions=OpenDirInWindow;

 [Desktop Action OpenDirInWindow]
 Name=Open Directory in Terminal
 Exec=gnome-terminal --window --working-directory %f

 [Desktop Action OpenDirInTab]
 Name=Open Directory in Terminal
 Exec=gnome-terminal --tab --working-directory %f

 [Desktop Action ExecInWindow]
 Name=Execute in Terminal
 Exec=gnome-terminal -e %f

 In this way, we reuse the existing spec and support various kinds 
of operations.
 The only drawback is %f means a file name, but what we need to 
pass to

 the terminal emulator is actually a full command line with args.

 Just my two cents.

 On Thu, Aug 30, 2018 at 3:36 PM Vladimir Kudrya 
 wrote:

 >
 > Couple of notes.
 >
 > xdg-terminal-exec in its current form is a minimum intervention
 > solution: you need to place desktop files for some terminals, 
then use

 > xdg-terminal-exec itself as a command to launch terminal.
 >
 > ArgPrefix has a solid generic use case: there was a bug in 
Ocrfeeder:

 > https://bugzilla.gnome.org/show_bug.cgi?id=767732 It required an
 > argument to open file, but no argument to just launch the app. 
Current

 > desktop entry spec can not handle this via single desktop entry.
 >
 >
 > I'll try to sum up, simplify, and build upon Jan's and Ian's 
proposals.

 >
 > Fields for destop entries:
 > MimeType: what app can open
 > MimeTypeView: what app can open for viewing
 > MimeTypeEdit: what app can open for edit
 > Intent: what actions app represents (analogous to MimeType, like:
 > x-intent/terminal, x-intent/increase-brightness.) Choosing goes
 > alongside mimetypes and schemes into mimeapps.list hierarchy.
 > ArgPrefix: argument(s) to be added to the beginning of command 
line if

 > there are other arguments provided.
 >
 > With all above:
 > xdg-open some.file: current behavior
 > xdg-open --edit some.file: uses MimeTypeEdit choices.
 > xdg-open --view some.file: uses MimeTypeView choices.
 > xdg-intent terminal: opens terminal.
 > xdg-intent termianl foo --bar: runs foo --bar in chosen 
terminal, using
 > ArgPrefix if needed. IMHO one of 

Re: Standardize BROWSER and MAILER environment variables.

[Slatian]

Hello again,


There's also sensible-browser from the sensible-utils project.

   https://salsa.debian.org/debian/sensible-utils


Thanks for the pointer to the sensible-utils which point to the 
[environ(7) manpage]:


> The user's preferred utility to {do something}. Any string acceptable 
> as a command_string operand to the `sh -c` command shall be valid.


This already describes pretty well the correct way to use EDITOR and 
PAGER variables which seems to be compatible with how sensible-utils 
(and many others) interpret the BROWSER variable.


```
sh -c "$BROWSER \"\$@\"" BROWSER "$@"
```

For trying other openers the sensible-utils solution is to only do that 
on a 127 or 126 exit code meaning that the command was not found or not 
executable.


For more complex use-cases previously covered by %s or `:`-fallback a 
specification should recommend wrapper scripts as naive implementations 
may not even interpret the shell syntax correctly.


---

As for the MAILER … E-Mail is a mess on this level too.

The most though probably went into the [LibreOffice senddoc.sh script].

All of them have in common, that they either directly or some
`--compose` (or similar) option accept a mailto: URI and are probably 
well off by being treated like described for the BROWSER variable.


Which illustrates that most mailers do one of the following:

* Accept an `attach[ment]=` option for the `mailto:` URI
  (Which is a security problem)
* Have an `--attach` option for their cli (kmail,sylpheed,claws)
* Have a `-a` option for their cli (dtmail, mutt)
* Have a proprietary interface for doing attachments (thunderbird)
* Don't have an interface for attachments at all

My favorite here is the `--attach` option as it seems to be one of the 
more common options while not being very ambiguous (opposed to `-a`).

It is also used by the LibreOffice wrapper itself and
xdg-email (though xdg-email isn't very smart about using it).
It is unfortunately not supported by any implementation of
`/usr/bin/mail` I could find.

---

[environ(7) manpage]:
https://manpages.debian.org/bookworm/manpages/environ.7.en.html

[libreoffice senddoc script]:

https://sources.debian.org/src/libreoffice/4:7.6.3-2/shell/source/unix/misc/senddoc.sh

---

To summarize:

Both BROWSER and MAILER should follow the definition from the environ(7) 
manpage:
> The user's preferred utility to {do something}. Any string acceptable 
> as a command_string operand to the `sh -c` command shall be valid.


The MAILER in addition SHOULD support an `--attach` option that is 
followed by one file path or `file:` URI, multiple instances should be 
possible after the `mailto:` URI.


```
$MAILER mailto:… [--attach …]...
```

---

Looking forward to feedback on this take.

Greetings!

- Slatian

Re: pyxdg-0.28 fails tests with python-3.12

[Andrey G. Grozin]

On Sat, 28 Oct 2023, Andrey G. Grozin wrote:

The problem becomes clear. test_basedirectory.py contains the line

   from imp import reload

with python3.11, it generates a deprecation warning: the module imp is 
deprecated, and will be removed in python3.12. Now in python3.12 it *has* 
been removed. And, instead of a warning, we get a fatal error.

Simply replacing

from imp import reload

by

from importlib import reload

solves the problem. Now the tests pass successfully. But 5 new deprecation 
warnings are produced:


DeprecationWarning: ast.Str is deprecated and will be removed in Python 
3.14; use ast.Constant instead


Probably, it would be better not to wait until things will break again (in 
python3.14), but to fix this new problem now.


Andrey

Re: pyxdg-0.28 fails tests with python-3.12

[Andrey G. Grozin]

The problem becomes clear. test_basedirectory.py contains the line

from imp import reload

with python3.11, it generates a deprecation warning: the module imp is 
deprecated, and will be removed in python3.12. Now in python3.12 it *has* 
been removed. And, instead of a warning, we get a fatal error.


I need to read about replacing

from imp import 

by something supported.

Andrey

Re: pyxdg-0.28 fails tests with python-3.12

[Andrey G. Grozin]

It seems sending log files in the email body leads to problems.

With python-3.10 and python-3.11 tests succeed. With python-3.12 they 
fail. The log file is attached.


Andreypython3.12 -m pytest -vv -ra -l -Wdefault --color=yes -o 
console_output_style=count -p no:cov -p no:flake8 -p no:flakes -p no:pylint -p 
no:markdown -p no:sugar -p no:xvfb -p no:pytest-describe -p no:plus -p no:tavern
= test session 
starts =
platform linux -- Python 3.12.0, pytest-7.4.3, pluggy-1.3.0 -- 
/var/tmp/portage/dev-python/pyxdg-0.28/work/pyxdg-rel-0.28-python3_12/install/usr/bin/python3.12
cachedir: .pytest_cache
hypothesis profile 'default' -> 
database=DirectoryBasedExampleDatabase(PosixPath('/var/tmp/portage/dev-python/pyxdg-0.28/work/pyxdg-rel-0.28/.hypothesis/examples'))
rootdir: /var/tmp/portage/dev-python/pyxdg-0.28/work/pyxdg-rel-0.28
plugins: timeout-2.2.0, anyio-4.0.0, hypothesis-6.88.1, pkgcore-0.12.23
collecting ... collected 49 items / 1 error

=== ERRORS 

_ ERROR collecting 
test/test_basedirectory.py _
ImportError while importing test module 
'/var/tmp/portage/dev-python/pyxdg-0.28/work/pyxdg-rel-0.28/test/test_basedirectory.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
test/test_basedirectory.py:10: in 
reload
E   NameError: name 'reload' is not defined

During handling of the above exception, another exception occurred:
/usr/lib/python3.12/site-packages/_pytest/python.py:617: in _importtestmodule
mod = import_path(self.path, mode=importmode, root=self.config.rootpath)
/usr/lib/python3.12/site-packages/_pytest/pathlib.py:567: in import_path
importlib.import_module(module_name)
/usr/lib/python3.12/importlib/__init__.py:90: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
:1381: in _gcd_import
???
:1354: in _find_and_load
???
:1325: in _find_and_load_unlocked
???
:929: in _load_unlocked
???
/usr/lib/python3.12/site-packages/_pytest/assertion/rewrite.py:186: in 
exec_module
exec(co, module.__dict__)
test/test_basedirectory.py:12: in 
from imp import reload
E   ModuleNotFoundError: No module named 'imp'
=== short test 
summary info ===
ERROR test/test_basedirectory.py
!!! Interrupted: 1 error during 
collection 
== 1 
error in 1.95s 
===

pyxdg-0.28 fails tests with python-3.12

[Andrey G. Grozin]

python3.12 -m pytest -vv -ra -l -Wdefault --color=yes -o
console_output_style=count -p no:cov -p no:flake8 -p no:flakes -p 
no:pylint -p no:markdown -p no:sugar -p no:xvfb -p no:pytest-describe -p plus -p

no:no:tavern
= test session starts
=
platform linux -- Python 3.12.0, pytest-7.4.3, pluggy-1.3.0 --
/var/tmp/portage/dev-python/pyxdg-0.28/work/pyxdg-rel-0.28-python3_12/install/usr/bin/python3.12
cachedir: .pytest_cache
hypothesis profile 'default' ->
database=DirectoryBasedExampleDatabase(PosixPath('/var/tmp/portage/dev-python/pyxdg-0.28/work/pyxdg-rel-0.28/.hypothesis/examples'))
rootdir: /var/tmp/portage/dev-python/pyxdg-0.28/work/pyxdg-rel-0.28
plugins: timeout-2.2.0, anyio-4.0.0, hypothesis-6.88.1, pkgcore-0.12.23
collecting ... collected 49 items / 1 error

=== ERRORS

_ ERROR collecting
test/test_basedirectory.py _
ImportError while importing test module
'/var/tmp/portage/dev-python/pyxdg-0.28/work/pyxdg-rel-0.28/test/test_basedirectory.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
test/test_basedirectory.py:10: in 
reload
E   NameError: name 'reload' is not defined

During handling of the above exception, another exception occurred:
/usr/lib/python3.12/site-packages/_pytest/python.py:617: in _importtestmodule
mod = import_path(self.path, mode=importmode, root=self.config.rootpath)
/usr/lib/python3.12/site-packages/_pytest/pathlib.py:567: in import_path
importlib.import_module(module_name)
/usr/lib/python3.12/importlib/__init__.py:90: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
:1381: in _gcd_import
???
:1354: in _find_and_load
???
:1325: in _find_and_load_unlocked
???
:929: in _load_unlocked
???
/usr/lib/python3.12/site-packages/_pytest/assertion/rewrite.py:186: in
exec_module
exec(co, module.__dict__)
test/test_basedirectory.py:12: in 
from imp import reload
E   ModuleNotFoundError: No module named 'imp'
=== short test summary info
===
ERROR test/test_basedirectory.py
!!! Interrupted: 1 error during
collection 

Re: Standardize BROWSER and MAILER environment variables. __ FollowUp-2

[Steven Kucharzyk]

I would like also to point out that if I try to print an email that is
longer than (1) One Page it "Left Justifies" the remaining pages to the
point of loosing characters. I have adjusted both the browser
magnification and the printer scale to no avail ... first page prints
correct and the rest not. 

I only found this out today, when attempting to make copies for mailing
to the IG over issues I have with the VA facility, so I can show the
correspondence that we have had. Any suggestions would be Appreciated.

Steven Kucharzyk

--

On Tue, 17 Oct 2023 23:41:58 +0200
Guillem Jover  wrote:

> Hi!
> 
> On Mon, 2023-10-16 at 20:14:03 +0200, Slatian wrote:
> > So a specification would have to include:
> > * When are those supposed to be called
> > * What are possible arguments
> > * Fancy %s syntax (or clearly state that it isn't possible)
> > * Quoting and escaping (or clearly state a lack of it)
> > * How fallbacks are supposed to be handled
> > 
> > I'm in favor of having as few features as possible to make it easy
> > to implement correctly without any libraries or helpers.
> > 
> > Before writing a draft, Id like to collect already existing
> > implementations of those variables.
> > 
> > The ones I currently know about are:
> > * xdg-utils (as described above)
> > * newsboat (BROWSER, with %u instead of %s, no fallback)
> 
> There's also sensible-browser from the sensible-utils project.
> 
>   https://salsa.debian.org/debian/sensible-utils
> 
> But doing a couple of quick queries:
> 
>   https://codesearch.debian.net/search?q=%24BROWSER=1=1=1
>   https://codesearch.debian.net/search?q=%22BROWSER%22=1=1
> 
> there seems to be lots of usage for the BROWSER env variable. You
> might want to check there.
> 
> Thanks,
> Guillem



-- 
MAIL DELIVERY CONFIRMATION REQUESTS:
Confirmation Requests, are sent to verify:
* Transmission *
* Verification of delivery by the local mail delivery system *
DOES NOT - Imply:
* The message was actually read or understood by the intended
recipient(s) *
* Indiscriminate confirmations may jeopardize your privacy *

This e-mail message may contain privileged and/or confidential
information, and is intended to be received only by persons entitled to
receive such information. If you have received this e-mail in error,
please notify the sender immediately. Please delete it and all
attachments from any servers, hard drives or any other media. Other use
of this e-mail by you is strictly prohibited.

The information contained in this email may be subject to the export
control laws and regulations of the United States, potentially
including but not limited to the Export Administration Regulations
(EAR) and sanctions regulations issued by the U.S. Department of
Treasury, Office of Foreign Asset Controls (OFAC). As a recipient of
this information you are obligated to comply with all applicable U.S.
export laws and regulations.

Re: Standardize BROWSER and MAILER environment variables.

[Guillem Jover]

Hi!

On Mon, 2023-10-16 at 20:14:03 +0200, Slatian wrote:
> So a specification would have to include:
> * When are those supposed to be called
> * What are possible arguments
> * Fancy %s syntax (or clearly state that it isn't possible)
> * Quoting and escaping (or clearly state a lack of it)
> * How fallbacks are supposed to be handled
> 
> I'm in favor of having as few features as possible to make it easy to
> implement correctly without any libraries or helpers.
> 
> Before writing a draft, Id like to collect already existing implementations
> of those variables.
> 
> The ones I currently know about are:
> * xdg-utils (as described above)
> * newsboat (BROWSER, with %u instead of %s, no fallback)

There's also sensible-browser from the sensible-utils project.

  https://salsa.debian.org/debian/sensible-utils

But doing a couple of quick queries:

  https://codesearch.debian.net/search?q=%24BROWSER=1=1=1
  https://codesearch.debian.net/search?q=%22BROWSER%22=1=1

there seems to be lots of usage for the BROWSER env variable. You
might want to check there.

Thanks,
Guillem

Standardize BROWSER and MAILER environment variables.

[Slatian]

Hello!

Trying to fix issues with the xdg-utils I've noticed, that neither the 
BROWSER nor the MAILER environment variables are properly standardized 
anywhere. There should be a specification on such variables.


I've already opened an issue over on the freedesktop gitlab,
with a rough description of how both are currently handled in xdg-utils:
https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/119

What both currently have in common is that:
* They are colon separated lists of commands that may have arguments.
* The URI or file-path argument is passed after the other arguments.
* Bad/broken support for quoting.
* When a command exits with an error exit code, the next one is tried.

In addition to that the BROWSER variable can have a %s somewhere in it 
that will get replaced with the URL instead of the URL being appended.


Example: BROWSER="fancy-browser --open-url=%s --fancy-option"

For both the fallback mechanism is known to cause trouble i.e. when a 
program was closed less gently (oom-killer, manual kill, crash) it 
causes an error code that triggers a second opener, even if if hours or 
days have passed. (Current proposed solution for xdg-utils are timeouts)


So a specification would have to include:
* When are those supposed to be called
* What are possible arguments
* Fancy %s syntax (or clearly state that it isn't possible)
* Quoting and escaping (or clearly state a lack of it)
* How fallbacks are supposed to be handled

I'm in favor of having as few features as possible to make it easy to 
implement correctly without any libraries or helpers.


Before writing a draft, Id like to collect already existing 
implementations of those variables.


The ones I currently know about are:
* xdg-utils (as described above)
* newsboat (BROWSER, with %u instead of %s, no fallback)

Greetings!

- Slatian

Re: A spec to set default terminal applications?

[Vladimir Kudrya]

Hi. Let's dust off this thread.

I'm starting to transition xdg-terminal-exec to use stock entries 
filtered by "TerminalEmulator" in Categories key.


On 31/08/2018 16.35, Jan Tojnar wrote:
Reusing `Categories` key would be nice, but we would still need 
`category-defaults.list` for actually choosing the default 
representant for each category, would not we?


Caching is a good point, we would need to create some mechanism no 
matter which solution we choose – for instance, if some of the actions 
were optional, they would probably need to be cached as well.


On Fri, 31 Aug, 2018 at 2:54 PM, PCMan  wrote:

Hi again,
There is another way to make this xdg terminal exec stuff more
standard compliant by reusing XDG menu spec.
https://specifications.freedesktop.org/menu-spec/latest/apas02.html
We can parse all desktop entry files and collect every one with
Category=TerminalEmulator to generate a list of terminal emulators.
This way we don't have to manually maintain a terminal.list file.
Of course parsing all of the *.desktop files is slow so we will need
something like "update-mime-database" to generate the list.

To provide desktop entry files for those apps which are not shipped
with their own, we can install desktop files for them.
set XDG_DATA_DIRS=/usr/share/terminal-emulators:$XDG_DATA_DIRS

And just add our own desktop entry files in
/usr/share/terminal-emulators/*.desktop for those terminals which do
not have desktop entries.
So we don't need to invent another spec to manage the terminals.

Regards

On Fri, Aug 31, 2018 at 8:46 PM PCMan  wrote:


 Hello,
 Just took a look at xdg-terminal-exec and I liked the idea.
 Actually I figured out something similar previously but did not 
write any code.
 There is, however, one thing I'd like to propose to make the spec 
more complete.

 Use the Desktop Entry Actions.

https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#extra-actions 



 Then, for each desktop entry file of a terminal emulator, we define
 some standard actions:
 * OpenDirInWindow: a command to open a dir in a new tab
 * OpenDirInTab: a command to open a dir in a new tab
 * ExecInWindow: a command to run a program in a new window
 * ExecInTab: a command to run a program in a new tab

 When the "InTab" actions are not defined in the desktop entry file,
 fallback to the "InWindow" version.
 This should cover most of the common operations when we need a 
terminal window.


 For example, we can write xterm.desktop like this
 [Desktop Entry]
 Name=Gnome Terminal
 Exec=gnome-terminal
 Actions=OpenDirInWindow;

 [Desktop Action OpenDirInWindow]
 Name=Open Directory in Terminal
 Exec=gnome-terminal --window --working-directory %f

 [Desktop Action OpenDirInTab]
 Name=Open Directory in Terminal
 Exec=gnome-terminal --tab --working-directory %f

 [Desktop Action ExecInWindow]
 Name=Execute in Terminal
 Exec=gnome-terminal -e %f

 In this way, we reuse the existing spec and support various kinds 
of operations.

 The only drawback is %f means a file name, but what we need to pass to
 the terminal emulator is actually a full command line with args.

 Just my two cents.

 On Thu, Aug 30, 2018 at 3:36 PM Vladimir Kudrya 
 wrote:

 >
 > Couple of notes.
 >
 > xdg-terminal-exec in its current form is a minimum intervention
 > solution: you need to place desktop files for some terminals, 
then use

 > xdg-terminal-exec itself as a command to launch terminal.
 >
 > ArgPrefix has a solid generic use case: there was a bug in 
Ocrfeeder:

 > https://bugzilla.gnome.org/show_bug.cgi?id=767732 It required an
 > argument to open file, but no argument to just launch the app. 
Current

 > desktop entry spec can not handle this via single desktop entry.
 >
 >
 > I'll try to sum up, simplify, and build upon Jan's and Ian's 
proposals.

 >
 > Fields for destop entries:
 > MimeType: what app can open
 > MimeTypeView: what app can open for viewing
 > MimeTypeEdit: what app can open for edit
 > Intent: what actions app represents (analogous to MimeType, like:
 > x-intent/terminal, x-intent/increase-brightness.) Choosing goes
 > alongside mimetypes and schemes into mimeapps.list hierarchy.
 > ArgPrefix: argument(s) to be added to the beginning of command 
line if

 > there are other arguments provided.
 >
 > With all above:
 > xdg-open some.file: current behavior
 > xdg-open --edit some.file: uses MimeTypeEdit choices.
 > xdg-open --view some.file: uses MimeTypeView choices.
 > xdg-intent terminal: opens terminal.
 > xdg-intent termianl foo --bar: runs foo --bar in chosen terminal, 
using
 > ArgPrefix if needed. IMHO one of the few intents that would ever 
require

 > arguments.
 >
 > This strategy is backward-compatible, uses same data and config
 > hierarchies, works without dbus (I don't want to touch it even 
with ten
 > meter stick), 'xdg-intent terminal' can be used as drop in for 
terminal

 > emulators. (xdg-terminal as wrapper to get rid of that space?).
 > 

xdg-utils 1.2.0-beta1 release

[Simon Lees]

Hi All,

I have created a test beta release of xdg-utils at [1] it contains 
contributions from over 20 people so thakyou to them. Some of the 
highlights are listed below.


* better support for Plasma6, Deepin, LXQt
* partial support for WSL / flatpak's
* Numerous other fixes and improvements

One of the main aim's with this beta release is to sort out any issues 
with the release process as it hasn't been done for quite some time. I 
have just let gitlab create the source tarball automatically, if people 
are happy with this I will just continue to do it this way because its 
simple. In that case we should update the release link on [2].
If people would prefer manual tarballs uploaded to the old location I am 
happy to do that (I have a copy of a tarball locally), someone will just 
need to show me how.


If no one raises any major issues with the beta i'll aim for a full 
release in around 2 weeks time.


Thanks

1. https://gitlab.freedesktop.org/xdg/xdg-utils/-/releases/v1.2.0-beta1
2. https://www.freedesktop.org/wiki/Software/xdg-utils/

--
Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


OpenPGP_signature.asc
Description: OpenPGP digital signature

unit systems representations

[Henry Miller]

I've become interested in what I call representations for my application.  I 
have most of a spec in my company already, I'm wondering if the broader 
community of open source desktops is interested.  If there is already a spec 
that works I cannot find it, but I'll be happy if someone points it to me.

This is about what users see on the user interface.  I believe all "business 
logic" code should strictly work in metric units,  "the system" should have a 
layer (or possibly in the widget toolkit), to do this translation for the user. 
 Of course even when working in metric sometimes the correct unit to work with 
changes - if you are working with something very large or very small then using 
a meter will result in unacceptable floating point loss of precision, but this 
is still less dimensions to keep track of. (and hopefully avoid anything like a 
spaceship crashing because someone assumed the wrong units) 

The US of course hard our weird system. Astronomers typically use light year 
not the metric petametre. In every country historians will have do deal with 
whatever was used before the country adopted metric. There are also regions 
that have not really fully switched to metric resulting in measures like 
kg/acre being in use.

There are a lot of other complex factors that go into what to show.  Often it 
is easy/cheap to measure weight, but if the user wants to see volume the 
conversion gets complex - gravity isn't a constant, your material might not be 
pure, temperature, and pressure are sometimes vary enough to matter, some of 
those variables are easy to measure as well, but others require a lab.  

Even when the measure you want to show is simple, the exact unit can differ for 
different things - airplanes are measured in mm, while most other things that 
large are meters.  Or you might want to see 5meters, 3cm instead of 5.03m.

I am working on an idea that I think captures all the complexity of what 
measures really do in the real world.  Would the freedesk.org community be 
interested in making it into a standard. 

-- 
  Henry Miller
  h...@millerfarm.com

Re: iTunes

[Elsie Hupp]

Hi Adrian,Apple doesn’t follow XDG standards—and neither do Chromebooks, for the most part—but this might nonetheless be of some help…“iTunes” (the application), while it did incorporate ”iTunes” (the music store) pretty early on, was mainly designed for offline listening and synchronizing attached devices.“iTunes” (the application) no longer really exists (except as an unrelated standalone storefront on iPhones). In its place is a much more lightweight music-listening application and separate device-management frameworks.Unlike with their operating systems, Apple has tried to make its media stores and media subscriptions available on as many platforms a possible, and this includes making much of the core functionality available in a web browser, as with Spotify, Netflix, and the like.So while I don’t think you can “purchase” music from “iTunes” (the store) on the web, you should be able to listen to previously “purchased” on the Apple Music website, and if you “purchased” music from the iTunes Store in the past, you can export it (on Mac or Windows) and then reimport it into any web-based music “locker” service, most of which should work on your Chromebook.As for using “iTunes” (the application) on a Chromebook (such as for exporting “purchased” music), it may be possible to run the Windows version of the application using the framework “Wine”, either on the the Chromebook’s underlying Linux subsystem or on a cloud-based virtual private server, but… again, that really isn’t related to XDG specifications.If you want to try using iTunes on Wine, this DuckDuckGo search should help you get started:itunes wine chromebookduckduckgo.comBest,Elsie HuppOn Jul 16, 2023, at 11:20 PM, adrian Nira  wrote:How can I download iTunes on my chromebook?

iTunes

[adrian Nira]

How can I download iTunes on my chromebook?

Re: Is pyxdg still actively maintained?

[Elsie Hupp]

Hi Alex,

In a comment on a pull request, the maintainer of pyxdg, Thomas Kluyver, 
described it as "only exist[ing] for historical reasons”:

https://gitlab.freedesktop.org/xdg/pyxdg/-/merge_requests/13

> Thomas Kluyver @takluyver commented 1 year ago
> 
> Hi Elsie,
> 
> My argument is essentially that a single Python XDG package makes no sense, 
> and it only exists for historical reasons. XDG has a whole lot of 
> specifications and software for a really wide range of things, and it makes 
> no sense to try to combine them in one big Python package. So I'd say you're 
> better off making a new library for dealing with user dirs and publishing it 
> independently.
> 
> If you still want it to be part of PyXDG, and you have (or can get) XDG 
> commit rights, you're welcome to take over as the maintainer of PyXDG.  It's 
> been 9 years since I volunteered to take it over, and I'm not sure anything I 
> work on actually uses it now, so I'd be quite happy to pass on responsibility 
> to someone else.

There is another package, xdg-base-dirs, that is actively maintained, and I 
asked the maintainer there, Scott Stevenson, about taking over pyxdg, and he 
declined:

https://github.com/srstevenson/xdg-base-dirs/issues/83

> Scott Stevenson @srstevenson commented on Oct 30, 2022
> 
> Thanks for opening this @elsiehupp. I'm not looking to take on maintainership 
> of other packages at this time, however, I've commented on #75 to try to 
> renew efforts to find a solution to the namespace collision that doesn't 
> break existing code for either xdg or pyxdg users.

IMHO at the very least pyxdg should be updated with a proper README for PyPI 
explaining the scope and status of the project. I touched on this in another 
pull request, but it wasn’t really the focus there.

https://gitlab.freedesktop.org/xdg/pyxdg/-/merge_requests/12

So to answer your question, pyxdg is not actively maintained, but Thomas seems 
receptive to handing over maintainership of the project to someone who is 
qualified and willing to take on the responsibility.

I don’t know if he’s on this mailing list (though it would make sense if he 
was), but if he doesn’t reply here you could just try opening an issue on the 
main pyxdg repository if you want to offer to be a new maintainer.

Best,
Elsie Hupp

> On May 9, 2023, at 11:51 AM, Alex Lowe  wrote:
> 
> Hi there
> 
> There seems to have been no maintainer activity for pyxdg in the last few 
> months. Obviously folks are busy with their own things, but that leads to the 
> question of whether it can be considered actively maintained or not. If not, 
> how can someone apply to become a maintainer?
> 
> Thanks,
> 
> Alex Lowe

Is pyxdg still actively maintained?

[Alex Lowe]

Hi there

There seems to have been no maintainer activity for pyxdg in the last few
months. Obviously folks are busy with their own things, but that leads to
the question of whether it can be considered actively maintained or not. If
not, how can someone apply to become a maintainer?

Thanks,

Alex Lowe

desktop file category keys, boolean, post-install

[flomer]

Hi,

I've a question about the choice for a good category key for xdg desktop 
files, based on a discussion here:


https://github.com/jackaudio/new-session-manager/issues/96

For that particular category (NSM) two keys are chosen, 
X-NSM-Capable=true and X-NSM-Exec=zynaddsubfx -I jack -O jack


The question is, if two keys are really needed or if one would cover all 
situations.


About X-NSM-Exec there is no discussion, but it's also argued that the 
second X-NSM-Capable is needed, because it needs to be a boolean with 
the following argumentation:


"It is important that this is a boolean value, so that it can be 
manually set to off if needed. (for example, user override of this value 
via local files as a way to filter specific entries; could be used also 
as post-install step in some projects where NSM/liblo is optional at 
build-time). So applications scanning the desktop files need to make 
sure to read the value and it be "true"."


Is this argumentation valid? Or can one also remove a key from the 
desktop file or just set the key empty (X-NSM-Exec=), to set it off 
manually or as post-install step? In that case one would only need one 
key for this category, which is preferable probably.


Regards,

Flomer

MR kindly asking for review

[Wang Gary]

Hi,

I recently submitted a Merge Request (MR) [1] to the xdg-spec project
in the freedesktop GitLab instance. The MR adds DDE to the Registered
OnlyShowIn Environments list, making this information available to
downstream developers, applications, and users.

The MR has been open for a few weeks, and since I don't know if there
are any extra steps that need to be taken before merging, I am writing
to kindly ask for review. Please let me know if there are any
additional steps I need to take to ensure that the MR can be merged,
and if there are any further changes that need to be made.

Thank you for your time and attention to this matter.

Best regards,
Gary

[1]: https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/69

Support wildcards in mimetypes

[Soni L.]

Currently, the standalone xdg tools (i.e., not falling back to the 
desktop environment) do not support wildcards in mimetypes.


So things like x-scheme-handler/web+* cannot be handled by the xdg 
tools. However, having a desktop environment allows correct handling of 
such things.

Status of xdg-utils

[Mark Raymond]

What is the status of xdg-utils? The release notes have entries for 
1.1.4 and 1.1.5, but the latest release is 1.1.3.


Searching, the most recent discussion on the mailing list regarding 
maintenance of xdg-utils appears to be a thread starting with this 
message: 
https://lists.freedesktop.org/archives/xdg/2019-December/014210.html but 
that didn't appear to go anywhere.


Context: I recently asked a question about an apparent bug in 
xdg-screensaver on Unix StackExchange 
(https://unix.stackexchange.com/q/729257/55664). It was fairly quickly 
answered by someone who was able to track down the issue and the one 
line fix. I have patched my copy, but it would be great to get that fix 
out to others. If that can be done by getting the change into the 
official xdg-utils, that would be great; if not, I'll try and find out 
who's the maintainer for my distro and see if I can get it in there.

Re: org.freedesktop.Application: Unclear licence & copyright

[Aleix Pol]

Then it would make sense to provide a different licence, like CC0 or
whatever we can offer. It's good that users know what they can and
cannot do with the snippets on the documentation.

Aleix

On Thu, Dec 15, 2022 at 9:05 PM Thiago Macieira  wrote:
>
> On Wednesday, 14 December 2022 21:20:15 -03 Aleix Pol wrote:
> > Hello,
> > I was recently asked to set the licence header on our
> > org.freedesktop.Application.xml file and realised it's not specified
> > anywhere. I opened a ticket and still don't know.
> >
> > Would anybody know what's the licence of that xml snippet or in its
> > default the documentation files?
> > https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/109
>
> Given that that is a data description of an API, I don't think it's
> copyrightable.
>
> But IANAL.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>Software Architect - Intel DCAI Cloud Engineering
>
>
>

Re: org.freedesktop.Application: Unclear licence & copyright

[Thiago Macieira]

On Wednesday, 14 December 2022 21:20:15 -03 Aleix Pol wrote:
> Hello,
> I was recently asked to set the licence header on our
> org.freedesktop.Application.xml file and realised it's not specified
> anywhere. I opened a ticket and still don't know.
> 
> Would anybody know what's the licence of that xml snippet or in its
> default the documentation files?
> https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/109

Given that that is a data description of an API, I don't think it's 
copyrightable.

But IANAL.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering

org.freedesktop.Application: Unclear licence & copyright

[Aleix Pol]

Hello,
I was recently asked to set the licence header on our
org.freedesktop.Application.xml file and realised it's not specified
anywhere. I opened a ticket and still don't know.

Would anybody know what's the licence of that xml snippet or in its
default the documentation files?
https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/109

Best,
Aleix

Re: XDG Shortcut Standard for the Directory Type

[Jake Gustafson]

Is anyone taking note of this? I believed I used the steps given to 
communicate an issue. Where is the best place to discuss this concern?


On 11/2/22 11:23, Jacob wrote:

Hello,

I've just joined the mailing list. My name is Jake Gustafson, known as 
Poikilos on GitHub and elsewhere. I have been creating stories, 
creature drawings, and comics since I was a child. I started learning 
to code when I was 12. If you look at my profile on GitHub 
 or or a high-level summary on my 
StackOverflow profile 
, you can see my 
various contributions in the form of mostly some small python 
libraries not yet in PyPi and also several pull requests to existing 
projects, as well as assisting with identifying or diagnosing issues 
in public-licensed software.


Thanks for allowing me to join the mailing list automatically. I hope 
this isn't a distraction from the mailing list if my issue is not 
supposed to be here. The website said discussions about XDG should 
take place on this mailing list. I hope this is the best place for the 
technical issue below, since the issue involves the standard itself 
rather than the software, which seems to implement the standard as the 
standard stands, from my tests regarding this issue (using 
desktop-file-validate).


The standard itself is missing a definition of what key is appropriate 
for the path where the Type is Directory. In fact, there doesn't seem 
to be any specification of the Directory type in the XDG standard 
other than that the extension should be ".directory". In fact, there 
seems to be no way to construct such a file in a way 
that desktop-file-validate doesn't show an error.


May I propose "Path" could be the key in this case? It seems intuitive.

It may also pave the way for a "File" Type implemented similarly. I 
suggest adding that.


I have had several uses for such a feature so I implemented these 
features in an alternative standard called blnk 
. If XDG implements the features, I 
would change my program to match the standard. The use cases are as 
follows:
- I (and various tech channels on YouTube) often install GNU/Linux 
systems on old/new computers for relatives to avoid various Windows 
issues. Such users don't understand symlinks. Even Mac users don't 
usually understand aliases (which they are called there and made easy 
to create like on Ubuntu) from what I've seen. They sometimes delete 
all of the files from one symlinked directory since they think there 
are two copies of everything. Having a shortcut that goes to the 
"real" directory is preferable and safer in this case.
- In another case, the directory shortcut can point to a location that 
may not always exist. Even some favorite bars or programs simply 
"forget" (or hide) a subdirectory of an unmounted drive or remote host 
upon loading. This is not clear to the user what is going on. They may 
wonder where the shortcut went or what is happening. If there was a 
complete .directory file standard, then DEs (maybe via xdg-launch or 
some new xdg command that doesn't depend on mimetype) could launch the 
file and stderr could say that the Directory is missing or not 
accessible. The current workaround is to make an Application shortcut 
to a directory, but this is not always advisable. I've heard 
recommendations online saying to launch some particular file browser, 
whereas xdg-launch would be better. If the .directory spec were 
completed then implemented be DEs, there would be a clear answer to 
the question and there wouldn't have to be workarounds or handwritten 
.desktop files.
- Perhaps DEs could implement following .desktop files in a similar 
way to symlinks: to traverse folders while inside of a file/directory 
chooser dialog box even. That feature is implemented on Windows, for 
example. That would allow people to have shortcuts in an appropriate 
place instead of an ever-growing "Favorites" bar in their file 
manager. Also, the favorites bar gets reset to nothing upon changing 
to a different DE or upon running a different flatpak. I understand 
these issues are not the realm of XDG to implement, but having some 
sort of complete specification for Type=Directory would allow DEs to 
do whatever they want with it and have a clear way to remain 
compatible with other DEs in this regard, regardless of whether their 
implementation involves my wishlist.


Thank you,
Jake "Poikilos" Gustafson

Re: EWMH 1.6 with frame synchronization?

[Jonas Ådahl]

On Fri, Nov 25, 2022 at 06:47:57PM +0800, Po Lu wrote:
> Jonas Ådahl  writes:
> 
> > I understand that, but at least you can point at the fact that it has
> > been implemented and used in GNOME for more or less a decade already.
> 
> Well, that apparently does not hold water in the world of the KWin
> developers, who say:
> 
>   https://www.mail-archive.com/kde-bugs-dist@kde.org/msg672095.html
> 
> Specifically:
> 
> > We are not introducing big changes into X11 at this time especially
> > for something non standard.
> 

Not all that surprised, kwin is as many other spending their effort on
Wayland rather than X11, where this issue doesn't exist to begin with.


Jonas

Re: EWMH 1.6 with frame synchronization?

[Po Lu]

Jonas Ådahl  writes:

> I understand that, but at least you can point at the fact that it has
> been implemented and used in GNOME for more or less a decade already.

Well, that apparently does not hold water in the world of the KWin
developers, who say:

  https://www.mail-archive.com/kde-bugs-dist@kde.org/msg672095.html

Specifically:

> We are not introducing big changes into X11 at this time especially
> for something non standard.

Re: EWMH 1.6 with frame synchronization?

[Jonas Ådahl]

On Fri, Nov 25, 2022 at 06:26:40PM +0800, Po Lu wrote:
> Jonas Ådahl  writes:
> 
> > Perhaps open a merge request adding it to
> > https://gitlab.freedesktop.org/xdg/xdg-specs/-/blob/master/wm-spec/wm-spec.xml,
> > but you should probably familiarize with what happened the last time it
> > was attempted, which was in 2011:
> >
> > https://mail.gnome.org/archives/wm-spec-list/2011-October/msg6.html
> 
> AFAICT from that discussion, the effort just fizzled out.  The main/only
> problem with the approach you outlined is that I don't have a
> gitlab.freedesktop.org account, and the lawyers at my organization are
> not keen to let me get one.
> 
> If I were to add the clarifications to the monotonic clock handling and
> send you a patch to wm-spec.xml, could you please open a merge request
> on my behalf?

I don't really have the time and motivation to do the work required move
the frame timings spec anywhere more formal. I can try to help trying to
interpret the mutter and gtk implementation if you have any questions
anyhow.

> 
> > But you can just as well go and implement it anyway, if you need this
> > kind of frame synchronization on X11; it's unrealistic that adding it to
> > wm-spec.xml would mean any changes were to be made to it anyway.
> 
> It'd really be easier for me to work on this if it were in the wm-spec.
> That way, I could point and say "that's a standard!", instead of "that's
> floating somewhere in a bowl of fish soup!"

I understand that, but at least you can point at the fact that it has
been implemented and used in GNOME for more or less a decade already.


Jonas

> 
> Thanks.

Re: EWMH 1.6 with frame synchronization?

[Po Lu]

Jonas Ådahl  writes:

> Perhaps open a merge request adding it to
> https://gitlab.freedesktop.org/xdg/xdg-specs/-/blob/master/wm-spec/wm-spec.xml,
> but you should probably familiarize with what happened the last time it
> was attempted, which was in 2011:
>
> https://mail.gnome.org/archives/wm-spec-list/2011-October/msg6.html

AFAICT from that discussion, the effort just fizzled out.  The main/only
problem with the approach you outlined is that I don't have a
gitlab.freedesktop.org account, and the lawyers at my organization are
not keen to let me get one.

If I were to add the clarifications to the monotonic clock handling and
send you a patch to wm-spec.xml, could you please open a merge request
on my behalf?

> But you can just as well go and implement it anyway, if you need this
> kind of frame synchronization on X11; it's unrealistic that adding it to
> wm-spec.xml would mean any changes were to be made to it anyway.

It'd really be easier for me to work on this if it were in the wm-spec.
That way, I could point and say "that's a standard!", instead of "that's
floating somewhere in a bowl of fish soup!"

Thanks.

Re: EWMH 1.6 with frame synchronization?

[Jonas Ådahl]

On Fri, Nov 25, 2022 at 05:13:45PM +0800, Po Lu wrote:
> Jonas Ådahl  writes:
> 
> > The confusion is that the timestamps can't be generated "directly" but
> > must still wrap in the same way X server timestamps. In other words,
> > it's fine to source your timestamps directly from the monotonic clock,
> > if it's concluded that the X server uses it, but you must still make
> > sure you wrap the values as if the milli second part is encoded using a
> > unsigned 32 bit integer. Mutter got this wrong in the past, and it
> > results in wierd bugs with frozen GTK frame clocks after almost two
> > months of uptime.
> 
> Yes, that's what I said ought to be clarified.  I'm sorry I wasn't too
> clear there.
> 
> So aside from that, what else is preventing the protocol from being
> included in the wm-spec?

I have no idea.

> And how can I help get it included?

Perhaps open a merge request adding it to
https://gitlab.freedesktop.org/xdg/xdg-specs/-/blob/master/wm-spec/wm-spec.xml,
but you should probably familiarize with what happened the last time it
was attempted, which was in 2011:

https://mail.gnome.org/archives/wm-spec-list/2011-October/msg6.html

But you can just as well go and implement it anyway, if you need this
kind of frame synchronization on X11; it's unrealistic that adding it to
wm-spec.xml would mean any changes were to be made to it anyway.


Jonas

> 
> Thanks a lot in advance.

Re: EWMH 1.6 with frame synchronization?

[Po Lu]

Jonas Ådahl  writes:

> The confusion is that the timestamps can't be generated "directly" but
> must still wrap in the same way X server timestamps. In other words,
> it's fine to source your timestamps directly from the monotonic clock,
> if it's concluded that the X server uses it, but you must still make
> sure you wrap the values as if the milli second part is encoded using a
> unsigned 32 bit integer. Mutter got this wrong in the past, and it
> results in wierd bugs with frozen GTK frame clocks after almost two
> months of uptime.

Yes, that's what I said ought to be clarified.  I'm sorry I wasn't too
clear there.

So aside from that, what else is preventing the protocol from being
included in the wm-spec? And how can I help get it included?

Thanks a lot in advance.

Re: EWMH 1.6 with frame synchronization?

[Jonas Ådahl]

On Fri, Nov 25, 2022 at 03:18:36PM +0800, Po Lu wrote:
> Po Lu  writes:
> 
> > Owen Taylor has a frame synchronization protocol for compositing
> > managers: https://fishsoup.net/misc/wm-spec-synchronization.html.
> >
> > It is currently only supported by Mutter and cannot be found outside his
> > blog.  Present does not quite work for this purpose, as the "present
> > redirection" code was never finalized.  Is anyone interested in
> > releasing a new version of the wm-spec with the frame synchronization
> > protocol?  I'd be more comfortable writing code to use it, and maybe
> > implementing it in more compositors, if it was specified in the actual
> > wm-spec.
> >
> > Thanks.
> 
> One clarification in the protocol I'd like to see is for the behavior
> when the X server time overflows to be clarified.  Right now, Mutter
> simply uses the X server time to generate the millisecond part of
> high-precision timestamps when the overflow happens, so that is what X
> clients expect.  I think the protocol should be clarified along those
> lines as well.

It's already relatively clearly specified, even with simple formula
illustrating how the timestamps look:

> For timestamps, the timestamp has the form (x_server_timestamp) * 1000
> + microsecond_value.

That leaves little room for interpretation. What could be improved is
the following part:

> In this case, high precision times can be generated directly, and two
> clients such will be able to exchange timestamps with sub-millisecond
> accuracy.

The confusion is that the timestamps can't be generated "directly" but
must still wrap in the same way X server timestamps. In other words,
it's fine to source your timestamps directly from the monotonic clock,
if it's concluded that the X server uses it, but you must still make
sure you wrap the values as if the milli second part is encoded using a
unsigned 32 bit integer. Mutter got this wrong in the past, and it
results in wierd bugs with frozen GTK frame clocks after almost two
months of uptime.


Jonas

Re: EWMH 1.6 with frame synchronization?

[Po Lu]

Po Lu  writes:

> Owen Taylor has a frame synchronization protocol for compositing
> managers: https://fishsoup.net/misc/wm-spec-synchronization.html.
>
> It is currently only supported by Mutter and cannot be found outside his
> blog.  Present does not quite work for this purpose, as the "present
> redirection" code was never finalized.  Is anyone interested in
> releasing a new version of the wm-spec with the frame synchronization
> protocol?  I'd be more comfortable writing code to use it, and maybe
> implementing it in more compositors, if it was specified in the actual
> wm-spec.
>
> Thanks.

One clarification in the protocol I'd like to see is for the behavior
when the X server time overflows to be clarified.  Right now, Mutter
simply uses the X server time to generate the millisecond part of
high-precision timestamps when the overflow happens, so that is what X
clients expect.  I think the protocol should be clarified along those
lines as well.

EWMH 1.6 with frame synchronization?

[Po Lu]

Owen Taylor has a frame synchronization protocol for compositing
managers: https://fishsoup.net/misc/wm-spec-synchronization.html.

It is currently only supported by Mutter and cannot be found outside his
blog.  Present does not quite work for this purpose, as the "present
redirection" code was never finalized.  Is anyone interested in
releasing a new version of the wm-spec with the frame synchronization
protocol?  I'd be more comfortable writing code to use it, and maybe
implementing it in more compositors, if it was specified in the actual
wm-spec.

Thanks.

XDG Shortcut Standard for the Directory Type

[Jacob]

Hello,

I've just joined the mailing list. My name is Jake Gustafson, known as
Poikilos on GitHub and elsewhere. I have been creating stories, creature
drawings, and comics since I was a child. I started learning to code when I
was 12. If you look at my profile on GitHub 
or or a high-level summary on my StackOverflow profile
, you can see my various
contributions in the form of mostly some small python libraries not yet in
PyPi and also several pull requests to existing projects, as well as
assisting with identifying or diagnosing issues in public-licensed software.

Thanks for allowing me to join the mailing list automatically. I hope this
isn't a distraction from the mailing list if my issue is not supposed to be
here. The website said discussions about XDG should take place on this
mailing list. I hope this is the best place for the technical issue below,
since the issue involves the standard itself rather than the software,
which seems to implement the standard as the standard stands, from my tests
regarding this issue (using desktop-file-validate).

The standard itself is missing a definition of what key is appropriate for
the path where the Type is Directory. In fact, there doesn't seem to be any
specification of the Directory type in the XDG standard other than that the
extension should be ".directory". In fact, there seems to be no way to
construct such a file in a way that desktop-file-validate doesn't show an
error.

May I propose "Path" could be the key in this case? It seems intuitive.

It may also pave the way for a "File" Type implemented similarly. I suggest
adding that.

I have had several uses for such a feature so I implemented these features
in an alternative standard called blnk .
If XDG implements the features, I would change my program to match the
standard. The use cases are as follows:
- I (and various tech channels on YouTube) often install GNU/Linux systems
on old/new computers for relatives to avoid various Windows issues. Such
users don't understand symlinks. Even Mac users don't usually understand
aliases (which they are called there and made easy to create like on
Ubuntu) from what I've seen. They sometimes delete all of the files from
one symlinked directory since they think there are two copies of
everything. Having a shortcut that goes to the "real" directory is
preferable and safer in this case.
- In another case, the directory shortcut can point to a location that may
not always exist. Even some favorite bars or programs simply "forget" (or
hide) a subdirectory of an unmounted drive or remote host upon loading.
This is not clear to the user what is going on. They may wonder where the
shortcut went or what is happening. If there was a complete .directory file
standard, then DEs (maybe via xdg-launch or some new xdg command that
doesn't depend on mimetype) could launch the file and stderr could say that
the Directory is missing or not accessible. The current workaround is to
make an Application shortcut to a directory, but this is not always
advisable. I've heard recommendations online saying to launch some
particular file browser, whereas xdg-launch would be better. If the
.directory spec were completed then implemented be DEs, there would be a
clear answer to the question and there wouldn't have to be workarounds or
handwritten .desktop files.
- Perhaps DEs could implement following .desktop files in a similar way to
symlinks: to traverse folders while inside of a file/directory chooser
dialog box even. That feature is implemented on Windows, for example. That
would allow people to have shortcuts in an appropriate place instead of an
ever-growing "Favorites" bar in their file manager. Also, the favorites bar
gets reset to nothing upon changing to a different DE or upon running a
different flatpak. I understand these issues are not the realm of XDG to
implement, but having some sort of complete specification for
Type=Directory would allow DEs to do whatever they want with it and have a
clear way to remain compatible with other DEs in this regard, regardless of
whether their implementation involves my wishlist.

Thank you,
Jake "Poikilos" Gustafson

Re: Question regarding $XDG_DATA_DIRS

[Elsie Hupp]

There are some scenarios where using or not using the trailing slash does 
actually make a difference, perhaps most prominently in the command-line 
arguments for rsync.

(I can never remember which is correct for a given behavior, so I invariably 
choose wrong. 路‍♀️)

> On Oct 16, 2022, at 11:16 AM, Lennart Poettering  wrote:
> 
> On Do, 13.10.22 00:56, Akbarkhon Variskhanov 
> (akbarkhon.variskha...@gmail.com) wrote:
> 
>> Hi.
>> 
>> I noticed that the default value has a trailing slash for both directories:
>> 
>>> If $XDG_DATA_DIRS is either not set or empty, a value equal to 
>>> /usr/local/share/:/usr/share/ should be used.
>> 
>> I was wondering what's the benefit of including a trailing slash? Is
>> there a specific purpose to it or is it a typo? With all due respect,
>> it looks so out of place. Path-related variables usually strip it off.
>> 
>> Sorry if I'm asking in the wrong place.
> 
> Behaviour should be the same, hence it doesn't matter.
> 
> Note that the root dir "/" necessarily ends in a slash, so it might
> make sense to always suffix dirs like that, to make the root dir less
> special.
> 
> In systemd documentation we have the rule to always suffix dirs with
> "/", to communicate that they are dirs.
> 
> But seriously, whether to suffix dirs or not, effect is the same. And
> to some level it's a bikeshedding questions wether to suffix or not.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

Re: Question regarding $XDG_DATA_DIRS

[Lennart Poettering]

On Do, 13.10.22 00:56, Akbarkhon Variskhanov (akbarkhon.variskha...@gmail.com) 
wrote:

> Hi.
>
> I noticed that the default value has a trailing slash for both directories:
>
> > If $XDG_DATA_DIRS is either not set or empty, a value equal to 
> > /usr/local/share/:/usr/share/ should be used.
>
> I was wondering what's the benefit of including a trailing slash? Is
> there a specific purpose to it or is it a typo? With all due respect,
> it looks so out of place. Path-related variables usually strip it off.
>
> Sorry if I'm asking in the wrong place.

Behaviour should be the same, hence it doesn't matter.

Note that the root dir "/" necessarily ends in a slash, so it might
make sense to always suffix dirs like that, to make the root dir less
special.

In systemd documentation we have the rule to always suffix dirs with
"/", to communicate that they are dirs.

But seriously, whether to suffix dirs or not, effect is the same. And
to some level it's a bikeshedding questions wether to suffix or not.

Lennart

--
Lennart Poettering, Berlin

Question regarding $XDG_DATA_DIRS

[Akbarkhon Variskhanov]

Hi.

I noticed that the default value has a trailing slash for both directories:

> If $XDG_DATA_DIRS is either not set or empty, a value equal to 
> /usr/local/share/:/usr/share/ should be used.

I was wondering what's the benefit of including a trailing slash? Is
there a specific purpose to it or is it a typo? With all due respect,
it looks so out of place. Path-related variables usually strip it off.

Sorry if I'm asking in the wrong place.

Cheers,
Akbar.

Re: XDG_DATA_HOME vs XDG_STATE_HOME usage

[Josef Šimánek]

út 13. 9. 2022 v 1:57 odesílatel Thiago Macieira  napsal:
>
> On Monday, 12 September 2022 16:22:32 PDT Josef Šimánek wrote:
> > Would you recommend XDG_STATE_HOME then? It seems it fits the best.
> > Sync across machines for this file really depends on user preference.
> > Sometimes it makes sense, sometimes not.
>
> Is this a notification the user may dismiss?

This notification is not dismissable, it is a one-off notification for
a given time-range.

> If so, then it should be DATA, not STATE.

STATE makes sense.

Thanks for all the insight, info and recommendation!

> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>Software Architect - Intel DCAI Cloud Engineering
>
>
>

Re: XDG_DATA_HOME vs XDG_STATE_HOME usage

[Thiago Macieira]

On Monday, 12 September 2022 16:22:32 PDT Josef Šimánek wrote:
> Would you recommend XDG_STATE_HOME then? It seems it fits the best.
> Sync across machines for this file really depends on user preference.
> Sometimes it makes sense, sometimes not.

Is this a notification the user may dismiss? If so, then it should be DATA, not 
STATE.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering

Re: XDG_DATA_HOME vs XDG_STATE_HOME usage

[Josef Šimánek]

út 13. 9. 2022 v 0:40 odesílatel Thiago Macieira  napsal:
>
> On Monday, 12 September 2022 15:26:49 PDT Josef Šimánek wrote:
> > Anyway, is that the decision maker for XDG_DATA_HOME vs
> > XDG_STATE_HOME? Synced vs not synced between machines?
>
> No. It should be about the nature of the data.
>
> https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html says
> "state data that should persist between (application) restarts, but that is
> not important or portable enough to the user that ..."
>
> That is to say, if those files were lost, it wouldn't be the end of the world.
> The user may perceive some changes, but not anything that they themselves
> created.
>
> That's again different from cache, which are files that should be periodically
> cleaned up. In my own system, I don't back up cache dirs, but I do back up
> state ones.

XDG_CACHE_HOME wasn't even considered from our side. Currently I'm
trying to find out the difference between XDG_DATA_HOME and
XDG_STATE_HOME for the mentioned usecase.

Would you recommend XDG_STATE_HOME then? It seems it fits the best.
Sync across machines for this file really depends on user preference.
Sometimes it makes sense, sometimes not.

> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>Software Architect - Intel DCAI Cloud Engineering
>
>
>

Re: XDG_DATA_HOME vs XDG_STATE_HOME usage

[Thiago Macieira]

On Monday, 12 September 2022 15:26:49 PDT Josef Šimánek wrote:
> Anyway, is that the decision maker for XDG_DATA_HOME vs
> XDG_STATE_HOME? Synced vs not synced between machines?

No. It should be about the nature of the data.

https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html says
"state data that should persist between (application) restarts, but that is 
not important or portable enough to the user that ..."

That is to say, if those files were lost, it wouldn't be the end of the world. 
The user may perceive some changes, but not anything that they themselves 
created.

That's again different from cache, which are files that should be periodically 
cleaned up. In my own system, I don't back up cache dirs, but I do back up 
state ones.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering

Re: XDG_DATA_HOME vs XDG_STATE_HOME usage

[Josef Šimánek]

út 13. 9. 2022 v 0:12 odesílatel Thiago Macieira  napsal:
>
> On Monday, 12 September 2022 14:39:26 PDT Josef Šimánek wrote:
> > This file is portable between systems, since the whole content is just
> > a number (UNIX timestamp). It is not crucial to the user, but it is
> > beneficial to sync this across machines to avoid potentially redundant
> > update recommendations. Our plan is to recommend update only once per
> > week thanks to this stored UNIX timestamp.
>
> Why would you not want to generate update recommendations? If the software in
> question is per system, the warning should be per system.

I see your point, but sometimes it is friendlier to sync those
notifications in between systems. We're still not 100% decided on
this.

Anyway, is that the decision maker for XDG_DATA_HOME vs
XDG_STATE_HOME? Synced vs not synced between machines?

> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>Software Architect - Intel DCAI Cloud Engineering
>
>
>

Re: XDG_DATA_HOME vs XDG_STATE_HOME usage

[Thiago Macieira]

On Monday, 12 September 2022 14:39:26 PDT Josef Šimánek wrote:
> This file is portable between systems, since the whole content is just
> a number (UNIX timestamp). It is not crucial to the user, but it is
> beneficial to sync this across machines to avoid potentially redundant
> update recommendations. Our plan is to recommend update only once per
> week thanks to this stored UNIX timestamp.

Why would you not want to generate update recommendations? If the software in 
question is per system, the warning should be per system.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering

XDG_DATA_HOME vs XDG_STATE_HOME usage

[Josef Šimánek]

Hello!

In RubyGems [1] we would like to keep the date of last software update
check (just UNIX timestamp) in file, but we're not sure which
directory to use to keep this info according to XDG Base Directory
specification.

According to the specification, it seems XDG_STATE_HOME is the best
place to store this file. But looking at the Debian explanation [2]
XDG_STATE_HOME directory is not recommended to be synced across
machines.

This file is portable between systems, since the whole content is just
a number (UNIX timestamp). It is not crucial to the user, but it is
beneficial to sync this across machines to avoid potentially redundant
update recommendations. Our plan is to recommend update only once per
week thanks to this stored UNIX timestamp.

Is there any recommendation which folder to use for our use case? Any
advice would be much appreciated.

Josef

[1] https://github.com/rubygems/rubygems/pull/5922#discussion_r967752848
[2] table at the end of https://wiki.debian.org/XDGBaseDirectorySpecification

Re: A few questions about escaping in desktop files

[Simon McVittie]

On Wed, 24 Aug 2022 at 16:24:24 -0400, Elsie Hupp wrote:
> As an aside, if the two main reference implementations resolve a number
> of ambiguities in the specification, might updating the specification to
> reflect these two reference implementations be a good way of eliminating
> said ambiguities?

That would be great to have, but for this to happen, someone needs to do
the work. Unfortunately, the people who are best-placed to understand the
finer points of this specification tend to be the same overworked people
who are already keeping an entire desktop environment afloat, which is why
it's me responding to this thread and not a core GNOME or KDE maintainer.

If you or someone else can do the research and propose spec updates,
I can't promise any particular timescale for them to be reviewed (again,
because the best people to review them would be the same overworked people
who need to review everything else), but the more help people can provide
in this direction, the more likely it is to happen.

Sorry, I'm responsible for enough things already and cannot commit to
doing this myself.

smcv

Re: A few questions about escaping in desktop files

[Elsie Hupp]

> It is considered valid and the right interpretation what GNOME and KDE both 
> do.


As an aside, if the two main reference implementations resolve a number of 
ambiguities in the specification, might updating the specification to reflect 
these two reference implementations be a good way of eliminating said 
ambiguities?

(I’m not remotely near familiar enough with any of the material to have any 
specific suggestions, though.)

Re: A few questions about escaping in desktop files

[meator]

On 8/23/22 16:30, Simon McVittie wrote:

That wording seems strange when compared with how GLib implements it,
but again, I didn't write this spec; all I can tell you is what one
of the implementations that have been in daily use for many years is
doing. Perhaps GLib is relying on the "as-if" rule, or perhaps the spec
doesn't match reality, or perhaps the spec author meant something that
is not how we're interpreting it.


Some of my questions still remain unanswered. But I'm not going to 
complain, passing the work to the shell significantly simplifies the 
code logic.



Because GLib is substituting the field codes before doing shell-style
parsing, it would be wrong for it not to quote the expansion of the field
codes. If it didn't quote the expansion of the field codes, then the
shell-style parsing would give it the wrong answer, because not every
character in a shell-style string represents itself: some are metacharacters
with a special meaning, like quotes and spaces.


Thanks, now I understand. My current plan is:
a) Expand the basic \s, \n, \t, \r, and \\ while parsing the desktop files.
b) Substitute the field codes with a quoted version of them (I 
personally put it in double quotes and then escape $, `, " and \ instead 
of using single quotes and then doing '"'"' for single quotes). This 
ensures that the shell won't do anything unexpected with it and that 
there will be the correct number of arguments as the spec requires:


> Implementations must take care not to expand field codes into 
multiple arguments unless explicitly instructed by this specification. 
This means that name fields, filenames and other replacements that can 
contain spaces must be passed as a single argument to the executable 
program after expansion.


c) Pass it to the shell. This gets pretty interesting when 
Terminal=true. I have to do execlp(emulator, emulator, "-e", shell, 
"-c", exec, (char *) NULL). For example for Htop with xterm and /bin/sh: 
"xterm -e /bin/sh -c htop". That is the terminal emulator executing 
shell executing the program. Heh.



For the GNOME side, all you'd really need is the GLib library, not
any GUIs. GDesktopAppInfo objects are responsible for handling .desktop
files.


Thanks! You helped me understand the standard better.


OpenPGP_signature
Description: OpenPGP digital signature

Re: A few questions about escaping in desktop files

[Simon McVittie]

On Mon, 22 Aug 2022 at 21:40:58 +0200, meator wrote:
> Let the shell do the unquoting?! To quote (pun intended) the standard:
> 
> > Implementations must undo quoting before expanding field codes and before
> > passing the argument to the executable program.
> 
> Isn't this forbidden? I guess the universal as-if rule mandates that if it
> won't change the behavior than it's possible, but this is strange.

That wording seems strange when compared with how GLib implements it,
but again, I didn't write this spec; all I can tell you is what one
of the implementations that have been in daily use for many years is
doing. Perhaps GLib is relying on the "as-if" rule, or perhaps the spec
doesn't match reality, or perhaps the spec author meant something that
is not how we're interpreting it.

> Why is [GLib] quoting the evaluated field code? The filenames and URLs are
> pretty unambiguous and could be copied verbatim into the argument without
> fear of something misinterpreting it. If I understand it correctly, it's
> going to be unquoted by g_shell_parse_argv() you mentioned.

Because GLib is substituting the field codes before doing shell-style
parsing, it would be wrong for it not to quote the expansion of the field
codes. If it didn't quote the expansion of the field codes, then the
shell-style parsing would give it the wrong answer, because not every
character in a shell-style string represents itself: some are metacharacters
with a special meaning, like quotes and spaces.

For instance, imagine you have a filename containing spaces, double quotes,
backticks or other awkward characters (this is valid, Unix filenames can
contain anything except '/' and '\x00'). If you have a .desktop file with

Exec=/usr/bin/gvim %f

then you need to end up with the equivalent of this argv for gvim:

char **argv = {"/usr/bin/gvim", "/path/to/Simon's \"awkward\" filename", 
NULL}

(You said you're using C++, so I'm using C/C++ string literal syntax.)

There are basically two ways you could achieve that. The one GLib has
chosen is to replace %f with a shell-quoted version of the path:

/usr/bin/gvim '/path/to/Simon'"'"'s "awkward" filename'

(or anything that would be parsed by a shell as being equivalent to that,
there are lots of choices), and then let g_shell_parse_argv() parse that
to get the desired argv, which it passes to execve() or equivalent.

A variation on this approach, which I think Qt/KDE uses, is to replace
%f with a similarly shell-quoted version of the path, but then pass the
whole thing to a shell and let the shell produce the argv, equivalent to
this C/C++ syntax:

char **argv = {"sh", "-c", "exec /usr/bin/gvim \"/path/to/Simon's 
\\\"awkward\\\" filename\"", NULL}

The other way you could potentially achieve this would be to do the
shell-parsing first, to get:

{"/usr/bin/gvim", "%f", NULL}

and then replace %f in-place, this time without shell-style quoting:

{"/usr/bin/gvim", "/path/to/Simon's \"awkward\" filename", NULL}

The spec forbids field codes inside a quoted argument, which if I understand
correctly makes either of these strategies viable.

> I'll have to somehow configure
> Gnome and KDE on my system or find their specific program that does this but
> this will work.

For the GNOME side, all you'd really need is the GLib library, not
any GUIs. GDesktopAppInfo objects are responsible for handling .desktop
files.

For Qt/KDE, I don't know which specific code is the equivalent of
GDesktopAppInfo.

smcv

Re: A few questions about escaping in desktop files

[meator]

Thanks for your quick response!

On 8/22/22 17:49, Simon McVittie wrote:

I didn't write this specification, but I believe the intention is that you
can either do the word-splitting and unquoting from first principles, or
construct a string to pass to a shell and let the shell do the unquoting.
Reserving characters like $ is a way to be nice to implementations that
want to delegate the word-splitting and unquoting to a shell.


Let the shell do the unquoting?! To quote (pun intended) the standard:

> Implementations must undo quoting before expanding field codes and 
before passing the argument to the executable program.


Isn't this forbidden? I guess the universal as-if rule mandates that if 
it won't change the behavior than it's possible, but this is strange.


When I first read this, I completely ruled out using a shell with Exec, 
but now I see that the "before passing the argument to the executable 
program" part doesn't strictly have to mean that a shell can't do its 
things before it would be passed to the program.


But then there are field codes. As I said, if it behaves correctly than 
it can probably do this in different order but I think this conflicts 
with the two implementations you have described.



GLib does almost the same as you are doing, but reversing your second
and third phases: first it decodes the .desktop file (using GKeyFile
and g_key_file_get_string() to expand the escape sequences \s, \n, \t,
\r, \\), then it replaces field codes like %f with a shell-style-quoted
version of their expansion (so for example %f expands to the result of
g_shell_quote(filename), similar to Python shlex.quote(filename)), then it
does the equivalent of shell word-splitting and unquoting to get an array
of arguments (g_shell_parse_argv(), similar to Python shlex.split()), and
finally it passes that array to an argv-based API similar to execve()
or posix_spawn(). This is considered to be a valid implementation.


A little disclaimer: I am working on a program that does this from the 
ground up. It's in C++ and it doesn't use toolkits nor GLib. I am not 
very familiar with them nor with python so my questions might be trivial.


Why is it quoting the evaluated field code? The filenames and URLs are 
pretty unambiguous and could be copied verbatim into the argument 
without fear of something misinterpreting it. If I understand it 
correctly, it's going to be unquoted by g_shell_parse_argv() you 
mentioned. Is this done just to make the parsing with 
g_shell_parse_argv() simpler?



Or, if you have to use your own implementation, then if in doubt, I would
suggest checking what GNOME and KDE would do with a particular .desktop
file. If they both parse it without error and get the same result, then
that is probably the result to be aiming for. Other GLib-based desktops
will do the same as GNOME, and other Qt-based desktops are likely to do
the same as KDE, so looking at GNOME and KDE will cover most users of
.desktop files.


This is probably the best way to test this. I'll have to somehow 
configure Gnome and KDE on my system or find their specific program that 
does this but this will work.



I believe the intention is that separating arguments with anything
other than a single 0x20 has unspecified behaviour: applications should
not install a .desktop file that does this, and if they do, different
implementations are not guaranteed to parse it the same way.


Ok.


However, if an implementation wants to be able to support something like

 Exec=my-utility --input-from-file=%f

then it is forced to have a parsing model where that works; and if its
parsing model makes that work, then that probably implies that
prefix%isuffix must be expanded to two arguments, "prefix--icon" and
"my-icon-namesuffix". Certainly it looks like this is what GLib would do.



I didn't think of --arg=$f. This makes sense. Field codes would be nicer 
to parse if each field code would have its own argument but this would 
break your example.



Honestly, put your "difficult" strings in a script somewhere else and
then put the path to the script in the .desktop file - that'll be a lot
more reliable and also easier to read.
I'm trying to come up with the most difficult, weird and ambiguous 
strings so that my implementation wouldn't get a segfault on them. If I 
would actually want to execute a program with such peculiar arguments 
than I would try to come up with something more reliable.


OpenPGP_signature
Description: OpenPGP digital signature

Re: A few questions about escaping in desktop files

[Simon McVittie]

On Mon, 22 Aug 2022 at 09:41:45 +0200, meator wrote:
> I've noticed that a lot of the special characters in the second phase have
> something to do with the shell. Is shell supposed to be involved in the
> execution of the program? I'm currently executing it directly (I'm not doing
> sh -c ). If there isn't a shell involved, why are there so many
> restricted characters? They look pretty useless.

I didn't write this specification, but I believe the intention is that you
can either do the word-splitting and unquoting from first principles, or
construct a string to pass to a shell and let the shell do the unquoting.
Reserving characters like $ is a way to be nice to implementations that
want to delegate the word-splitting and unquoting to a shell.

GLib does almost the same as you are doing, but reversing your second
and third phases: first it decodes the .desktop file (using GKeyFile
and g_key_file_get_string() to expand the escape sequences \s, \n, \t,
\r, \\), then it replaces field codes like %f with a shell-style-quoted
version of their expansion (so for example %f expands to the result of
g_shell_quote(filename), similar to Python shlex.quote(filename)), then it
does the equivalent of shell word-splitting and unquoting to get an array
of arguments (g_shell_parse_argv(), similar to Python shlex.split()), and
finally it passes that array to an argv-based API similar to execve()
or posix_spawn(). This is considered to be a valid implementation.

I haven't done any Qt/KDE development for a while, but if I remember
correctly, Qt/KDE does does the first two phases very similarly to
GLib, but then instead of doing the word-splitting itself, it passes
the entire command to a shell via something similar to system() or
{"sh", "-c", ...} and lets the shell figure out what to do next. This is
also considered to be a valid implementation. (Sorry, I don't remember
whether this code is in Qt or in a KDE library.)

If there is an existing high-quality implementation that is suitable for
your language/dependency/etc. requirements (for instance GDesktopAppInfo
in GLib, or whatever part of the Qt/KDE stack is their closest
equivalent), then I'd recommend using that instead of implementing
your own.

Or, if you have to use your own implementation, then if in doubt, I would
suggest checking what GNOME and KDE would do with a particular .desktop
file. If they both parse it without error and get the same result, then
that is probably the result to be aiming for. Other GLib-based desktops
will do the same as GNOME, and other Qt-based desktops are likely to do
the same as KDE, so looking at GNOME and KDE will cover most users of
.desktop files.

Where there are ambiguities in the spec, then the right resolution for
those ambiguities is likely to be one of:

- it is considered valid and the right interpretation is what GNOME and
  KDE both do;

- it is considered invalid, applications should not install .desktop files
  that do this, and if they do, the interpretation is unspecified

> > Arguments are separated by a space.
> 
> A literal space ' ' 0x20? For example the shell uses $IFS which allows a
> space, a tab and a newline as separators.

I believe the intention is that separating arguments with anything
other than a single 0x20 has unspecified behaviour: applications should
not install a .desktop file that does this, and if they do, different
implementations are not guaranteed to parse it the same way.

> How many arguments of echo would
> 
> Exec=echo prefix%isuffix
> 
> produce? 2 or 4?

The intention is clearly that %i appears as an unquoted word in its own
right, rather than being concatenated with other words, so the answer is
"don't do that, it's silly" :-)

However, if an implementation wants to be able to support something like

Exec=my-utility --input-from-file=%f

then it is forced to have a parsing model where that works; and if its
parsing model makes that work, then that probably implies that
prefix%isuffix must be expanded to two arguments, "prefix--icon" and
"my-icon-namesuffix". Certainly it looks like this is what GLib would do.

> So when I have
> 
> Exec=true $test > 1
> 
> It should be quoted as
> 
> Exec=true "\\$test" ">" 1
> 
> And the program would receive three arguments (argc = 4), "$test", ">" and
> "1" or JHRlc3Q=, Pg==, MQ== in base64 (I'm including the base64 encoded
> string because it is unambiguous). Is this correct?

Honestly, put your "difficult" strings in a script somewhere else and
then put the path to the script in the .desktop file - that'll be a lot
more reliable and also easier to read.

smcv

A few questions about escaping in desktop files

[meator]

Hello. I'm reading the latest Desktop Entry Specification and I have 
some questions.
If I understand it correctly, there are three phases of parsing a Exec 
key: the base escaping which is done for string, localestring, 
iconstring and therefore for Exec, Exec quoting and then field code 
expansion.


I've noticed that a lot of the special characters in the second phase 
have something to do with the shell. Is shell supposed to be involved in 
the execution of the program? I'm currently executing it directly (I'm 
not doing sh -c ). If there isn't a shell involved, why are there 
so many restricted characters? They look pretty useless.


The rule says that the argument containing one or more restricted 
characters shall be enclosed in double quotes and the characters 
matching regex ["`$\\] shall be escaped with \.

So when I have

Exec=true $test > 1

It should be quoted as

Exec=true "\\$test" ">" 1

And the program would receive three arguments (argc = 4), "$test", ">" 
and "1" or JHRlc3Q=, Pg==, MQ== in base64 (I'm including the base64 
encoded string because it is unambiguous). Is this correct?


> Arguments are separated by a space.

A literal space ' ' 0x20? For example the shell uses $IFS which allows a 
space, a tab and a newline as separators.


So

Exec=true a\nb

would mean that the 'true' program would receive a single argument (i.e. 
argc = 2). The "\n" would be replaced with a newline in the first phase 
of parsing and the program would receive "ab" as the first 
argument or YQpi in base64. Is this correct?


Let's say I would like to pass a literal "\n" (XG4=) to the program.

Exec=echo n

Is this correct?

> Arguments may be quoted in whole.

What does this mean?

How many arguments of echo would

Exec=echo prefix%isuffix

produce? 2 or 4?

Thanks in advance,
meator


OpenPGP_signature
Description: OpenPGP digital signature

Titlebar widgeting spec finished

[samuel ammonius]

[copy of this gitlab issue
. I probably
should have posted it here from the start]

This is a follow-up for this issue
 from 2 weeks
ago. Since then, I've written the code for the spec and documented it, and
uploaded it here .

I've never contributed to XDG (or anything) before, so I really need some
help with what to do next. Is there anyone I should contact to ask if this
can become a specification?

EDIT: Should I just send a pull request?

Re: Proposal: titlebar widgeting specification

[samuel ammonius]

On Sun, Aug 14, 2022 at 2:41 AM Mathew Gordon  wrote:

> I really like it, this could also give the ability to have an advanced
> title bar in eg: game programming where it's likely that you aren't
> using a widget kit at all. Maybe if anyone is maintaining a WM they
> could implement something like this into the testing branch?


Can you explain what you mean by advanced? The API I've planned
out so far includes the following widgets:

   1. TbSpacer
   2. TbSeparator
   3. TbLabel
   4. TbIcon
   5. TbButton
   6. TbIconButton
   7. TbCheckBox
   8. TbTextInput
   9. TbSlider
   10. TbComboBox
   11. TbListView
   12. TbMenu


(Sorry for the late reply. I rushed through your message without really
getting it, and I thought you were just saying you liked the idea)

Re: Proposal: titlebar widgeting specification

[notebook]

Without having much say, ...


1. Add widgets to the title bar (such as labels, text inputs, buttons, 
checkboxes, combo boxes, etc...) to combine the benefits of CSD and window 
managers


I extremely like this idea!
I would hope that this brings back together window manager windows and the 
current CSD implementations.



 2. Get information about the window manager's appearance to implement CSD 
without off-putting the user


I'm too rookie to judge about the importance of (2)

Regards,
Chris | DarkTrick


On 2022/07/25 5:28, samuel ammonius wrote:

I don't have any rock-solid plan for this specification, I'm just throwing it out there for 
discussion. I'm using the term "window manager" synonymously with "wayland 
compositor" throughout this email. The idea is that window managers could provide an API for 
applications to do either of the following:

 1. Add widgets to the title bar (such as labels, text inputs, buttons, 
checkboxes, combo boxes, etc...) to combine the benefits of CSD and window 
managers
 2. Get information about the window manager's appearance to implement CSD 
without off-putting the user


An API like this could then lead the way for real widgeting toolkits to 
integrate it into their syntax without much contrast. For example, GTK could 
have the headerbar use this API once GNOME's window manager supports this 
specification, or Qt could create a QTitleBar widget with a similar syntax to
QToolBar (including functions like addWidget, addSeparator, and so on). This 
will allow both developers and users to get the best out of what both CSV and 
window managers have to offer, and to be relieved of having to pick one or even 
not getting to choose.

The challenge with creating something like this is that it will have to be very 
well designed if we want to avoid either driving developers crazy or destroying
performance through something like a CSS parser. A design like this is 
possible, but still a challenge. There's a lot of possible ways that the API 
could look, so I'll
give a brief template to get started:

  (This code is going to look horrible on any email clients that don't 
support HTML)  ___

#include #include intmain(intargc,char*argv[]){TitleBar *bar 
=get_titlebar(/* pointer to X11 Window / Wayland shell surface */);TbWidget *checkbox 
=titlebar_add_widget(bar,titlebar_button,"click me!");

 TbWidget*btn =titlebar_add_widget(bar,titlebar_button,"click me!");TbWidget *label 
=titlebar_add_widget(bar,titlebar_label,"<--- click it!!!")titlebar_widget_set_text(label,"<--- 
nevermind, don\'t click it!!!");titlebar_widget_set_tooltip(label,"clicking it will trigger the end of the 
world");titlebar_remove_widget(bar,btn);update_titlebar(bar);sleep(99); /* showtime! */}



This template shows some basic functions that probably wouldn't change much in 
the future. The rest of the implementation could be done in many different ways,
each with their own pros and cons. Here's a few of the questions that would 
need to be answered:

  * *Communication -* How will the API communicate to window managers? One 
option is DBus. Another option could be a standard location for window managers 
to place libraries (eg. /usr/lib/tbwidgets/[openbox].so) which implement the 
specification, but this would require loading those libraries during runtime 
rather than compile time, and I'm not sure if that's even possible.
  * *Layout API -* The possibilities for how apps may want to organize the titlebar in 
different situations is infinite. An app may want to set a maximum and minimum size for 
widgets, may want to use relative or absolute sizing/positioning, may want to hide/shrink 
certain widgets when the titlebar is too small, and so on, so a CSS property-like 
solution would be a bad approach. I think the only way to give users the ability to place 
widgets however they want is to have the user create a function that takes an unsigned 
int parameter for the titlebar's new length, and have a function like 
"titlebar_set_resize_callback(TitleBar *bar, void(*callback)(int));" that the 
user can pass their function to. This callback function could then be called by the 
internal API right before the widgets are rendered whenever the window is resized 
horizontally.
  * *Info detail* - This question applies to the second part of the API as 
mentioned in the introduction. When an app wants to get data about a window 
manager so that it can implement CSD (or maybe even style the app based on the 
appearance of the window manager), what kind of info should be available and 
how should that info be organized? It could get very complicated to offer all 
of this information considering things like gradients, animations, borders, 
shadows, fonts, etc. I don't have any good solutions to this so far.
  o On the topic of how this info will be designed, there would need to be 
a way for apps