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: Code of Conduct questions

[Jacob Lifshay]

That would also work.

On Sun, Oct 21, 2018 at 5:30 PM John Tapsell  wrote:

> Or could we use an alternative?
>
> On Mon, 22 Oct 2018, 08:36 Jacob Lifshay, 
> wrote:
>
>> Hi, we were thinking of asking if freedesktop would host Kazan (
>> https://github.com/kazan-3d/kazan) for us, however some of our community
>> members have objections with how freedesktop's Code of Conduct is currently
>> written. Would it be acceptable for a project on freedesktop to have a
>> different code of conduct as long as it has similar intent? The code of
>> conduct that we would like to use is similar to
>> https://libre-riscv.org/charter/
>>
>> Thanks,
>> Jacob Lifshay
>> ___
>> 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

Code of Conduct questions

[Jacob Lifshay]

Hi, we were thinking of asking if freedesktop would host Kazan (
https://github.com/kazan-3d/kazan) for us, however some of our community
members have objections with how freedesktop's Code of Conduct is currently
written. Would it be acceptable for a project on freedesktop to have a
different code of conduct as long as it has similar intent? The code of
conduct that we would like to use is similar to
https://libre-riscv.org/charter/

Thanks,
Jacob Lifshay
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

RFD: Using Type=MetaApplication for package managers and application stores

[Jacob Edwards]

Hello everyone.

Over the past few years Ubuntu has been using desktop entries to fetch
applications from its repositories and display them in the software
center. All packages with a desktop file are considered applications;
they appear with their entries' Name, Icon, and Comment in the
software center, while other packages are hidden as technical items.

It turns out this approach is problematic.

 * Some applications have extra desktop launchers. Wesnoth, for instance,
   comes with a map editor. From the perspective of an app store, however,
   'wesnoth.desktop' and 'wesnoth-1.8_editor.desktop' are just one app.
 * Some applications have no primary launcher. Wine, for instance, comes
   with a notepad, a configuration launcher, a registry editor, a program
   uninstaller, a help app, and a drive browser. None of these embody
   Wine as one thing a user is interested in installing.
 * Finally, at a package level, it is often advantageous to package
   desktop launchers separately from the main package. So an app store
   ends up installing a 'app-common' package instead of the entire
   application.

In the past we've manually maintained an entry blacklist and package-app
mapping for the software center. It's become clear that this solution
won't scale.

There's been some discussion around a solution at the package level:

# https://dev.launchpad.net/ArchiveIndex#Overrides

However, I think it would be much cleaner to extend the Desktop Entry
standard to include *generic, non-executable descriptions of a user
application*. Such a file might look like this:

[Desktop Entry]
Version=1.0
Type=MetaApplication
Name=Foo Viewer
Comment=The best viewer for Foo objects available!
URL=http://fooview.com
Icon=fooview
MimeType=image/x-foo;

# And perhaps.
Package=fooview
Screenshot=http://fooview.com/screenshot.jpg
Description=[Longer description of fooview here]

Would any other parties be interested in modifications like this landing
in the Desktop Entry spec?
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

A language checking mailing list

[Jacob R Rideout]

Hello,

Recently, many of the developers of free grammar, style and spell
checking have started to talk about collaboration. OO.o, Gnome and KDE
all are starting to add this capability to their software, but there
is little agreement on standard interfaces and formats. This is
something we'd like to remedy and fd.o seems the proper venue to host
such discussions.

Could we create a mailing list for the Desktop Language Checking Spec

http://freedesktop.org/wiki/Standards_2fdesktop_2dlanguage_2dchecking_2dspec

Perhaps something like [EMAIL PROTECTED] or even
[EMAIL PROTECTED] would work.

Many thanks,

Jacob Rideout
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg