Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg

[rhkramer]

On Thursday, September 16, 2021 12:51:05 PM Peter White wrote:
> P.S.: Please reply to the list, so the headers stay intact. I almost did
> not notice and would have replied to you privately. Also, please don't
> break my formatting. I am trying to obey the netiquette of limiting line
> length and quite frankly, so should you. ;)

+1 (especialy on keeping the conversation on list)

Re: Help System Specification: Rationale of help path

[rhkramer]

On Saturday, May 15, 2021 08:35:41 AM notebook wrote:
> rhkramer:
> > I am not likely to ever try to
> > access a help file in other than my native language ((American) English),
> > so getting into a directory with all the other English help files seems
> > more natural to me.
> 
> Unfortunately this only works, if you are able to enjoy the pleasure of an
> almost-always supported language.

Ahh, good point, I guess -- I guess it would be nicer if all languages had all 
the help files ;-)
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Help System Specification: Rationale of help path

[rhkramer]

> On Sun, 2021-05-09 at 07:41 +0900, notebook wrote:
> > Hello,
> > 
> > Summary
> > 
> > I'd like to know why help files are sorted by language first and then
> > by application name, instead of the other way around.
> > // I hope this is the right place
> > Details
> > ===
> > In [1] is specified, that help files are found under
> > `$XDG_DATA_DIRS/help/$lang/$path/`. That is, help files are "sorted"
> > by language first, and then by application name.
> >Example:
> >  /usr/share/help/en/gedit
> >  /usr/share/help/en/firefox
> >  /usr/share/help/de/gedit

>From the peanut gallery, I prefer the above.  I am not likely to ever try to 
access a help file in other than my native language ((American) English), so 
getting into a directory with all the other English help files seems more 
natural to me.

That is as a user -- maybe as a developer who might be translating help files 
into other languages, it might be better the other way round.

But, as Shaun wrote (all elided), it is probably not worth the effort to 
change.


> > I personally see more benefit in "sorted" by application name first,
> > and language second.
> >Example:
> >  /usr/share/help/gedit/en
> >  /usr/share/help/gedit/de
> >  /usr/share/help/firefox/en
> > 
> > Apart from easier manual handling, I would say this ordering helps
> > keeping applications apart from each other, versus, the current spec
> > looks like it turn the whole system into a big soup.
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: A standard for global/desktop environment shortcuts to prevent conflicts with Linux apps

[rhkramer]

On Wednesday, May 06, 2020 08:05:40 PM Noah Davis wrote:
> Start key == Windows key. Maybe I didn't use the right name, but I've
> always called it the Start key since it opens the start menu. It's
> called Meta in Qt and Super in GTK.

Thanks -- I'm going to try to engrave those in my brain (but maybe not 
tonight).

The other one(s) that I don't understand is what I think is called (by at 
least some) the Alt Gr key.  And then the key that looks like it has a menu on 
it.

> 
> On Wed, May 6, 2020 at 5:37 PM  wrote:
> > On Wednesday, May 06, 2020 03:41:16 PM Noah Davis wrote:
> > > Hello, KDE is currently trying to standardize on reserving the
> > > Meta/Super/Start/Command key for global/desktop environment shortcuts.
> > > It seems to me that it would be in the interest of every desktop
> > > environment to standardize on this in order to prevent global/shell
> > > shortcuts from conflicting with Linux apps. For instance, Alt + Left
> > > Click is an old shortcut for dragging windows around that is still
> > > used by KWin, but it conflicts with Blender, GIMP, Inkscape and Krita.
> > > Many creative workflow apps need modifier+mouse button shortcuts to be
> > > fast and easy to use and apps generally avoid using Meta/Super
> > > already.
> > > 
> > > Any thoughts?
> > 
> > Of course!  ;-)
> > 
> > It would help me to know which key(s) you're talking about on a
> > "standard" (Dos / Windows?) 104-key keyboard (well, I didn't count them,
> > but I'm pretty sure it's 104 keys.
> > 
> > The bottom row of my keyboard (the row with the spacebar in it) has keys
> > from left to right:
> > 
> > 
> > 
> > win* is a key with no letters but what looks like the Windows logo
> > 
> > command* is a key with no letters but a logo that might be intended to
> > depict a menu
> > 
> > Which key(s) are you talking about, and what is the (your?) preferred
> > name (or set of names) for that (those) key(s)?
> > 
> > Thanks!
> > 
> > 
> > 
> > ___
> > xdg mailing list
> > xdg@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: A standard for global/desktop environment shortcuts to prevent conflicts with Linux apps

[rhkramer]

On Wednesday, May 06, 2020 03:41:16 PM Noah Davis wrote:
> Hello, KDE is currently trying to standardize on reserving the
> Meta/Super/Start/Command key for global/desktop environment shortcuts.
> It seems to me that it would be in the interest of every desktop
> environment to standardize on this in order to prevent global/shell
> shortcuts from conflicting with Linux apps. For instance, Alt + Left
> Click is an old shortcut for dragging windows around that is still
> used by KWin, but it conflicts with Blender, GIMP, Inkscape and Krita.
> Many creative workflow apps need modifier+mouse button shortcuts to be
> fast and easy to use and apps generally avoid using Meta/Super
> already.
> 
> Any thoughts?

Of course!  ;-)

It would help me to know which key(s) you're talking about on a "standard" 
(Dos / Windows?) 104-key keyboard (well, I didn't count them, but I'm pretty 
sure it's 104 keys.

The bottom row of my keyboard (the row with the spacebar in it) has keys from 
left to right:



win* is a key with no letters but what looks like the Windows logo

command* is a key with no letters but a logo that might be intended to depict 
a menu

Which key(s) are you talking about, and what is the (your?) preferred name (or 
set of names) for that (those) key(s)?

Thanks!



___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Seeking clarification of Desktop Entry Specification

[rhkramer]

On Friday, April 24, 2020 06:37:59 AM Stephan Bergmann wrote:
> I have three questions regarding
>  ec-1.1.html>:
> 
> (1)  #basic-format says "A file is interpreted as a series of lines that
> are separated by linefeed characters."  #value-types says "The escape
> sequences \s, \n, \t, \r, and \\ are supported for values of type string
> and localestring, meaning ASCII space, newline, tab, carriage return,
> and backslash, respectively."  Even though the former is about the
> structure of the file itself while the latter is about the encoded
> payload, it is confusing that one talks about "linefeed" while the other
> talks about "newline" and "carriage return".  Should "newline" read
> "linefeed" (meaning U+000A LINE FEED) instead?

Replying only to (1) re linefeed / newline characters:

Some of the ambiguity / confusion no doubt is because of differences among 
Windows / Linux / Mac usage to indicate line ends.

I won't get these details correct, but you'll get the idea:

Linux uses \n to indicate the end of a line

Windows uses (iirc) \r\n (2 characters, but maybe it is \n\r) to indicate the 
end of a line

Mac (at least the older versions -- the newer versions, based on BSD may use 
\n like Linux) uses \r to indicate the end of a line

(When I talk about things like this, I typically point out that, in (wrapped) 
text files, those line endings indicate the end of a paragraph, not a single 
line -- maybe I'm being a little ambiguous here, so I'll think about 
clarifying that.)

___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: xdg-basedir for secrets

[rhkramer]

On Friday, June 07, 2019 03:49:45 PM Jonas DOREL wrote:
> To me, secrets are fundamentally different from data (even confidential
> data) because they serve as a mean to authenticate you or authorize your
> utilisation of some services.

+1

> I guess the question is: should there be a dedicated folder for secrets
> or should they just be in XDG_DATA_HOME and manage differently by the
> applications (through your configuration) ?

From the peanut gallery, I think it should be somewhere other than 
XDG_DATA_HOME (and ...CONFIG), but probably not refer to it as ...SECRETS.
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Consider adding license information to freedesktop.org wiki contents?

[rhkramer]

On Sunday, May 06, 2018 05:49:15 AM Simon Lees wrote:
> if I wrote anything on the wiki which I don't think I did I would be
> more then happy for it to be relicensed under a BSD/MIT style license
> but would be less happy to allow because I don't think its the right
> license for the task.

allow ___???
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Dashes and underscores in desktop file IDs

[rhkramer]

On Wednesday, October 11, 2017 07:28:08 AM Simon McVittie wrote:
> If there is consensus that the recommendation should be dashes and not
> underscores, I'd be willing to go with that instead, but I think we
> should pick one.

I'd like to cast a vote in favor of dashes instead of underscores, primarily 
because (at least on US keyboards), typing an underscore requires pressing 
 while typing a dash does not.

I do agree that a standard would be nice--in lots of situations (not just app 
names, but also filenames for example), either might be used, and if I need to 
glance at a filename, store it in short term wetwork memory, I always have 
trouble distinguishing and remembering whether what I saw was a dash or an 
underbar.  It requires an extra level of concentration which I would prefer to 
avoid.

(I suppose I will eventually train myself to look more carefully at things 
like filenames with underbars or dashes rather than have to go back and look a 
2nd time.)

> Unfortunately it looks as though the AppStream spec currently allows
> dashes but not underscores, which (if enforced) conflicts fairly badly
> with Flatpak renaming AppStream XML that doesn't match the Flatpak app
> IDs (underscores but not dashes). Would the maintainers of AppStream
> be willing/able to relax the spec for  to allow underscores?
> If not, then I think the AppStream spec should explain what you should
> do if your desktop file ID contains an underscore (presumably replacing
> it with a dash).
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Fwd: why not XDG_PREFIX_HOME

[rhkramer]

On Friday, September 15, 2017 07:45:14 AM Johannes Löthberg wrote:
> Hey,
> 
> Quoting Marc Boocha (2017-08-30 10:37:44)
> 
> > Instead having an XDG_BIN_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, we should
> > have a single XDG_PREFIX_HOME. This will be located as ~/.local. 

I don't agree with the proposal, but, most especially, ~/.local might be the 
default, but should be easily changeable.  (Also, maybe the default should be 
in terms of another environment variable ($HOME) instead of to an explicit 
location.)

See below.

> > Since
> > make install or package manger normal produce these directories, have
> > separate environmental variables is not needed.
> > 
> > XDG_BIN_HOME is equivalent to XDG_PREFIX_HOME/bin
> > 
> > XDG_CONFIG_HOME is equivalent to XDG_PREFIX_HOME/etc (currently ~/.config
> > although I feel this is more logical)
> > 
> > XDG_DATA_HOME is equivalent to XDG_PREFIX_HOME/share
> > 
> > This conserves the number of environmental variable used and makes it
> > easy to add extensions like headers and libraries.
> > 
> > Also since XDG_BIN_DIRS is same as PATH, why is it even needed
> 
> While that might be more consistent with the global directories and
> potentially nicer, I have no plans of making breaking changes to the
> spec that would be much less likely to be adopted.  And you'd end up
> having all of them set for likely years before a significant portion of
> software did adopt it.  

> Some people still would want to have things
> separate, or named differently, so we would still need the old variables
> as well, which would just add more cruft to the spec.  

+1


> Environment
> variables are cheap, not really a precious resource we need to preserve.
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: [PATCH 0/2] XDG basedir bin dirs

[rhkramer]

On Tuesday, August 29, 2017 12:42:01 PM Johannes Löthberg wrote:
> The second patch adds XDG_BIN_HOME and XDG_BIN_DIRS to the basedir spec,
> standardizing ~/.local/bin as the default user-specific bin directory.

I didn't look at the patches (sorry), but I'll comment anyway--as long as it 
is just standardizing ~/.local/bin as the *default* user-specific bin 
directory, I have no objection.

But, I move all user specific configuration and similar files completely out of 
~/ to a (non-standard named) top level directory, e.g., //local/bin.  

And, in general, I keep those directories visible, not hidden.
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Separate X Screens - possible on Intel Integrated HD Graphics?

[rhkramer]

You're welcome!

On Sunday, January 17, 2016 11:49:42 AM you wrote:
> Thanks rhkramer,
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Separate X Screens - possible on Intel Integrated HD Graphics?

[rhkramer]

I just came across an article on Linux Journal that mentions a program named 
x2x which might be helpful.  The mention of x2x is on the third page of the 
article, and I've included one quotation:

Build a Large-Screen Command Center with 
the RPi 2 

http://www.linuxjournal.com/content/build-large-screen-command-center-
rpi-2?page=0,2_source=phplist11_medium=email_content=text_campaign=LinuxCounter%20Newsletter%202016%2F01

I guess I could mention that the article deals with two (large) monitors 
driven by separate Raspberry Pis runniing, essentially, Debian (Raspian)--now 
read the quote above.


With x2x, you can move the mouse (and keyboard focus) from one RPi to the 
other, one monitor to the other, as though the screens were attached to a 
single computer. It's fast and seamless. 


I've just barely skimmed the article, so I make no promises / endorsements--
just something that might be helpful.

On Monday, January 18, 2016 03:55:38 PM you wrote:
> I used to do this with gnome 2 using nvidia's --separate-x-screen
> option, it didn't require a second keyboard and mouse. The reason I used
> to do this is so that I could change virtual desktops / workspaces
> independently per screen, ie screen 1 was on virtual desktop 3 and
> screen 2 was on virtual desktop 4, I could then change screen 2 to be on
> virtual desktop 1 without effecting screen 1. I found this more useful
> then being able to drag windows between screens. Unfortunately modern
> DE's often don't support this well as it involves running two instances
> of the display manager at the same time. In my case I found that
> enlightenment has this behavior without running separate x screens so I
> use that instead now.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Separate X Screens - possible on Intel Integrated HD Graphics?

[rhkramer]

On Sunday, January 17, 2016 08:10:38 AM you wrote:
> The usual pattern is that people ask about multiple screens but do not
> really want them. Having multiple screens only limits what you can do
> and gives you no meaningful benefits.

On my previous system (which I used for about 5 years) I used multiple screens 
(driven by an NVidia card) to great benefit.  My current system (started using 
about 6 months ago) has a 32" monitor so I no longer feel the need for 
multiple screens.

On some of the industrial (process control) systems I've been responsible for, 
we put up to 4 monitors (with different displays) driven by one computer in 
front of a single operator.

I have to admit that the Linux / X window (and successor) terminology 
confurses me--when I say multiple screens, I mean multiple monitors driven by 
a single PC and different content on each, and, ideally (but not always the 
case) the ability to move content between displays and copy and paste to and 
from each.

To say that nobody can get any meaningful benefits from multiple screens (or 
from anything else) implies a degree of omniscience (sp?) that I'm not sure 
you have.

I probably should have written this and filed it in my drafts folder, but 
sometimes I don't do what is best for myself.  ;-)
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg