Re: [Mypaint-discuss] Major-ish UI updates pending: tabbed-workspace branch
In these days I've used this UI on my habitual workflow, the float tabs are very interesting, in some cases, when you combine them to compound a dock a bit more complex... I think that my question is planned in the future of new UI: the show/hide of tabs on dock mantains always the same origin on dock created. ... J. Americo Gobbo [Painter and Illustrator] Website http://americogobbo.com.br | Bloghttp://americogobbo.blogspot.com| Flickr http://flickr.com/rabisco | Twitter http://twitter.com/rabisco | Facebook http://www.facebook.com/americogobbo On Thu, Sep 5, 2013 at 12:13 PM, José Américo Gobbo jag.rabi...@gmail.comwrote: Hi Andrew, I've been testing the new improvements in the UI, mainly the dockable of set brushes. For me is very useful to have yet the old options for setting the brushes. A good enhancement would be to have the possibility to compose this options on the slide, but I don't have idea if it is easy or complex. Thanks, americo ... J. Americo Gobbo [Painter and Illustrator] Website http://americogobbo.com.br | Bloghttp://americogobbo.blogspot.com| Flickr http://flickr.com/rabisco | Twitter http://twitter.com/rabisco| Facebook http://www.facebook.com/americogobbo On Sun, Jul 21, 2013 at 1:14 PM, Andrew Chadwick a.t.chadw...@gmail.comwrote: On 21 July 2013 00:00, Bol Bib bolle...@hotmail.com wrote: h,I'm loving the look of that. and if the autohide experience is good this will be just gravy. about the footer bar,maybe it should fade out or something? and only be at 10% opacity or something so it won't be in your way? or does it already autohide? It's already an auto-hide widget. Without going into technicalities, the top, bottom, and sidebars are just displayed alongside the central canvas, so opacity can't be used here. I fixed up the old code which keeps the canvas steady when the left or top bars hide, so you don't get the huge distraction of the canvas moving position on screen when the automated hide event happens. It had broken under GTK3 due to some internal changes in the way offsets are calculated. drawing at any border of a screen is usually very iffy anyway,but I do like having my vertical space without much visual obstructions Sure; they should all get out of the way sensibly. one thing I cannot see. Is there a way to prevent one or the other docker from hiding? You can turn off autohide globally, and when drawing with the pen down autohide doesn't happen. a button or a keyboard stroke? cause I feel that autohide is good,but sometimes you do need only one open for a longer time. how does that work? Tab shows and hides the UI still, but differently. It toggles whether autohide is enabled, and when you turn it off, all the UI reappears. Turning it on makes it all go away. I'm trying to figure out whether/how different bits of the UI could be turned off permanently. I'm considering * View --- * View Fullscreen [F11] * View [y/n] Auto-hide in Fullscreen [Tab] * View Auto-hide [y/n] Sidebars * View Auto-hide [y/n] Floating Windows * View Auto-hide [y/n] Footer Bar * View Auto-hide [y/n] Menu and Toolbar * View --- * View Layout [y/n] Menu and Toolbar * View Layout [y/n] Footer Bar * View --- The sidebars and floating windows are really fundamental to the way brush palettes and colour choosers are presented, so they can't just be turned off (besides, if you don't want one of these tool tabs it can just be closed individually). But with those options maybe things will be more stable. -- Andrew Chadwick ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Major-ish UI updates pending: tabbed-workspace branch
I think I understand - do you mean that if you repeatedly show and hide the Layers panel with L (for example), it should always go back to its previous group? That's fairly easily achievable, but restoring the tab to the same location within its previous set of tabs would be more difficult to implement. The default algorithm is designed to favour existing floating windows over sidebars, and spread new panels out as much as possible so that more are shown side by side. However it doesn't attempt to group similar kinds of panel together so that, e.g. all the brush selectors go in one group (when there's space). Would that be an improvement? On 3 October 2013 13:57, José Américo Gobbo jag.rabi...@gmail.com wrote: In these days I've used this UI on my habitual workflow, the float tabs are very interesting, in some cases, when you combine them to compound a dock a bit more complex... I think that my question is planned in the future of new UI: the show/hide of tabs on dock mantains always the same origin on dock created. ... J. Americo Gobbo [Painter and Illustrator] Website | Blog | Flickr | Twitter | Facebook On Thu, Sep 5, 2013 at 12:13 PM, José Américo Gobbo jag.rabi...@gmail.com wrote: Hi Andrew, I've been testing the new improvements in the UI, mainly the dockable of set brushes. For me is very useful to have yet the old options for setting the brushes. A good enhancement would be to have the possibility to compose this options on the slide, but I don't have idea if it is easy or complex. Thanks, americo ... J. Americo Gobbo [Painter and Illustrator] Website | Blog | Flickr | Twitter | Facebook On Sun, Jul 21, 2013 at 1:14 PM, Andrew Chadwick a.t.chadw...@gmail.com wrote: On 21 July 2013 00:00, Bol Bib bolle...@hotmail.com wrote: h,I'm loving the look of that. and if the autohide experience is good this will be just gravy. about the footer bar,maybe it should fade out or something? and only be at 10% opacity or something so it won't be in your way? or does it already autohide? It's already an auto-hide widget. Without going into technicalities, the top, bottom, and sidebars are just displayed alongside the central canvas, so opacity can't be used here. I fixed up the old code which keeps the canvas steady when the left or top bars hide, so you don't get the huge distraction of the canvas moving position on screen when the automated hide event happens. It had broken under GTK3 due to some internal changes in the way offsets are calculated. drawing at any border of a screen is usually very iffy anyway,but I do like having my vertical space without much visual obstructions Sure; they should all get out of the way sensibly. one thing I cannot see. Is there a way to prevent one or the other docker from hiding? You can turn off autohide globally, and when drawing with the pen down autohide doesn't happen. a button or a keyboard stroke? cause I feel that autohide is good,but sometimes you do need only one open for a longer time. how does that work? Tab shows and hides the UI still, but differently. It toggles whether autohide is enabled, and when you turn it off, all the UI reappears. Turning it on makes it all go away. I'm trying to figure out whether/how different bits of the UI could be turned off permanently. I'm considering * View --- * View Fullscreen [F11] * View [y/n] Auto-hide in Fullscreen [Tab] * View Auto-hide [y/n] Sidebars * View Auto-hide [y/n] Floating Windows * View Auto-hide [y/n] Footer Bar * View Auto-hide [y/n] Menu and Toolbar * View --- * View Layout [y/n] Menu and Toolbar * View Layout [y/n] Footer Bar * View --- The sidebars and floating windows are really fundamental to the way brush palettes and colour choosers are presented, so they can't just be turned off (besides, if you don't want one of these tool tabs it can just be closed individually). But with those options maybe things will be more stable. -- Andrew Chadwick ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss -- Andrew Chadwick ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Major-ish UI updates pending: tabbed-workspace branch
On 21 July 2013 00:00, Bol Bib bolle...@hotmail.com wrote: h,I'm loving the look of that. and if the autohide experience is good this will be just gravy. about the footer bar,maybe it should fade out or something? and only be at 10% opacity or something so it won't be in your way? or does it already autohide? It's already an auto-hide widget. Without going into technicalities, the top, bottom, and sidebars are just displayed alongside the central canvas, so opacity can't be used here. I fixed up the old code which keeps the canvas steady when the left or top bars hide, so you don't get the huge distraction of the canvas moving position on screen when the automated hide event happens. It had broken under GTK3 due to some internal changes in the way offsets are calculated. drawing at any border of a screen is usually very iffy anyway,but I do like having my vertical space without much visual obstructions Sure; they should all get out of the way sensibly. one thing I cannot see. Is there a way to prevent one or the other docker from hiding? You can turn off autohide globally, and when drawing with the pen down autohide doesn't happen. a button or a keyboard stroke? cause I feel that autohide is good,but sometimes you do need only one open for a longer time. how does that work? Tab shows and hides the UI still, but differently. It toggles whether autohide is enabled, and when you turn it off, all the UI reappears. Turning it on makes it all go away. I'm trying to figure out whether/how different bits of the UI could be turned off permanently. I'm considering * View --- * View Fullscreen [F11] * View [y/n] Auto-hide in Fullscreen [Tab] * View Auto-hide [y/n] Sidebars * View Auto-hide [y/n] Floating Windows * View Auto-hide [y/n] Footer Bar * View Auto-hide [y/n] Menu and Toolbar * View --- * View Layout [y/n] Menu and Toolbar * View Layout [y/n] Footer Bar * View --- The sidebars and floating windows are really fundamental to the way brush palettes and colour choosers are presented, so they can't just be turned off (besides, if you don't want one of these tool tabs it can just be closed individually). But with those options maybe things will be more stable. -- Andrew Chadwick ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Major-ish UI updates pending: tabbed-workspace branch
h,I'm loving the look of that. and if the autohide experience is good this will be just gravy. about the footer bar,maybe it should fade out or something? and only be at 10% opacity or something so it won't be in your way? or does it already autohide? drawing at any border of a screen is usually very iffy anyway,but I do like having my vertical space without much visual obstructions one thing I cannot see. Is there a way to prevent one or the other docker from hiding? a button or a keyboard stroke? cause I feel that autohide is good,but sometimes you do need only one open for a longer time. how does that work? Kind regards Date: Wed, 17 Jul 2013 22:28:50 +0200 From: davidre...@gmail.com To: a.t.chadw...@gmail.com CC: mypaint-discuss@gna.org Subject: Re: [Mypaint-discuss] Major-ish UI updates pending: tabbed-workspace branch @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 a.t.chadw...@gmail.com wrote: On 12 July 2013 11:14, Jon Nordby jono...@gmail.com wrote: On 11 July 2013 22:32, Andrew Chadwick a.t.chadw...@gmail.com 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
Re: [Mypaint-discuss] Major-ish UI updates pending: tabbed-workspace branch
On 11 July 2013 22:32, Andrew Chadwick a.t.chadw...@gmail.com wrote: Hi all -- 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) * Dockable interface using standard GtkNotebook behaviour. Closer to GIMP's look. * 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? Also, regarding push on screen edge: wouldnt it be more interesting to use this for moving the canvas? * Tab now toggles auto-hide. It's a little crude, but it works: might need to be more customizable. * Reworks of (some) publish/subscribe interfaces. More syntax sugar, and lets both observed and observer objects die naturally (theoretically at least; PyGI/GObject doesn't in many cases) * 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. 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. * Dockable tool widgets/panels/subwindows/bleh are registered the way Martin wanted, via an API call (namely setting __gtype_name__ in some future plugin's class definitions, but hey: it's an API call and it's a start). There's nothing written yet for register a new dockable in such-and-such a category. * Don't load all the backgrounds at startup. Also exists in master since a week or two, be aware when merging. * Generally defer loading of dialog-type subwindows wherever we can. * Quite a few drag/drop fixes and other GTK3 niceties. * Additional sidebar on the left. More potential panels means more space, although tabs make space usage more efficient generally. * 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 so 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) -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Major-ish UI updates pending: tabbed-workspace branch
Hi all -- 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... * Dockable interface using standard GtkNotebook behaviour. Closer to GIMP's look. * 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. * Tab now toggles auto-hide. It's a little crude, but it works: might need to be more customizable. * Reworks of (some) publish/subscribe interfaces. More syntax sugar, and lets both observed and observer objects die naturally (theoretically at least; PyGI/GObject doesn't in many cases) * 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? * Dockable tool widgets/panels/subwindows/bleh are registered the way Martin wanted, via an API call (namely setting __gtype_name__ in some future plugin's class definitions, but hey: it's an API call and it's a start). There's nothing written yet for register a new dockable in such-and-such a category. * Don't load all the backgrounds at startup. * Generally defer loading of dialog-type subwindows wherever we can. * Quite a few drag/drop fixes and other GTK3 niceties. * Additional sidebar on the left. More potential panels means more space, although tabs make space usage more efficient generally. * 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 so something similar for brushes in the right+bottom corner. One regression right now: there's no dockable foldout for common brush settings any more. I'd like to add that back in as a sort of relevant options for the current mode panel, similar to the way the GIMP works. It's approaching a fairly stable state now, so I'd like to merge it within the next week if possible. -- Andrew Chadwick ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Major-ish UI updates pending: tabbed-workspace branch
Hi Andrew, well, for me the tarball that is generated has an error when I try unpacking. thanks americo ... J. Americo Gobbo [Painter and Illustrator] Website http://americogobbo.com.br | Bloghttp://americogobbo.blogspot.com| Flickr http://flickr.com/rabisco | Twitter http://twitter.com/rabisco | Facebook http://www.facebook.com/americogobbo On Thu, Jul 11, 2013 at 5:32 PM, Andrew Chadwick a.t.chadw...@gmail.comwrote: Hi all -- 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... * Dockable interface using standard GtkNotebook behaviour. Closer to GIMP's look. * 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. * Tab now toggles auto-hide. It's a little crude, but it works: might need to be more customizable. * Reworks of (some) publish/subscribe interfaces. More syntax sugar, and lets both observed and observer objects die naturally (theoretically at least; PyGI/GObject doesn't in many cases) * 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? * Dockable tool widgets/panels/subwindows/bleh are registered the way Martin wanted, via an API call (namely setting __gtype_name__ in some future plugin's class definitions, but hey: it's an API call and it's a start). There's nothing written yet for register a new dockable in such-and-such a category. * Don't load all the backgrounds at startup. * Generally defer loading of dialog-type subwindows wherever we can. * Quite a few drag/drop fixes and other GTK3 niceties. * Additional sidebar on the left. More potential panels means more space, although tabs make space usage more efficient generally. * 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 so something similar for brushes in the right+bottom corner. One regression right now: there's no dockable foldout for common brush settings any more. I'd like to add that back in as a sort of relevant options for the current mode panel, similar to the way the GIMP works. It's approaching a fairly stable state now, so I'd like to merge it within the next week if possible. -- Andrew Chadwick ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
