Add support for wide Org Tables

[dustinswan]

If an Org Table is too wide, it will wrap making it difficult to read.

Would it be possible to disable wrapping and allow horizontal scrolling for Org Tables only?

[vzaliva]

Because the phone screen is quite narrow, the tables with more than 2-3 columns do not fit horizontally. I think it is very important to show them without wrapping. Attached is a screenshot illustrating the problem:

[easbarba]

Same here!

[artbristol]

I would approach this as follows:
Change NoteViewModel.content to be a List<NoteContent> instead of a String. NoteContent would have subclasses for Text (a plain block of text) and Table (a table) and any other richly displayed content (e.g. Logbook drawer).
I'd also consider changing the DB entity Note to normalise the content into another table with a row for each item in the list.
Then in the UI, it should be easy enough to display tables differently from plain text.
Any thoughts @nevenz ?

[nevenz]

I'm not sure what will be the best way to do this. Using Spans is another option.

Perhaps we should check how some other apps do it. There are libraries too - for example, I have Markwon in my notes as something to check.

[artbristol]

Sure, having looked into the code a bit more, I think spans might be a better idea.
Perhaps an overlay span with fixed width, and a link to another view that allows (just) the table to be edited?

[nevenz]

Perhaps an overlay span with fixed width, and a link to another view that allows (just) the table to be edited?

Sure, sounds good. What would clicking of the link do? Are you thinking something like a popup window, entering edit mode for entire content, just that cell, or something else?

BTW, horizontal scrolling of the content is also needed (it's actually what the main issue here is - one could use monospaced font even now as a workaround for aligning, but still have the same problem with wrapping).

[artbristol]

I was thinking of a new combined view/edit screen. The table's content could be truncated or collapsed somehow on the main note view (like a drawer) to avoid needing horizontal scrolling there. You'd need to go to the new screen to view the table.

[decadent]

These days, the sorta-standard way to display wide tables and images on phone screens is to have the individual tables or images be scrollable horizontally on their own, without the rest of the content being affected. Works pretty well on websites: e.g. see any larger table on Wikipedia.

[daraul]

I don't mind the horizontal scroll, though being able to collapse/hide the table sounds useful for larger tables.

[artbristol]

@nevenz I've been experimenting with horizontal scrolling of the note content (view only so far) here https://github.com/artbristol/orgzly-android/tree/poc/horizontalscroll

It sort-of works (lots still to fix up, of course). It adds a RecyclerView to show the note content as a list of alternating table and non-table sections. I'm not entirely happy with the nested RecyclerView, but to have a single RecyclerView would entail changing the main Recycler view to have e.g.

• header
• note section
• note section
• note section
• header
• note section

etc. instead of the current

• note
• note
• note

which seems arduous.

I'm wondering what you think of the approach?

[nevenz]

@artbristol, why even use a RecyclerView for the content? Why not just a simple vertical LinearLayout?

[artbristol]

@artbristol, why even use a RecyclerView for the content? Why not just a simple vertical LinearLayout?

Forgive my ignorance of Android, but I thought a LinearLayout only worked when you knew in advance which views would be contained. Don't we need a ListView or RecyclerView since there could be an arbitrary number of table/text sections in the note content?

[nevenz]

Forgive my ignorance of Android, but I thought a LinearLayout only worked when you knew in advance which views would be contained. Don't we need a ListView or RecyclerView since there could be an arbitrary number of table/text sections in the note content?

But it's not arbitrary, it's known after AocNoteContent.parse, right?

So LinearLayout's children can be just replaced there. At the same place where content text is now set for TextView.

Unless I'm missing something I don't think there's a benefit of using RecyclerView, as I see that all note content's views are inflated together when scrolling.

[artbristol]

Thanks for the feedback. On the branch I've tried to implement your suggestion by removing the recycler view and creating the child views in the list programmatically (using addView). Am I on the right lines?

[nevenz]

On the branch I've tried to implement your suggestion by removing the recycler view and creating the child views in the list programmatically (using addView). Am I on the right lines?

Sure, I think it's simpler and can be used until there's a good reason to use RecyclerView instead.

BTW, LinearLayout's children could still be inflated from the layouts, no need to create those programmatically.

[artbristol]

OK I've inflated the layouts using the LayoutInflater.
Obviously there's still a lot of work to do, but do you think it's yet worth creating a PR for my branch, so we can discuss changes there?

[nevenz]

Obviously there's still a lot of work to do, but do you think it's yet worth creating a PR for my branch, so we can discuss changes there?

Sounds good to me. Thanks!

[artbristol]

Created a draft PR #799