Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add a sharing portal #12

Open
matthiasclasen opened this issue Jun 22, 2016 · 38 comments
Open

Add a sharing portal #12

matthiasclasen opened this issue Jun 22, 2016 · 38 comments
Labels
enhancement help wanted new portals This requires creating a new portal interface

Comments

@matthiasclasen
Copy link
Contributor

The idea for the sharing portal is that applications can describe support for this in their desktop file:

Implements: org.freedesktop.Share
...

[org.freedesktop.Share]
Types: images, text,... (mimetypes)
@matthiasclasen matthiasclasen added the new portals This requires creating a new portal interface label Oct 9, 2018
@andyholmes andyholmes mentioned this issue Oct 3, 2019
Closed
@sowelipililimute
Copy link

A simple idea for a potential d-bus API (interface: org.freedesktop.Sharing)

methods:

  • ShareFiles
    • "file", ah, in: an array of file descriptors
  • ShareLinks
    • "link", as, in: an array of links

I don't know any use cases where an application would want to know the result of sharing, so I didn't bother including them.

As far as actually implementing it, I'd say it should probably be up to the backend to do whatever it wants to do with the files/links being shared. KDE's portal could call Purpose, and GNOME's portal could use whatever infrastructure GNOME has for sharing, if any.

@mardy
Copy link
Contributor

mardy commented Dec 14, 2019

I don't know if it matters, but in Ubuntu for phones we had two actions for sharing: one was actually sharing, the other was exporting. I don't think it made a difference in how the content was handled, but from the UI point of view they were different actions; and each application could register itself as a receiver/handler for either action (or both).

  • share: ultimately share with people (upload, send a link by SMS, etc.)
  • export: send to another application for storage or further processing

@TingPing TingPing mentioned this issue Feb 4, 2020
Closed
@Marukesu Marukesu mentioned this issue Oct 20, 2021
Closed
@jadahl jadahl mentioned this issue Oct 27, 2021
Closed
@Marukesu Marukesu mentioned this issue Jun 18, 2022
Open
@swick
Copy link
Contributor

swick commented Dec 16, 2022

Looks like Web Share will be a thing and something we probably should try to be compatible with.

https://www.w3.org/TR/2022/PR-web-share-20221215/

@rredford rredford mentioned this issue Dec 18, 2022
Closed
@imhemish
Copy link

Something similar: #937

@imhemish imhemish mentioned this issue Dec 30, 2022
Closed
@CutestNekoAqua
Copy link

I think this is really useful and really important to have. Its super useful and on android it makes it SUPER easy for developers to add application interoperability.

@SaphiraKai
Copy link

Agreed, being able to send files and data between applications without breaching any sandboxes is almost necessary, in my opinion.

@9thyear2
Copy link

9thyear2 commented Jan 6, 2023

I'd like to see something like this implemented

@andyholmes
Copy link
Contributor

Let's all avoid the "me too" comments and just hit the 👍, otherwise everyone subscribed will keep getting e-mails.

@CutestNekoAqua
Copy link

I think what we need is a maintainer telling us what is needed for this to get work on :)
Am happy to help

@jadahl
Copy link
Collaborator

jadahl commented Jan 17, 2023

I don't think any maintainer has a clear idea of how a "share" portal would work exactly, so a way to help is to gather information about how other platforms (Android, iOS, Web Share API for example) does this, try to summarize, and then see how we can learn from that and if suitable see how it can be done with the building blocks we rely on (.desktop files, portal D-Bus APIs, etc).

It'd also be useful to gather information about potential existing applications that could make use of this portal, both in a "shared to" manner and "sharing" manner, or both.

The description of the issue have some very rough idea of how it could work (e.g. how to let an application advertise what it can be shared), but it's only a very bare boned starting point of an idea.

@MikelJohnson
Copy link

Hi!
I've been thinking about this for a while and for the last four days I've been working on a small POC prototype.
It's rough around edges, but I think it's a good starting point if nothing else
Here's the repo MikelJohnson/share-portal-poc.
I go into a pretty detailed explanation of implementation here

I've also recorded a demo of the sharing process and a demo of an app dynamically adding contacts to the share sheet

I hope this will give some inspiration on how the final api might look like.

@Mikenux
Copy link

Mikenux commented Mar 24, 2023

We may want to differentiate social apps from viewing and editing apps, in order to have clean user interfaces.

@andyholmes
Copy link
Contributor

We may want to differentiate social apps from viewing and editing apps, in order to have clean user interfaces.

I think that's a good point, but this should be doable from the implementation side with .desktop entry categories?

Something related worth considering is dynamic items, like contacts or bluetooth devices that could have offline/online state. Is that something a portal needs to negotiate, or maybe that's irrelevant to the application anyways?

@Mikenux
Copy link

Mikenux commented Mar 25, 2023

I think that's a good point, but this should be doable from the implementation side with .desktop entry categories?

It's a good question. It is certainly the easiest way, if it is assumed that few developers would lie about it. The complex way is to have clues like the app uses a specification to give its contact list, "chat notifications", etc.

Also, I forgot to add the "subtypes" of social sharing: chat (contacts), post (on social media), and upload (uploading a file to a file-sharing web service).

For other things, I don't know. The only thing I can say is that the contacts are not so dynamic (i.e. as if presented in a UI only if they are online).

@orowith2os
Copy link

I ended up bringing this up again, here's what I had (from scratch):

  • preferred app categories for what to share with
  • the content itself with mimetypes wrapped around it
  • preferred appid(s) to share with

And some additions to desktop files:

  • ways for an app to say it can take in shared data, and describe how
  • mimetypes the app supports
  • what the app will do with that information (very short - see GitHub mobile's share name when going to share anything to it for reference)

@jadahl
Copy link
Collaborator

jadahl commented Sep 11, 2023

I ended up bringing this up again, here's what I had (from scratch):

I suggest reading through the precious discussions, and doing the expected research, instead of inventing things from scratch.

preferred app categories for what to share with

Use case for this? Why shouldn't the user be allowed to be in more direct control of what they tend to prefer to share things with?

the content itself with mimetypes wrapped around it

Probably want fd passing for the content.

preferred appid(s) to share with

Apps are isolated by default. What apps will have app IDs to list, and why would they want this?

@orowith2os
Copy link

I suggest reading through the precious discussions, and doing the expected research, instead of inventing things from scratch.

Inventing it from scratch isn't the goal - laying out how it might work is. And then comparing with the current work to see if it helps any. I also didn't care to try and find this issue when initially doing so. From now on, I'll be taking the entire thing into context.

Use case for this? Why shouldn't the user be allowed to be in more direct control of what they tend to prefer to share things with?

Hence the word "preferred" - for example, Krita might want to share its images first and foremost with an image viewer application, and so could signal that with the preferred categories. Any applications supporting the mimetype would show in the resulting menu, with apps fitting into the specified categories being put at a higher priority if implemented as such in the portal backend.

Probably want fd passing for the content.

We can probably take from how the Wayland protocol works here too with drag-n-drop.

Apps are isolated by default. What apps will have app IDs to list, and why would they want this?

Applications within an ecosystem might want to put a higher priority on applications in their ecosystem to share with - for example, Inochi Creator (Inochi2D) might want to put Inochi Session as the first and foremost application to share its exported files with. And then other applications supporting the .inx and .inp file formats can show below that.

This would be useful for tighter ecosystem integration in e.g. GNOME and KDE.

@Mikenux
Copy link

Mikenux commented Sep 13, 2023

Hence the word "preferred" - for example, Krita might want to share its images first and foremost with an image viewer application, and so could signal that with the preferred categories.

In my opinion, it's up to users to choose what they want to do, not the app itself. This also means defining which categories can be used and how to handle the possible addition of new categories. If categories are to be used, starting, for example, with "Open with" and "Social" and the app can only choose one, that's a start and makes sense in relation to what we see in the app ecosystem and users might want. There can be more categories, but putting some constraints on their use (so that an app does not use too many categories to appear everywhere), and only for user experience reasons (and not for the will of app developers) seems to me the way to go.

@razzeee
Copy link
Contributor

razzeee commented Sep 13, 2023

The appstream categories / subcategories might be a bit problematic for this. In general, they seem very old and in a need of an update.

https://specifications.freedesktop.org/menu-spec/latest/apa.html

@orowith2os
Copy link

In my opinion, it's up to users to choose what they want to do, not the app itself.

This would not infringe that freedom.

@Mikenux
Copy link

Mikenux commented Sep 13, 2023

@orowith2os:

Yes, that wouldn't infringe it. However, by presenting apps of a specific category before others, you are somehow suggesting that there is a high probability that users will need these apps before the others. You will reflect this even more if more than one category is used. Also, in the UI, I think one will certainly expect a "Recently Used" section to be displayed first. If categories are to be added, even if they are optional, I would see them more as filters to find specific apps rather than a "main" element in a user experience.

Personally, I would remove anything that looks like promotion or self-promotion, which is more the scope of the app stores. However, I understand self-promotion of apps better if they are part of a suite from the same developers, like LibreOffice and Inochi2D. Knowing whether it is something that should be displayed in a user interface with other apps or as an entry in the app user interface (e.g. an "Open in Inochi Session" entry in a menu), that's another question.

@orowith2os
Copy link

@Mikenux I feel like you're trying to complicate this far more than it needs to be.

@Mikenux
Copy link

Mikenux commented Sep 13, 2023

What am I trying to complicate? I'm just giving my opinion to make you understand that this part is not convincing (even if we forget my comment on the promotion). It's up to you to be more convincing and better explain the interest in light of the comments on this part of your initial proposal.

@Mikenux
Copy link

Mikenux commented Sep 15, 2023

Just for convenience, does it seem reasonable to only discuss file sharing ("open with" and social) here and discuss links in another issue?

Also, the issue elementary/portals#49 mentioned here made me think about selecting an app to add a task, event or reminder from a link or a text selection such as, for example, a date or an event. Is this something to discuss as a global topic in another issue, in this issue, or based on what is being shared (i.e. a file, a link, a text selection)?

@orowith2os
Copy link

Just for convenience, does it seem reasonable to only discuss file sharing ("open with" and social) here and discuss links in another issue?

Both would be in scope of the Sharing portal, we should discuss how to go about it here.

Not sure how much overlap there would be with the OpenURI portal.

@Mikenux
Copy link

Mikenux commented Sep 16, 2023

Ok. For the OpenURI portal, as I understand it, it's also about selecting a default application (e.g. always open web links in preferred web browser), and we don't want that option here.

I would still like to know why it would be interesting that an app has the possibility to display certain categories of applications at the top of the list. I'll see this anchored more in a specific rather than general user experience (i.e. where we show all relevant apps relative to a file type or extension, or (web) link).

@MikelJohnson
Copy link

MikelJohnson commented Sep 16, 2023 via email

@orowith2os
Copy link

The categories and appids are just hints to the portal for what to show the data with first - the portal is not forced to follow them.

The intention is for e.g. a GNOME app to put a higher priority on sharing, say, an upscaled image with an app in the GNOME ecosystem, and a KDE app to do the same. Or, for some niche cases (like Inochi2D) a higher priority is put on a specific app, as not much else is likely to use its file types or anything.

The user is ultimately the one who chooses what gets what. If the portal wouldn't like this, it can just not follow it, and share with whatever.

@Mikenux
Copy link

Mikenux commented Sep 18, 2023

@MikelJohnson: I took a look at your proposal months ago, but indeed never gave any feedback on it. So here is, but this concerns everyone.

App Actions. The problem with actions is that apps can define as many as they want. Also, when I see screenshots of Android and Apple systems, as well as actions on my iPad (iOS 12, so old), I never saw many actions for apps. Also, certain actions sometimes seem implicit to me. Examples: If I know that an app is a video editor, then I don't need an "Edit Video" action; If I know that a music player with a music library supports playlists, I probably don't need the "Play" or "Add to Playlist" actions, as they can be handled app side; If I have a Note app with notebooks, actions like "Create New Note" and "Add to Notebook" can be done on the app side. We might prefer to explore this and see if we can standardize relevant actions. I noted that in case of events, tasks and reminders, one can have different actions like "Create" and "Attach to" (to open a file in case of an event or task) which seems useful, or simply "Event", "Task", "Reminder" (not really actions, but perhaps more meaningful; they can also be linked to default apps for example). (@orowith2os: Are the categories you're thinking of also like actions, like you mentioned "image viewer" - so a view action?)

Contacts. A contact portal may be preferred if we want to merge contacts (in a UI: select contact > select service [including email] to send with). This can also allow you to list contacts from the same service in order to send to several contacts.

However, I think we really need to know what desktop environment developers want:

  • An Activity sheet? Includes devices, “open with” (view/edit), contacts, social apps, general actions (e.g. copy or paste to [app], save to [remote storage app], event, task, reminder), perhaps also the internal actions of the app.
  • An “Open with” sheet and a Share sheet (i.e. social: devices, contacts, social apps) with possibly some general actions?
  • A user interface that shows as many items as possible to the user?
  • Should the UI have all items directly visible? (vs. a scrolling view)

That's all I can say.

@orowith2os:

The intention is for e.g. a GNOME app to put a higher priority on sharing, say, an upscaled image with an app in the GNOME ecosystem, and a KDE app to do the same.

It's good to think about integration with the ecosystem of desktop environments, but don't forget that it's also something that apps not part of such an ecosystem could use (if you only think about applications developed "by" GNOME or KDE).

Or, for some niche cases (like Inochi2D) a higher priority is put on a specific app, as not much else is likely to use its file types or anything.

Pay attention to what you write. Reading "niche cases" and "as not much else is likely to use its file types or anything", then I might ask you "So why include this since this app will be clearly visible?". You're not selling your idea very well here.

@orowith2os
Copy link

(@orowith2os: Are the categories you're thinking of also like actions, like you mentioned "image viewer" - so a view action?)

The categories I'm thinking of are like the ones in desktop files, saying what categories an application falls into. Actions are a different problem, and I would like to see them available (preferably specified in the desktop file of the applications) too.

No, I will not be budging on specifying app categories in the portal.

Pay attention to what you write. Reading "niche cases" and "as not much else is likely to use its file types or anything", then I might ask you "So why include this since this app will be clearly visible?". You're not selling your idea very well here.

This is just one use case. I'm sure you can find others. We shouldn't be decreasing usability for these apps when they're also usable for other, more widely known, apps, and when you mix in some globs (e.g. org.gnome.*). If some globs just aren't useful for one desktop's vision, it can just ignore them. Again, preferences. Not rules. Preferences.

On a side note, someone working on Calls apps for the relevant ecosystems (KDE, GNOME) should also be brought in for discussion on the Contacts portal, and we can split that into its own issue.

@Mikenux
Copy link

Mikenux commented Sep 18, 2023

@orowith2os:

Ok. We'll see what DE developers think of your idea.

Pay attention to what you write. Reading "niche cases" and "as not much else is likely to use its file types or anything", then I might ask you "So why include this since this app will be clearly visible?". You're not selling your idea very well here.

This is just one use case. I'm sure you can find others. We shouldn't be decreasing usability for these apps when they're also usable for other, more widely known, apps, and when you mix in some globs (e.g. org.gnome.*). If some globs just aren't useful for one desktop's vision, it can just ignore them. Again, preferences. Not rules. Preferences.

This was an advice 😉

@Mikenux
Copy link

Mikenux commented Sep 18, 2023

On a side note, someone working on Calls apps for the relevant ecosystems (KDE, GNOME) should also be brought in for discussion on the Contacts portal, and we can split that into its own issue.

#15

@Mikenux
Copy link

Mikenux commented Sep 18, 2023

Some links in GNOME:

@GeorgesStavracas GeorgesStavracas moved this to Needs Triage in Triage Oct 2, 2023
@Mikenux
Copy link

Mikenux commented Oct 19, 2023 •
edited
Loading

For information, I found at least one case that could belong to the “Open With” and “Share With” (i.e. share with people) categories: personal information management apps. These apps include contact management and calendar, which can open contact card and calendar files. Opening these files belongs to "Open With" when we add a contact or calendar, and to "Share With" when we share a card or calendar, or when we want to send files with an e-mail.

I don't know if there are other exceptions, but if anyone is interested, other hints are needed for such apps, since apps should ideally not belong to both categories.

agx pushed a commit to agx/xdg-desktop-portal that referenced this issue Dec 20, 2023
@alexlarsson
Merge pull request flatpak#12 from matthiasclasen/filechooser-combo
3b5a1ea 
Implement filechooser combobox support
whot added a commit to whot/xdg-desktop-portal that referenced this issue Feb 8, 2024
@whot
meson.build: force /usr/share to be in the XDG_DATA_DIRS for tests
c59957b 
g_proxy_resolver_get_default() via g_proxy_resolver_gnome_init() fails
hard if the XDG_DATA_DIR isn't set because the GSettings cannot be found:

In particular this statement fails:
   resolver->proxy_settings = g_settings_new (GNOME_PROXY_SETTINGS_SCHEMA);

  (gdb) bt
  #0  0x00007ffff7eb9bef in g_log_structured_array () at /lib64/libglib-2.0.so.0
  flatpak#1  0x00007ffff7eb9edc in g_log_default_handler () at /lib64/libglib-2.0.so.0
  flatpak#2  0x00007ffff7eba180 in g_logv () at /lib64/libglib-2.0.so.0
  flatpak#3  0x00007ffff7eba463 in g_log () at /lib64/libglib-2.0.so.0
  flatpak#4  0x00007ffff7d7b952 in g_settings_set_property () at /lib64/libgio-2.0.so.0
  flatpak#5  0x00007ffff7c4775a in object_set_property () at /lib64/libgobject-2.0.so.0
  flatpak#6  0x00007ffff7c48068 in g_object_new_internal.part () at /lib64/libgobject-2.0.so.0
  flatpak#7  0x00007ffff7c4a1a3 in g_object_new_valist () at /lib64/libgobject-2.0.so.0
  flatpak#8  0x00007ffff7c4a55f in g_object_new () at /lib64/libgobject-2.0.so.0
  flatpak#9  0x00007ffff7fb4ac4 in g_proxy_resolver_gnome_init () at /usr/lib64/gio/modules/libgiognomeproxy.so
  flatpak#10 0x00007ffff7c625ea in g_type_create_instance () at /lib64/libgobject-2.0.so.0
  flatpak#11 0x00007ffff7c47fb4 in g_object_new_internal.part () at /lib64/libgobject-2.0.so.0
  flatpak#12 0x00007ffff7c495d6 in g_object_new_with_properties () at /lib64/libgobject-2.0.so.0
  flatpak#13 0x00007ffff7c4a581 in g_object_new () at /lib64/libgobject-2.0.so.0
  flatpak#14 0x00007ffff7d03c6c in try_implementation () at /lib64/libgio-2.0.so.0
  flatpak#15 0x00007ffff7d09e8e in _g_io_module_get_default () at /lib64/libgio-2.0.so.0
  flatpak#16 0x00007ffff7d18d2a in g_proxy_resolver_get_default () at /lib64/libgio-2.0.so.0
  flatpak#17 0x00000000004d4083 in proxy_resolver_init (resolver=0x5a6cc0) at ../src/proxy-resolver.c:99

This causes xdp to abort, it never claims the bus and our tests time
out.
whot added a commit to whot/xdg-desktop-portal that referenced this issue Feb 8, 2024
@whot
meson.build: force /usr/share to be in the XDG_DATA_DIRS for tests
1bddb01 
g_proxy_resolver_get_default() via g_proxy_resolver_gnome_init() fails
hard if the XDG_DATA_DIR isn't set because the GSettings cannot be found:

In particular this statement fails:
   resolver->proxy_settings = g_settings_new (GNOME_PROXY_SETTINGS_SCHEMA);

  (gdb) bt
  #0  0x00007ffff7eb9bef in g_log_structured_array () at /lib64/libglib-2.0.so.0
  flatpak#1  0x00007ffff7eb9edc in g_log_default_handler () at /lib64/libglib-2.0.so.0
  flatpak#2  0x00007ffff7eba180 in g_logv () at /lib64/libglib-2.0.so.0
  flatpak#3  0x00007ffff7eba463 in g_log () at /lib64/libglib-2.0.so.0
  flatpak#4  0x00007ffff7d7b952 in g_settings_set_property () at /lib64/libgio-2.0.so.0
  flatpak#5  0x00007ffff7c4775a in object_set_property () at /lib64/libgobject-2.0.so.0
  flatpak#6  0x00007ffff7c48068 in g_object_new_internal.part () at /lib64/libgobject-2.0.so.0
  flatpak#7  0x00007ffff7c4a1a3 in g_object_new_valist () at /lib64/libgobject-2.0.so.0
  flatpak#8  0x00007ffff7c4a55f in g_object_new () at /lib64/libgobject-2.0.so.0
  flatpak#9  0x00007ffff7fb4ac4 in g_proxy_resolver_gnome_init () at /usr/lib64/gio/modules/libgiognomeproxy.so
  flatpak#10 0x00007ffff7c625ea in g_type_create_instance () at /lib64/libgobject-2.0.so.0
  flatpak#11 0x00007ffff7c47fb4 in g_object_new_internal.part () at /lib64/libgobject-2.0.so.0
  flatpak#12 0x00007ffff7c495d6 in g_object_new_with_properties () at /lib64/libgobject-2.0.so.0
  flatpak#13 0x00007ffff7c4a581 in g_object_new () at /lib64/libgobject-2.0.so.0
  flatpak#14 0x00007ffff7d03c6c in try_implementation () at /lib64/libgio-2.0.so.0
  flatpak#15 0x00007ffff7d09e8e in _g_io_module_get_default () at /lib64/libgio-2.0.so.0
  flatpak#16 0x00007ffff7d18d2a in g_proxy_resolver_get_default () at /lib64/libgio-2.0.so.0
  flatpak#17 0x00000000004d4083 in proxy_resolver_init (resolver=0x5a6cc0) at ../src/proxy-resolver.c:99

This causes xdp to abort, it never claims the bus and our tests time
out.
whot added a commit to whot/xdg-desktop-portal that referenced this issue Feb 8, 2024
@whot
meson.build: force /usr/share to be in the XDG_DATA_DIRS for tests
82e5176 
g_proxy_resolver_get_default() via g_proxy_resolver_gnome_init() fails
hard if the XDG_DATA_DIR isn't set because the GSettings cannot be found:

In particular this statement fails:
   resolver->proxy_settings = g_settings_new (GNOME_PROXY_SETTINGS_SCHEMA);

  (gdb) bt
  #0  0x00007ffff7eb9bef in g_log_structured_array () at /lib64/libglib-2.0.so.0
  flatpak#1  0x00007ffff7eb9edc in g_log_default_handler () at /lib64/libglib-2.0.so.0
  flatpak#2  0x00007ffff7eba180 in g_logv () at /lib64/libglib-2.0.so.0
  flatpak#3  0x00007ffff7eba463 in g_log () at /lib64/libglib-2.0.so.0
  flatpak#4  0x00007ffff7d7b952 in g_settings_set_property () at /lib64/libgio-2.0.so.0
  flatpak#5  0x00007ffff7c4775a in object_set_property () at /lib64/libgobject-2.0.so.0
  flatpak#6  0x00007ffff7c48068 in g_object_new_internal.part () at /lib64/libgobject-2.0.so.0
  flatpak#7  0x00007ffff7c4a1a3 in g_object_new_valist () at /lib64/libgobject-2.0.so.0
  flatpak#8  0x00007ffff7c4a55f in g_object_new () at /lib64/libgobject-2.0.so.0
  flatpak#9  0x00007ffff7fb4ac4 in g_proxy_resolver_gnome_init () at /usr/lib64/gio/modules/libgiognomeproxy.so
  flatpak#10 0x00007ffff7c625ea in g_type_create_instance () at /lib64/libgobject-2.0.so.0
  flatpak#11 0x00007ffff7c47fb4 in g_object_new_internal.part () at /lib64/libgobject-2.0.so.0
  flatpak#12 0x00007ffff7c495d6 in g_object_new_with_properties () at /lib64/libgobject-2.0.so.0
  flatpak#13 0x00007ffff7c4a581 in g_object_new () at /lib64/libgobject-2.0.so.0
  flatpak#14 0x00007ffff7d03c6c in try_implementation () at /lib64/libgio-2.0.so.0
  flatpak#15 0x00007ffff7d09e8e in _g_io_module_get_default () at /lib64/libgio-2.0.so.0
  flatpak#16 0x00007ffff7d18d2a in g_proxy_resolver_get_default () at /lib64/libgio-2.0.so.0
  flatpak#17 0x00000000004d4083 in proxy_resolver_init (resolver=0x5a6cc0) at ../src/proxy-resolver.c:99

This causes xdp to abort, it never claims the bus and our tests time
out.
@Mikenux
Copy link

Mikenux commented Mar 14, 2024

@orowith2os

Regarding the categories, those of the menu specification concern the menu, whereas here it concerns the opening of a file. For example, audio and video categories are not needed when requesting to open an audio or video file with another app. So it makes no sense to have them all for the portal. Additionally, having them in the portal provides control over what can be added if xdg-desktop-portal developers/maintainers don't have much influence on certain specifications. Finally, I think it is important to make support of these categories mandatory for DEs, because the "Open With" experience is also part of an app UX; this way, app developers can be sure that this experience is available on all DEs.

@razzeee
Copy link
Contributor

razzeee commented Mar 14, 2024

Using the categories at all is a bad idea.

@CutestNekoAqua
Copy link

Using the categories at all is a bad idea.

How so? Thats just a statement w/o reason, except if someone alr stated it above and I was just too lazy to read, which is very likely

@razzeee
Copy link
Contributor

razzeee commented Mar 14, 2024

Desktop categories have aged very poorly. The spec is 20 years old and has only been updated in ways not involving categories lately (last category facing changes were in 2012) as far as I can tell.

There also doesn't seem to be someone actively maintaining them.

Looking at, also will raise some questions, as some of these aged poorly - for e.g. app stores rarely use the Network category for browsers, but rename it.
https://specifications.freedesktop.org/menu-spec/latest/apa.html#main-category-registry
https://specifications.freedesktop.org/menu-spec/latest/apas02.html

https://gitlab.freedesktop.org/xdg/xdg-specs/-/tree/master/menu?ref_type=heads

@Paulo-B Paulo-B mentioned this issue Apr 7, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement help wanted new portals This requires creating a new portal interface
Projects
Triage
Status: Needs Triage
Milestone
No milestone
Development

No branches or pull requests