Skip to content

Loading…

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

Closed
achadwick opened this Issue · 2 comments

2 participants

@achadwick
MyPaint member

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 <image/> 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
@achadwick achadwick added bug ux labels
@achadwick achadwick removed the ux label
@iirelu iirelu added the UX label
@achadwick achadwick added the bitesize label
@achadwick
MyPaint member

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

@achadwick achadwick self-assigned this
@achadwick achadwick removed the bitesize label
@achadwick
MyPaint 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.

@achadwick achadwick added a commit that referenced this issue
@achadwick achadwick 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.
34da84d
@achadwick achadwick added a commit that closed this issue
@achadwick achadwick OpenRaster: save+load whether the frame is active
Save a custom xsd:bool declaring whether the frame is on or off in an XML
attribute in OpenRaster files and autosave oradirs. It's a distinct
concept from image size, and shouldn't be confused with it.

Update the frame-enabled state from the saved value when loading OpenRaster
files or oradirs files. The default is no frame (infinite canvas).

Closes mypaint/mypaint#18.
513e9e2
@achadwick achadwick closed this in 513e9e2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.