NEW: Selected style indicator, statusbar redesign
A new control in the left end of the statusbar lets you quickly view and change the fill and stroke of the selected object(s).
* The two indicators, labelled "F:" (top) and "S:" (bottom), display fill and stroke of the selected object(s) correspondingly.
* Each indicator can display either a color/opacity swatch (the opacity shown here is the fill opacity or stroke opacity, not the master opacity) or a label specifying "N/A" (nothing selected), "None" (no fill/stroke), "Unset" (unset fill/stroke), "L Gradient", "R Gradient", "Pattern" (corresponding fill/stroke types), or "Different" (selected objects have different stroke types).
* Additionally, each indicator may be accompanied by one of two flags, "M" ("multiple", meaning there are two or more objects all with the _same_ fill/stroke) or "A" ("averaged", meaning there are two or more objects with flat color fill/stroke whose colors are averaged).
* Just as the Fill&Stroke dialog, the new control correctly displays the fill/stroke of the selected gradient handle or selected text fragment in the corresponding tools.
* Left-click on an indicator opens or activates the Fill&Stroke dialog with the corresponding tab selected.
* Right-click on an indicator opens a popup menu with the following commands:
** "Remove fill/stroke": Removes fill or stroke from the selected objects.
** "Last set color": Applies to the selected objects the fill/stroke color that was last applied to anything.
** "Last selected color": Applies to the selected objects the fill/stroke color that was last displayed in this indicator. (To easily copy fill/stroke color between objects: select source, select destination, apply "last selected color".)
** "Unset fill/stroke": Unsets fill or stroke from selected objects (useful for clone originals).
** "Edit fill/stroke...": Opens or activates the Fill&Stroke dialog with the corresponding tab selected.
* Middle-click on an indicator removes fill/stroke from selected objects; if it is already removed (i.e. if the indicator displays "None"), it does the same as the "Last set color" command from the popup menu. (In other words, it toggles between "None" and the last set color.)
The zoom field and the cursor coordinates indicator have been rearranged for compactness and moved to the right end of the statusbar.
== Implementation notes: ==
* There's no fixed pixel sizes for fonts used anywhere. Instead, the control uses a font size 70% of the current gtk default. I hope this works for most people, but I know there will be those who will find this font size too small, and others for whom it will be too large and pushing the vertical size of the statusbar. I want to hear your feedback on this.
* The new control is itself done in gtkmm, yet it uses an old GTK color preview widget, and fits nicely into the old GTK desktop widget. The Glibmm::wrap() and gobj() are all you need to combine GTK and gtkmm stuff freely. So, I may be missing something, but I really don't understand why you gtkmm guys do this --new-gui thing instead of just converting the existing desktop widget-by-widget.
* Despite lots of functionality, the new control is quite small in the code. That's because it reuses all the architectural concepts I've been slowly pushing in the last two years: desktop's current color, set and query style signals. With that in place, coding this entire control took just a couple days. It should also be easy to change or extend it.
* TODO: I also plan to add a master opacity spinbutton to this control.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Nov 10, 2005, at 11:36 PM, bulia byak wrote:
- The new control is itself done in gtkmm, yet it uses an old GTK
color preview widget, and fits nicely into the old GTK desktop widget. The Glibmm::wrap() and gobj() are all you need to combine GTK and gtkmm stuff freely. So, I may be missing something, but I really don't understand why you gtkmm guys do this --new-gui thing instead of just converting the existing desktop widget-by-widget.
You just hit on one of the key things I've been trying to convey.
Gtkmm-ification is not so much a step or a item, but rather should just be an aspect of other work.
And to help in converting widget-by-widget, we can work on cleaning up the interfaces. As we do that, it makes pieces more independent and easier to switch out widget-by-widget.
Jon Cruz:
On Nov 10, 2005, at 11:36 PM, bulia byak wrote:
- The new control is itself done in gtkmm, yet it uses an old GTK
color preview widget, and fits nicely into the old GTK desktop widget. The Glibmm::wrap() and gobj() are all you need to combine GTK and gtkmm stuff freely. So, I may be missing something, but I really don't understand why you gtkmm guys do this --new-gui thing instead of just converting the existing desktop widget-by-widget.
Gtkmm-ification is not so much a step or a item, but rather should just be an aspect of other work.
I'm not religious on the --new-gui issue and, yes, most of the work needed to do for full gtkmm is independent of the underlying main GUI --- that's the big advantage of the gtk+/gtkmm switch.
However, you know that the main application handling and, with this in inkscape at least, the main desktop widget would need a testbed before being included in the mainstream source, that's IMO the sole reason for --main-gui.
Note that, with this, the need for simultaneous handling of SPDesktopWidget and EditWidget has lead to major cleanup of the SPDesktop code, so was not for nothing. See also the recent discussion on the inkcape object.
ralf
replying to myself...
However, you know that the main application handling and, with this in inkscape at least, the main desktop widget would need a testbed before being included in the mainstream source, that's IMO the sole reason for --main-gui.
...for --new-gui should that read.
So, you might ask, what's needed before we have a Gtkmm desktop?
The todo on that is, as I see it:
-------------------------------------- Bugs - changing msg label changes window size - enlarging window doesn't recenter picture - zoom out to 1%, zoom back, no longer at the same positin
Features - really include URI input box? - bulia's selected style widget - layer dialog (because there will be no layer selector on desktop) - infamous icons/menu/actions --------------------------------------
That's all, folks! When that is done, and the logic switched, inkscape will no longer be "gtk+ with some gtkmm" but "gtkmm with some gtk+".
Addenda and help appreciated, ralf
Quoting Ralf Stephan <ralf@...748...>:
Features
- layer dialog (because there will be no layer selector on
desktop)
Nope, sorry, we're keeping the layer selector. A layer dialog is great, but the layer selector is more convenient for some things.
-mental
mental@...3... wrote:
Quoting Ralf Stephan <ralf@...748...>:
Features
- layer dialog (because there will be no layer selector on
desktop)
Nope, sorry, we're keeping the layer selector. A layer dialog is great, but the layer selector is more convenient for some things.
Please tell me that you are indicating that we're keeping the layer selector /in addition/ to getting a layers dialog. Is that correct? And if that is the case, I think it should be something that people should be a able to toggle on and off via the view menu (for those that would prefer dialog only and more statusbar).
-Josh
On 11/11/05, mental@...3... <mental@...3...> wrote:
Quoting Ralf Stephan <ralf@...748...>:
Features
- layer dialog (because there will be no layer selector on
desktop)
Nope, sorry, we're keeping the layer selector. A layer dialog is great, but the layer selector is more convenient for some things.
I second that.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Features
- layer dialog (because there will be no layer selector on
desktop)
Nope, sorry, we're keeping the layer selector. A layer dialog is great, but the layer selector is more convenient for some things.
So this list item will just be changed to - reimplement layer selector
ralf
On Nov 11, 2005, at 3:47 AM, Ralf Stephan wrote:
Features
- infamous icons/menu/actions
This is probably one of the key things to look at.
There are a lot of things now that we need to redo behind the scenes to get stuff working well. Since we moved up to GTK+ 2.4 we have Actions to play with.
Converting verbs to be happy-happy with Actions would touch on the UI, toolbars, menus, dynamic menus from XML and possibly a few other things.
On Fri, Nov 11, 2005 at 09:15:47AM -0800, Jon A. Cruz wrote:
On Nov 11, 2005, at 3:47 AM, Ralf Stephan wrote:
Features
- infamous icons/menu/actions
This is probably one of the key things to look at.
There are a lot of things now that we need to redo behind the scenes to get stuff working well. Since we moved up to GTK+ 2.4 we have Actions to play with.
Converting verbs to be happy-happy with Actions would touch on the UI, toolbars, menus, dynamic menus from XML and possibly a few other things.
Fwiw, this is one area that got a lot of work done in the original gtkmmification. At one point we had the entirety of the Inkscape menus implemented on the Actions stuff (including icons and text). However it got out of sync quickly, and in fact much of it has been disabled. Note that the icons were being rendered via rsvg instead of livarot because gtkmm has the code to render svg's through that path. However, iirc it expects the svg icons to be individual files, whereas with inkscape we work with all the svgs in a single file; this issue never really got adequately sorted out, and the individual .svg's got dumped.
Easiest solution would probably be to tap back into the inkscape renderer for the icons as is done with the main interface currently, but who knows. I think there'd be an argument in favor of this from the standpoint that "it provides a built-in test case for the inkscape renderer", however I think it could equally be said that relying on rsvg for it would give us a built-in compatibility test.
Bryce
On Nov 11, 2005, at 12:46 PM, Bryce Harrington wrote:
Easiest solution would probably be to tap back into the inkscape renderer for the icons as is done with the main interface currently, but who knows.
I do.
:-)
There's a bit of work to get things hooked in as a proper theme icon source, but I researched enough when I did my initial icon push to have a good handle on it.
Once we have things to Actions again, I can get some kludges in place for the short term, and then work on a real solution.
I think there'd be an argument in favor of this from the standpoint that "it provides a built-in test case for the inkscape renderer", however I think it could equally be said that relying on rsvg for it would give us a built-in compatibility test.
Nah. We don't need that.
Just wait for me to add the rsvg pane to the icon preview dialog. I was planning on that and hooking up for 'live' changes, so you'll get even better compatibility testing. The scope is not that hard, and then I'll also have a nice testbed for moving forward on <multiImage> and <switch> for both Inkscape and rsvg.
Can you please comment on this item?
Features
- really include URI input box?
If you don't know what, atm it's a text input box that takes a full bar for itself, below the toolbars-to-come.
ralf
On Fri, Nov 11, 2005 at 07:53:42PM +0100, Ralf Stephan wrote:
Can you please comment on this item?
Features
- really include URI input box?
If you don't know what, atm it's a text input box that takes a full bar for itself, below the toolbars-to-come.
My thinking here was to give it a separate toolbar that is turned off by default.
Bryce
On Fri, Nov 11, 2005 at 12:47:29PM +0100, Ralf Stephan wrote:
replying to myself...
However, you know that the main application handling and, with this in inkscape at least, the main desktop widget would need a testbed before being included in the mainstream source, that's IMO the sole reason for --main-gui.
...for --new-gui should that read.
So, you might ask, what's needed before we have a Gtkmm desktop?
The todo on that is, as I see it:
Bugs
- changing msg label changes window size
- enlarging window doesn't recenter picture
- zoom out to 1%, zoom back, no longer at the same positin
Features
- really include URI input box?
I never got around to finishing this but I did code up the stuff to actually load a file via a URI so in theory if --new-gui can load a file into the canvas, it should be pretty trivial to hook this up - just add an on enter event that causes a file reload. Whether or not this is actually a useful feature or not - who knows. ;-)
- bulia's selected style widget
- layer dialog (because there will be no layer selector on desktop)
- infamous icons/menu/actions
That's all, folks! When that is done, and the logic switched, inkscape will no longer be "gtk+ with some gtkmm" but "gtkmm with some gtk+".
Addenda and help appreciated, ralf
SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (6)
-
unknown＠example.com -
Bryce Harrington -
bulia byak -
Jon A. Cruz -
Joshua A. Andler -
Ralf Stephan