Linus, Robert described perfectly whats happening, the problem is
only the
dive notes generated by the planner ( it has an HTML table) and saving
that as simples text breaks the format tina completely.
You tell me what to do and I'll do, but for now I dont know what
should I
do to keep the dive planner and the notes correct, if not saving them in
HTML.
Em 20/07/2014 05:10, "Robert Helling" <[email protected]> escreveu:
>
> On 20 Jul 2014, at 08:49, Linus Torvalds
<[email protected]>
> wrote:
>
> Good morning!
>
> > I have no idea where this insanity started, but this is seriously
> > useless and complete crap.
>
> I think I can help with that question. When I redid the “planned
dive to
> notes” to make it include a runtime table I thought about the
“table” part
> of that. In my first version, I had an ascii table which of course
looked
> “complete crap” when presented in a proportional font. Then I tried to
> figure out how to enforce a fixed width font and realised that this
(in
> Qt’s way) would be done by applying a style sheet which would make the
> notes effectively html. But with that, I thought, we can actually
use an
> html table for the table, which it is now. Then somebody took off from
> there and added red color and boldface to the notes generated by the
> planner. So that the notes are now html.
>
> Then somebody complained that after saving and reloading their notes
> displayed html source. And iirc that prompted Tomaz to write the
code that
> you are worried about right now.
>
> I think, what is needed here is an executive decision on what the
notes
> are:
>
> 1) plain text (i.e. no color, boldface and table generated by the
> planner). I must say even though I see the purity argument for that
I don’t
> like this option very much. And we somehow gave up on this when we
gave up
> 7bit ASCII in favour of unicode.
>
> 2) html (as partly generated by Qt) which is the current situation
which
> has the main disadvantage that it looks “complete crap” as soon as
you open
> the .xml or the git file in an editor but is opaque to the user.
>
> 3) have some mild form of mark up/rich text (for table, boldface,
color)
> but only store that part that is absolutely necessary. We could
implement
> that with some intermediate representation (we could store a mildly
marked
> up version of the notes and only display the proper html, so have a
> different internal representation than what we display, as we do
with units
> etc) or we could get rid of all unnecessary html tags when storing
> (possibly with xslt). This option of course would need more coding.
A mild
> version would be to memorise if notes are pure ascii (as entered by
the
> user) or proper html (as generated by the planner) and store and
display
> accordingly.
>
> Unfortunately, we can not go with 2) for the moment and hope to
move to 1)
> or 3) later as then all users files would be “poisoned” by the
> html-garbledigog that we have now.
>
> Best
> Robert
>
> _______________________________________________
> subsurface mailing list
> [email protected]
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
>
----------
_______________________________________________
subsurface mailing list
[email protected]
http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
