Some thoughts on MobileOrg and its development ....

Some thoughts on MobileOrg and its development ....

[Alexis]

Hi all,

In light of recent discussions about 'MobileOrg' - which seemingly
actually constitutes two distinct projects for two different platforms -
together with the apparent relative lack of activity of both projects,
despite demand for them, i can't help but wonder if the 'MobileOrg'
endeavour needs a reboot.

More specifically, it seems to me that rebuilding MobileOrg as a single
project on top of Apache Cordova:

https://cordova.apache.org/

might be a way forward, for several reasons:

* It would help ensure that basically the same set of functionality is
  available across platforms, modulo specific limitations/issues with
  specific platforms. And when people add or modify core functionality,
  that functionality would more easily become available to people across
  platforms, rather than the functionality being initially implemented
  on platform X, and people on platform Y having to wait for it to be
  implemented in its entirety.

* Overall, only one lot of end-user documentation would need to be
  maintained.

* It would enable MobileOrg to be made available for mobile platforms
  other than Android and iOS, such as Windows Phone and Blackberry.

* The number of people available to assist with development might well
  be greater, due to the core development environment involving HTML,
  CSS and JavaScript. Barriers to entry for both regular and occasional
  committers would be much lower.

i'm aware that Cordova has various limitations,
including-but-not-limited-to the lack of native 'feel' of Cordova-based
applications. However, i feel that the above advantages, combined with
the my notion that Emacs users are probably less concerned with a
perfectly slick UI than with having access to functionality they
need/want, probably outweighs such limitations.

Unfortunately, due to other existing commitments, i wouldn't be able to
take point on such a reboot. But i'd definitely be willing and able to
help out!  Particularly in the area of contact management and syncing,
of course. :-)

Thoughts/comments/criticisms?


Alexis.

Re: Some thoughts on MobileOrg and its development ....

[Xebar Saram]

[-- Attachment #1: Type: text/plain, Size: 2402 bytes --]

Would love to see a reboot and further development on org-mobile. I am not
a developer myself but would love to help out with testing , writing
documentation etc

best

Z


On Sat, Aug 9, 2014 at 3:56 AM, Alexis <flexibeast@gmail.com> wrote:

>
> Hi all,
>
> In light of recent discussions about 'MobileOrg' - which seemingly
> actually constitutes two distinct projects for two different platforms -
> together with the apparent relative lack of activity of both projects,
> despite demand for them, i can't help but wonder if the 'MobileOrg'
> endeavour needs a reboot.
>
> More specifically, it seems to me that rebuilding MobileOrg as a single
> project on top of Apache Cordova:
>
> https://cordova.apache.org/
>
> might be a way forward, for several reasons:
>
> * It would help ensure that basically the same set of functionality is
>   available across platforms, modulo specific limitations/issues with
>   specific platforms. And when people add or modify core functionality,
>   that functionality would more easily become available to people across
>   platforms, rather than the functionality being initially implemented
>   on platform X, and people on platform Y having to wait for it to be
>   implemented in its entirety.
>
> * Overall, only one lot of end-user documentation would need to be
>   maintained.
>
> * It would enable MobileOrg to be made available for mobile platforms
>   other than Android and iOS, such as Windows Phone and Blackberry.
>
> * The number of people available to assist with development might well
>   be greater, due to the core development environment involving HTML,
>   CSS and JavaScript. Barriers to entry for both regular and occasional
>   committers would be much lower.
>
> i'm aware that Cordova has various limitations,
> including-but-not-limited-to the lack of native 'feel' of Cordova-based
> applications. However, i feel that the above advantages, combined with
> the my notion that Emacs users are probably less concerned with a
> perfectly slick UI than with having access to functionality they
> need/want, probably outweighs such limitations.
>
> Unfortunately, due to other existing commitments, i wouldn't be able to
> take point on such a reboot. But i'd definitely be willing and able to
> help out!  Particularly in the area of contact management and syncing,
> of course. :-)
>
> Thoughts/comments/criticisms?
>
>
> Alexis.
>
>

[-- Attachment #2: Type: text/html, Size: 3088 bytes --]

Re: Some thoughts on MobileOrg and its development ....

[David Masterson]

Alexis <flexibeast@gmail.com> writes:

> Hi all,
>
> In light of recent discussions about 'MobileOrg' - which seemingly
> actually constitutes two distinct projects for two different platforms -
> together with the apparent relative lack of activity of both projects,
> despite demand for them, i can't help but wonder if the 'MobileOrg'
> endeavour needs a reboot.
>
> More specifically, it seems to me that rebuilding MobileOrg as a single
> project on top of Apache Cordova:
>
> https://cordova.apache.org/
>
> might be a way forward, for several reasons:
>
> * It would help ensure that basically the same set of functionality is
>   available across platforms, modulo specific limitations/issues with
>   specific platforms. And when people add or modify core functionality,
>   that functionality would more easily become available to people across
>   platforms, rather than the functionality being initially implemented
>   on platform X, and people on platform Y having to wait for it to be
>   implemented in its entirety.
>
> * Overall, only one lot of end-user documentation would need to be
>   maintained.
>
> * It would enable MobileOrg to be made available for mobile platforms
>   other than Android and iOS, such as Windows Phone and Blackberry.
>
> * The number of people available to assist with development might well
>   be greater, due to the core development environment involving HTML,
>   CSS and JavaScript. Barriers to entry for both regular and occasional
>   committers would be much lower.
>
> i'm aware that Cordova has various limitations,
> including-but-not-limited-to the lack of native 'feel' of Cordova-based
> applications. However, i feel that the above advantages, combined with
> the my notion that Emacs users are probably less concerned with a
> perfectly slick UI than with having access to functionality they
> need/want, probably outweighs such limitations.
>
> Unfortunately, due to other existing commitments, i wouldn't be able to
> take point on such a reboot. But i'd definitely be willing and able to
> help out!  Particularly in the area of contact management and syncing,
> of course. :-)
>
> Thoughts/comments/criticisms?

Sounds interesting.  Unfortunately, I haven't done this type of
development in many years.  At this moment, I'm not even sure how to go
about setting up Cordova and its prerequisites.  Otherwise, I might be
interested in taking the lead on this.

Ultimately, someone will have to pull apart the current
immplementation(s) of MobileOrg in order to redevelop it in Cordova.
Anyone got a handle on that?

-- 
David Masterson
Programmer At Large

Re: Some thoughts on MobileOrg and its development ....

[Jacek Generowicz]

Alexis <flexibeast@gmail.com> writes:

> i can't help but wonder if the 'MobileOrg' endeavour needs a reboot.

It seems clear that it does.

> More specifically, it seems to me that rebuilding MobileOrg as a single
> project [...] might be a way forward, 

This is vital!

> on top of Apache Cordova:
>
> https://cordova.apache.org/

I'd just like to float Kivy as another possibility:

   http://kivy.org

What makes Kivy interesting to me in this context (apart from its
cross-platform nature) is its excellent support of gestures, which gives
me (the perhaps naive) hope that a little more than an utterly trivial
feature set might be provided on the mobile form factor.

> Unfortunately, due to other existing commitments, i wouldn't be able
> to take point on such a reboot.

The dreamer in me thinks this might be the itch-to-scratch that finally
motivates me to getting to grips with Kivy; the realist in me is pretty
certain that I fall into the same category as you.

Re: Some thoughts on MobileOrg and its development ....

[Ashton Kemerling]

I did some digging into that a few months ago. While I'm not an
experienced iOS dev, I flailed about for a few weeks trying to add
deadline parsing and failed miserably. 

I'm fairly convinced that most of the code is either super platform
specific or in need of replacing with easier to maintain & test
components. 


-- 
Ashton Kemerling

Re: Some thoughts on MobileOrg and its development ....

[David Wagle]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

What's involved in 'rebooting' the project? Are the various owners of the
iPhone and Android packages on this list?

I'm not a coder at all, but I've administratively managed software projects
before. I'm more than happy to do what I know how to do -- which is mostly
send out emails asking people if they can help do stuff?


On Tue, Aug 12, 2014 at 8:07 PM, Ashton Kemerling <ashtonkemerling@gmail.com
> wrote:

> I did some digging into that a few months ago. While I'm not an
> experienced iOS dev, I flailed about for a few weeks trying to add
> deadline parsing and failed miserably.
>
> I'm fairly convinced that most of the code is either super platform
> specific or in need of replacing with easier to maintain & test
> components.
>
>
> --
> Ashton Kemerling
>
>

[-- Attachment #2: Type: text/html, Size: 1234 bytes --]

Re: Some thoughts on MobileOrg and its development ....

[Ashton Kemerling]

David Wagle <david.wagle@gmail.com> writes:

> What's involved in 'rebooting' the project? Are the various owners of
> the iPhone and Android packages on this list? 
>
> I'm not a coder at all, but I've administratively managed software
> projects before. I'm more than happy to do what I know how to do --
> which is mostly send out emails asking people if they can help do stuff? 
>
> On Tue, Aug 12, 2014 at 8:07 PM, Ashton Kemerling
> <ashtonkemerling@gmail.com> wrote:
>
>     I did some digging into that a few months ago. While I'm not an
>     experienced iOS dev, I flailed about for a few weeks trying to add
>     deadline parsing and failed miserably.
>     
>     I'm fairly convinced that most of the code is either super platform
>     specific or in need of replacing with easier to maintain & test
>     components.
>     
>     
>     --
>     Ashton Kemerling
>     
>
>

Honestly, I don't know exactly what would be involved, I'm not
experienced in mobile and I don't have anywhere near the spare bandwidth
to be anything other than a secondary contributor. I do suspect that a
lot of existing code would be thrown away in a combined approach due to
the massive semantic and structural differences between native code and
HTML/JS/CSS.

I can say for certain that we would have to figure out the handoff of
various credentials from the old maintainers (who I am assuming would
not like to continue being maintainers) for the respective app-stores
and Dropbox tokens. 

-- 
Ashton Kemerling

Re: Some thoughts on MobileOrg and its development ....

[Alexis]

Ashton Kemerling writes:


> I can say for certain that we would have to figure out the handoff of
> various credentials from the old maintainers (who I am assuming would
> not like to continue being maintainers) for the respective app-stores
> and Dropbox tokens.

Not necessarily. One could, for example, create an entirely new project
on GitHub called 'MobileOrgRebooted', and create entirely new apps in
the respective stores using that name. (As it is, there's not a
uniformly named app in any case - we have 'MobileOrg' for iOS, and
'MobileOrg-Android' for, well, Android.) And it certainly seems to me
that it would be best to start the actual coding of the reboot /first/,
and only worry about naming rights issues if and when it takes
off. Doing otherwise is likely to bring into play another possible
obstacle to getting actual implementation happening.


Alexis.

Re: Some thoughts on MobileOrg and its development ....

[Alexis]

David Wagle writes:

> What's involved in 'rebooting' the project?

My thought involves starting from scratch. Say we use Cordova (i can't
speak to the pros and cons of Cordova vs. Kivy in terms of things like
functionality provided, possible barriers to contribution etc.). Cordova
takes care of a certain amount of the (semi-)boilerplate code needed for
each platform; and of the remainder of the code, the core functionality
would need to get reimplemented in HTML/CSS/JavaScript, with 'shims'
being created between this code and the surrounding platform-specific
code. Consequently, i think there would likely be very little use of
most of the code in either current MobileOrg project.


Alexis.

Re: Some thoughts on MobileOrg and its development ....

[Ashton Kemerling]

That seems reasonable to me.

-- 
Ashton Kemerling

Re: Some thoughts on MobileOrg and its development ....

[Jacek Generowicz]

Alexis <flexibeast@gmail.com> writes:

> One could, for example, create an entirely new project on GitHub
> called 'MobileOrgRebooted', and create entirely new apps in the
> respective stores using that name.

That strikes me as the sensible thing to do.

> (As it is, there's not a uniformly named app in any case - we have
> 'MobileOrg' for iOS, and 'MobileOrg-Android' for, well, Android.)

There's also MobileOrgNG for Android.

> And it certainly seems to me that it would be best to start the actual
> coding of the reboot /first/, and only worry about naming rights
> issues if and when it takes off. Doing otherwise is likely to bring
> into play another possible obstacle to getting actual implementation
> happening.

Agreed.

Re: Some thoughts on MobileOrg and its development ....

[Carlos Sosa]

Jacek Generowicz <jacek.generowicz@cern.ch> writes:

> Alexis <flexibeast@gmail.com> writes:
>
>> One could, for example, create an entirely new project on GitHub
>> called 'MobileOrgRebooted', and create entirely new apps in the
>> respective stores using that name.
>
> That strikes me as the sensible thing to do.
>
>> (As it is, there's not a uniformly named app in any case - we have
>> 'MobileOrg' for iOS, and 'MobileOrg-Android' for, well, Android.)
>
> There's also MobileOrgNG for Android.

There's a difference feature wise between MobileOrgNG[1] and
MobileOrg-Android[2], which I believe should be merged into one project.
For instance, I don't know of MobileOrgNG having a SSH synchronizer
which many people make use of, including me, but with that said,
MobileOrgNG has a far greater and friendlier interface.

I would suggest merging both projects for the sake of a better user
experience.

[1] - https://github.com/kvj/mobileorg-android
[2] - https://github.com/matburt/mobileorg-android

-- Carlos Sosa

Re: Some thoughts on MobileOrg and its development ....

[Alexis]

Carlos Sosa writes:

> There's a difference feature wise between MobileOrgNG[1] and
> MobileOrg-Android[2], which I believe should be merged into one project.
> For instance, I don't know of MobileOrgNG having a SSH synchronizer
> which many people make use of, including me, but with that said,
> MobileOrgNG has a far greater and friendlier interface.
>
> I would suggest merging both projects for the sake of a better user
> experience.

Well, again, the fundamental problem here is that none of these three
MobileOrg* projects are being actively worked on / maintained. The last
commit to MobileOrgNG was on 13 February last year (and is "149 commits
ahead, 863 commits behind" MobileOrg-Android). And despite
not-insignificant discussion here on the Org mailing list about the
MobileOrg* projects over the last few months, none of the lead devs for
any of these projects has chimed in, which suggests work on the Org
ecosystem is a very low priority for them right now. So it seems to me
that the likelihood of getting the two projects to work on a merge
process is similarly very low.

It's certainly true that someone could create a third Android-specific
version of MobileOrg that combines what they feel to be the best of both
Android apps. However, assuming that new app took off, we would still
have two different implementations on two different platforms where
fixes and improvements to code and documentation on one platform
wouldn't be immediately useful and/or appropriate for the other
platform. (Not to mention there'd still not be even theoretical support
for platforms other than iOS and Android.)

From a purely selfish point of view, as an Android user, a new Android
app combining MobileOrg-Android and MobileOrgNG would probably meet my
needs in the short term. In the medium to long term, however, i'm not
yet convinced that it would make the Org-on-mobile-devices situation
much more sustainably active than it is now.


Alexis.

Re: Some thoughts on MobileOrg and its development ....

[Sean Escriva]

Greetings Org users!

(Current MobileOrg iOS maintainer here)

Great to read some feedback. It's often hard to know who really cares if
MobileOrg even exists.

Jacek Generowicz <jacek.generowicz@cern.ch> writes:

> Alexis <flexibeast@gmail.com> writes:
>
>> i can't help but wonder if the 'MobileOrg' endeavour needs a reboot.
>
> It seems clear that it does.
>
>> More specifically, it seems to me that rebuilding MobileOrg as a single
>> project [...] might be a way forward, 
>
> This is vital!

I haven't talked with Matburt for some time now, so I don't want to
speak for him.

However from my perspective there's a huge value in having a single
codebase. Basically my preference is to do whatever will allow the most
contributors to help out.

>
>> on top of Apache Cordova:
>>
>> https://cordova.apache.org/
>
> I'd just like to float Kivy as another possibility:
>
>    http://kivy.org
>
> What makes Kivy interesting to me in this context (apart from its
> cross-platform nature) is its excellent support of gestures, which gives
> me (the perhaps naive) hope that a little more than an utterly trivial
> feature set might be provided on the mobile form factor.

If Cordova or Kivy are a way to that I'm open to looking at them, but
don't have experience with either.

I am comfortable with python so Kivy appeals to me personally.

From the little experience I have with them, cross platform frameworks
do suffer from a loss of fidelity compared to native applications but as
mentioned that may be an acceptable trade off.

There's tons of options for possible paths here (even
https://wukix.com/mocl for fellow LISPers) but the key in my mind is to
support a community of contributors.

>
>> Unfortunately, due to other existing commitments, i wouldn't be able
>> to take point on such a reboot.
>
> The dreamer in me thinks this might be the itch-to-scratch that finally
> motivates me to getting to grips with Kivy; the realist in me is pretty
> certain that I fall into the same category as you.
>

Realistically this is the issue in most cases, plenty of well meaning
help but not a lot of time to do anything. Life gets in the way.

As of the iOS version specifically, I have held off updating due to a
few requests to maintain support for older devices.

My preference in the short term for iOS would be to update the code to
the latest sdk and add a few minor features if needed, but then
determine the best way forward to maintain a single common functional
base.

I am an owner on the github org: https://github.com/MobileOrg and it
would be excellent to make it the central org for any efforts. I'm happy
to help that happen however I can.

-- 
-sean

Re: Some thoughts on MobileOrg and its development ....

[Ashton Kemerling]

It's probably hard to assertain interest because

1) iOS projects have a high barrier to entry contribution wise.
2) A lot of people feel mobileorg doesn't fit their current needs, and
are using something else.

I definitely fall into both categories. I wouldn't be surprised if a few
people come back once things get going again.

-- 
Ashton Kemerling

Re: Some thoughts on MobileOrg and its development ....

[Jacek Generowicz]

Sean Escriva <sean.escriva@gmail.com> writes:

>>> https://cordova.apache.org/

>>    http://kivy.org

> From the little experience I have with them, cross platform frameworks
> do suffer from a loss of fidelity compared to native applications but
> as mentioned that may be an acceptable trade off.

We are talking about interfacing to org-mode, an Emacs mode: I don't
think that the target audience is one which excessively values
platform-specific look-and-feel and has an insurmountable aversion to
idiosyncratic interfaces :-)

> There's tons of options for possible paths here 

Do you have a decent resource for seeking them out? I found good ones
surprisingly difficult to find.

> (even https://wukix.com/mocl for fellow LISPers) but the key in my
> mind is to support a community of contributors.

Yes, I almost mentioned Mocl along with Kivy, but two things stopped me:

  + Mocl is not free, which will not help increase the number of
    contributors,

  + I get the feeling that the average org-mode user is even less Lispy
    than your average Emacs user, Elisp notwithstanding.

>>> Unfortunately, due to other existing commitments, i wouldn't be able
>>> to take point on such a reboot.
>>
>> The dreamer in me thinks this might be the itch-to-scratch that finally
>> motivates me to getting to grips with Kivy; the realist in me is pretty
>> certain that I fall into the same category as you.
>
> Realistically this is the issue in most cases, plenty of well meaning
> help but not a lot of time to do anything. Life gets in the way.

For me, after life getting in the way, by far the biggest barrier to
contribution is the platform-specificity of the projects: I simply can't
be bothered to even think about contributing to something which only be
useful to "half" the potential users.

Re: Some thoughts on MobileOrg and its development ....

[Henning Weiss]

[-- Attachment #1: Type: text/plain, Size: 3530 bytes --]

Hi,

My name is Henning and I am the co-maintainer of MobileOrg Android.

The reason I stopped working on the project is partially the lack of time,
but also because I didn't believe in the design of org-mobile-push/pull and
edit nodes. Almost half of the bugs on our issue tracker are with regards
to synchronization. Our mailing list is also full with questions about how
to set synchronization up. This is the reason I tried to come up with a
better design based on git synchronization. And I did ;)

I have been working over the last couple of months on a private prototype.
I'm currently using it in my daily life and it works for me. It uses Git
(and only Git) for synchronization and doesn't use org-mobile at all. The
idea is that you keep all org files under git version control.
Synchronization of all "clients" (apps or Emacs) is done against that
repository. It is also possible to configure whether to use "ours" or
"theirs" merge strategy when conflicts occur. I have focused on designing
an app I can trust.

It already has an outline view like MobileOrg, an agenda view, you can add
and edit nodes, synchronize changes with a remote repository and
synchronize scheduled entries to the calendar. I ported some of my code
from MobileOrg, but a lot of it is written from scratch.

I don't feel comfortable publishing it for general consumption yet. There
are still some rough edges for the end user, but the core functionality is
done and it works reliably. If you want to help development and testing,
feel free to contact me :)

Henning


On Thu, Aug 14, 2014 at 12:17 PM, Jacek Generowicz <jacek.generowicz@cern.ch
> wrote:

>
> Sean Escriva <sean.escriva@gmail.com> writes:
>
> >>> https://cordova.apache.org/
>
> >>    http://kivy.org
>
> > From the little experience I have with them, cross platform frameworks
> > do suffer from a loss of fidelity compared to native applications but
> > as mentioned that may be an acceptable trade off.
>
> We are talking about interfacing to org-mode, an Emacs mode: I don't
> think that the target audience is one which excessively values
> platform-specific look-and-feel and has an insurmountable aversion to
> idiosyncratic interfaces :-)
>
> > There's tons of options for possible paths here
>
> Do you have a decent resource for seeking them out? I found good ones
> surprisingly difficult to find.
>
> > (even https://wukix.com/mocl for fellow LISPers) but the key in my
> > mind is to support a community of contributors.
>
> Yes, I almost mentioned Mocl along with Kivy, but two things stopped me:
>
>   + Mocl is not free, which will not help increase the number of
>     contributors,
>
>   + I get the feeling that the average org-mode user is even less Lispy
>     than your average Emacs user, Elisp notwithstanding.
>
> >>> Unfortunately, due to other existing commitments, i wouldn't be able
> >>> to take point on such a reboot.
> >>
> >> The dreamer in me thinks this might be the itch-to-scratch that finally
> >> motivates me to getting to grips with Kivy; the realist in me is pretty
> >> certain that I fall into the same category as you.
> >
> > Realistically this is the issue in most cases, plenty of well meaning
> > help but not a lot of time to do anything. Life gets in the way.
>
> For me, after life getting in the way, by far the biggest barrier to
> contribution is the platform-specificity of the projects: I simply can't
> be bothered to even think about contributing to something which only be
> useful to "half" the potential users.
>
>

[-- Attachment #2: Type: text/html, Size: 4595 bytes --]

Re: Some thoughts on MobileOrg and its development ....

[Eric Abrahamsen]

Henning Weiss <hdweiss@gmail.com> writes:

> Hi,
>
> My name is Henning and I am the co-maintainer of MobileOrg Android.
>
> The reason I stopped working on the project is partially the lack of
> time, but also because I didn't believe in the design of
> org-mobile-push/pull and edit nodes. Almost half of the bugs on our
> issue tracker are with regards to synchronization. Our mailing list
> is also full with questions about how to set synchronization up. This
> is the reason I tried to come up with a better design based on git
> synchronization. And I did ;)

Sounds great! I think a lot of us already keep our ~/org directories
under git version-control, and probably many more mean to, but just need
a good push to start doing it. This would be a good push.

> I have been working over the last couple of months on a private
> prototype. I'm currently using it in my daily life and it works for
> me. It uses Git (and only Git) for synchronization and doesn't use
> org-mobile at all. The idea is that you keep all org files under git
> version control. Synchronization of all "clients" (apps or Emacs) is
> done against that repository. It is also possible to configure
> whether to use "ours" or "theirs" merge strategy when conflicts
> occur. I have focused on designing an app I can trust.
>
> It already has an outline view like MobileOrg, an agenda view, you
> can add and edit nodes, synchronize changes with a remote repository
> and synchronize scheduled entries to the calendar. I ported some of
> my code from MobileOrg, but a lot of it is written from scratch.
>
> I don't feel comfortable publishing it for general consumption yet.
> There are still some rough edges for the end user, but the core
> functionality is done and it works reliably. If you want to help
> development and testing, feel free to contact me :)

Maybe you could publish a very basic how-to here, and then we could
annoy you privately with problems?

Thanks!
Eric

> Henning
>
>
> On Thu, Aug 14, 2014 at 12:17 PM, Jacek Generowicz <
> jacek.generowicz@cern.ch> wrote:
>
>    
>     Sean Escriva <sean.escriva@gmail.com> writes:
>    
>     >>> https://cordova.apache.org/
>    
>     >>    http://kivy.org
>    
>     > From the little experience I have with them, cross platform
>     frameworks
>     > do suffer from a loss of fidelity compared to native
>     applications but
>     > as mentioned that may be an acceptable trade off.
>    
>     We are talking about interfacing to org-mode, an Emacs mode: I
>     don't
>     think that the target audience is one which excessively values
>     platform-specific look-and-feel and has an insurmountable
>     aversion to
>     idiosyncratic interfaces :-)
>    
>     > There's tons of options for possible paths here
>    
>     Do you have a decent resource for seeking them out? I found good
>     ones
>     surprisingly difficult to find.
>    
>     > (even https://wukix.com/mocl for fellow LISPers) but the key in
>     my
>     > mind is to support a community of contributors.
>    
>     Yes, I almost mentioned Mocl along with Kivy, but two things
>     stopped me:
>    
>       + Mocl is not free, which will not help increase the number of
>         contributors,
>    
>       + I get the feeling that the average org-mode user is even less
>     Lispy
>         than your average Emacs user, Elisp notwithstanding.
>    
>     >>> Unfortunately, due to other existing commitments, i wouldn't
>     be able
>     >>> to take point on such a reboot.
>     >>
>     >> The dreamer in me thinks this might be the itch-to-scratch
>     that finally
>     >> motivates me to getting to grips with Kivy; the realist in me
>     is pretty
>     >> certain that I fall into the same category as you.
>     >
>     > Realistically this is the issue in most cases, plenty of well
>     meaning
>     > help but not a lot of time to do anything. Life gets in the
>     way.
>    
>     For me, after life getting in the way, by far the biggest barrier
>     to
>     contribution is the platform-specificity of the projects: I
>     simply can't
>     be bothered to even think about contributing to something which
>     only be
>     useful to "half" the potential users.
>    

Re: Some thoughts on MobileOrg and its development ....

[Jorge A. Alfaro-Murillo]

Eric Abrahamsen writes: 

> Henning Weiss <hdweiss@gmail.com> writes: 
>> I have been working over the last couple of months on a private 
>> prototype. I'm currently using it in my daily life and it works 
>> for me. It uses Git (and only Git) for synchronization and 
>> doesn't use org-mobile at all. The idea is that you keep all 
>> org files under git version control. Synchronization of all 
>> "clients" (apps or Emacs) is done against that repository. It 
>> is also possible to configure whether to use "ours" or "theirs" 
>> merge strategy when conflicts occur. I have focused on 
>> designing an app I can trust. 
>> 
>> It already has an outline view like MobileOrg, an agenda view, 
>> you can add and edit nodes, synchronize changes with a remote 
>> repository and synchronize scheduled entries to the calendar. I 
>> ported some of my code from MobileOrg, but a lot of it is 
>> written from scratch. 

Sounds great... can't wait!

> 
> Maybe you could publish a very basic how-to here, and then we 
> could annoy you privately with problems? 

That's a good idea, 1+

-- 
Jorge.

Re: Some thoughts on MobileOrg and its development ....

[Xebar Saram]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

would LOVE to try it as well

thx!

z


On Thu, Aug 14, 2014 at 4:36 PM, Jorge A. Alfaro-Murillo <
jorge.alfaro-murillo@yale.edu> wrote:

> Eric Abrahamsen writes:
>
>> Henning Weiss <hdweiss@gmail.com> writes:
>>
>>> I have been working over the last couple of months on a private
>>> prototype. I'm currently using it in my daily life and it works for me. It
>>> uses Git (and only Git) for synchronization and doesn't use org-mobile at
>>> all. The idea is that you keep all org files under git version control.
>>> Synchronization of all "clients" (apps or Emacs) is done against that
>>> repository. It is also possible to configure whether to use "ours" or
>>> "theirs" merge strategy when conflicts occur. I have focused on designing
>>> an app I can trust.
>>> It already has an outline view like MobileOrg, an agenda view, you can
>>> add and edit nodes, synchronize changes with a remote repository and
>>> synchronize scheduled entries to the calendar. I ported some of my code
>>> from MobileOrg, but a lot of it is written from scratch.
>>>
>>
> Sounds great... can't wait!
>
>
>
>> Maybe you could publish a very basic how-to here, and then we could annoy
>> you privately with problems?
>>
>
> That's a good idea, 1+
>
> --
> Jorge.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2168 bytes --]

Re: Some thoughts on MobileOrg and its development ....

[Samuel Loury]

[-- Attachment #1: Type: text/plain, Size: 4356 bytes --]

Xebar Saram <zeltakc@gmail.com> writes:

> would LOVE to try it as well

So would I !

>>> Henning Weiss <hdweiss@gmail.com> writes:
>>>
>>>> I have been working over the last couple of months on a private
>>>> prototype. I'm currently using it in my daily life and it works for me. It
>>>> uses Git (and only Git) for synchronization and doesn't use org-mobile at
>>>> all. The idea is that you keep all org files under git version control.
>>>> Synchronization of all "clients" (apps or Emacs) is done against that
>>>> repository. It is also possible to configure whether to use "ours" or
>>>> "theirs" merge strategy when conflicts occur. I have focused on designing
>>>> an app I can trust.
>>>> It already has an outline view like MobileOrg, an agenda view, you can
>>>> add and edit nodes, synchronize changes with a remote repository and
>>>> synchronize scheduled entries to the calendar. I ported some of my code
>>>> from MobileOrg, but a lot of it is written from scratch.

I only used the android version, but I was not satisfied with its design
either.

I find the org double synchronization scheme (org <-> org mobile inbox
<-> internal phone database) really annoying.

Actually, I have been thinking about how to use my org file with my
phone and the way I found the more practical was to synchronize the
files with my phone using git (git annex actually) and using emacs in a
debian chrooted environment.

With the constantly evolving org-mode code in emacs-lisp, I don't think
a re-implementation would survive.

Besides, emacs-lisp allows to customize pretty everything, so much that
two org-mode setup may easily be made barely compatible with each
other. See the setup of Bernt Hansen for instance that is the most
advanced I have seen so far⁴.

An other point of the evolving characteristic of org is the lack of
definition of what the org-mode grammar is. Without this, it is most
likely that someday, both emacs org-mode and mobile org will diverge at
some point. There has been a very good draft of org mode syntax¹ made by
Nicolas Goaziou. May be this could be the basis of a new
implementation, but it should be worked on to be considered stable and
used as a reference for future implementations.

Those are the reasons why I am not convinced that a new implementation
would work and one of the main reasons each time I wanted to contribute
to mobileorg-android, I was stopped by the feeling that it would be a
useless effort (and the lack of time of course :-)).

Therefore, I wonder if we could let emacs implementation do all the
heavy stuff and customization, and only provide a mobile UI on top of
it.

Emacs could be accessed remotely or be run into the phone. In my Galaxy
S3 with chrooted debian, emacs runs fast enough for my user experience
not to be disturbed.

I have tried the excellent org-ehtml² from Eric Schulte. It already
allows to make basic edition of TODO entries and view the agenda views
(only the basic org-agenda export to html for new). The main problem I
see with this html/js view is that we often encounter strange issues due
to bad browser implementations.

I have been using the XML-RPC trac plugin³ for a while now and I made we
wonder if we could reproduce this in the scope of mobile org. With an
RPC interface, one would be free to create their own interface easily
(at least python xml-rpc library is really easy to manipulate) and an
official interface could emerge from that.

The interface could provide functions like:
--8<---------------cut here---------------start------------->8---
getAgendaFiles() -> list of files names
getTODOsFromFile(file) -> list of todos
getAllTODOs() -> list of todos
getAgendaViews() -> list of names
getAgendaView(name) -> list of todos ?
clockIn(id)
clockOut(id)
refile(id, parent_id)
getKeywords() -> list of keywords
setKeyword(id, keyword)
...
--8<---------------cut here---------------end--------------->8---
I don't know if those functions would be good, but they give an idea.

¹ http://orgmode.org/worg/dev/org-syntax.html
² https://github.com/eschulte/org-ehtml
³ http://trac-hacks.org/wiki/XmlRpcPlugin
⁴ http://doc.norang.ca/org-mode.html
--
Konubinix
GPG Key    : 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A

[-- Attachment #2: Type: application/pgp-signature, Size: 472 bytes --]

Re: Some thoughts on MobileOrg and its development ....

[Samuel Loury]

[-- Attachment #1: Type: text/plain, Size: 3376 bytes --]

Samuel Loury <konubinix@gmail.com> writes:

> I have been using the XML-RPC trac plugin³ for a while now and I made we
> wonder if we could reproduce this in the scope of mobile org. With an
> RPC interface, one would be free to create their own interface easily
> (at least python xml-rpc library is really easy to manipulate) and an
> official interface could emerge from that.
I have made a some research on the net and found epc¹. This library
appears to do exactly what I am looking for: a remote procedure call
mechanism in emacs.

For what I have tried so far, it looks very promising.

To install the python side, just run:
--8<---------------cut here---------------start------------->8---
pip install epc
--8<---------------cut here---------------end--------------->8---

To install the emacs server part, it is a bit trickier since elpa ships
only the client part. It was not so hard though.  I installed deferred²,
ctable³ and epc⁴. Then I could launch the emacs rpc server.

For the time being, I only tried exporting the org agenda files. And it
was really easy.

The server code (in emacs) looks like:
--8<---------------cut here---------------start------------->8---
(require 'cl)
(require 'epcs)

(defvar pyepc-epcs
  (epcs:server-start
   (lambda (mngr)
     (lexical-let ((mngr mngr))
       (epc:define-method mngr 'org-agenda-files 'org-agenda-files)
       )
     )
   9998
   )
  )
--8<---------------cut here---------------end--------------->8---

The client code (in python) looks like:
--8<---------------cut here---------------start------------->8---
From epc.client import EPCClient
client = EPCClient(("localhost", 9998), log_traceback=True)
print str(client.methods_sync())
print str(client.call_sync('org-agenda-files', []))
client.close()
--8<---------------cut here---------------end--------------->8---

In conclusion, the communication between emacs and python is very
easy. The difficult part now, is to re-factorise the emacs org-mode code
that creates the agenda so that it may provide a data structure
representing the information. I have only had a quick look, but it does
not look straight.

I think it is not much work to get a workable emacs on android⁵ and I
honestly don't know on iPhone.

Once it is done, it would be hopefully easy to configure emacs to run
the epcs code and use anything python based to communicate with it. I
will probably use sl4a⁶ since it is totally awesome.

The aspect I like about the design I propose is that the core (emacs +
epcs) is loosely coupled with the interface. This way, anyone would be
free to provide their one.

What do you think about this project. Do you think it could work? I
think I will eventually start it anyway (just to see). Off course, since
I am also a busy person, it would probably slow, but I honestly think it
would be worth it. Anyone would like to contribute?

Thanks for reading.

¹ http://python-epc.readthedocs.org/en/latest/
² https://github.com/kiwanami/emacs-deferred.git
³ https://github.com/kiwanami/emacs-ctable.git
⁴ https://github.com/kiwanami/emacs-epc.git
⁵ http://article.gmane.org/gmane.emacs.orgmode/77698
⁶ https://code.google.com/p/android-scripting/
--
Konubinix
GPG Key    : 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A

[-- Attachment #2: Type: application/pgp-signature, Size: 472 bytes --]