EdgeColor option (or switchable type 'edge_bar', 'bar' for geom_bar)

[matthijscox]

First of all: great toolbox, I love the possible customizations so far!

One thing I was trying to do is plot bars without a black edge using geom_bar. I noticed there are actually two bar types: 'bar' and 'edge_bar', the latter being called by geom_bar. The 'bar' has EdgeColor = 'none', but I cannot call it with geom_bar yet. Or am I not seeing an option or geometry somewhere?

I could solve this myself with a user input into geom_bar, for example 'edge', with a true/false setting. This than changes the input geom to plotci from edge_bar to bar, respectively (or internally changes the EdgeColor for stacked bars).

However, a generalization of this to other geometries could be to set the EdgeColor directly via the draw_data structure, for example for area's. But I don't know if that's valuable to anyone. Perhaps someone wants a black background with white edges? And I don't see an obvious set_xxx_options function for this.

[piermorel]

Hi, thanks for the feedback!

I indeed have to make the way to interact these objects more uniform... In the meantime the fastest way is to modify the bars after the draw call using Matlab's own set() function and the stored bar handles set(g.results.geom_bar_handle,'EdgeColor','none')

[piermorel]

As for common ways to set options, I have something like that in geom_label() in order customize text colors... What do you think about it?

[matthijscox]

Oh, I see you have 'auto' options in geom_label for some options. That's nice indeed. If you also add a 'FaceColor' option which is default set to 'auto' you would have full customization for the bars. You could even make empty faces and only plot the lines, with a 'none' input for the FaceColor.

[matthijscox]

I like the idea, so I started playing a bit with it. Now I can set the FaceColor to none and the EdgeColor to auto, and adapt any other patch options, like LineWidth. If you want I can try a pull request, though that would be my first.

[piermorel]

Nice result! You are welcome to do a pull request. Two things off the top of my head:

• check that your changes also work when using the stacked option
• The trickiest part might be not to break plotci() which is used for a bunch of other functions (or to remove plotci() dependence).

Anyway I'm taking holidays so there is time to fine tune everything :)

[matthijscox]

Ha, great advice and I was already incorporating it myself. I removed the plotci dependency, perhaps that dependency should actually be inverted, but I'll not touch that. I'm also taking a holiday next week, but I'll see what I can do :)

[matthijscox]

Looking into the stacked bars, I found some strange behavior if any of the groups matches the x data. The y-offset of the bars seems to be computed incorrectly in that case. I'll see if I can easily fix that as well.

[matthijscox]

Alright, the above stacking issue is a bit more complex, and should probably become a separate issue. It's related to how you determine the height of the stack, using the dodge_x and the x position and the obj.firstrun, which in this particular case seems insufficient information to separate the stacks. This is thanks to my color group input being the same as x, which makes GRAMM cycle over all elements separately.

I will make a pull request of the original enhancement suggestion.

[piermorel]

I created a different issue on the stacked bars by copying your comments. Good catch, stacked bars can be surprisingly tricky.