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 14 Oct 2010 10:58:31 PM UTC  
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 04 Jan 2013 08:50:44 PM UTC, 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 01 Dec 2012 07:00:55 AM UTC, 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 27 Nov 2012 01:32:06 PM UTC, 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 03 Oct 2011 09:11:40 AM UTC, 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 03 Oct 2011 08:51:55 AM UTC, 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 27 Aug 2011 01:08:39 AM UTC, 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 22 Aug 2011 07:13:18 PM UTC, 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 04 Aug 2011 02:17:36 PM UTC, 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 31 Jul 2011 02:26:42 PM UTC, 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 31 Jul 2011 02:09:01 PM UTC, 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 28 Jul 2011 12:09:03 AM UTC, 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 23 Feb 2011 11:17:36 PM UTC, 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 14 Oct 2010 11:00:39 PM UTC, 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 14 Oct 2010 10:58:31 PM UTC, 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 04 Jan 2013 08:50:44 PM UTCjonnorOpen/ClosedOpen=>Closed
    Tue 27 Nov 2012 01:32:06 PM UTCachadwickStatusIn Progress=>Ready For Test
    Sat 27 Aug 2011 01:08:39 AM UTCachadwickStatusWish=>In Progress
    Mon 22 Aug 2011 07:13:18 PM UTCachadwickAssigned toNone=>achadwick
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup