Support for plain timestamps

[lahertel]

I was wondering whether there is any particular reason why only deadlines and schedules are implemented in orgzly, but not plain timestamps. I find the latter really helpful for appointsments etc. Also check gnu.org

[tkamat]

I will try to implement this, seems relatively straightforward despite my meager android knowledge.

[tkamat]

I will try to implement this, seems relatively straightforward despite my meager android knowledge.

[nevenz]

I will try to implement this, seems relatively straightforward

Thanks!

Just note there can be multiple timestamps per note anywhere in the content, which would need to be parsed and stored in a new table and linked to notes. Which also answers original question - that's the reason why this hasn't been implemented right from the start - it's more complex then scheduled and deadline times.

[nevenz]

I will try to implement this, seems relatively straightforward

Thanks!

Just note there can be multiple timestamps per note anywhere in the content, which would need to be parsed and stored in a new table and linked to notes. Which also answers original question - that's the reason why this hasn't been implemented right from the start - it's more complex then scheduled and deadline times.

[tkamat]

Yeah you are right, I have been having more trouble with this than I initially expected.

One question, do you want the timestamps in the ui to show up only when it senses one present, or do you want an "add timestamp" button at all times?

[tkamat]

Yeah you are right, I have been having more trouble with this than I initially expected.

One question, do you want the timestamps in the ui to show up only when it senses one present, or do you want an "add timestamp" button at all times?

[nevenz]

One question, do you want the timestamps in the ui to show up only when it senses one present, or do you want an "add timestamp" button at all times?

So considering that:

• Plain timestamps can be scattered throughout note's content
• There's no single place in note where one timestamp should be put when writing an Org file (like there is for scheduled and deadline times)

I think there are two parts of implementing full support for plain timestamps:

1. Parse note's content (for the first time and on after any content change) and search for timestamps. Store every found timestamp to DB (to a new table which would contain note_id).
2. Add a toolbar above note's content in note view (similar to the one for comments on GitHub). This toolbar will be used for many other things in the future (bold, italic, lists, tables, links, ...). Add "Insert timestamp" to the toolbar, which would open a dialog with date/time picker (already exists in Orgzly) and insert it to the note's content.

First one is I think much more important and will allow searching, showing notes in agenda, reminders, etc. And UI part would be pretty convenient (well, more then convenient, since typing org timestamp is a PITA).

Anyway, that was my plan and how I'd go for it. Perhaps there's a better one, or we can support only one plain timestamp per note, though I don't think that's a good idea.

It's a decent amount of work, but can be done step at the time. And it's not really complicated as it might sound. First part is probably enough to consider plain timestamps supported (at least I would).

If you're still up for it, which would be great, feel free to ask about anything.

There are already pieces of code in Orgzly which do similar things. For example, looking for timestamp reminds of searching for #+TITLE: in book's preface after it's changed. Storing multiple timestamps per note in DB is similar to storing multiple properties per note. And the only problem with the toolbar that comes to mind is inserting value from the dialog to EditText at the cursor position from which dialog is called (might be trivial, I just haven't done anything like that).

[nevenz]

One question, do you want the timestamps in the ui to show up only when it senses one present, or do you want an "add timestamp" button at all times?

So considering that:

• Plain timestamps can be scattered throughout note's content
• There's no single place in note where one timestamp should be put when writing an Org file (like there is for scheduled and deadline times)

I think there are two parts of implementing full support for plain timestamps:

1. Parse note's content (for the first time and on after any content change) and search for timestamps. Store every found timestamp to DB (to a new table which would contain note_id).
2. Add a toolbar above note's content in note view (similar to the one for comments on GitHub). This toolbar will be used for many other things in the future (bold, italic, lists, tables, links, ...). Add "Insert timestamp" to the toolbar, which would open a dialog with date/time picker (already exists in Orgzly) and insert it to the note's content.

First one is I think much more important and will allow searching, showing notes in agenda, reminders, etc. And UI part would be pretty convenient (well, more then convenient, since typing org timestamp is a PITA).

Anyway, that was my plan and how I'd go for it. Perhaps there's a better one, or we can support only one plain timestamp per note, though I don't think that's a good idea.

It's a decent amount of work, but can be done step at the time. And it's not really complicated as it might sound. First part is probably enough to consider plain timestamps supported (at least I would).

If you're still up for it, which would be great, feel free to ask about anything.

There are already pieces of code in Orgzly which do similar things. For example, looking for timestamp reminds of searching for #+TITLE: in book's preface after it's changed. Storing multiple timestamps per note in DB is similar to storing multiple properties per note. And the only problem with the toolbar that comes to mind is inserting value from the dialog to EditText at the cursor position from which dialog is called (might be trivial, I just haven't done anything like that).

[Sodel-the-Vociferous]

What do you think of having this in the long-press "right-click" menu in the note editor, instead of creating an ever-present toolbar?

[Sodel-the-Vociferous]

What do you think of having this in the long-press "right-click" menu in the note editor, instead of creating an ever-present toolbar?

[nevenz]

What do you think of having this in the long-press "right-click" menu in the note editor, instead of creating an ever-present toolbar?

I think we'd still want a tool bar for other stuff, like bolding, lists, etc.

Personally I'm not a fan of long-click in general - I find it slow. But it might make more sense for inserting new content.

However, if we have a toolbar, it might be better to keep all actions you can perform visible in it and in one place. Though we could still keep a subset of actions in long-click pop-up, similar to swipe menu now.

[nevenz]

What do you think of having this in the long-press "right-click" menu in the note editor, instead of creating an ever-present toolbar?

I think we'd still want a tool bar for other stuff, like bolding, lists, etc.

Personally I'm not a fan of long-click in general - I find it slow. But it might make more sense for inserting new content.

However, if we have a toolbar, it might be better to keep all actions you can perform visible in it and in one place. Though we could still keep a subset of actions in long-click pop-up, similar to swipe menu now.

[fresheed]

@tkamat, any news on that? Do you need help?

[fresheed]

@tkamat, any news on that? Do you need help?

[wyleyr]

@tkamat and @fresheed: this issue is really keeping me from using Orgzly more seriously, and it seems to be important for a lot of other feature requests, so if there's any way I can help, let me know! (I am a heavy Org mode user but unfortunately, I have no Android development experience. Happy to learn something if it would help, though!)

[wyleyr]

@tkamat and @fresheed: this issue is really keeping me from using Orgzly more seriously, and it seems to be important for a lot of other feature requests, so if there's any way I can help, let me know! (I am a heavy Org mode user but unfortunately, I have no Android development experience. Happy to learn something if it would help, though!)

[fresheed]

@wyleyr , it turned out that I even didn't start to work on this and I suspect that tkamat neither. So this issue can become yours : ]
As nevenz stated, most important part is to parse all timestamps in file and save them in database. IIRC, it doesn't require lots of Android coding, mainly plain Java. I think that implementation of this part is enough for initial release - we'll be able to use existing timestamps in files for reminders etc. UI for timestamps insertion can be added later.
Also @nevenz, maybe this issue is already being implemented?

[fresheed]

@wyleyr , it turned out that I even didn't start to work on this and I suspect that tkamat neither. So this issue can become yours : ]
As nevenz stated, most important part is to parse all timestamps in file and save them in database. IIRC, it doesn't require lots of Android coding, mainly plain Java. I think that implementation of this part is enough for initial release - we'll be able to use existing timestamps in files for reminders etc. UI for timestamps insertion can be added later.
Also @nevenz, maybe this issue is already being implemented?

[fmdkdd]

Like @wyleyr, I want to see this implemented in order to use Orgzly as portable agenda. I have modified the parser to collect all timestamps (see orgzly/org-java#7), but I'm not quite sure where and how to use put these parsed timestamps in the DB. I have no Android development experience either, but I managed to build both projects, deploy on a simulator, and run the tests. Any pointers would be appreciated.

[fmdkdd]

Like @wyleyr, I want to see this implemented in order to use Orgzly as portable agenda. I have modified the parser to collect all timestamps (see orgzly/org-java#7), but I'm not quite sure where and how to use put these parsed timestamps in the DB. I have no Android development experience either, but I managed to build both projects, deploy on a simulator, and run the tests. Any pointers would be appreciated.

[nevenz]

They would probably go to org_ranges and a new join table would have to be created (note_org_ranges or note_content_times or similar).

First data insert would be in Provider#loadBookFromReader, but since modifying content can add new timestamps, NoteFragment would have to parse the content too when it's changed.

And there's cleanup to do on note or book deletion.

Ask away, when you get to look around for these. Thanks!

[nevenz]

They would probably go to org_ranges and a new join table would have to be created (note_org_ranges or note_content_times or similar).

First data insert would be in Provider#loadBookFromReader, but since modifying content can add new timestamps, NoteFragment would have to parse the content too when it's changed.

And there's cleanup to do on note or book deletion.

Ask away, when you get to look around for these. Thanks!

[drgibbon]

I'm not sure what should be done for items that have multiple active timestamps, but I think that at least an entry with a single active timestamp should be available for display in the agenda. Very happy to see some movement on this one as I'm switching over to org-mode for everything, and plain timestamps (active) seem to be the recommended way of storing a simple appointment.

[drgibbon]

I'm not sure what should be done for items that have multiple active timestamps, but I think that at least an entry with a single active timestamp should be available for display in the agenda. Very happy to see some movement on this one as I'm switching over to org-mode for everything, and plain timestamps (active) seem to be the recommended way of storing a simple appointment.

[nhardt]

As just a user I'd be thrilled with anything that is compatible with how orgmode defines a 1 time scheduled item, like a meeting, which is just a plain timestamp. I'd be willing/happy to put the timestamp in the heading, in a custom field (orgmode will pick it up) or any other non standard thing that orgmode in emacs can pick up. Due to some other oddities, even items that repeat M-F I have 5 separate entries for. I can live with 1 timestamp per item. Thanks for a great tool!

[nhardt]

As just a user I'd be thrilled with anything that is compatible with how orgmode defines a 1 time scheduled item, like a meeting, which is just a plain timestamp. I'd be willing/happy to put the timestamp in the heading, in a custom field (orgmode will pick it up) or any other non standard thing that orgmode in emacs can pick up. Due to some other oddities, even items that repeat M-F I have 5 separate entries for. I can live with 1 timestamp per item. Thanks for a great tool!

[Chobbes]

Is there any news on this? It seems like a really important feature to be able to fully use orgzly with org-mode!

The fact that there's this pretty big divide in how they represent time for events is quite problematic! This is one of the biggest hurdles when using orgzly for me.

[Chobbes]

Is there any news on this? It seems like a really important feature to be able to fully use orgzly with org-mode!

The fact that there's this pretty big divide in how they represent time for events is quite problematic! This is one of the biggest hurdles when using orgzly for me.

[zeltak]

+1

its also important to me since i solely use timestamp for meetings

best

Z

[zeltak]

+1

its also important to me since i solely use timestamp for meetings

best

Z

[nevenz]

There's a big database usage rewrite in progress (switching to RoomDatabase, removing Cursor usage, etc.). So I've been avoiding working on any database-heavy features. I'll be focusing on most requested features after that, this one included.

[nevenz]

There's a big database usage rewrite in progress (switching to RoomDatabase, removing Cursor usage, etc.). So I've been avoiding working on any database-heavy features. I'll be focusing on most requested features after that, this one included.

[brownstyler]

This is an essential feature for me as I use timestamps almost exclusively over scheduling!

[brownstyler]

This is an essential feature for me as I use timestamps almost exclusively over scheduling!