From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Jones Subject: Re: Agenda in MobileOrg for Android Date: Tue, 9 Apr 2013 16:51:47 -0400 Message-ID: References: <20130324025258.521fa38a@aga-netbook> <20130407151332.218212de@aga-netbook> <20130408112847.769a44d3@aga-netbook> <20130409222755.064b6dd5@aga-netbook> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2c5c0fff1e304d9f3b9b1 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:40445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPfWV-0002tn-QO for emacs-orgmode@gnu.org; Tue, 09 Apr 2013 16:52:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPfWS-0000sV-Kv for emacs-orgmode@gnu.org; Tue, 09 Apr 2013 16:52:11 -0400 Received: from mail-ob0-x22a.google.com ([2607:f8b0:4003:c01::22a]:57898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPfWS-0000sQ-Ae for emacs-orgmode@gnu.org; Tue, 09 Apr 2013 16:52:08 -0400 Received: by mail-ob0-f170.google.com with SMTP id uy19so5264889obc.1 for ; Tue, 09 Apr 2013 13:52:07 -0700 (PDT) In-Reply-To: <20130409222755.064b6dd5@aga-netbook> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Marcin Borkowski Cc: "emacs-orgmode@gnu.org" --001a11c2c5c0fff1e304d9f3b9b1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Apr 9, 2013 at 4:27 PM, Marcin Borkowski wrote: > 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 happening. 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: http://matburt.net/files/MobileOrg/ > * 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=99" (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. --001a11c2c5c0fff1e304d9f3b9b1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 9, 2013 at 4:27 PM, Marcin Borkowski <mbork@wmi.amu.edu.pl> wrote:
<= br>> I see. =A0OTOH, one argument *against* a database (as opposed to pa= rsing
> 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 fi= le parser and we tried to stick with that for as long as we could because i= n some ways it is just easier! =A0We ran into some really nasty problems as= we went along, though, and the further we got into our desired feature lis= t the worse it became simply relying on that file parser. =A0I was initiall= y 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.
=A0
>
>
> That's interesting. =A0I would be very glad= to learn what might the
> pitfalls of "just overwriting files&q= uot; 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 fil= es and forget to push it up to your mobile. =A0Later in the day you make a = change to the same node, or even somewhere else in the file while on your m= obile device and then push that file up. =A0 In the evening you get back to= your computer running emacs and pull your remote changes in. =A0 What do y= ou want to happen? =A0Should the one still on your computer that you last c= hanged this morning take precedence? =A0or the one on the mobile device? = =A0 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. =A0 That's why the org-mobi= le-* functions exist. =A0Now it can be argued that there is a better way an= d I'd probably agree with that statement but it's not an easy probl= em to solve.

Here's another case... if you are editing a file in emacs and the f= ile changes outside of emacs what happens? =A0emacs 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 tha= t's happening.

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 a= fter
> =A0 reading this thread. =A0I'll try to set it up again. = =A0I installed from
> =A0 the Google Play; is it better to use the gi= thub repo? =A0It says
> =A0 "0.9.7" in the release notes on the wiki, Google Play sa= ys it's
> =A0 0.9.8, and maybe it would be better to use master o= r even 0.9.10
> =A0 (looking at the branches on github)? =A0Where do = I find the info about
> =A0 installing the bleeding edge version from github on my phone (I= 9;m
> =A0 quite new to Android, as I mentioned.)

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

http://= matburt.net/files/MobileOrg/

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

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

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

Yep... the only way we know that it "sucks" is if peop= le tell us what sucks about it. =A0UI/UX has been an iterative process wher= e we have to take feedback from our users. =A0It's a real challenge to = build a UI that works for the most people and we want to make the most peop= le happy.
--001a11c2c5c0fff1e304d9f3b9b1--