Re: Specifying sensible device types to use an application on in the desktop file

Hi Matthias, On Fri, Oct 09, 2020 at 04:17:07PM +0200, Matthias Klumpp wrote: > Am Fr., 9. Okt. 2020 um 13:29 Uhr schrieb David Edmundson > : > > > > In terms of prior art within Plasma we have: > > `X-KDE-FormFactor` > > > > Values are "desktop", "handset", "tablet", "mediacenter". Though

Re: Specifying sensible device types to use an application on in the desktop file

Hi, On Fri, Oct 09, 2020 at 05:08:10PM +0200, piegames wrote: > So the main motivation for this is to *hide elements* from the menu? As > in, if I unplug the keyboard I cannot find some apps in the launcher > any more? That sounds arbitrary and frustrating IMO. But I don't really > understand the

Re: Specifying sensible device types to use an application on in the desktop file

Am Fr., 9. Okt. 2020 um 16:46 Uhr schrieb Marco Martin : > > On Fri, Oct 9, 2020 at 4:17 PM Matthias Klumpp wrote: > > So within AppStream, apps will highly likely in addition to defining > > their user input methods also be able to set preferred screen sizes > > with an upper and lower limit. >

Re: Specifying sensible device types to use an application on in the desktop file

So the main motivation for this is to *hide elements* from the menu? As in, if I unplug the keyboard I cannot find some apps in the launcher any more? That sounds arbitrary and frustrating IMO. But I don't really understand the point of this feature. What will it bring to the users? To compare:

Re: Specifying sensible device types to use an application on in the desktop file

On Fri, Oct 9, 2020 at 4:17 PM Matthias Klumpp wrote: > So within AppStream, apps will highly likely in addition to defining > their user input methods also be able to set preferred screen sizes > with an upper and lower limit. pixels or millimeters? (would prefer the second) -- Marco Martin

Re: Specifying sensible device types to use an application on in the desktop file

On Fri, Oct 9, 2020 at 4:17 PM Matthias Klumpp wrote: > > Am Fr., 9. Okt. 2020 um 13:29 Uhr schrieb David Edmundson > : > > > > In terms of prior art within Plasma we have: > > `X-KDE-FormFactor` > > > > Values are "desktop", "handset", "tablet", "mediacenter". Though arguably > > it's

Re: Specifying sensible device types to use an application on in the desktop file

Am Fr., 9. Okt. 2020 um 13:29 Uhr schrieb David Edmundson : > > In terms of prior art within Plasma we have: > `X-KDE-FormFactor` > > Values are "desktop", "handset", "tablet", "mediacenter". Though arguably > it's expandable freeform text. > Then this acts as a filter just like the OnlyShowIn

Re: Specifying sensible device types to use an application on in the desktop file

In terms of prior art within Plasma we have: `X-KDE-FormFactor` Values are "desktop", "handset", "tablet", "mediacenter". Though arguably it's expandable freeform text. Then this acts as a filter just like the OnlyShowIn key does. It shows there's clearly a valid use case. David

Specifying sensible device types to use an application on in the desktop file

Hi, with Linux 'desktop' environments nowadays running on different form factors and input methods (desktop pc/laptop, tablet, phone, tv, ...) it would be useful for desktop shells to know what screen resolutions / sizes and ways of user input an application supports in order to make a sensible

Re: RFC: deprecating crypto usage in secret-service

I (nobody) posit that backward compatibility takes a back seat to security, especially for low level systems; that xdg is most useful when all its components achieve widespread adoption; that nobody has ever foreseen the eventual problem with a vulnerability where "you're already screwed

Fix Wiki Page for StatusNotifierItem Markup Specification

Good afternoon, Re: https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/Markup/ ... The above page for allowable markup in StatusNotifierItem specification is broken; there is a missing and wrapping the Image markup example (...) and so the page renders the image HTML rather

Re: Type=Webapp

You propose to add `Type=Webapp` to the desktop entry specification. Thus, please provide the exact semantics of you proposal, ideally in a way that is easy to understand for someone who has read the spec instead of the mail backlog. >From what I understand about your proposal though, it seems to

Re: Type=Webapp

This is exactly what I've understood. I didn't ask for Emmanuel's opinion, but I assume he would've find a different way to make that package, if Type=Webapp and WebApp-mode in browsers would be available. My comment remains. --GK On Mon, 21 Sep 2020 23:16:10 -0700 Sparr wrote: > I

Re: Type=Webapp

I don't think you understood what I was saying. The package you linked to *is* a local installation. There is no "web" involved in using that package. It is conceptually identical to VSCode, just with python httpd and epiphany instead of node and electron. Maybe Type=Webapp would make sense for

Re: Type=Webapp

Sparr, Sure, ConverseJS not a simple local installation, and I don't think it intends to be installed locally, at least not on end-user type of systems. A WebApp is a WebApp, regardless of complexity. That being said, I see the result. Eventually, I think, once Type=Webapp is implemented

Re: Type=Webapp

While ConverseJS is available as a web app, that does not seem relevant to the package you've linked. That package does not use the actual hosted-on-the-internet web app. It deploys a local instance of the conversejs codebase and connects to that with a local browser. In effect, this is no

Re: Type=Webapp

Friends, good evening Allow me to begin and state, that no matter how big an operation is and no matter which industry (i.e. Computing, Entertainment etc.), it appears that we ALWAYS HAVE TO make Trials & Errors in order for us to observe and see what we want for our audience, even in times we

Re: Taking over xdg-utils

I would be happy to test any of these scripts/libraries on i3 and sway. Thayne McCombs On Wed, Sep 2, 2020 at 7:19 PM Simon Lees wrote: > > > > On 8/30/20 6:53 AM, Piotr Karbowski wrote: > > Hi Simon, > > > > On 26/08/2020 09.27, Simon Lees wrote: > >> I am also interested in this, there are

Re: Freedesktop "Recent File Storage Specification" broken by concept - what's the correct way to fix it?

On Thu, 2020-09-03 at 15:30 +0100, Emmanuele Bassi wrote: > Great! I guess I'll need to have access to the repository, then. :-) I've updated the READMEs in the repository: https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/34 The easiest way to contribute a spec is to create a merge

Re: Freedesktop "Recent File Storage Specification" broken by concept - what's the correct way to fix it?

Great! I guess I'll need to have access to the repository, then. :-) Ciao, Emmanuele. On Thu, 3 Sep 2020 at 15:13, Bastien Nocera wrote: > On Thu, 2020-09-03 at 15:11 +0100, Emmanuele Bassi wrote: > > it was just never promoted as the actual specification, and left as a > > "draft" because of

Re: Freedesktop "Recent File Storage Specification" broken by concept - what's the correct way to fix it?

On Thu, 2020-09-03 at 15:11 +0100, Emmanuele Bassi wrote: > it was just never promoted as the actual specification, and left as a > "draft" because of the general state of disrepair of the fd.o > infrastructure. I fixed the specifications website last year to be fully automated and generated out

Re: Freedesktop "Recent File Storage Specification" broken by concept - what's the correct way to fix it?

Hi; On Thu, 3 Sep 2020 at 14:47, Stefan Blachmann wrote: > Hi! > > All DMs and OSes (Windows, MacOS) provide a menu for recently used files. > The freedesktop "Recent File Storage Specification" was probably > intended as an unified means to provide freedesktop software users > with access to

Freedesktop "Recent File Storage Specification" broken by concept - what's the correct way to fix it?

Hi! All DMs and OSes (Windows, MacOS) provide a menu for recently used files. The freedesktop "Recent File Storage Specification" was probably intended as an unified means to provide freedesktop software users with access to recently used files via a start menu. The specification is here:

Re: Taking over xdg-utils

On 8/30/20 6:53 AM, Piotr Karbowski wrote: > Hi Simon, > > On 26/08/2020 09.27, Simon Lees wrote: >> I am also interested in this, there are simply to many bugs related to >> shell quoting behavior etc that break something else when they get >> fixed. Unfortunately I have been moved into a

Re: Standardisation of cgroup usage for user applications

Hi, thanks for the mail. On Tue, 2020-08-25 at 17:02 +0100, David Edmundson wrote: > Given there is realistically only one cgroup controller out there > with user access the current discussions have been happening on > systemd, with a draft specification here: >

Re: RFC: deprecating crypto usage in secret-service

On Sun, 30 Aug 2020 at 22:34:24 -0600, Thayne wrote: > How about having some way to signal to D-Bus that a message is > sensitive so should be stored in non-swappable memory? Sorry, this is unlikely to be implementable. dbus-daemon (or dbus-broker or whatever other message bus implementation is

Re: RFC: deprecating crypto usage in secret-service

How about having some way to signal to D-Bus that a message is sensitive so should be stored in non-swappable memory? > Approaching it from another angle, what threat would this protect > against which could otherwise steal data from D-Bus over unix sockets? > I think it would have to be

Re: Taking over xdg-utils

On 30/08/2020 16.40, Emmanuele Bassi wrote: > That's the literal *opposite* of the correct approach: you must always start > from a compliant code, otherwise you're just writing something that is not > useful to people writing and consuming the freedesktop platform. > > If a specification is

Re: Taking over xdg-utils

Hi, On 30/08/2020 15.18, Emmanuele Bassi wrote: > This approach is entirely broken, and I'd recommend you not do this if you > want > to take over the maintenance of a freedesktop component. I think you're being a bit too harsh here, but I get your point. xdg-utils is supposed to be with

Re: RFC: deprecating crypto usage in secret-service

Thank you for the comments. "Thomas Kluyver" writes: > It's not clear to me that using file descriptors fulfils the same goal > as the encryption mechanism. The secret service spec [1] suggests that > the goal is for swappable memory to contain encrypted (rather than > plaintext) secrets.

Re: Taking over xdg-utils

On Sun, 30 Aug 2020 at 14:50, Piotr Karbowski wrote: > Hi, > > On 30/08/2020 15.18, Emmanuele Bassi wrote: > > This approach is entirely broken, and I'd recommend you not do this if > you want > > to take over the maintenance of a freedesktop component. > > I think you're being a bit too harsh

Re: Taking over xdg-utils

On Sat, 29 Aug 2020 at 22:23, Piotr Karbowski wrote: > My goal is to create a drop-in replacement for xdg-utils, while greatly > simplifying the logic. For example, xdg-open uses xdg-mime, and xdg-mime > have whole logic to choose what tool it should use to query for > mimetype, if there's kde,

Re: Taking over xdg-utils

On Sunday, 30 August, 2020 2:53:37 AM IST Piotr Karbowski wrote: > Hi Simon, > > On 26/08/2020 09.27, Simon Lees wrote: > > I am also interested in this, there are simply to many bugs related to > > shell quoting behavior etc that break something else when they get > > fixed. Unfortunately I have

Re: Taking over xdg-utils

Hi everyone. On 2020-08-30 00:23, Piotr Karbowski wrote: My goal is to create a drop-in replacement for xdg-utils, while greatly simplifying the logic. For example, xdg-open uses xdg-mime, and xdg-mime have whole logic to choose what tool it should use to query for mimetype, if there's kde, it

Re: Taking over xdg-utils

Hi Simon, On 26/08/2020 09.27, Simon Lees wrote: > I am also interested in this, there are simply to many bugs related to > shell quoting behavior etc that break something else when they get > fixed. Unfortunately I have been moved into a different team at work for > the next few months and don't

Re: Taking over xdg-utils

On Wed, 2020-08-26 at 16:57 +0930, Simon Lees wrote: > Hi > > On 8/26/20 1:17 AM, Piotr Karbowski wrote: > > On 25/08/2020 16.54, David Edmundson wrote: > > > >Project looks kind of abandoned and I'd like to pick it up, is > > > there > > > anyone who can pass the access to repository? > > > >

Re: Unable to access free media player spec.

Knowing where it is NOT, isn't particularly useful. The obvious solution is for somebody to upload a copy to gitlab, and then update the link in the wiki. http://lives-video.com https://www.openhub.net/accounts/salsaman On Mon, 17 Aug 2020 at 02:02, Thayne wrote: > gitorious was replaced

Re: Taking over xdg-utils

Hi On 8/26/20 1:17 AM, Piotr Karbowski wrote: > On 25/08/2020 16.54, David Edmundson wrote: >> >Project looks kind of abandoned and I'd like to pick it up, is there >> anyone who can pass the access to repository? >> >> If you want to pick a project up, don't keep asking for permission. I would

Re: Taking over xdg-utils

On 25/08/2020 16.54, David Edmundson wrote: > >Project looks kind of abandoned and I'd like to pick it up, is there > anyone who can pass the access to repository? > > If you want to pick a project up, don't keep asking for permission. I would > start by reviewing everyone else's patches that

Standardisation of cgroup usage for user applications

Recently there has been work on a specification to consistently group userspace application processes together through cgroups and make sure we all use the same naming conventions for services and slices. Given there is realistically only one cgroup controller out there with user access the

Leaving some maintainership positions

Hey, >From today, I won't be maintaining shared-mime-info or the xdg-specs modules anymore. I've also relinquished my mailing-list admin position for this list. For shared-mime-info specifically, 16 years is probably long enough to maintain anything. Cheers PS: I don't intend to remove myself

Re: RFC: deprecating crypto usage in secret-service

It's not clear to me that using file descriptors fulfils the same goal as the encryption mechanism. The secret service spec [1] suggests that the goal is for swappable memory to contain encrypted (rather than plaintext) secrets. Passing the secret over a separate channel wouldn't seem to do

RFC: deprecating crypto usage in secret-service

Hello, Currently, the secret-service protocol suggests two mechanisms ("algorithms" in the specification) to transfer secrets: "plain" and "dh-ietf1024-sha256-aes128-cbc-pkcs7". The former sends secret data in plaintext, while the latter transmits the data in an encrypted form, using a mechanism

Re: Unable to access free media player spec.

gitorious was replaced by gitlab, so I would expect this to be in the xdg-specs repo https://gitlab.freedesktop.org/xdg/xdg-specs. However, I can't find it there. Thayne McCombs On Sun, Aug 16, 2020 at 8:59 PM salsaman wrote: > > Hi, > I am unable to access Free Media Player Specifications, > >

Unable to access free media player spec.

Hi, I am unable to access Free Media Player Specifications, clicking on the link shown on the page https://www.freedesktop.org/wiki/Specifications/free-media-player-specs/

Re: XDG Default Applications specification proposal

Dear XDG list, Am 05.08.20 um 08:03 schrieb Thayne: > On Fri, Jul 31, 2020 at 10:17 AM wrote: >> Elektra has many specifications: >> >> - its API: https://doc.libelektra.org/api/ >> - a >300 pages book capturing the meta-specification >>https://book.libelektra.org >> - many grammars that

Re: XDG Default Applications specification proposal

On Fri, Jul 31, 2020 at 10:17 AM wrote: > Elektra has many specifications: > > - its API: https://doc.libelektra.org/api/ > - a >300 pages book capturing the meta-specification >https://book.libelektra.org > - many grammars that specify different configuration file formats > - different

Re: Taking over xdg-utils

Hi, On 01/01/2020 06.43, Simon Lees wrote: > > Hi > > On 12/31/19 2:55 AM, Piotr Karbowski wrote: >> Hi, >> >> It appears that xdg-utils is dead upstream, handful of merge requests >> (mine including) rots waiting for comments/merge, no new commits being >> pushed to repo either. >> >> I am

Re: XDG Default Applications specification proposal

On Friday, 31 July 2020 09:20:46 PDT elek...@markus-raab.org wrote: > > I could say: without GLib becoming a dependency, GLib will fail on the > > requirement to be available in every distro. Does that mean Qt/KDE > > developers should be willing to accept XDG specifications that are > > written

Re: XDG Default Applications specification proposal

Dear XDG list, short summary as the email got very long: I think the success of the D-Bus specification blinded about the fact that not in every situation a specification is the best solution. For configuration, a protocol that describes how to get or set a configuration value is not feasible. We

Re: XDG Default Applications specification proposal

On Wed, 22 Jul 2020 at 14:39:22 +0200, elek...@markus-raab.org wrote: > Would you also see dbus for notification as implementation detail? Yes; for Notifications, dbus *is* an implementation detail, but D-Bus is not. (I'm being very careful with case combination and spelling here.) The

Re: XDG Default Applications specification proposal

Dear XDG folks, Am 22.07.20 um 08:16 schrieb Thayne: > On Tue, Jul 21, 2020 at 8:02 AM wrote: >>> * Reading the configuration format should not require linking to specific >>> implementation libraries >> >> This is "not invented here". >> > No, what library is used is an implementation detail,

Re: XDG Default Applications specification proposal

On Tue, Jul 21, 2020 at 8:02 AM wrote: > > * Reading the configuration format should not require linking to specific > > implementation libraries > > This is "not invented here". > No, what library is used is an implementation detail, and should not be part of the specification. From what I

Re: XDG Default Applications specification proposal

Dear XDG folks, On 20.07.20 at 13:00 s...@collabora.com wrote: > On Thu, 16 Jul 2020 at 22:40:43 -0600, Thayne wrote: >> and we should just put the >> terminal launching command in a standard place like an >> XDG_TERMINAL_LAUNCHER environment variable > > I would prefer not to be doing this via

Re: XDG Default Applications specification proposal

On Mon, Jul 20, 2020 at 12:33 PM Marc Boocha wrote: > > Only one think I must add is in the world of sandboxing and containers like > flatpak we need a method can be exposed. and really rather not xdg-open like > wrapper that end wrapping 20 programs with platform detection. > Show quoted text

Re: XDG Default Applications specification proposal

On Mon, Jul 20, 2020 at 10:24 AM Vladimir Kudrya wrote: > > I believe my previous proposal still holds here. > https://github.com/Vladimir-csp/xdg-terminal-exec > I'm fine with that proposal as well. ___ xdg mailing list xdg@lists.freedesktop.org

Re: XDG Default Applications specification proposal

Only one think I must add is in the world of sandboxing and containers like flatpak we need a method can be exposed. and really rather not xdg-open like wrapper that end wrapping 20 programs with platform detection. Show quoted text On Mon, 20 Jul 2020, 21:54 Vladimir Kudrya, wrote: > I believe

Re: XDG Default Applications specification proposal

I believe my previous proposal still holds here. https://github.com/Vladimir-csp/xdg-terminal-exec On 2020-07-20 14:00, s...@collabora.com wrote: * Must be user-configurable (overriding desktop and distro defaults) Check. * Must

Re: XDG Default Applications specification proposal

On Thu, 16 Jul 2020 at 22:40:43 -0600, Thayne wrote: > Perhaps trying to make > this more general is overcopmlicating it I suspect it might be. > and we should just put the > terminal launching command in a standard place like an > XDG_TERMINAL_LAUNCHER environment variable I would prefer not

Re: XDG Default Applications specification proposal

That doesn't really solve the problem of determining the application. And adds the additional problem that the application must support dbus, which many of these applications currently don't (especially yerminals). On Fri, Jul 17, 2020, 07:34 Marc Boocha wrote: > Well I think it should be

Re: XDG Default Applications specification proposal

On Friday, 17 July, 2020 9:51:32 AM IST Thayne wrote: > On Sat, Jul 11, 2020 at 3:28 AM Marc Boocha wrote: > > May be a dbus api? > > Already xdg utils has to wrap alot of programs. We really sort that one > > too. > What would such a dbus API look like? Well I think it should be portal but lets

Re: XDG Default Applications specification proposal

On Fri, Jul 10, 2020 at 10:44 AM Roman Chistokhodov wrote: > > I don't think there's a need in defining default applications if other > applications have no other way to interact with them other than just > launching. The opening a file/directory/uri in another app is already covered > by

Re: XDG Default Applications specification proposal

On Fri, Jul 10, 2020 at 12:33 PM Dasith Gunawardhana wrote: > > Hi, > > Windows recently introduced their "Hosted Apps" model. I think a similar > concept will work well for this problem. It would require an extension to the > Desktop Entry Specification and a new Default Apps Specification. >

Re: XDG Default Applications specification proposal

On Sat, Jul 11, 2020 at 3:28 AM Marc Boocha wrote: > > May be a dbus api? > Already xdg utils has to wrap alot of programs. We really sort that one too. > What would such a dbus API look like? Thayne McCombs ___ xdg mailing list

Re: XDG Default Applications specification proposal

Dear XDG list, Am 10.07.20 um 18:57 schrieb Emmanuele Bassi: > The whole discussion started off because GLib developers do not really > want to add a settings key for this; it's a bad option, for us, as it > falls apart when it comes to system and vendor overrides, and it plays > really badly in

Re: XDG Default Applications specification proposal

May be a dbus api? Already xdg utils has to wrap alot of programs. We really sort that one too. Regards, Marc Boocha ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg

Re: XDG Default Applications specification proposal

Hi, Windows recently introduced their "Hosted Apps" model. I think a similar concept will work well for this problem. It would require an extension to the Desktop Entry Specification and a new Default Apps Specification. If an application requires another application as an executor or runtime,

Re: XDG Default Applications specification proposal

On Fri, 10 Jul 2020 at 10:08, David Edmundson wrote: > > I don't like the idea of duplicating configuration for the options where > it's already solved with mimetypes. If we have two "sources of truth" for > the same thing, it can get complicated quickly. > > A terminal isn't a handler for any

Re: XDG Default Applications specification proposal

I don't think there's a need in defining default applications if other applications have no other way to interact with them other than just launching. The opening a file/directory/uri in another app is already covered by different spec. Launching a recorder/calendar/calculator does not make much

Re: XDG Default Applications specification proposal

Hi. Terminal is a bit of a special case with additional launch args and does not fit well into MIME handling. I already made a proposal with a demonstrator some time ago on this list. Started somewhere around this https://lists.freedesktop.org/archives/xdg/2017-May/013909.html and resulted

Re: XDG Default Applications specification proposal

Within KDE we have a GUI for choosing default web browser, file manager, email client and terminal emulator separately from mime types. 3 of those are done with URL handlers, but then we hit the same issue with terminal and end up with an effectively bespoke config entry. So I do think that's a

Re: XDG Default Applications specification proposal

Thayne wrote: > In particular, this specifies which terminal application should be > used to launch applications from desktop entries with Terminal=true. Indeed, there is a need to make this easier. I wrote this code the other day: ;; Returns the terminal emulator program for a given desktop

XDG Default Applications specification proposal

A few months ago I put together a draft specification for a standard mechanism for specifying default applications for things like terminal emulators, calculators, etc. that don't fit aren't necessarily opened with a file with a MIME type:

Re: improve PRIMARY buffer copy-paste behaviour, paste over

Dear XDG community, Am 01.07.20 um 23:56 schrieb Johannes Thrän: > guys, don't let this just die off. Nobody has to code anything now, no > paradigms shifted, no workflows broken. It breaks the workflow of XDG: to update documents only by the original author who has write access to the Git repo.

Re: improve PRIMARY buffer copy-paste behaviour, paste over

Hi, guys, don't let this just die off. Nobody has to code anything now, no paradigms shifted, no workflows broken. I'm just asking to reformulate a standard document a bit more specific in order to make something mediocre good. If the specifics I posted are too long or faulty, we can discuss how

Re: Redistribution of file URI specification

On Wed, Jul 1, 2020, at 08:35, Bastien Nocera wrote: > On Tue, 2020-06-30 at 20:01 +, Christian Dürr wrote: > > Hello, > > > > I'd like to redistribute the Freedesktop file-uri specification as > > part of the > > terminal working directory notification proposal > > ( > >

Re: Redistribution of file URI specification

On Tue, 2020-06-30 at 20:01 +, Christian Dürr wrote: > Hello, > > I'd like to redistribute the Freedesktop file-uri specification as > part of the > terminal working directory notification proposal > ( > https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/7 > ), > to

Redistribution of file URI specification

Hello, I'd like to redistribute the Freedesktop file-uri specification as part of the terminal working directory notification proposal (https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/7), to prevent link rot from potentially invalidating the reference to the official

Re: improve PRIMARY buffer copy-paste behaviour, paste over

Hi, On Tue, Mar 17, 2020 at 12:26 PM wrote: > > A reference implementation sounds like a good next step > I found the time to change one of the gtk3 widgets (gtkentry) to behave like I suggested earlier. The widget supports paste-over-selection maneuvers using the mouse alone. I didn't change

Re: RFC: Application icons/desktop files and their respective tools and specifications

On Sun, 14 Jun 2020 at 03:14:26 +0300, IFo Hancroft wrote: > 1. The Desktop Entry Specifications says the name of a .desktop file > should use be a valid D-Bus well-known name, and follow the reverse DNS > convention for the for the author and dot and then CamelCase. (Note that this is a

RFC: Application icons/desktop files and their respective tools and specifications

I have noticed a couple of things trying to fix a recently installed application's icon that wasn't working/showing up in my menu and this brought a couple of questions and points I'd like to hear your opinions on: 1. The Desktop Entry Specifications says the name of a .desktop file should use be

Re: A standard for file browser widgets

On 2020-06-10 9:03 p.m., jtoj...@gmail.com wrote: On Wed, 2020-06-10 at 21:00 -0300, Soni L. wrote: > There doesn't appear to be a spec for that. There is a technical specification: https://flatpak.github.io/xdg-desktop-portal/portal-docs.html But yeah, it is implementation driven. How

Re: A standard for file browser widgets

On Wed, 2020-06-10 at 21:00 -0300, Soni L. wrote: > There doesn't appear to be a spec for that. There is a technical specification: https://flatpak.github.io/xdg-desktop-portal/portal-docs.html But yeah, it is implementation driven. ___ xdg mailing

Re: A standard for file browser widgets

On 2020-06-10 8:58 p.m., jtoj...@gmail.com wrote: On Wed, 2020-06-10 at 20:16 -0300, Soni L. wrote: > I'd like to propose the following standard for file browser widgets: We already have xdg-desktop-portal, which allows applications to use the preferred file chooser of the desktop

Re: A standard for file browser widgets

On Wed, 2020-06-10 at 20:16 -0300, Soni L. wrote: > I'd like to propose the following standard for file browser widgets: We already have xdg-desktop-portal, which allows applications to use the preferred file chooser of the desktop environment. Most modern apps already support that, since it is a

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

To dictate how apps behave? Of course not. However, if the XDG specs are going to be fundamental to FOSS standardization, incompatibilities such as these with the major proprietary systems should certainly be documented and communicated. Many developers try to keep keymapping consistent across

A standard for file browser widgets

I'd like to propose the following standard for file browser widgets: --- # File Browser Widget Standard Users should be able to choose and customize file browser dialogs to fit their needs. Currently users have multiple file browser dialogs they need to customize, and some that they are

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

On Wed, Jun 10, 2020 at 12:29 PM Chanslor Rosenthal wrote: > There’s nothing a person can do, however, about the shift from “ctrl+<>” > to “super+<>” when you move to Mac > Most cross platform games still use ctrl on mac instead of altering shortcuts to super. Ditto many CLI tools. Ditto some

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

It is not FD.o's responsibility to dictate how apps behave on macOS. macOS is not an FD.o platform. If an app is attempting to target FD.o platforms and macOS, they obviously need to make changes dependent on the target platform—but that's outside of FD.o. On Mon, Jun 8, 2020 at 4:31 PM Nate

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

Yes, I suppose every application shortcut that uses Ctrl should replace it with Command when run on macOS. Back when I was a Mac guy, apps which didn't do this were very annoying. Seems like a reasonable thing to add to the spec. Nate On 6/8/20 4:23 PM, Sparr wrote: This spec does not just

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

This spec does not just apply to whole desktop environments. It claims to apply to applications as well. I am calling out applications that run both in FOSS desktop environments AND in other environments. GIMP is one such example. Until recently, GIMP used the same set of libraries to build for

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

I'm not sure it's relevant. This spec is for FOSS desktop environments. Typically you aren't going to be installing Plasma or GNOME on a Mac on top of macOS. You might wipe macOS and install a FOSS OS, in which case the spec fully applies with no issues. Nate On 6/8/20 4:11 PM, Sparr

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

I think it's worth calling out, although I suspect most of us are already aware, that in macOS most applications use the command/super key for shortcuts that would use ctrl in other OSes, while still also using ctrl and option/alt as application modifier keys as well. I do not expect

Re: Thumbnails: add HiDpi folders

On 6/5/20 11:24 PM, Méven wrote: Date: Mon, 1 Jun 2020 10:23:16 -0600 From: Nate Graham mailto:n...@kde.org>> To: xdg@lists.freedesktop.org Subject: Re: Thumbnails: add HiDpi folders Message-ID:

Re: Thumbnails: add HiDpi folders

> > Date: Mon, 1 Jun 2020 10:23:16 -0600 > From: Nate Graham > To: xdg@lists.freedesktop.org > Subject: Re: Thumbnails: add HiDpi folders > Message-ID: <7a961085-09bc-2079-6918-2acd70e21...@kde.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > I like the idea. How would fractional

Re: Thumbnails: add HiDpi folders

I like the idea. How would fractional scaling be handled though? If I'm using a 1.25x scale (as I am right now), would it generate an @2x thumbnail, store that, and scale it down for display? Or would it generate an @1.25x scale thumbnail? Nate On 5/26/20 12:45 AM, Méven wrote: Hello, I

Thumbnails: add HiDpi folders

Hello, I have been working on adding support for HiDpi thumbnails in KDE frameworks. [1] So I'd like to take the high road and update the specification [2] The crust of my specification update proposal is as follows : Thumbnails generated with high-dpi (usually using a scale factor of 2)

problem with avahi

Hello, I am using freedesktop that is included in openindiana distributions (OI-hipster2020.04). I have a problem when trying to print from pluma: nothing is printed and I get the following message     GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name     org.freedesktop.Avahi

Question about shared-mime-info spec

hello, I am maintaining a "freeplane" package for Debian, which has this MIME configuration (according to shared-mime-info-spec): This has "or" semantics (freeplane is invoked if a file is named *.mm OR contains the magic string), but the application

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

I've created a merge request: https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/27 On Sun, May 10, 2020 at 1:06 AM Noah Davis wrote: > > To get more specific: > I think this should be a pretty small and simple standard. > Applications should completely avoid using Meta/Super. >

<    1   2   3   4   5   6   7   8   9   10   >