Jon,
It's good to see the swatches being worked on. Shift+click now works, which is excellent. Some comments:
- please remove the padding between the swatches (not only does this waste space, but also makes the colors harder to discern due to a well-known optical illusion)
- please make it remember the display mode and the loaded palette across sesssions (and the window size/placement too, of course)
- please do something with the menu and X buttons, they are rather ugly (why don't you just copy them over from Gimp, they're nice there)
- please fix it to not display the scrollbars when they are not needed
- could you add a "no color" button to the beginning of each palette, which would set "none" to either fill or stroke
- what is eek-preview.cpp? is it temporary? if not could you please rename it to something more useful?
bulia byak wrote:
Jon,
It's good to see the swatches being worked on. Shift+click now works, which is excellent. Some comments:
- please remove the padding between the swatches (not only does this
waste space, but also makes the colors harder to discern due to a well-known optical illusion)
Sounds good. Should this be only in grid mode, or in list mode also?
- please make it remember the display mode and the loaded palette
across sesssions (and the window size/placement too, of course)
This goes along in with the PanelManager/dialog retune.
- please do something with the menu and X buttons, they are rather
ugly (why don't you just copy them over from Gimp, they're nice there)
Yes, I know. They are majorly ugly. Just temporary. The main problem is that to get things going well takes quite a bit of coding if we don't want to switch to GTK+ 2.6 (which we don't).
- please fix it to not display the scrollbars when they are not needed
This goes in with the Panel/Dockable/DockFillable rework.
- could you add a "no color" button to the beginning of each palette,
which would set "none" to either fill or stroke
Nope.
:-P
That's not a color. That's a style attribute. So that will fall under the style swatches/picker. Not sure how long it will take before that gets some work, so I'll look for places to put things in UI.
- what is eek-preview.cpp? is it temporary? if not could you please
rename it to something more useful?
Well, it's a preview widget that needed some 'collection' name prefix. I kept asking for better suggestions than 'Foo' for that, but nobody spoke up. It's part of a set of planned things that will be self-contained, low-level, reusable widgets and objects. One thing to go in there is a Color object that knows how to deal with more than just pure RGB(A). An abstract 'style' object is another, and then a widget to display one or more styles (the fill/stroke status display widget).
Anyway, I figured that "Eek" was a bit better than "Jon's" or "Foo", so went that for now (I also avoided 'Ink' since I want them reusable, and that things like 'InkColor' start to carry a misleading connotation). If you can think of a better short prefix, let me know.
On 4/28/05, Jon A. Cruz <jon@...18...> wrote:
- please remove the padding between the swatches (not only does this
waste space, but also makes the colors harder to discern due to a well-known optical illusion)
Sounds good. Should this be only in grid mode, or in list mode also?
Yes, in all modes
Yes, I know. They are majorly ugly. Just temporary. The main problem is that to get things going well takes quite a bit of coding if we don't want to switch to GTK+ 2.6 (which we don't).
Well, if 2.6 will fix it much more easily than now, I can wait :)
- could you add a "no color" button to the beginning of each palette,
which would set "none" to either fill or stroke
Nope.
:-P
That's not a color. That's a style attribute. So that will fall under the style swatches/picker.
Not really.
You are already setting style in swatches.cpp:
sp_repr_css_set_property( css, attrName, c ); sp_desktop_set_style(desktop, css);
All you need to do instead, for that special button (which must always go first and may display e.g. checkers or an empty frame) is:
sp_repr_css_set_property( css, attrName, "none" ); sp_desktop_set_style(desktop, css);
That's all. Please do it, it will be a MAJOR convenience as it will remove many of the remaining reasons to ever open Fill&Stroke.
Anyway, I figured that "Eek" was a bit better than "Jon's" or "Foo", so went that for now (I also avoided 'Ink' since I want them reusable, and that things like 'InkColor' start to carry a misleading connotation). If you can think of a better short prefix, let me know.
Why not call it just "preview" then?
bulia byak wrote:
On 4/28/05, Jon A. Cruz <jon@...18...> wrote:
That's not a color. That's a style attribute. So that will fall under the style swatches/picker.
Not really.
You are already setting style in swatches.cpp:
Oh, yes. I know how I'm *implementing* things, but on the outside its coming from something that only represents a color. What you want is currently covered in the fill&stroke dialog as "No paint | Flat color | Linear Gradient | Radia Gradient". It's a different section of that dialog, and a different concept.
That's all. Please do it, it will be a MAJOR convenience as it will remove many of the remaining reasons to ever open Fill&Stroke.
And that's the long-term goal I'm looking at. I just want to be sure to do it in a good way so that the dialog can be left aside. So among other things, a Fill has a color, bit a Fill is not a color.
Why not call it just "preview" then?
Well, among other reasons is that GTK+ already has a deprecated widget called "preview".
On 4/28/05, Jon A. Cruz <jon@...18...> wrote:
Oh, yes. I know how I'm *implementing* things, but on the outside its coming from something that only represents a color.
Well, if you can't make it a swatch, make it a button somewhere. E.g. on the top panel of the dialog, left-aligned. That space is wasted anyway.
And btw, why this horizontal divider and some empty space at the bottom of the dialog? Can you please squeeze that out?
Also it would be very nice to scroll the palette (if it does not entirely fit) by middle mouse button, the way we scroll canvas. Can you do that?
bulia byak wrote:
Well, if you can't make it a swatch, make it a button somewhere. E.g. on the top panel of the dialog, left-aligned. That space is wasted anyway.
Yes, I was planing on shoving in a new button somewhere. But... if I get time to embed the swatch palette in the main UI window, I'll just drop it next to that.
And btw, why this horizontal divider and some empty space at the bottom of the dialog? Can you please squeeze that out?
That's from the temp Dialog that's holding the Panel right now. Part of Dockable will let the new Dialog know to draw that or not.
Also it would be very nice to scroll the palette (if it does not entirely fit) by middle mouse button, the way we scroll canvas. Can you do that?
We'll try to get that in. That falls under the container (Panel which implements PreviewFillable) needing new layout code. Among other things, I think behaving like the Gimp's and doing a flow-layout that avoids horizontal scrolling would also be good.
I'd like to add a few comments on swatches aspect... 1) in grid mode, maybe swatches would look better with a thin black border, like on gimp, don't you think ? when neighbor colors look almost the same (which is likely to happen), I think it helps a lot to choose a color... 2) when moving over swatches, searching for a color, you want to see its name, so you have to wait for the tooltip to come up : it would be nicer, when it's up, that it refreshes instantly when moving over other colors. i hope i'm clear... 3) there's a focus shape on the last selected swatch... there's no reason for keeping that, except if the "focus" is not set to the last selected swatch, but on the color of the selected object. but that's probably more than just a GUI question.
I wish I could drop a patch for those things, but i'm not skilled enough, I'll try to dive more into the code when I have time. Btw, congratulations to you all for this amazing piece of software ;)
françois (alias paco)
On 4/28/05, Jon A. Cruz <jon@...18...> wrote:
bulia byak wrote:
Well, if you can't make it a swatch, make it a button somewhere. E.g. on the top panel of the dialog, left-aligned. That space is wasted anyway.
Yes, I was planing on shoving in a new button somewhere. But... if I get time to embed the swatch palette in the main UI window, I'll just drop it next to that.
And btw, why this horizontal divider and some empty space at the bottom of the dialog? Can you please squeeze that out?
That's from the temp Dialog that's holding the Panel right now. Part of Dockable will let the new Dialog know to draw that or not.
Also it would be very nice to scroll the palette (if it does not entirely fit) by middle mouse button, the way we scroll canvas. Can you do that?
We'll try to get that in. That falls under the container (Panel which implements PreviewFillable) needing new layout code. Among other things, I think behaving like the Gimp's and doing a flow-layout that avoids horizontal scrolling would also be good.
SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 4/28/05, François Steinmetz <francois.steinmetz@...400...> wrote:
I'd like to add a few comments on swatches aspect...
- in grid mode, maybe swatches would look better with a thin black
border, like on gimp, don't you think ? when neighbor colors look almost the same (which is likely to happen), I think it helps a lot to choose a color...
On the contrary, when neighbor colors are close, it is MUCH easier to compare them and choose one when they are just next to each other, without any borders.
- when moving over swatches, searching for a color, you want to see
its name, so you have to wait for the tooltip to come up : it would be nicer, when it's up, that it refreshes instantly when moving over other colors. i hope i'm clear...
They work fast enough for me.
- there's a focus shape on the last selected swatch... there's no
reason for keeping that, except if the "focus" is not set to the last selected swatch, but on the color of the selected object. but that's probably more than just a GUI question.
I agree, a swatch should be defocused as soon as it's pressed. I did this for the controls bar buttons.
bulia byak wrote:
On 4/28/05, François Steinmetz <francois.steinmetz@...400...> wrote:
- there's a focus shape on the last selected swatch... there's no
reason for keeping that, except if the "focus" is not set to the last selected swatch, but on the color of the selected object. but that's probably more than just a GUI question.
I agree, a swatch should be defocused as soon as it's pressed. I did this for the controls bar buttons.
There's a property on GtkButton to prevent grabbing focus on a click (and it's documentation mentions toolbars). I added a property with that name and turned it on in the swatches, so it should behave better now.
On 4/28/05, Jon A. Cruz <jon@...18...> wrote:
Yes, I was planing on shoving in a new button somewhere. But... if I get time to embed the swatch palette in the main UI window, I'll just drop it next to that.
Yes.
Also it would be very nice to scroll the palette (if it does not entirely fit) by middle mouse button, the way we scroll canvas. Can you do that?
We'll try to get that in. That falls under the container (Panel which implements PreviewFillable) needing new layout code. Among other things, I think behaving like the Gimp's and doing a flow-layout that avoids horizontal scrolling would also be good.
Exactly. In fact I think it will make sense, instead of small/medium/large/huge, to have two modes: horizontal and vertical. In horizontal mode, there may be only horizontal scrolling if any, and the swatches would reflow and squeeze to fit exactly the allocated vertical space. In vertical mode, correspondingly, only vertical scrollbar may be present. And if there is more space than necessary for the current amount of swatches require, they grow to fit exactly. In other words, I want to control the size of the swatches by resizing the palette, not by choosing some predefined size, and I only want to choose the direction in which I will scroll if the swatches don't fit even at the minimum size. Can you do that?
Exactly. In fact I think it will make sense, instead of small/medium/large/huge, to have two modes: horizontal and vertical. In horizontal mode, there may be only horizontal scrolling if any, and the swatches would reflow and squeeze to fit exactly the allocated vertical space. In vertical mode, correspondingly, only vertical scrollbar may be present. And if there is more space than necessary for the current amount of swatches require, they grow to fit exactly. In other words, I want to control the size of the swatches by resizing the palette, not by choosing some predefined size, and I only want to choose the direction in which I will scroll if the swatches don't fit even at the minimum size. Can you do that?
I totally agree - and to control everything, you may choose the number of lines (horizontal) or columns (vertical) like in gimp. and forget what i said about borders, it actually looks nice ;-)
On 4/29/05, François Steinmetz <francois.steinmetz@...400...> wrote:
I totally agree - and to control everything, you may choose the number of lines (horizontal) or columns (vertical) like in gimp.
I don't think even this is necessary. The algorithm might work like this:
- There's a minimum and a maximum swatch dimensions, Dmin and Dmax. (Perhaps the small/medium/large switch may remain, just choosing each their own Dmin and Dmax values.) I think Dmax should be about 5 times larger than Dmin.
- In horizontal mode:
1 The allocated vertical space is divided by Dmin. That's how many rows we have. The rows will have the height Dmin or slightly more (if there's a remainder in the division) so that the height fits exactly.
2 With this number of rows, swatches are flown into so many columns as necessary, with the width of Dmin. If they don't fit, horizontal scrollbar appears.
3 If the columns take _less_ width than the available horizontal space, they are stretched horizontally so as to fit exactly.
4 If the horizontal stretch makes them wider than Dmax, then the number of rows is reduced, the height is correspondingly increased, and they are reflown. The goal is to fill all horizontal space with the swatch width not exceeding Dmax.
- In vertical mode it's all the same, replacing rows by columns, width by height, and vice versa.
I think this will be the most natural behavior.
Jon, can you please implement it?
looks ok... but there's something that should be looked at more carefully : in 2), if the scrollbar appears, it reduces the available vertical space (does it not ?), possibly leading to swatches with a height < Dmin... it definitely wouldn't be a good idea to recalculate the number of rows then (because it would lead to 2 possible layouts for some geometries : with and without the scrollbar... quite confusing), so in this case a height < Dmin should be allowed, I guess... or we can calculate the number of rows in 1) by dividing by something like (Dmin + Dmax)/2 so as not to have a height < Dmin.
On 4/29/05, bulia byak <buliabyak@...400...> wrote:
On 4/29/05, François Steinmetz <francois.steinmetz@...400...> wrote:
I totally agree - and to control everything, you may choose the number of lines (horizontal) or columns (vertical) like in gimp.
I don't think even this is necessary. The algorithm might work like this:
- There's a minimum and a maximum swatch dimensions, Dmin and Dmax.
(Perhaps the small/medium/large switch may remain, just choosing each their own Dmin and Dmax values.) I think Dmax should be about 5 times larger than Dmin.
- In horizontal mode:
1 The allocated vertical space is divided by Dmin. That's how many rows we have. The rows will have the height Dmin or slightly more (if there's a remainder in the division) so that the height fits exactly.
2 With this number of rows, swatches are flown into so many columns as necessary, with the width of Dmin. If they don't fit, horizontal scrollbar appears.
3 If the columns take _less_ width than the available horizontal space, they are stretched horizontally so as to fit exactly.
4 If the horizontal stretch makes them wider than Dmax, then the number of rows is reduced, the height is correspondingly increased, and they are reflown. The goal is to fill all horizontal space with the swatch width not exceeding Dmax.
- In vertical mode it's all the same, replacing rows by columns, width
by height, and vice versa.
I think this will be the most natural behavior.
Jon, can you please implement it?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Wow, the swatches without any separation are very nice. Please don't listen to anyone who will tell you they need borders or something :)
bulia byak wrote:
Wow, the swatches without any separation are very nice. Please don't listen to anyone who will tell you they need borders or something :)
Don't worry. We'll keep that. being able to differentiate better with no separation was one thing covered in my color theory classes. (But it has been long enough that I've forgotten the names of the things involved)
For some things (like patterns and styles), we will want separation, but for others we won't. I'm going to try to get that in the UI as default, but have it hooked to standard theme mechanisms so that those people who like things strange can tweak them.
On Thu, Apr 28, 2005 at 08:39:39PM -0700, Jon A. Cruz wrote:
bulia byak wrote:
Wow, the swatches without any separation are very nice. Please don't listen to anyone who will tell you they need borders or something :)
Don't worry. We'll keep that. being able to differentiate better with no separation was one thing covered in my color theory classes. (But it has been long enough that I've forgotten the names of the things involved)
Can someone post a screenshot? :-)
Bryce
Jon A. Cruz wrote:
Don't worry. We'll keep that. being able to differentiate better with no separation was one thing covered in my color theory classes. (But it has been long enough that I've forgotten the names of the things involved)
For some things (like patterns and styles), we will want separation, but for others we won't. I'm going to try to get that in the UI as default, but have it hooked to standard theme mechanisms so that those people who like things strange can tweak them.
In other applications, even styles and patterns are not bordered, but placed side by side like the color swatches. I think it's a good thing. Could we not have them separated and see if that causes any problems?
-Kevin Wixson
On 4/28/05, bulia byak <buliabyak@...400...> wrote:
All you need to do instead, for that special button (which must always go first and may display e.g. checkers or an empty frame)
Actually no, for consistency with Fill&Stroke it must display an X of some kind. And while you're at it, maybe you can add a second always-present swatch with an ? sign, for which you do:
sp_repr_css_unset_property( css, attrName ); sp_desktop_set_style(desktop, css);
participants (5)
-
Bryce Harrington -
bulia byak -
François Steinmetz -
Jon A. Cruz -
Kevin Wixson