<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">This is already hijacking the initial
      thread. I won't go on here after this message.<br>
      <br>
      Le 06/12/2019 à 11:17, Antoine Monmayrant a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:37b63e4f-c8b3-c788-5f1c-4b900efdc30f@laas.fr">
      <br>
      Le 06/12/2019 à 08:41, Stéphane Mottelet a écrit :
      <br>
      <blockquote type="cite">Please think about the future of Scilab,
        not always its past. </blockquote>
    </blockquote>
    <br>
    <p>For my part, i think about future, taking into account the
      present.<br>
      And the past is also interesting to learn from past successes, and
      failures.</p>
    <br>
    <blockquote type="cite"
      cite="mid:37b63e4f-c8b3-c788-5f1c-4b900efdc30f@laas.fr">
      <br>
      <br>
      I do agree with you.
      <br>
      I mentioned in the past that the default colormap was so ugly it
      should be considered a bug (
      <a class="moz-txt-link-freetext" href="http://bugzilla.scilab.org/show_bug.cgi?id=11054">http://bugzilla.scilab.org/show_bug.cgi?id=11054</a> ).
      <br>
      <br>
    </blockquote>
    <p>The problem was and is not that the default colormap is ugly, but
      that it holds for the whole figure, instead of per axes.</p>
    <blockquote type="cite">I proposed changing the default colormap to
      something sensible and also proposed adding decent replacement to
      the abomination that is jetcolormap.
      <br>
      <p></p>
    </blockquote>
    <br>
    <p>jetcolormap() is jetcolormap(), and is used as a jetcolormap
      swatch in many other softwares, noticeably thermal imaging ones.<br>
      It is one very standard colormap among other ones. I don't see the
      point about any abomination.<br>
      <br>
    </p>
    <blockquote type="cite"
      cite="mid:37b63e4f-c8b3-c788-5f1c-4b900efdc30f@laas.fr">The answer
      was: "but we can't: backward compatibility".
      <br>
      <br>
      I think scilab is one of the only plotting soft that is still
      using horrible defaults (matlab, python.matplotib, ... all have
      evolved and changed to reasonable defaults).
      <br>
    </blockquote>
    <p><br>
      This is why i am wondering why my <a moz-do-not-send="true"
href="http://mailinglists.scilab.org/Scilab-users-A-new-smarter-default-grid-style-for-Scilab-6-1-0-SEP-tt4037595.html">open
        post about changing the default grid style in axes</a> has
      received strictly no answer, noticably from futurologists. Is it
      OK with the current defaults? Not for me.<br>
      Was it OK with the <a moz-do-not-send="true"
        href="https://help.scilab.org/docs/6.0.1/en_US/bode.html">default
        ticks and grid style of bode() up to 6.0.1</a>? Not for me. This
      is why changing them <a moz-do-not-send="true"
        href="https://codereview.scilab.org/#/c/20634/">was proposed</a>
      and <a moz-do-not-send="true"
        href="https://help.scilab.org/docs/6.0.2/en_US/bode.html">accepted
        in 6.0.2</a>.<br>
      Etc, etc etc.</p>
    <p>There were actually extremely conservative positions or
      actions/inactions about some cases -- i am wondering for instance
      about the disp() inversion --, hardly believable, because almost
      or definitely without rationale. And we can hope that, for this
      case, it will be corrected soon.<br>
      <br>
      But these extreme cases -- that are even hard to consider as naive
      -- do no allow any extreme positions in the opposite, whose main
      processing could aim to avoid providing rationale as well, in the
      pretendly opposite direction but for the same reason: it's
      shorter, and at first sight, it looks easier.</p>
    <p>Regards<br>
      Samuel</p>
    <p><br>
    </p>
  </body>
</html>