AppChooser: misc design changes and cleanups #14
Conversation
|
|
||
| private AppButton selected; |
There was a problem hiding this comment.
Since clicking the app button will choice it. there's no need for this anymore.
| add_choice (choice); | ||
| public void update_choices (string[] app_ids) { | ||
| foreach (var app_id in app_ids) { | ||
| if (!(app_id in buttons) && app_id != sender_app_id) { |
There was a problem hiding this comment.
need to do this on the last_choice setter too. right now, i got code as the default choice for text files when testing it from code.
| button.clicked.connect (() => { | ||
| chosen (button.app_id); | ||
| }); |
There was a problem hiding this comment.
This can be in one line, like the one for the cancel button.
| button.clicked.connect (() => { | |
| chosen (button.app_id); | |
| }); | |
| button.clicked.connect (() => chosen (button.app_id)); |
| grid.attach (switcher, 0, 3, 2); | ||
| grid.attach (cancel, 1, 4); |
There was a problem hiding this comment.
without the ButtonBox, the button is really small. i wonder if we can put the switcher in the ButtonBox and have both on the same row.
|
I think I actually want to reconsider this completely because I'm a bit confused about how we're deciding what to launch and when. It looks like from the portal spec that OpenURI and AppChooser are two pretty different workflows. OpenURI seems unidirectional, as in an app is requesting to open a thing in another app, whereas AppChooser is redirecting app data back into the app to be used in some way. So it seems like these should be two separate interfaces. I'm a bit confused about why AppChooser is being called at all when OpenURI portal is being invoked in, for example, your code flatpak branch It seems like if we're doing a unidirectional workflow this would be more like a share sheet design where we're offering apps, actions, and maybe even contacts to carry out This is a totally different design from GtkAppChooser for example where we're selecting app information to hand back to an application |
The AppChooser is the backend for the OpenURI portal, it's the one providing the information that we use and the one with the application interacts, any information that we return is to the OpenURI portal and not to the application. The OpenURI portal calls the AppChooser if:
It's unidirectional for the application, but not for the OpenURI portal, it's stores the selected choice and if a application is chosen more than three times, is set as the default for that caller. and we probably don't want a one time action or contract as the default handle. So, basically, we don't define when the dialog is shown or what's the chooses in the dialog. we only provide it to for when the frontend needs it. |
|
@Marukesu okay, I see. In that case, it sounds like this should be more like the GtkAppChooser design with the listbox and possibly a link to AppCenter etc and not a fast/share sheet style design. And we probably want a different sharing portal of some kind for Code and not to use this API OR have a separate share sheet design when ASK is passed and hand back |
There's a proposal for a Share portal, but no implementation for it right now.
We can't known when ASK is passed too, so we can't have diferent dialogs in that case. |
|
Okay cool then that definitely influenced the direction I'd like to go here a lot! And I think that cements for me that this isn't the right portal for that Code branch. Maybe we should work on a sharing portal implementation :) |
Since we're still kind of prototyping, I just jammed a bunch of shit in here. I can break it up if requested: