bugMyPaint - Bugs: bug #16869, [Usability] Make UI usable with...

Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #16869: [Usability] Make UI usable with Tablet PC

Submitted by:  Jon Nordby <jonnor>
Submitted on:  Thu Oct 14 22:58:31 2010  
Severity: 3 - NormalPriority: 5 - Normal
Status: Ready For TestPrivacy: Public
Assigned to: Andrew Chadwick <achadwick>Open/Closed: Closed
Release: Planned Release: None
Operating System: 

(Jump to the original submission Jump to the original submission)

Fri Jan 4 20:50:44 2013, comment #13:

This bug has been closed because it is marked ready-for-test and
no further comments have been added in a long while. Since we
have not heard otherwise, we assume that the fixes works as intended.

If there are problems with the implemented functionality, please
file a new issue.

Jon Nordby <jonnor>
Project Administrator
Sat Dec 1 07:00:55 2012, comment #12:

I'm sorry. I completely forgot about my bug post here. I would have paid more attention if I had remembered this and known it was being worked on. Thanks for all the work you guys have been doing. I'll try to build the commit and test it out some.

Demented <dementedsnake>
Tue Nov 27 13:32:06 2012, comment #11:

Jon, Demented: can you test https://gitorious.org/mypaint/mypaint/commit/34cca9ae2c47b2eecb45c2df75af07ecddb56f16 please, and let me know whether the toolbar buttons make "intuitive sense" now? The commit above addresses the following buttons:

- Layer move (little blue layers stack with one pushed over to the side)
- Canvas pan, tilt/rotate and zoom (green viewfinders with various symbols in them)

but I want to be sure that all the main buttons work right with a tablet pen, including the geometric "line mode" buttons. If it does, and every action can be triggered sanely on a tablet - even if you have to do a little configuration first - let's close this bug. Please test!

Additionally there's been some significant refactoring in the button bindings part of the prefs dialog. I don't know what buttons to expect on a tablet, but if there's >3 you can now bind them to various actions.

(Jonnor: only if you managed to get your hands on the relevant hardware, of course ☺)

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Mon Oct 3 09:11:40 2011, comment #10:

I get what you're saying; sounds like a spring-loaded mode or "quasimode" (http://www.useit.com/alertbox/springload.html), and it's something I want to get done as part of bug #18574 when I have the time to refactor the stategroup code.

Save with increment: under discussion: see bug #18720, and it's better that you follow up there re. the naming discussion. I guess it'd smooth the workflow for everyone, not having to open save dialogs and find a keyboard (even a soft keyboard).

But yes. Next priority for me is that modes/states refactor, I think.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Mon Oct 3 08:51:55 2011, comment #9:

This may only be a short-term workaround, but would adding two buttons to the toolbar to emulate Shift and Ctrl work? It wouldn't be perfect, but you could click one of the buttons, and it'd send the signal to tell MyPaint that button was being held down. Then you use it in junction with a mouse button, and after you release the mouse button (i.e. finish the trigger), the Shift/Ctrl button turns itself off again.

It should be possible to operate the "mouse button + shift/ctrl key" functions semi-normally, though it would be more time consuming. But like I said, it'd be a workaround at best, until a better solution is devised.

Unlike jonnor, I -am- using MyPaint on a slate. Surprisingly, with very little trouble. But a few options towards making it easy to run the program "mouse only" (excluding file naming) would be nice.

... Actually, about file naming. The "Save as Scrap" function already does this... Would it be possible to add a "Save as/with Increment" that automatically makes a new save file based on the last one?

You open "Tree001_001.ora" and "Save with Increment" will automatically save the new file as "Tree001_002.ora". No keyboard required. That would certainly be a help to tablet/slate users.

Maybe a small text bow in the Saving tab of the Properties window could allow us to set our own naming convention. %n%M_%m.ora would save things with a (n)ame, (M)ajor version number, _, and a (m)inor version number. Others could be (t)ime, (T)ime including date, etc.. It would default naming new unnamed images to something like "untitledwork" with maybe a date. plus the user-specified extras.

Sorry, went on a bit of a ramble there. Hope some of that was at least mildly helpful.

Demented <dementedsnake>
Sat Aug 27 01:08:39 2011, comment #8:

http://gitorious.org/mypaint/mypaint/commit/b8c2b6334cd9 and its parent put colour and brush choice and history on the toolbar as well. Blend modes are now accessible via the brush dropdown, since they're rather obscure and potentially confusing features.

Bug #18574 details how picker modes might evolve into something we can enter via a clickable bit of the UI. Currently they're key or pointer button only affairs; you can't enter them from the menu. Not sure it's a blocker of this one though. Maybe.

Related design thread in the forums at http://forum.intilinux.com/mypaint-development-and-suggestions/top-panel-dockables/

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Mon Aug 22 19:13:18 2011, comment #7:

Well, I gave putting the menu on the toolbar a try, and I'm quite pleased with the result even if it feels like we're aping Office and Firefox: http://gitorious.org/mypaint/mypaint/commit/213c6bea

There's now a menu button in the top left corner that appears if you hide the menubar. Right now it invokes the popup menu without much in the way of adornment or optimizing the menu structure. The menu button should activate if the user clicks on (0, 0) in fullscreen mode when the button's visible, no matter what GTK theme they're using.

Awaiting a request to make it orange... :)

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Thu Aug 4 14:17:36 2011, comment #6:

Merge done recently. Our use of space might be improved if we think hard about what the actual mode-like behaviours of MyPaint are - take a look at https://mail.gna.org/public/mypaint-discuss/2011-08/msg00001.html - and put buttons for those on the toolbar. They are of course nothing to do with Eraser Mode or Lock Alpha.

Menu on the toolbar is not particularly HIG-like, and is likely to look fairly horrible in certain themes unless we do it carefully. But it might be possible to do what new Firefoxes do and put the menu on the toolbar if the menu bar is hidden (I'd want the top left pixel to hit the menu in fullscreen mode if we do that and the menu is turned on in fullscreen).

We could do with one less colour selector button, which probably means some more consolidation and rethought of the selectors. Some other time though.

At default startup, I think the toolbar and the menu should be visible so that the user doesn't have to turn them on. There should also be a colour chooser (doesn't matter which one, and it doesn't even have to be a floating window panel thingy: a colour swatch on the toolbar with a popup palette might be enough), and a brush chooser (same deal). That too is fairly stripped down: does that seem like a good idea?

If you want to go the route of colour and brush buttons/menus/whatever on the toolbar and no floaty-docky-panels on by default, what about integrating the colour usage history and adding a similar brush usage history alongside them?

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Sun Jul 31 14:26:42 2011, comment #5:

Btw. would it anything close to HIG conform if the main menu was only accessible through the toolbar, instead of a menu bar?

Martin Renold <martinxyz>
Project Administrator
Sun Jul 31 14:09:01 2011, comment #4:

I have commented at the merge request; I think the branch should be merged.

I bring up at this bugreport my only real concern with the toolbar branch: I think MyPaint now has too much GUI visible by default.

After the first startup, the MyPaint GUI should tell the user "choose a brush, here are some colors, start to paint", and not make the user try to understand what this "lock_alpha" mode is about, or toggle through all possible tool windows to find out what the button icons mean. I think there are a bit too many ways (with respect to "buttons visible by default") to manage tool windows now.

Martin Renold <martinxyz>
Project Administrator
Thu Jul 28 00:09:03 2011, comment #3:

I've been fiddling with https://gitorious.org/~achadwick/mypaint/achadwick-mypaint/commits/toolbar recently: it adds a toolbar for some commonly-used view and brush manipulations, plus some basic save and load functionality, tool dialog toggle buttons, and undo/redo. Additionally you can optionally leave the entire UI onscreen now when entering fullscreen mode. Might solve part of the problem :) There's a merge request at https://gitorious.org/mypaint/mypaint/merge_requests/6 for it. Hopefully it's not too messy to apply.

We'd still need to address the fact that certain stategroup.States can't be invoked using buttons or menus yet. Ideally I'd like Pick Colour, Layer and Context to have buttons too, and a way of getting out of fullscreen mode with no input available other than a single pointer button before we can consider this closed :)

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Wed Feb 23 23:17:36 2011, comment #2:

The dockable-panels* branches I'm currently working on add a (currently unused) slot for a toolbar. Might that be a good place to add things like save/load/scrap, mirror and zoom, visibility/hiding of individual subwindows, and maybe even some brushkey buttons in a sub-panel. Maybe some icons for the brush/color menu single-key changers too, if there's room.

Maybe take a hint from Inkscape's calligraphy toolbar for some of the stuff currently on the foldout in the Brush Selection window.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Thu Oct 14 23:00:39 2010, comment #1:

I might target this for 1.0, if I can get my hands on the appropriate hardware.

Jon Nordby <jonnor>
Project Administrator
Thu Oct 14 22:58:31 2010, original submission:

By tablet PC I of course mean the convertible laptops type, not a slate.

A major item here is not requiring so much keyboard input as tablet users typically have access to very few or no buttons in addition to what is on the stylus.

There are several pages with ideas and mock-ups in the wiki about this.

Jon Nordby <jonnor>
Project Administrator


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by dementedsnake (Posted a comment)
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by achadwick (Posted a comment)
  • -unavailable- added by jonnor (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri Jan 4 20:50:44 2013jonnorOpen/ClosedOpen=>Closed
    Tue Nov 27 13:32:06 2012achadwickStatusIn Progress=>Ready For Test
    Sat Aug 27 01:08:39 2011achadwickStatusWish=>In Progress
    Mon Aug 22 19:13:18 2011achadwickAssigned toNone=>achadwick
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup