write should not change the format of an opened journal entry

[walter]

By design, FN-SPACE (and CTRL-U) opens the current page source in the Write activity. [Thank you Simon.] The Write activity doesn't see the text as HTML (I thought this bug was already filed, but I cannot find it), but were it to, I think there is still another bug: (1) From Write, use "Save As" (CTRL-SHIFT-S) to save the source as a .html file; (2) Open the .html file from the Browse activity; (3) Note that the file opened in the browser as raw text, not HTML.

[erikos]

1) 'The write activity does not see the text as html' I am not really sure what you mean here.

2) So i did the following test: a) create a document in write with colored text, tables etc b) save it as .html (so this saves as a file on the file system not as a journal entry) c) open it in browse with the navigation bar d) it opens correctly, interprets the html f) use the fn+space key to show the source again g) write does show the html source that has write originally created fine

Was the above the use case you described?

[walter]

There are several examples of where things go awry--probably all related:

(1) Use "View Source" (Fn-space) to open an HTML document in the Write Activity. It appears as text in the Write activity. (2) As per your steps b and c, Save As (CTRL-SHIFT-S) to save as html to the file system. (3) Alas, it opens as text in the browser, it is not interpreted as html.

Opening the document from the Journal doesn't offer Browse as a resume option. Opening the document in Write, it appears as text, not html, which for View Source is appropriate.

-walter

[erikos]

(2) i did use the (Ctrl-Shift-S) to save as html and the interesting thing is that when you do show the source of a web page in write and save it with (Ctrl-Shift-S) and open it then in browse it is not interpreted as html, what i did test was that i created a document in write, saved this with (Ctrl-Shift-S) and this got interpreted correctly.

For the resume option in browse I discussed with tomeu and marco today and i think the idea is to limit the possibilities of resume options to not have a too long list.

[erikos]

So actually the problem is that when you do save as html in write not only the plain text is saved. When you save it as plain text in write change the ending from .txt to .html it will be interpreted as html by the browser. I am not so much sure someone will/should use the save as option in write as it is independent from the journal, correct me if I am wrong.

[marco]

Sounds like we should get this feature to work for real, since we implemented it (and it's an important one).

[marco]

I misread this, I don't think opening in Browse is actually important for killjoy.

[erikos]

I am not so much sure there is a problem here. Creating the source file and opening it in write does work (at least what I have tested). What does not work is the resuming of a source entry from the journal when the write activity is closed: https://dev.laptop.org/ticket/4042 And I think in general we decided that only the write activity is displayed as option to open the source entries.

[walter]

Between this bug and 4042 I think we have some problems that need to be fixed.

The idea behind view source is two-fold: (1) let kids see the internal structure of HTML content; and (2) let kids make changes to that content. This is one of the paths of least resistance to getting kids to start simple programming.

Now, one could argue that they should use an HTML editor instead of Write for the above, but Write is capable of doing these operations in a reasonably friendly way and it is the only real option we have in the near term.

So what are the bugs? 4022 is a matter of properly closing the loop: C-U or FN-SPACE causes browse to open the page content in Write as raw HTML. You can change view the source as per goal (1) and you can modify it as per goal (2), but you have no way of viewing your modifications in the browser. I don't understand the root cause, but I assume it is related to file or mime-types and somehow registering the "resume" with the D-Bus datastore API? Seems like we are very close to being able to fix this one. I think the importance of letting the kids hack HTML trumps limiting the possibilities of resume options.

4042 I only just experienced for the first time while testing Build 622 over the weekend. No resume options were given, which is presumably a bug and not a matter of limiting the possibilities of resume options. I haven't tried it on recent Joyride builds, so maybe it is no longer a problem.

[marco]

The problem is that mime type does not provide enough information to handle all the cases correctly here. I can think of several possible solutions. I'll add this to dev meeting agenda and see what we can come up with.

[marco]

Simon, as we discovered in the meeting we have a metadata property for this already. Are you still blocking on something here or is it just matter of fixing the implementation?

[erikos]

Browse sets the metadata entry 'source' to '1' and the 'mime_type' to 'text/html'. This gets picked up fine by write and it opens the source of the page. The problem is that write once it's saves it does store the journal entry in its own format and browse can not open it anymore. Write should not change the mime-type and the format of an opened journal entry.

My test to verify this was: If I just store the source page from browse to the journal (and do not open it in write) I can open it again in browse and the html is interpreted as desired.

[walter]

I am not sure if it is just an anomaly of Joyride 226, but things seem to have gone awry:

Fn-Space doesn't work. Ctrl-U opened the source into the Write activity (as opposed to saving it in the Journal). I made a minor modification of the source code and quit both Write and the Browser. Returning to the Journal, the only resume option was Write. When I opened the file in Write, only to find that the character mapping was incorrect--I haven't done a through analysis, but seems like an encoding error--raw as UTF-8 or some such mismatch.

[uwog]

Working on this;

For the charater encoding: this might be a tricky problem. If the HTML is written in some encoding other than UTF8 or LATIN-1, then AbiWord text import will (or at least should) detect that. However, when writing it back I _think_ AbiWord currently always writes UTF8 (as opposed to the original encoding).

[walter]

The page in question was laptop.org, which uses an encoding of charset="iso-8859-1"; However the strange thing is that the file opened fine in Abiword; I inserted a few characters and then quit. Reopening in Abiword, the encoding was messed up. So this is something Abiword is doing to the encoding. (Maybe it is changing it to UTF8, but not telling anyone?)

[uwog]

Fixed; Will be in Write-51.