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.

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

Dynamic filters based on locations #373

Open
Ypot opened this issue Aug 2, 2018 · 5 comments
Open

Dynamic filters based on locations #373

Ypot opened this issue Aug 2, 2018 · 5 comments

Comments

@Ypot
Copy link

Ypot commented Aug 2, 2018

As we use different tags representing different location contexts where tasks must be done, it would be a superb feature if orgzly could use the mobile GPS to offer to the users the possibility to associate location related tags, with the real location determined by the GPS, and activate it on the filter.

Example: the user has a tag :@Home:
In settings, the user could associate the tag :@Home: with a GPS location or a GPS address.
In a filter it could be stablished that when GPS location coincides with the stablished location of :@Home:, the filter is modified showing the tasks within this context.
The filter could be automatically modified too when at work (:@work:), etc, showing a dynamic list of tasks.

@nevenz
Copy link
Member

nevenz commented Aug 10, 2018

So you'd define something like:

- Home
  - Location: 18.170857, -76.680804
  - Query: t.@home i.next

- Work
  - Location: 7795X5QW+FQJ
  - Query: t.@work i.project

And have saved search l.current o.priority which would become t.@home i.next o.priority at home and t.@work i.project o.priority at work.

@Ypot
Copy link
Author

Ypot commented Aug 11, 2018

Thanks nevenz. For me it's not easy to understand your thoughts fully and express myself correctly, due to my inexperience with github and the app. Shall I try though.

A doubt: would you have to set a different configuration for each query? For example, if I want to trigger a different filter "t.@work i.next o.priority" would it be in conflict with the already configured one, when you use l.current?

Work

  • Location: 7795X5QW+FQJ
  • Query: t.@work i.project

Work

  • Location: 7795X5QW+FQJ
  • Query: t.@work i.next

Maybe another option:
You define
tag @home -> Location: 18.170857, 2
tag @work -> Location: 8.170857, 25

Saved Search t.current i.whatever.

If you need same i.whatever for a different location, you just need to add a new location to the correspondent tag.
tag @library -> Location: 1.170857, 21

@nevenz
Copy link
Member

nevenz commented Aug 11, 2018

I think we're suggesting the same. It's just that my examples included more then a tag mapped to a location.

@debanjum
Copy link
Contributor

debanjum commented Oct 21, 2018

Does Orgzly support updating the Orgzly widget's search query using Android Intents ? Or even just opening Orgzly with search query passed in the intent. This would provide a broader, more generic solution that can deal with location updates from external applications (e.g Tasker, Termux etc) too.

Can open a separate issue if this is out of scope of this change ?

EDIT: Maybe #399 with it's support for orgzly search queries will partially solve this ? If @Ypot is fine with using an external application to handle gps to org-tag mapping and the triggering of the orgzly search query

@nevenz
Copy link
Member

nevenz commented Oct 22, 2018

Does Orgzly support updating the Orgzly widget's search query using Android Intents ? Or even just opening Orgzly with search query passed in the intent. This would provide a broader, more generic solution that can deal with location updates from external applications (e.g Tasker, Termux etc) too.

Support for intent to open search query could be added. I'm not so sure about how well would updating the widget's query work, as here are some Android restrictions.

Can open a separate issue if this is out of scope of this change ?

Yeah, I think that would be better, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants