On Thu, Jul 21, 2011 at 12:22 AM, Andrew Chadwick <[email protected]>wrote:
> I'm twiddling away on an unofficial branch of MyPaint which splits the > view of the single working document into multiple viewports, in a > split-screen manner: > > Needless to say, as a pixel artist, I approve of this ;) > - > > http://gitorious.org/~achadwick/mypaint/achadwick-mypaint/commits/split-view > - http://en.wikipedia.org/wiki/Split_screen_%28computer_graphics%29 > > Each split has its own translation, zoom, rotation and mirroring. This > can be used to provide something of a poor man's overview widget, or a > usable mixer palette in a corner of the painting which can be picked > from when working in the opposite corner, or just a pair of zoomed in > and zoomed out views. > Well, I'd recommend GPick as a mixer, personally (RGB mixing is drab). But a palette area, I can see the use of -- I'd use that a LOT. Anyway -- Being able to see a quick flipped/rotated view anytime sounds pretty neat. I'd like to know how this performs.I'll check it out, finally. > > The imagined use case for this is that users like to continue work > immediately where they left off when re-opening a saved work on a later > date, and they won't generally want to have to faff around with windows > and controls each time to get it "right". Therefore, save the division > of space in the split windows and where each viewport points, and > recreate the structure when reloading the document. > > The branch above uses an ugly mypaint-specific bodge to demonstrate one > approach to this. However I'd like to implement this in as > cross-OpenRaster-consumer a fashion as possible and in a way that can be > preserved by other editors even if they choose not to permit the use > case identified above in their UI. Even if their notion of viewport > splitting is radically different from ours, I'd like to share concepts > as much as humanly possible. So can we come up with some common ground > and agree on a common way of storing the data? I'd really likely to boil > things down to their essence before moving this forward for us. > > Based on the example of some tiling WMs (mainly AwesomeWM), I'd like to suggest a model that is table based: * NROWS, NCOLUMNS (1,1 if this is a leaf 'tile') * zoom, pan,rotate, flip parameters (only if this is a leaf tile). Panning position expressed in terms of unzoomed image pixel units (I think. Not sure how this interacts with rotation). * (NCOLUMNS) vertical split positions (reading below, I see we agree -- proportional to overall size.) * (NROWS) horizontal split positions * list of subordinate view IDs (strings), left to right, top to bottom. Give one window the special id 'MAIN' or 'MASTER' (if this data is not available, guess it as the largest tile in the overall layout when loading). Whether the other views are displayed or not, this should be (and its zoom etc settings should be respected as far as possible). This kind of looks like a binary tree anyway :) > > > I can think of some places where MyPaint does things strangely in > general, in all branches: > > - View rotation is a number of radians ranging from 0 to 2*pi. It might be better to express as degrees or a float from 0 to 1. > I think degrees is the best (most 'standard') option. 0..1 is an interesting option, though... I kinda like it. I wonder if it would be confused for radians because of the similar relative scale, though. > > - View mirroring is a concept which may not be used in all other editors. > IMO that's okay. We should store that setting anyway, and other editors should simply remember it when saving if they don't support it themselves. (Also, IME it's almost as useful for photo editing as for drawing.. so not implementing it may be justifiable, but there isn't really a reason to specifically NOT implement it. I don't think it counts as a MyPaint-ism.) > > > Both of these affect the notion of what a view of the document is, but > the split-screen implementation on my branch is somewhat funky too: > > - It's structured as a binary tree dividing space, which is horrible > for other programs which might want to do this as multiple windows but > fast to dump and recreate in terms of two-panel HPaneds and VPaneds. > Leaf nodes are the views themselves. There's no reason this can't be > made into a flat list that's more convenient for other ORA-consumers > though, provided we can store the tree path to each viewport in a path > or name field. > > - Each split is saved along with the position of the divider, expressed > as a proportion of the total width (or height) of the screen. This gains > us some window size-independence. Other implementations may want to save > the sizes of their windows, or even their positions. > > - I use an enforced maximum number of viewports right now. Likely > that's a fairly irrelevant implementation detail. > It sounds like we have similar ideas on how it should be implemented. Something else related: * it occurred to me that people have good reason to want this: Different views having different layer visibility states (being able to check how your work interacts with other layers, even though on your main area you don't want to be troubled by that). Whether MyPaint ends up implementing such a thing or not, we should probably consider this in the data model (I could easily imagine GIMP eventually spitting out such data). The simplest reading policy would just be to take visibility info from the tile classified as MASTER/MAIN. Lastly: * Some policy for dealing with unmanageable layouts is needed. For example,someone spreads their MyPaint window across two displays, and places 8 tiles on the right display (or maybe they have only one display, but excessive resolution/physical size, so they can spam splits); They save a file and send it to you. When this is crammed into your one average-resolution non-widescreen display, the tiles drop below what I'd call reasonable minimum dimensions. We then have to drop some tiles, IMO, to restore sanity. The 'MASTER' tile idea goes some way towards ensuring we don't discard the most important tile. Is there more that could be done here?
_______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
