emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Matthew Jones <bsdmatburt@gmail.com>
To: Marcin Borkowski <mbork@wmi.amu.edu.pl>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: Agenda in MobileOrg for Android
Date: Tue, 9 Apr 2013 16:51:47 -0400	[thread overview]
Message-ID: <CABSYn2ghr0VUdzCBX3OXxDKVskKYRC1JRsQvMZ93fHw_RkBn_A@mail.gmail.com> (raw)
In-Reply-To: <20130409222755.064b6dd5@aga-netbook>

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

On Tue, Apr 9, 2013 at 4:27 PM, Marcin Borkowski <mbork@wmi.amu.edu.pl>

> I see.  OTOH, one argument *against* a database (as opposed to parsing
> text files) might be exactly preserving the formatting etc. of files (of
> course, with all the syncing stuff this is not important anyway).

Certainly at the beginning it was easier to rely on our file parser and we
tried to stick with that for as long as we could because in some ways it is
just easier!  We ran into some really nasty problems as we went along,
though, and the further we got into our desired feature list the worse it
became simply relying on that file parser.  I was initially very skeptical
about going the database route but it is easily one of the best decisions
we have made with regard to refactoring of the project and it has enabled
some of the great features we have today.

> That's interesting.  I would be very glad to learn what might the
> pitfalls of "just overwriting files" be; it may be the case that "just
> overwriting" would work well with *my personal* use pattern of
> Org-mode, and that would be why I don't understand MobileOrg's approach.

So imagine this... in the morning you synchronize you org files to your
mobile device but then make a change in one of those files and forget to
push it up to your mobile.  Later in the day you make a change to the same
node, or even somewhere else in the file while on your mobile device and
then push that file up.   In the evening you get back to your computer
running emacs and pull your remote changes in.   What do you want to
happen?  Should the one still on your computer that you last changed this
morning take precedence?  or the one on the mobile device?   The answer is
probably that you want to merge those changes... that is something that
emacs can do, but as is the case with most patch-work it can't always do
that in automated fashion.   That's why the org-mobile-* functions exist.
 Now it can be argued that there is a better way and I'd probably agree
with that statement but it's not an easy problem to solve.

Here's another case... if you are editing a file in emacs and the file
changes outside of emacs what happens?  emacs doesn't like it at all... so
you need some sort of built in emacs mechanism for being able to merge
changes in a safe way, and it needs to not surprise the user when that's

These are the kinds of issues we are all struggling to solve in one way or
another but the general consensus is that "just overwriting" is the worst
of the possible options, even if it is technically the easiest.

> * Yes, I did uninstall, but I've reinstalled MobileOrg again after
>   reading this thread.  I'll try to set it up again.  I installed from
>   the Google Play; is it better to use the github repo?  It says
>   "0.9.7" in the release notes on the wiki, Google Play says it's
>   0.9.8, and maybe it would be better to use master or even 0.9.10
>   (looking at the branches on github)?  Where do I find the info about
>   installing the bleeding edge version from github on my phone (I'm
>   quite new to Android, as I mentioned.)

Google Play is always up to date... usually we'll only post an updated
changeset on github if something major has changed, if it's just a bug fix
then you probably won't see it mentioned.   If you can't access Google
play, as mentioned in the wiki, you can always find the latest and past
release here:


> * I did not leave a one-star review; I guess I'm too lazy for that, but
>   also it would be a bit unfair without further investigation of my
>   problems.

I didn't mean to suggest that you personally did... but it happens a lot
more than I wish it did.  We also get faulted a lot for the perception of
complexity of the way the we have to handle synchronization but as I've
mentioned above... it's a little more complex than just pushing the files
to the device or pulling them off the device.

> * I am very busy these days, but I'll try hard to start using MobileOrg
>   and (if the problems I had persist), I'll try to report them on
>   MobileOrg's mailing list.  In fact, my problems were twofold:
>   firstly, syncing didn't "Just Work™" (sometimes I got errors on
>   MobileOrg, sometimes in Emacs), and some of the UI choices *did*
>   suck.  As soon as I find some time, I'll try to describe exactly what
>   I mean by this, so that either it could get improved or I could get
>   convinced that it's my usage that sucks (which is obviously possible,
>   especially given my lack of experience).

Yep... the only way we know that it "sucks" is if people tell us what sucks
about it.  UI/UX has been an iterative process where we have to take
feedback from our users.  It's a real challenge to build a UI that works
for the most people and we want to make the most people happy.

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

  reply	other threads:[~2013-04-09 20:52 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-24  1:52 Agenda in MobileOrg for Android Marcin Borkowski
2013-03-24  2:04 ` John Hendy
2013-04-07 13:13   ` Marcin Borkowski
2013-04-07 21:16     ` David Rogers
2013-04-07 21:41       ` Marcin Borkowski
2013-04-08  4:33         ` David Rogers
2013-04-08  6:24           ` Marcin Borkowski
2013-04-08  1:20     ` James Harkins
2013-04-08  9:26       ` Marcin Borkowski
2013-04-09 10:19         ` Gareth Smith
2013-04-08  6:52     ` James Harkins
2013-04-08  9:28       ` Marcin Borkowski
2013-04-09 18:24         ` Matthew Jones
2013-04-09 20:27           ` Marcin Borkowski
2013-04-09 20:51             ` Matthew Jones [this message]
2013-04-09 21:36               ` Marcin Borkowski
2013-04-09 22:06           ` John Hendy
2013-04-23 10:50           ` Android MobileOrg: appointments without SCHEDULED/DEADLINE (was: Agenda in MobileOrg for Android) Karl Voit
2013-04-24  4:41             ` Android MobileOrg: appointments without SCHEDULED/DEADLINE Rémi Vanicat
2013-04-24  7:38               ` Eric S Fraga
2013-04-24 14:46                 ` Rémi Vanicat
2013-04-24 17:21               ` Henning Weiss
2013-04-24 17:33               ` MobileOrg and repeating events (was: Android MobileOrg: appointments without SCHEDULED/DEADLINE) Karl Voit
2013-04-24 17:15             ` Android MobileOrg: appointments without SCHEDULED/DEADLINE (was: Agenda in MobileOrg for Android) Henning Weiss
2013-04-24 17:30               ` Karl Voit
2013-04-25  8:55               ` Android MobileOrg: appointments without SCHEDULED/DEADLINE Eric S Fraga
2013-04-15 12:45         ` Agenda in MobileOrg for Android Andreas Leha
2013-04-15 15:24           ` Bastien
2013-04-15 18:36             ` Andreas Leha
2013-05-12  1:55         ` mobileorg-android
2013-05-13  3:00           ` [mobileorg-android] " James Harkins
2013-05-13 13:28             ` Marcin Borkowski
  -- strict thread matches above, loose matches on Subject: below --
2013-04-07 17:54 Itai kloog
2013-04-09 18:09 Jorge A. Alfaro Murillo
2013-04-09 18:18 ` David Rogers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABSYn2ghr0VUdzCBX3OXxDKVskKYRC1JRsQvMZ93fHw_RkBn_A@mail.gmail.com \
    --to=bsdmatburt@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mbork@wmi.amu.edu.pl \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).