Just one minor annoyance, which might be ubuntu's gtk theme problem, I see now is that there is no obvious "None" label at the top of list. It is there but appears as a few pixels high unmarked region you need to click at to remove marker.

That's not a theme bug, that's a real bug IMO. So I've fixed it by using the Gtk::Remove stock icon where we want to say "No Marker".

Thanks for testing and finding that problem.

One other idea: Is it complicated to auto-select color profile in CMS combo-box of Fill/Stroke tab if there is only one assigned to a working document? Don't know if there is something I've overlooked in this approach though. Maybe others will have something to add...

I'm not sure what you mean here. Maybe a mock-up would show me what you mean.

Martin,

On Wed, 2013-06-12 at 00:18 +0200, Johan Engelen wrote:

Oops, now on Windows upon attempting to open the Fill&Stroke dialog:

(inkscape.exe:7384): glibmm-CRITICAL **: unhandled exception (type Glib::Error) in signal handler: domain: gtk-icon-theme-error-quark code : 0 what : Icon 'gtk-remove' not present in theme

Sorry Johan, got that fixed in the latest, you should see no icon because gtk-remove doesn't exist (not sure about Windows icons) but at least it won't crash and I've improved the implementation while I was there.

Martin,

On Wed, 2013-06-12 at 01:17 +0200, ~suv wrote:

r12367 no longer crashes AFAICT.

Blubber! I've set the icon to 'remove' instead of 'gtk-remove' but with no list online for default icons in gtk and a very incomplete list of icons in the Ubuntu themes... It's trial and error time.

Let me know if it works, it does on Ubuntu.

Martin,

On 2013-06-12 02:06 +0100, Martin Owens wrote:

On Wed, 2013-06-12 at 01:17 +0200, ~suv wrote:

...

r12367 no longer crashes AFAICT.

Blubber! I've set the icon to 'remove' instead of 'gtk-remove' but with no list online for default icons in gtk and a very incomplete list of icons in the Ubuntu themes... It's trial and error time.

Let me know if it works, it does on Ubuntu.

Not sure if you misread my earlier message?

- Revision 12364 ("Fix new bug with No-Marker having no icon, use Stock GTK::Remove icon for No-Marker.") introduced the crash (regression) when opening the 'Fill & Stroke' dialog, if e.g. the stock GTK+ icon theme 'hicolor' is used (or no icon theme is explicitly defined at all).

- Revision 12367 ("Change back to using NULL and fix windows theme error by checking") works without crash - independent of the icon theme used.

- Revision 12369 ("Use 'remove' instead of 'gtk-remove' for theme.") also works without crash, no matter which icon theme is used.

Usability issue with the current solution:

Depending on the desktop (or GTK+) settings, neither of the two later revisions (12367, 12369) displays an icon (or a fallback label) in the marker selector menu though [1]:

Without an icon (or label, tooltip or whatsoever) - how do you tell (new) users how they can remove a marker once it has been set? There is nothing obvious in the popup menu which would indicate how to reset the marker to 'None', unless one happens to notice that the row above the top-most listed symbol in the popup menu displays a small (or even tiny) highlighted (empty) stripe if hovered, and in fact is the active menu entry for 'No marker'.

Just wondering: 'gtk-remove', or 'GTK_STOCK_REMOVE' does exist (even in the stock icon theme), and seems to work just fine elsewhere in Inkscape's dialogs (e.g. to remove a layer, or a live-path-effect). Why not in the marker selection menu in Fill & Stroke?

----- [1] tested & confirmed on OS X 10.7.5 with gtk icon theme explicitly set to 'hicolor', as well as with an empty 'gtkrc' file -> fallback to stock items/theme

Just wondering: 'gtk-remove', or 'GTK_STOCK_REMOVE' does exist (even in the stock icon theme), and seems to work just fine elsewhere in Inkscape's dialogs (e.g. to remove a layer, or a live-path-effect). Why not in the marker selection menu in Fill & Stroke?

I decided to fix the problem by using an inkscape icon, I added a new method to sp-icon to generate a pixbuf-only instead of juggling multiple GtkImages and SPIcon objects.

Seems to work. Let me know if it's causing any more problems.

Best Regards, Martin Owens

El 16/06/13 09:09, Vladimir Savic escribió:

Hi Martin, Sorry for very late reply.

There is no need for mock-up really. Read this lines if you've never tried assigning an ICC profile to a document: "...First at least one CMYK profile needs to be added to the document being worked on. That can be accessed in the GUI through the "Color Management" tab on the document properties dialog. Once at least one profile has been added, the color pickers in the Fill & Stroke dialog can be used to pick colors in that colorspace via specifying the ICC profile." [1] What annoys me is that even if you have only one ICC profile attached to a doc, you still need to manually select it from a drop-down combo of CMS tab (Fill&Straoke dialog). Can Inkscape automatically pick it for me?

Regards, Vlada

I always wondered the reason of that tab. I mean, I can understand that every object in the SVG document may have different color profiles and that that dialog allows to choose whatever profile you want for the selected object. The question, however, is if that case of several profiles in the same document is so frequent to justify that awkward default worflow for managed color. I think it's more realistic to think that a user would select one profile for RGB and other for CMYK, and if she does it, it will be probably because she wants every RGB and CMYK objects in the document in that colorspace. Don't get me wrong, I'm not saying that nobody will need other profiles in the document, but I'm convinced that's a less frequent case, and a rare or edge case shouldn't make the experience of frequent tasks more difficult or cumbersome. Right now we have basically a "color-unmanaged" workflow and a tool for managing color in a per-object basis. I'd love to hear if a single user ever used that feature for a complex drawing with hundreds of colors and objects. Also, the CMS tab seems to work for CMYK but not for RGB but it allows to pick an RGB profile anyway.

IMO, this can be improved unifying the sliders and getting rid of the CMS tab. If somebody chose a CMYK profile and attached it to the document, it clarly means that CMYK values are relevant and a raw representation in CMYK of RGB values isn't desirable anymore, so I think it would be pretty reasonable to assume that if there is a single CMYK profile set in the document, user will expect color managed CMYK when she uses it. Regarding RGB, if there is no RGB profile set, generally sRGB is assumed. Again, if a user choses a different RGB profile, is it to expect that she wants that RGB profile for the elements in the document, same case. And what if user choses more than one profile? Then a multiple selector can be used (pretty much like the current CMS tab). Multiple profiles would require just an extra setting in the profile embedding dialog for selecting what profile is the default or fallback profile. In that case every color would be color-managed once a profile is selected, and only if another RGB or CMYK profile is added the selector would appear in the RGB and CMYK sliders. (maybe an "unmanaged" option could be added too).

I think this would work, but there's a remaining issue: unmanaged RGB and CMYK sliders are linked (I mean, they are representations of the same color in different models), but that's not possible with managed colors. That's technically solvable just with warnings in the dialogs. For instance, if user chose an RGB combination that falls beyond the current CMYK profile's gamut, a big fat label could warn the user that the current color is out-of-gamut, allowing him to tweak the CMYK sliders, which would automatically clip the RGB color to the closest CMYK combination using the default rendering intent set in the preferences as soon as he clicks on one of the sliders. That also can be fixed by adding optional RGB clamping, so the RGB sliders can't go beyond the printable gamut.

I think it can be done, and that would simplify the color managed workflow in inkscape a lot. If done properly, the unified dialogs could be extended to allow also unmanaged values and different profiles, but that should be, IMO, a second level option and not the primary workflow. I'm convinced that most of the users choose a single colorspace (or two, an RGB and a CMYK tops) for their everyday color-managed work.

I'd love to know what you guys think about this. Maybe I missed something, but if you think it's a viable idea I would gladly turn this idea into a detailed blueprint. It looks like a good GSoC project for the future :-)

Gez.

On Wed, 2013-06-12 at 01:14 +0400, Alexandre Prokoudine wrote:

It's a very nice idea, thank you for that :) But why is there a waste of whitespace towards the bottom?

That's the colour dialogs. I had a look at them and it depends on which colour selector is being used... the widgets are not behaving and a lack of templating (i.e. glade) makes experimentation impossible.

I'm actually a bit annoyed about that, the amount of inconsistent and over-verbose code going into manufacturing gtk widgets is a crime in some other universe I'm sure.

Martin,