Undo / Redo buttons not in correct order accoring to Gnome HIG

Bug #671467 reported by grofaty on 2010-11-05
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Pinta
Low
Unassigned

Bug Description

I use Gedit and Pinta a lot, but I am always confused where Undo/Redo buttons are. Both programs are using different position for Undu/Redo actions. I have checked Gnome HIG and I see Pinta is not using correct toolbar icons order.

Undo and Redo buttons in toolbar are not in the correct position. Undo and Redo should be after Save button. See attached picture.

See Gnome HIG picture of toolbar: http://library.gnome.org/devel/hig-book/stable/images/toolbars-labels-below.png.en
more about toolbar on Gnome HIG: http://library.gnome.org/devel/hig-book/stable/toolbars-labels-tooltips.html.en

grofaty (grofaty) wrote :
grofaty (grofaty) wrote :

I also thing there should be less space between icons. Compare Gedit and Pinta and you will see there is in Pinta extra space between icons in toolbar. Reduce empty space between icons in toolbar. It will also enable possibility to add extra icons on toolbar when required.

grofaty (grofaty) wrote :

Now I have found out that I can't see all of the icons on toobar on my 1024x768 screen resolution (this is max resolution my notebook is supporting). Please see what I see on my toobar in attached picture.

grofaty (grofaty) wrote :

If I click on maximize button twice to unmaximize Pinta and then on the right sight extend toolbar I can see additional icons - see attached picture.

I think if space between picture is reduced then all of the icons could be displayed on my screen resolution.

Jonathan Pobst (jpobst) wrote :

While I agree there is a ridiculous amount of space on the toolbar, that is theme dependent. I originally set it to a reasonable size toolbar and was asked to change it because it was violating the HIG by not following the user's theme settings. If you compare to Nautilus, you will see that Pinta's toolbar spacing is correct and Gedit has messed with their spacing.

grofaty (grofaty) wrote :

Jonathan, ok leave icon spacing in toolbar like it is now. Just fix the order of Undo/Redo (first post in this thread). Undo and Redo should according to Gnome HiG be after Save and before Cut.

Jonathan Pobst (jpobst) wrote :
Changed in pinta:
importance: Undecided → Low
milestone: none → 0.6
status: New → Fix Committed
grofaty (grofaty) wrote :

Tested in Pinta 0.6 Windows XP sp3. Problem remains! See attachment.

Changed in pinta:
status: Fix Committed → New
Jonathan Pobst (jpobst) wrote :

I did not change this for Windows, as on Windows, Cut/Copy/Paste comes before Undo/Redo.

This fix will only be visible on !Windows.

grofaty (grofaty) wrote :

Jonathan, is there a Ubuntu version of Pinta like ppa:moonlight-team/pinta - I would like to test Pinta 0.6 on Ubuntu too.

Jonathan Pobst (jpobst) wrote :

Not yet. When they update the ppa, I'll add it to the downloads page.

Jonathan Pobst (jpobst) on 2011-02-19
Changed in pinta:
status: New → Fix Released

Jonathan,
today I have installed Pinta 0.7 on Windows XP and Ubuntu 10.10 and have tested ALL of the bug reports market as "Fix Committed". It took me several hours, but I have finished them all. Most of the bugs fix is really released, so I have marked bug reports as "Fix Released", but some of them are not fix (one or two, can't really remember) so I have marked bugs back to "New".

I have also marked bug 694074 by mistake as "Fix Released" I should mark it as "New", because bug is not fixed. But now I can't change status back to New because Launchpad does not allows me to do that - not having permissions. Can you please change a status of this bug to New?

There are also two bugs with "Fix Released" both are building code from source code: 701862 and 606860. I haven't tested this, but this two bugs probably could be marked as "Fix Released". If you think bugs are fixed it would be nice if this bugs are also marked as "Fix Released". Can you please mark them as appropriate?

There are also two bug reports: 582109 and 587649 and there is fix provided by some developers. It would be nice if you could just check if this code is solving the problem and commit the change to hig. It would be nice if developers would know that there's work is appreciated. If the code does not fix the problem, then it should be written in bug report that code does not fix the bug.

I have tested Pinta 0.7 and I have found some new (regression) bugs. I have reported them in Launchpad.

On Launchpad there are several bugs as wishlist. Is there any time-table when and if this features will be implemented. And if there is any list it would be nice if there would be the order specified and maybe some web page made to ask developers for help on making simple fixes.

Thanks for building such an excellent product. My honor to help.
Regards

Jonathan Pobst (jpobst) wrote :

Please don't send me an email as a comment on an old bug. Use the mailing list or send me an email: monkey at jpobst dot com.

694074 - Commented on
701862 - Marked released
606860 - Marked released
582109 - I already have a comment on it saying it doesn't work for me
587649 - I'm pretty sure I don't want this behavior. Adding double clicks to toolbar items seems like a bad idea.

Thanks for the new bugs!

Wishlist items probably won't be fixed before 1.0, as I'm trying to just fix the important bugs so I can do a 1.0 release. Aside from that, I haven't really figured out what to do with feature requests. Some of them I will probably never do, but so far I've left them open in case someone wants to contribute them. Or, post 1.0, when I add extensions, people may want to do them as extensions. I am thinking maybe using UserVoice to set up something like this: http://bit.ly/etUAf9, so people can suggest things, vote on them, and developers could implement them as extensions.

As always, thanks for your excellent work on finding and triaging bugs!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers