#1493 closed enhancement (fixed)
Keep preferable activities
Reported by: | alsroot | Owned by: | tomeu |
---|---|---|---|
Priority: | Unspecified by Maintainer | Milestone: | |
Component: | Sugar | Version: | 0.86.x |
Severity: | Unspecified | Keywords: | r+ |
Cc: | Distribution/OS: | Unspecified | |
Bug Status: | Unconfirmed |
Description
How it could be:
for activity_id less Journal objects, sugar could store chosen "Resume with" activity and use it for later fast click activation
Attachments (1)
Change History (13)
Changed 14 years ago by alsroot
comment:1 follow-up: ↓ 2 Changed 13 years ago by tomeu
- Keywords r! added; r? removed
comment:2 in reply to: ↑ 1 ; follow-up: ↓ 5 Changed 13 years ago by alsroot
Replying to tomeu:
Patch looks great to me, I'm going to ask in the mailing lists for opinions about adding this feature.
Two comments:
- considered adding to profile.py instead of creating mimeregistry.py ?
in my mind we shouldn't expose such internals to activities, since its all about shell workflow
- need to update the sugar.schemas.in file
you mean add default preferences for popular mime_types?
feature itself doesn't rely on existence of valid predefined value in gconf
comment:3 Changed 13 years ago by garycmartin
Sorry, not totally clear on the end goal here. Having had a quick skim of the patch, is the idea that (where possible) downloaded objects, or objects added with copy-to-journal type process are assigned to an activity? e.g. so downloading a pdf with Browse would not just appear in Journal as a default document icon, but would show as a Read activity icon?
comment:4 follow-up: ↓ 6 Changed 13 years ago by wadeb
From looking at the patch, what happens is:
- You download the first PDF file and open it using a random activity, say SweetPDFReader.
- Further PDF files you download are then opened using SweetPDFReader by default.
- You right click on a PDF file you downloaded and open with Read.
- Further PDF files you download are then opened using Read by default.
Essentially, it tracks the most recent "Open With" choice for MIME objects - objects downloaded from Browse, copied from a USB key, or added using copy-to-journal - and makes that choice the default.
Without this patch, it seems like Sugar makes an arbitrary choice when choosing which activity to open a MIME (non-Activity instance) Journal object.
I for one like the addition of mimeregistry.py; it makes sense to me to collect all information regarding Sugar's handling of MIME objects (vs. Activity instance objects) in one place.
comment:5 in reply to: ↑ 2 ; follow-up: ↓ 7 Changed 13 years ago by tomeu
Replying to alsroot:
Replying to tomeu:
Patch looks great to me, I'm going to ask in the mailing lists for opinions about adding this feature.
Two comments:
- considered adding to profile.py instead of creating mimeregistry.py ?
in my mind we shouldn't expose such internals to activities, since its all about shell workflow
I agree with that, it's only that if we have lots of small python files it gets harder to find stuff in the shell. What about having a shellprofile.py module instead?
- need to update the sugar.schemas.in file
you mean add default preferences for popular mime_types?
feature itself doesn't rely on existence of valid predefined value in gconf
Hmm, I think the default should be taken from the gconf defaults and not be hardcoded, so a deployment can override it at will. It also helps to provide documentation about the options.
comment:6 in reply to: ↑ 4 Changed 13 years ago by garycmartin
Replying to wadeb:
From looking at the patch, what happens is:
- You download the first PDF file and open it using a random activity, say SweetPDFReader.
- Further PDF files you download are then opened using SweetPDFReader by default.
- You right click on a PDF file you downloaded and open with Read.
- Further PDF files you download are then opened using Read by default.
Essentially, it tracks the most recent "Open With" choice for MIME objects - objects downloaded from Browse, copied from a USB key, or added using copy-to-journal - and makes that choice the default.
Thanks Wade, yes that does seem a good default Sugar solution. It very nicely avoids several manual UI steps and interfaces that traditional desktops use to achieve a similar ability. i.e. on OS X you have to "get info" on the file; fold out an "open with" section; use a drop down menu (that can get very long and full of unexpected applications) to pick a default; then click the "change all" button to set for other files of this type.
comment:7 in reply to: ↑ 5 Changed 13 years ago by alsroot
Replying to tomeu:
Replying to alsroot:
Replying to tomeu:
Patch looks great to me, I'm going to ask in the mailing lists for opinions about adding this feature.
Two comments:
- considered adding to profile.py instead of creating mimeregistry.py ?
in my mind we shouldn't expose such internals to activities, since its all about shell workflow
I agree with that, it's only that if we have lots of small python files it gets harder to find stuff in the shell. What about having a shellprofile.py module instead?
so you meant not sugar-toolkit/profile.py, then it could be profile.py in sugar package to collect all info about user preferences.
- need to update the sugar.schemas.in file
you mean add default preferences for popular mime_types?
feature itself doesn't rely on existence of valid predefined value in gconf
Hmm, I think the default should be taken from the gconf defaults and not be hardcoded, so a deployment can override it at will. It also helps to provide documentation about the options.
Yup, but there is no hardcoded gconf setting, mimeregistry just creates new keys and tried to read existed, but yeah, we can have default keys for popular mime_types.
comment:8 Changed 13 years ago by erikos
- Keywords r? added; r! removed
comment:9 Changed 13 years ago by erikos
Let's revisit this one.
comment:10 Changed 13 years ago by tomeu
- Keywords r+ added; r? removed
comment:11 Changed 13 years ago by alsroot
- Resolution set to fixed
- Status changed from new to closed
Patch looks great to me, I'm going to ask in the mailing lists for opinions about adding this feature.
Two comments: