Ticket #4022 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

write should not change the format of an opened journal entry

Reported by: walter Owned by: uwog
Priority: high Milestone: Update.1
Component: write-activity (abiword) Version:
Keywords: Cc: erikos, walter
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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.

Change History

Changed 7 years ago by jg

  • milestone changed from Never Assigned to First Deployment, V1.0

Changed 7 years ago by erikos

  • owner changed from marco to erikos

Changed 7 years ago by erikos

  • owner changed from erikos to walter

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?

Changed 7 years ago by 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

Changed 7 years ago by 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.

Changed 7 years ago by erikos

  • cc uwog added

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.

Changed 6 years ago by marco

  • keywords killjoy? added

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

Changed 6 years ago by marco

  • keywords killjoy? removed

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

Changed 6 years ago by 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.

Changed 6 years ago by walter

  • cc walter added
  • milestone changed from V1.1 to Update1

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.

Changed 6 years ago by 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.

Changed 6 years ago by marco

  • owner changed from walter to erikos

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?

Changed 6 years ago by erikos

  • cc erikos added; uwog removed
  • owner changed from erikos to uwog
  • component changed from browse-activity to write-activity (abiword)
  • summary changed from browser cannot open files generated by view source to write should not change the format of an opened journal entry

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.

Changed 6 years ago by 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.

Changed 6 years ago by 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).

Changed 6 years ago by 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?)

Changed 6 years ago by uwog

  • status changed from new to closed
  • resolution set to fixed

Fixed; Will be in Write-51.

Note: See TracTickets for help on using tickets.