Re: [O] Some thoughts on MobileOrg and its development ....
Samuel Loury konubi...@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
pgpEzYPVBLQ0D.pgp
Description: PGP signature
Re: [O] Some thoughts on MobileOrg and its development ....
Xebar Saram zelt...@gmail.com writes: would LOVE to try it as well So would I ! Henning Weiss hdwe...@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 pgp8ITS7zhZVp.pgp Description: PGP signature
Re: [O] Some thoughts on MobileOrg and its development ....
Sean Escriva sean.escr...@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: [O] Some thoughts on MobileOrg and its development ....
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.generow...@cern.ch wrote: Sean Escriva sean.escr...@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: [O] Some thoughts on MobileOrg and its development ....
Henning Weiss hdwe...@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.generow...@cern.ch wrote: Sean Escriva sean.escr...@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: [O] Some thoughts on MobileOrg and its development ....
Eric Abrahamsen writes: Henning Weiss hdwe...@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: [O] Some thoughts on MobileOrg and its development ....
would LOVE to try it as well thx! z On Thu, Aug 14, 2014 at 4:36 PM, Jorge A. Alfaro-Murillo jorge.alfaro-muri...@yale.edu wrote: Eric Abrahamsen writes: Henning Weiss hdwe...@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: [O] Some thoughts on MobileOrg and its development ....
Alexis flexibe...@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: [O] Some thoughts on MobileOrg and its development ....
Jacek Generowicz jacek.generow...@cern.ch writes: Alexis flexibe...@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: [O] Some thoughts on MobileOrg and its development ....
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: [O] Some thoughts on MobileOrg and its development ....
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.generow...@cern.ch writes: Alexis flexibe...@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: [O] Some thoughts on MobileOrg and its development ....
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: [O] Some thoughts on MobileOrg and its development ....
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: [O] Some thoughts on MobileOrg and its development ....
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 ashtonkemerl...@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
Re: [O] Some thoughts on MobileOrg and its development ....
David Wagle david.wa...@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 ashtonkemerl...@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: [O] Some thoughts on MobileOrg and its development ....
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: [O] Some thoughts on MobileOrg and its development ....
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: [O] Some thoughts on MobileOrg and its development ....
That seems reasonable to me. -- Ashton Kemerling
Re: [O] Some thoughts on MobileOrg and its development ....
Alexis flexibe...@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.
[O] Some thoughts on MobileOrg and its development ....
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: [O] Some thoughts on MobileOrg and its development ....
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 flexibe...@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.
Re: [O] Some thoughts on MobileOrg and its development ....
Alexis flexibe...@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
