Frame re-enabling at load time: buggy and inconsistent #18

Closed
achadwick opened this Issue Jun 24, 2014 · 2 comments

Comments

Projects
None yet
2 participants
@achadwick
Member

achadwick commented Jun 24, 2014

Migrated from Gna! bug 20926 because the underlying issue is not really fixed, to my eyes. The original report was basically just a request for the frame to be enabled at load time, which is done but is somewhat inconsistent.

  • Loading an ORA file updates the frame to the dimensions in the element, but supposedly only enables the frame if its dimensions are something other than the data bounding box's.

    The goal of this silly criterion is that if the user turned off the frame to get an "infinite canvas", that choice should be preserved. However all OpenRaster files must have a top level pixel width and height, and for MyPaint "infinite canvas"es, this width and height are that of the data bounding box. Trying to infer it is fairly nasty and magical. Really the XML should use a mypaint_frame="enabled" field somewhere (or better still its namespaced equivalent).

    • In practice though, the frame is never enabled though on a command line load regardless of its enabled state and size before saving. Oops.
    • Immediately pressing F5 (File → Revert) to reload the same file results in the frame being shown IF the silly criteria above apply.
    • Loading MyPaint without a command-line file then loading an OpenRaster file (for which the silly criteria apply) results in the frame being enabled.
  • Loading a PNG or a JPEG file always updates the frame to the correct dimensions (those of the loaded file), but always disables the frame. To be honest, I'm not sure whether this is the right behaviour or not.

@achadwick achadwick added this to the MyPaint 1.2 milestone Jun 24, 2014

@achadwick achadwick added bug labels Jun 24, 2014

@achadwick achadwick removed the ux label Jul 9, 2014

@iirelu iirelu added the ux label Nov 27, 2014

@achadwick achadwick added the bitesize label Apr 20, 2015

@achadwick achadwick modified the milestones: MyPaint 1.2.0-alpha, MyPaint 1.2.0 Apr 20, 2015

@achadwick

This comment has been minimized.

Show comment
Hide comment
@achadwick

achadwick Apr 20, 2015

Member

New feature, and probably something simple. Moving to the 1.2.0-alpha milestone.

Member

achadwick commented Apr 20, 2015

New feature, and probably something simple. Moving to the 1.2.0-alpha milestone.

@achadwick achadwick self-assigned this Jul 1, 2015

@achadwick achadwick removed the bitesize label Jul 1, 2015

@achadwick

This comment has been minimized.

Show comment
Hide comment
@achadwick

achadwick Jul 1, 2015

Member

Choosing a namespace is perhaps not bitesize.

I'm going to use http://mypaint.org/ns/openraster for MyPaint-specific extension attrs and elements used in OpenRaster documents. It's not a resource that exists right now, but that can change.

Member

achadwick commented Jul 1, 2015

Choosing a namespace is perhaps not bitesize.

I'm going to use http://mypaint.org/ns/openraster for MyPaint-specific extension attrs and elements used in OpenRaster documents. It's not a resource that exists right now, but that can change.

achadwick added a commit that referenced this issue Jul 2, 2015

Add namespace for MyPaint's OpenRaster extensions
MyPaint needs to store a number of additional fields in OpenRaster files
for its own benefit. The natural way of doing this in XML is to use a
namespace, so I've picked "http://mypaint.org/ns/openraster" - which isn't
an addressable resource yet, but it a) doesn't have to be, and b) could be
one day if it's useful to have something there.

Okay, OpenRaster doesn't even have its own xmlns yet, but no reason not to
be ahead of the curve.

Addresses mypaint/mypaint#18.

@achadwick achadwick closed this in 513e9e2 Jul 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment