Git Product home page Git Product logo

mobileorg.next's People

Contributors

d12frosted avatar mgmart avatar swflint avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

snillocydoc

mobileorg.next's Issues

suggestion for todo states with swipe

hello.
i thought it would be cool to do this:
lets say we have a list item, that is TODO. then i can swipe to the right, and it will go to NEXT. then i can swipe again and it will go to DONE. swiping left will put it back to NEXT.

does that sound interesting? it would be even better if it can get the "next" state the same way org-mode gets the next state, either by the top file todo tags, or custom ways.

moving it here from MobileOrg/mobileorg#195

A common portable library?

Would you be open to designing a base library with something like https://wukix.com/mocl? And all the UI specific code can be done in native objective-c or java (if android support is ever a goal).

It would also open up opportunities for a web interface and more.

roadmap

do you have some stuff planned? maybe then we can help with the great rewrite.

Concept of inbox needs explanation

The concept of inbox which is introduced in refiling-widget needs some explanation.

I'm not sure where it comes from. Is it an Org file which is synched with the desktop? Or is it the location where new captures are stored?

How should inbox be managed during synching?

What's the best strategy to implement the git-transport

As it seems there will be no support for attachments, images or tree-sync in org-mobile.el. Therefore I think the approach should to use git as a transport and fiddle in org-mobile.el later (if it's still necessary).

The best strategy I can think of is that every write from MobileOrg comes be in a separate branch if head is different from the last fetch.

That and a default setting wether MobileOrg or the repository should win if there are conflicts should be sufficient to avoid conflict handling on the mobile device.

I'm not sure if this approach is too naive. I would appreciate any thoughts on this.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.