@A.Chadwick : I tested your WIP branch : I played a lot with dockers ..ermm ... too much , overkill screenshot incoming : http://i.imgur.com/qJb7gX7.jpg
Pros : Docking on the left and splitting the palette docker from the color selector. Simplicity of brush preset. Cons : Bottom footer bar : I don't like having less workspace vertically in general , no revelant info into it at the moment in my taste, but it's "work in progress" and I trust what you can do with it. For sure I would love here brush size, opacity , and some easy button lost on the Brush Preset panel. Cool work ! On Fri, Jul 12, 2013 at 11:24 PM, Andrew Chadwick <[email protected]>wrote: > On 12 July 2013 11:14, Jon Nordby <[email protected]> wrote: > > On 11 July 2013 22:32, Andrew Chadwick <[email protected]> wrote: > >> I've been working on some UI stuff recently: just pushed a preview to > >> > >> > https://gitorious.org/~achadwick/mypaint/achadwick-mypaint/commits/tabbed-workspace > >> for testing. It's quite involved, so I don't want to merge it just yet > >> if folks are doing performance tweaks in master... > > > > Probably there are not much changes in lib/, right? In that case I dont > > think there is any conflict with the work I have ongoing. > > But please do check that the changes do not introduce performance > > regressions (by running tests/test_performance.py -a before and after) > > Will do. The publish/subscribe tweaks live there, and one day the > palette and color model classes should go there. > > >> * Fullscreen management has changed. Sidebars, top and bottom bars, > >> and floating windows containing dockable panels now auto-hide with a > >> delay, and also auto-reveal when you mouseover or push a screen edge. > > > > auto-show and auto-hide is very tricky to get right, are you sure you > want > > this to be default? > > It already is (in fullscreen). The difference is that at present > nothing auto-shows when you waft in its direction. > > Getting it right will be tricky. Everybody seems to have a different > idea of the right way to do it if you ask. I've focussed on canvas > position stability, and stability of auto-shown UI bits while you're > interacting with it. Trying to reduce the number of disconnects when > in flow. > > > Also, regarding push on screen edge: wouldnt it be more interesting to > use > > this for moving the canvas? > > Not really, in my view. There's no velocity component in the direction > you bump after an edge is bumped, so it seems a little more natural to > reveal stuff. I'm also loath to move the canvas when a user is pretty > much *not* interacting with it :) > > >> * Tab now toggles auto-hide. It's a little crude, but it works: might > >> need to be more customizable. > > I think the weirdest thing is rollover for hidden floating windows. > This seems much odder to me than bumping a sidebar edge to show a > sidebar, so perhaps it deserves a "Don't automatically hide floating > windows" option. > > Edge bumping is used in a lot of media players, for unfullscreen > buttons and for the playback position bar. I'm hoping the analogy will > be obvious. > > (Bumps of course only happen when pointer buttons are not help down to > allow pen-on-canvas painting to go off the edge and return without > interruptions) > > >> * Fairly major refits of the way palettes and brush groups work. Big > >> parallels going on here in terms of concept and appearance: something > >> for a future refactor? > > > > I think brushes and backgrounds are even more similar, so a future > > rethinking of the way this works. > > [... should also consider that usecase.] > > They already share a base class and a lot of "show a bunch of pixbufs > in a flowed grid" behaviour. The palette adds that approximate > matching thing, so there's always a highlight rectangle pointing at > "the current colour" even when that's only an approximate match. That > might be nifty to do for brushes: they only add 20 or 30 more > dimensions for the match (ideas for weighting welcome!) > > Unifying the way they all render would be a nice touch of consistency. One > day. > > > Also, I am thinking more and more that the generic approach we take to > brush > > group management is not ideal. I suspect we would be better of with just > > letting users "favorite" brushes easily, and that this would make them > > available in a "favorites" / "my brushes" tab/whatever in the UI. Should > be > > possible to export/share this group, of course. > > Yeah, I really like the keep-it-simple approach you describe. Right > button menu on anything showing a brush icon for "edit this brush" and > "add to favourites"? > > Apropos of that, copying a brush for editing separately now opens out > a brush group named _("new") and puts the brush there, which seems > cleaner to me than putting it where it came from with the same icon. > "Add to favourites" should do that, albeit just listing the same brush > twice rather than copying. And to _("favorites"). > > I think it seems cleaner because I'm still visualizing brush groups as > carefully curated and artfully made collections that should be Kept > Intact, rather than as big grotty jars you can stuff brushes in, any > way you like. Question is - what's right for artists, and does the jam > jar full of brushes analogy really hold? > > >> * Don't load all the backgrounds at startup. > > > > Also exists in master since a week or two, be aware when merging. > > Yep, saw that recently :) It should be rebased neatly on top of it, > but it won't harm to double check. > > >> * Footer bar showing the current mode and what pressing modifiers and > >> pointer buttons will do, like Inkscape. Left+bottom corner gets the > >> common colour controls; might [d]o something similar for brushes in the > >> right+bottom corner. > > > > Is the footer on-canvas or a separate widget? (sorry for not just > checking > > myself, no buildenv on this machine) > > Separate HBox. The UI down there is arranged using glade. > > -- > Andrew Chadwick > > _______________________________________________ > Mypaint-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/mypaint-discuss >
_______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
