Font-family drop-down menu change.
Hi,
I've just checked in code that inserts a list of fonts (and font-fallback lists) that are in a document at the top of the font-family drop-down menu that is in the Text toolbar. The fonts that are in the document are rendered with a blue fill to help distinguish them from the normal list of fonts. If a font is not present on the users system, a red line is drawn on top of the font name.
Let me know what you think of this.
Tav
From what I can see, I think it's a great enhancement (haven't tried
with a font that doesn't exist yet). The only thing I would suggest adding would be a divider line at the bottom of the list of specially recognized fonts (below the blue and I'm assuming red-lined section) that really adds an extra visual separation from the main list of not used fonts. Effectively the way most word processors do it.
Cheers, Josh
On Wed, Feb 6, 2013 at 1:24 AM, Tavmjong Bah <tavmjong@...8...> wrote:
Hi,
I've just checked in code that inserts a list of fonts (and font-fallback lists) that are in a document at the top of the font-family drop-down menu that is in the Text toolbar. The fonts that are in the document are rendered with a blue fill to help distinguish them from the normal list of fonts. If a font is not present on the users system, a red line is drawn on top of the font name.
Let me know what you think of this.
Tav
Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
The menu separator added in r12105/12106 looks great!
In the 'Text and Font' dialog though, the list of font families is currently out-of-sync with the font of the current selection: the inserted (duplicate) entries of used fonts at the top, and the separator item (listed as font 'separatoR') are not taken into consideration for the position of the selected/highlighted item in the list further down. Result: in the dialog, the hightlighted font family on the left and the preview at the bottom no longer match (preview is correct).
----- Related feature request in the bug tracker: - Bug #171456 “Preferred font list in font dialog”:
| In some applications, font dropdowns have a 'recently | used fonts' area at the top of the dropdown listing | fonts that have been used recently. This would be | useful with Inkscape, since on a system with a | non-trivial amount of fonts installed, it becomes | tedious to repeatedly scroll down to select a | particular font. | | This list should be taken from the set of fonts | actually used in the document.
https://bugs.launchpad.net/inkscape/+bug/171456 -----
On 2013-02-06 15:15 +0100, Josh Andler wrote:
From what I can see, I think it's a great enhancement (haven't tried
with a font that doesn't exist yet). The only thing I would suggest adding would be a divider line at the bottom of the list of specially recognized fonts (below the blue and I'm assuming red-lined section) that really adds an extra visual separation from the main list of not used fonts. Effectively the way most word processors do it.
Cheers, Josh
On Wed, Feb 6, 2013 at 1:24 AM, Tavmjong Bah <tavmjong@...8...> wrote:
Hi,
I've just checked in code that inserts a list of fonts (and font-fallback lists) that are in a document at the top of the font-family drop-down menu that is in the Text toolbar. The fonts that are in the document are rendered with a blue fill to help distinguish them from the normal list of fonts. If a font is not present on the users system, a red line is drawn on top of the font name.
Let me know what you think of this.
Tav
Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2013-02-07 at 21:05 +0100, ~suv wrote:
The menu separator added in r12105/12106 looks great!
In the 'Text and Font' dialog though, the list of font families is currently out-of-sync with the font of the current selection: the inserted (duplicate) entries of used fonts at the top, and the separator item (listed as font 'separatoR') are not taken into consideration for the position of the selected/highlighted item in the list further down. Result: in the dialog, the hightlighted font family on the left and the preview at the bottom no longer match (preview is correct).
OK, this is going to take some time to fix properly. I'll need to move some of the code into the FontLister class so it can be used in both places. This is a better solution anyway in the long run.
Related feature request in the bug tracker:
- Bug #171456 “Preferred font list in font dialog”:
| In some applications, font dropdowns have a 'recently | used fonts' area at the top of the dropdown listing | fonts that have been used recently. This would be | useful with Inkscape, since on a system with a | non-trivial amount of fonts installed, it becomes | tedious to repeatedly scroll down to select a | particular font. | | This list should be taken from the set of fonts | actually used in the document.
https://bugs.launchpad.net/inkscape/+bug/171456
On 2013-02-06 15:15 +0100, Josh Andler wrote:
From what I can see, I think it's a great enhancement (haven't tried
with a font that doesn't exist yet). The only thing I would suggest adding would be a divider line at the bottom of the list of specially recognized fonts (below the blue and I'm assuming red-lined section) that really adds an extra visual separation from the main list of not used fonts. Effectively the way most word processors do it.
Cheers, Josh
On Wed, Feb 6, 2013 at 1:24 AM, Tavmjong Bah <tavmjong@...8...> wrote:
Hi,
I've just checked in code that inserts a list of fonts (and font-fallback lists) that are in a document at the top of the font-family drop-down menu that is in the Text toolbar. The fonts that are in the document are rendered with a blue fill to help distinguish them from the normal list of fonts. If a font is not present on the users system, a red line is drawn on top of the font name.
Let me know what you think of this.
Tav
Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2013-02-07 at 21:05 +0100, ~suv wrote:
The menu separator added in r12105/12106 looks great!
In the 'Text and Font' dialog though, the list of font families is currently out-of-sync with the font of the current selection: the inserted (duplicate) entries of used fonts at the top, and the separator item (listed as font 'separatoR') are not taken into consideration for the position of the selected/highlighted item in the list further down. Result: in the dialog, the hightlighted font family on the left and the preview at the bottom no longer match (preview is correct).
Would anybody miss the 'Text and Font' dialog now that we have the style selector in the 'Text' tool toolbar? I started the process of updating the 'Text and Font' dialog to match the Text toolbar but I have discovered that it is going to take quite a bit of work. For example the dialog font selector cannot handle font-family lists, nor does it have an entry box for typing in the name of a font. Both the toolbar and the dialog do mostly the same things but in quite different ways. If we keep the dialog, a helper class should probably be written that encapsulates the common functionality.
Tav
I wouldn't miss it. I find this to be a similar case to our moving the functionality from the gradient editor into the gradient tool controls bar. As far as I'm concerned, any time functionality moves out of a dialog and into a tool/on-canvas... it's a win. Just my .02 (and I know others feel differently)
Cheers, Josh
On Fri, Feb 8, 2013 at 9:49 AM, Tavmjong Bah <tavmjong@...8...> wrote:
On Thu, 2013-02-07 at 21:05 +0100, ~suv wrote:
The menu separator added in r12105/12106 looks great!
In the 'Text and Font' dialog though, the list of font families is currently out-of-sync with the font of the current selection: the inserted (duplicate) entries of used fonts at the top, and the separator item (listed as font 'separatoR') are not taken into consideration for the position of the selected/highlighted item in the list further down. Result: in the dialog, the hightlighted font family on the left and the preview at the bottom no longer match (preview is correct).
Would anybody miss the 'Text and Font' dialog now that we have the style selector in the 'Text' tool toolbar? I started the process of updating the 'Text and Font' dialog to match the Text toolbar but I have discovered that it is going to take quite a bit of work. For example the dialog font selector cannot handle font-family lists, nor does it have an entry box for typing in the name of a font. Both the toolbar and the dialog do mostly the same things but in quite different ways. If we keep the dialog, a helper class should probably be written that encapsulates the common functionality.
Tav
El 08/02/13 15:09, Josh Andler escribió:
I wouldn't miss it. I find this to be a similar case to our moving the functionality from the gradient editor into the gradient tool controls bar. As far as I'm concerned, any time functionality moves out of a dialog and into a tool/on-canvas... it's a win. Just my .02 (and I know others feel differently)
I wouldn't miss it either. I tried to find something that the dialog allows and it can't be done with the current options in the tool control bar and I found none.
However, I wonder if the dimensions of the bar are enough for adding more advanced features in the future. I'd really love to see in some point opentype features like ligatures and alternates, paragraph controls for flowed text (like spacing before and after), etc. and maybe that will require a dialog, so I'm not sure if killing the current dialog is "future proof".
Anyway, with the current features it doesn't seem to be necessary at all.
Gez.
On 02/09/2013 01:52 AM, John Smith wrote:
find something that the dialog allows and it can't be done with the
current options
The Text tab has the red squiggly line and right click list for quick spell check.
One more thing I'd like to add... When I focus on font selection dropdown widget and start cycling through typefaces using keyboard up/down arrow keys - only recently used fonts are being cycled through. This is a serious limitation for anyone doing creative work. There is simply no easy way to experiments with fonts without that big&ugly dialog. I'd try making arrow keys cycle through unused fonts listing. Recently/in-document-present ones are easily accessible anyway.
Vlada
On Feb 8, 2013, at 9:49 AM, Tavmjong Bah wrote:
Would anybody miss the 'Text and Font' dialog now that we have the style selector in the 'Text' tool toolbar? I started the process of updating the 'Text and Font' dialog to match the Text toolbar but I have discovered that it is going to take quite a bit of work. For example the dialog font selector cannot handle font-family lists, nor does it have an entry box for typing in the name of a font. Both the toolbar and the dialog do mostly the same things but in quite different ways. If we keep the dialog, a helper class should probably be written that encapsulates the common functionality.
I believe that in the abstract we will have need of both the toolbar and a dialog. However, in the short-term we might be able to drop the dialog for a while.
However... we probably want to get some code cleanup in place so that the bulk of the *functional* work is from a few shared data classes and helper classes, and the *ui* work might use a few shared widgets and classes. In the ideal state we could have both the toolbar and the dialog with a very minimal amount of extra code that it not shareable between them.
Part of this might share with the glyph dialog... as I know a few sneaky places that it might be having gtk kill our performance in exactly the same way that is hitting the font dialog and toolbar.
On Mon, Feb 11, 2013 at 6:17 AM, Jon Cruz wrote:
Would anybody miss the 'Text and Font' dialog now that we have the style selector in the 'Text' tool toolbar? I started the process of updating the 'Text and Font' dialog to match the Text toolbar but I have discovered that it is going to take quite a bit of work. For example the dialog font selector cannot handle font-family lists, nor does it have an entry box for typing in the name of a font. Both the toolbar and the dialog do mostly the same things but in quite different ways. If we keep the dialog, a helper class should probably be written that encapsulates the common functionality.
I believe that in the abstract we will have need of both the toolbar and a dialog.
Even if we get on-canvas spellchecking?
Alexandre Prokoudine http://libregraphicsworld.org
On Feb 10, 2013, at 6:24 PM, Alexandre Prokoudine wrote:
On Mon, Feb 11, 2013 at 6:17 AM, Jon Cruz wrote:
Would anybody miss the 'Text and Font' dialog now that we have the style selector in the 'Text' tool toolbar? I started the process of updating the 'Text and Font' dialog to match the Text toolbar but I have discovered that it is going to take quite a bit of work. For example the dialog font selector cannot handle font-family lists, nor does it have an entry box for typing in the name of a font. Both the toolbar and the dialog do mostly the same things but in quite different ways. If we keep the dialog, a helper class should probably be written that encapsulates the common functionality.
I believe that in the abstract we will have need of both the toolbar and a dialog.
Even if we get on-canvas spellchecking?
Yes, even then.
One thing we should keep in mind is that different people work from different mental models. One main example of this is contrasting the people who write down a list of turns when taking directions vs. those who draw out a map.
Another use case might be if someone has the text/font dialog detached and floating. Given that we'd have context-sensitive toolbars, some people like to keep more visible by leveraging a floating palette/dialog. In the past I've even worked with someone who hit the limit on simultaneous open windows/buffers in one of the updates to emacs. Just because my brain doesn't happen to work that way does not always mean nobody else's brain does.
One point we want to be sure to avoid is the GNOME-type oversimplification where they've confused eliminating options as the same as making a UI easier to use. We might call that "simpler vs. simplistic". With a simpler UI it is easier to get things done, but with a simplistic UI one gets blocked from doing advanced things.
On Feb 10, 2013 6:55 PM, "Jon Cruz" <jon@...18...> wrote:
On Feb 10, 2013, at 6:24 PM, Alexandre Prokoudine wrote:
On Mon, Feb 11, 2013 at 6:17 AM, Jon Cruz wrote:
I believe that in the abstract we will have need of both the toolbar
and a dialog.
Even if we get on-canvas spellchecking?
Yes, even then.
Not really with the current set of redundant features... that's all that we're losing at this point. It's still not a huge loss considering it is (or at least was) not common to see on-canvas spell checking in other design programs).
One thing we should keep in mind is that different people work from
different mental models. One main example of this is contrasting the people who write down a list of turns when taking directions vs. those who draw out a map.
We can't accommodate *every* workflow. Editing on-canvas should always be the goal where possible. I can create a list of directions or a map on the canvas with what we have now...
Another use case might be if someone has the text/font dialog detached
and floating. Given that we'd have context-sensitive toolbars, some people like to keep more visible by leveraging a floating palette/dialog. In the past I've even worked with someone who hit the limit on simultaneous open windows/buffers in one of the updates to emacs. Just because my brain doesn't happen to work that way does not always mean nobody else's brain does.
Seriously? Inkscape is not emacs (most of our users want the same workflow or shortcuts that every other application they have uses). I personally think we need to embrace the designer community before the hacker community... hackers always find ways to improve for their own preferences. For designers and most average users, they will really prefer a simple and streamlined workflow. We live in a world of touch ui and having duplicate ways of doing things or making them cumbersome will lose more users than it will gain.
One point we want to be sure to avoid is the GNOME-type
oversimplification where they've confused eliminating options as the same as making a UI easier to use. We might call that "simpler vs. simplistic". With a simpler UI it is easier to get things done, but with a simplistic UI one gets blocked from doing advanced things.
Here, we're not trying to remove functionality to reduce confusion... To me, we're removing redundancy. If the dialog were reimplemented from scratch to give awesome new features, that would rock... but having it offer nothing really beneficial over the text tool is just creating maintenance overhead as it currently exists.
I would honestly prefer to see us go a hybrid approach of what we have now plus GIMP's floating text controls. Get all of the common/basic controls into the floating control box and then only use the text tool control bar for advanced formatting features.
Cheers, Josh
P.S. Dammit Jon, what's with bringing non-plain text into the conversation? ;)
On Mon, Feb 11, 2013 at 7:28 AM, Josh Andler wrote:
I would honestly prefer to see us go a hybrid approach of what we have now plus GIMP's floating text controls. Get all of the common/basic controls into the floating control box and then only use the text tool control bar for advanced formatting features.
+100500
Alexandre Prokoudine http://libregraphicsworld.org
On Feb 10, 2013, at 7:55 PM, Alexandre Prokoudine wrote:
On Mon, Feb 11, 2013 at 7:28 AM, Josh Andler wrote:
I would honestly prefer to see us go a hybrid approach of what we have now plus GIMP's floating text controls. Get all of the common/basic controls into the floating control box and then only use the text tool control bar for advanced formatting features.
+100500
Definitely
On 02/11/2013 04:55 AM, Alexandre Prokoudine wrote:
On Mon, Feb 11, 2013 at 7:28 AM, Josh Andler wrote:
I would honestly prefer to see us go a hybrid approach of what we have now plus GIMP's floating text controls. Get all of the common/basic controls into the floating control box and then only use the text tool control bar for advanced formatting features.
+100500
No more points for you! :) Kidding... I agree wholeheartedly.
While writing this I got an idea. What if clicking at red-lined font item would select object(s) that still have missing font property set?
Vlada
Alexandre Prokoudine http://libregraphicsworld.org
On Mon, Feb 11, 2013 at 1:16 PM, Vladimir Savic wrote:
While writing this I got an idea. What if clicking at red-lined font item would select object(s) that still have missing font property set?
People on G+ also asked if blue was actually redundant (the font is available? OK, no need to visualize it).
Alexandre Prokoudine http://libregraphicsworld.org
On Mon, 2013-02-11 at 13:25 +0400, Alexandre Prokoudine wrote:
On Mon, Feb 11, 2013 at 1:16 PM, Vladimir Savic wrote:
While writing this I got an idea. What if clicking at red-lined font item would select object(s) that still have missing font property set?
People on G+ also asked if blue was actually redundant (the font is available? OK, no need to visualize it).
The blue could be removed... although I kind of like it. I set the color to blue to distinguish between document fonts and system fonts before I figured out how to add the separator.
Tav
On Feb 10, 2013, at 7:28 PM, Josh Andler wrote:
Here, we're not trying to remove functionality to reduce confusion... To me, we're removing redundancy. If the dialog were reimplemented from scratch to give awesome new features, that would rock... but having it offer nothing really beneficial over the text tool is just creating maintenance overhead as it currently exists.
I would honestly prefer to see us go a hybrid approach of what we have now plus GIMP's floating text controls. Get all of the common/basic controls into the floating control box and then only use the text tool control bar for advanced formatting features.
I think that's the main practical point that I was also backing.
The main case for having both was "in the abstract". Definitely not disputing that the current dialog can be dropped.
The main point for coding then is to avoid hardcoding functionality to widgets in the toolbar. We've had too much of that in the past, so just need to keep clear of introducing more.
On Sun, 2013-02-10 at 18:17 -0800, Jon Cruz wrote:
On Feb 8, 2013, at 9:49 AM, Tavmjong Bah wrote:
Would anybody miss the 'Text and Font' dialog now that we have the style selector in the 'Text' tool toolbar? I started the process of updating the 'Text and Font' dialog to match the Text toolbar but I have discovered that it is going to take quite a bit of work. For example the dialog font selector cannot handle font-family lists, nor does it have an entry box for typing in the name of a font. Both the toolbar and the dialog do mostly the same things but in quite different ways. If we keep the dialog, a helper class should probably be written that encapsulates the common functionality.
I believe that in the abstract we will have need of both the toolbar and a dialog. However, in the short-term we might be able to drop the dialog for a while.
However... we probably want to get some code cleanup in place so that the bulk of the *functional* work is from a few shared data classes and helper classes, and the *ui* work might use a few shared widgets and classes. In the ideal state we could have both the toolbar and the dialog with a very minimal amount of extra code that it not shareable between them.
I have started to work on this. It is going to take awhile. My plan is to move all functionality having to do with manipulating the font-family and font-style (slant, weight, etc) GtkListStore's to the FontLister class (font-lister.h). FontLister will keep track of the selected font-family and style. When font-family changes, it will update the font-style GtkListStore. It will then, when appropriate, update the selected style to the closest previously selected style (e.g. changing "italic" to "oblique").
There is much duplication of code in the text-toolbar, font-selector, text-edit that can be reduced.
Unifying the UI code would be another project.
Tav
Would anybody miss the 'Text and Font' dialog now that we have the style selector in the 'Text' tool toolbar?
The changes to the text toolbar family list are a huge win for most use cases - great work Tav !
However one (small?) problem is using the mouse wheel (or arrow keys) on the text toolbar font family combobox.
Previously this was a very fast way to test many fonts "on canvas", but now this only cycles thru the "used" fonts since any newly selected font is added to the top of the font family combobox and removed from its previous position.
The Text dialog has a similar function in that you can use the arrow keys on the family list to see a preview of the font without "applying it". But without the Text dialog i cant see a way to quickly preview many fonts ...
Any ideas ?
On Mon, 2013-02-18 at 05:45 -0800, John Smith wrote:
Would anybody miss the 'Text and Font' dialog now that we have the
style selector in the 'Text' tool toolbar?
The changes to the text toolbar family list are a huge win for most use cases - great work Tav !
However one (small?) problem is using the mouse wheel (or arrow keys) on the text toolbar font family combobox.
Previously this was a very fast way to test many fonts "on canvas", but now this only cycles thru the "used" fonts since any newly selected font is added to the top of the font family combobox and removed from its previous position.
Hmm, I hadn't noticed that. The first thing I thought of was to iterate backwards through the font-family list but that results in the same problem... as soon as you get to the document font-family part of the list and find a font that is on the system it would take you back down to the corresponding system font entry. Instead of using font-family names to decide where in the list we are we can probably keep track of an iterator. I'll add this to the to-do list. I first want to get the Text and Font dialog updated.
Tav
On 2013-02-18 20:33 +0100, Tavmjong Bah wrote:
On Mon, 2013-02-18 at 05:45 -0800, John Smith wrote:
On 2013-02-08 18:49 +0100, Tavmjong Bah wrote:
Would anybody miss the 'Text and Font' dialog now that we have the style selector in the 'Text' tool toolbar?
The changes to the text toolbar family list are a huge win for most use cases - great work Tav !
However one (small?) problem is using the mouse wheel (or arrow keys) on the text toolbar font family combobox.
Previously this was a very fast way to test many fonts "on canvas", but now this only cycles thru the "used" fonts since any newly selected font is added to the top of the font family combobox and removed from its previous position.
Hmm, I hadn't noticed that. The first thing I thought of was to iterate backwards through the font-family list but that results in the same problem... as soon as you get to the document font-family part of the list and find a font that is on the system it would take you back down to the corresponding system font entry. Instead of using font-family names to decide where in the list we are we can probably keep track of an iterator. I'll add this to the to-do list. I first want to get the Text and Font dialog updated.
Also reported as Bug #1122553 “Font selection with arrow keys in toolbar stopped working“ https://bugs.launchpad.net/inkscape/+bug/1122553
Hopefully fixed in r12149.
On Mon, 2013-02-18 at 20:43 +0100, ~suv wrote:
On 2013-02-18 20:33 +0100, Tavmjong Bah wrote:
On Mon, 2013-02-18 at 05:45 -0800, John Smith wrote:
On 2013-02-08 18:49 +0100, Tavmjong Bah wrote:
Would anybody miss the 'Text and Font' dialog now that we have the style selector in the 'Text' tool toolbar?
The changes to the text toolbar family list are a huge win for most use cases - great work Tav !
However one (small?) problem is using the mouse wheel (or arrow keys) on the text toolbar font family combobox.
Previously this was a very fast way to test many fonts "on canvas", but now this only cycles thru the "used" fonts since any newly selected font is added to the top of the font family combobox and removed from its previous position.
Hmm, I hadn't noticed that. The first thing I thought of was to iterate backwards through the font-family list but that results in the same problem... as soon as you get to the document font-family part of the list and find a font that is on the system it would take you back down to the corresponding system font entry. Instead of using font-family names to decide where in the list we are we can probably keep track of an iterator. I'll add this to the to-do list. I first want to get the Text and Font dialog updated.
Also reported as Bug #1122553 “Font selection with arrow keys in toolbar stopped working“ https://bugs.launchpad.net/inkscape/+bug/1122553
not sure if it has been mentioned (not worth mentioning in a bug)
typing the name of a font is now annoying if you have font with the same prefix already included in your document. this is especially annoying for related fonts (not font families) like source sans pro and source code pro
not really sure if there is a better way to fix this since the intended behavior could be to select the font already included. its just weird sometimes not having them next to each other in the list after typing (I probably have to untrain myself)
Andy
On Mon, Feb 25, 2013 at 12:35 AM, Tavmjong Bah <tavmjong@...8...> wrote:
Hopefully fixed in r12149.
On Mon, 2013-02-18 at 20:43 +0100, ~suv wrote:
On 2013-02-18 20:33 +0100, Tavmjong Bah wrote:
On Mon, 2013-02-18 at 05:45 -0800, John Smith wrote:
On 2013-02-08 18:49 +0100, Tavmjong Bah wrote:
Would anybody miss the 'Text and Font' dialog now that we have the style selector in the 'Text' tool toolbar?
The changes to the text toolbar family list are a huge win for most use cases - great work Tav !
However one (small?) problem is using the mouse wheel (or arrow keys) on the text toolbar font family combobox.
Previously this was a very fast way to test many fonts "on canvas", but now this only cycles thru the "used" fonts since any newly selected font is added to the top of the font family combobox and removed from its previous position.
Hmm, I hadn't noticed that. The first thing I thought of was to iterate backwards through the font-family list but that results in the same problem... as soon as you get to the document font-family part of the list and find a font that is on the system it would take you back down to the corresponding system font entry. Instead of using font-family names to decide where in the list we are we can probably keep track of an iterator. I'll add this to the to-do list. I first want to get the Text and Font dialog updated.
Also reported as Bug #1122553 “Font selection with arrow keys in toolbar stopped working“ https://bugs.launchpad.net/inkscape/+bug/1122553
Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2013-02-06 15:15 +0100, Josh Andler wrote:
On Wed, Feb 6, 2013 at 1:24 AM, Tavmjong Bah <tavmjong@...8...> wrote:
I've just checked in code that inserts a list of fonts (and font-fallback lists) that are in a document at the top of the font-family drop-down menu that is in the Text toolbar. The fonts that are in the document are rendered with a blue fill to help distinguish them from the normal list of fonts. If a font is not present on the users system, a red line is drawn on top of the font name.
Let me know what you think of this.
From what I can see, I think it's a great enhancement (haven't tried with a font that doesn't exist yet). The only thing I would suggest adding would be a divider line at the bottom of the list of specially recognized fonts (below the blue and I'm assuming red-lined section) that really adds an extra visual separation from the main list of not used fonts. Effectively the way most word processors do it.
The changes between r12104 and r12105 seem to increase launch time of inkscape trunk noticeably (it now takes longer than current stable): http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12105
Tools: installed fonts count: 'fc-list | wc -l' timing of inkscape: 'time inkscape --verb=FileQuit' (multiple runs -> average of 'real' times)
Inkscape settings: Preferences: default (new) Icons: separate $XDG_CACHE_HOME for each tested revision (trunk)
On Ubuntu 12.10 (Unity, 64bit, VM), ~1500 fonts: stable 0.48.3.1 ~10 sec trunk r11087 ~ 8 sec trunk r12108 ~14 sec
On OS X 10.7 (64bit, X11 backend), ~2700 fonts: stable 0.48.4 ~13.5 sec trunk r12104 ~12.5 sec trunk r12105 ~20.5 sec
On OS X 10.7 (64bit, Quartz backend), ~1750 fonts: stable 0.48.4 ~10 sec trunk r12104 ~ 9 sec trunk r12105/8 ~14 sec
On OS X 10.5 (32bit, X11 backend), ~1300 fonts: stable 0.48.4 ~14 sec trunk r12104 ~13 sec trunk r12106/8 ~22 sec
Questions: - Can others reproduce these results? - How much of a concern are these increased launch times?
On 2013-02-09 02:17 +0100, ~suv wrote:
The changes between r12104 and r12105 seem to increase launch time of inkscape trunk noticeably (it now takes longer than current stable):
(…)
On Ubuntu 12.10 (Unity, 64bit, VM), ~1500 fonts: stable 0.48.3.1 ~10 sec trunk r11087 ~ 8 sec trunk r12108 ~14 sec
Sorry, there's a typo (the older tested revision was more recent):
On Ubuntu 12.10 (Unity, 64bit, VM), ~1500 fonts: stable 0.48.3.1 ~10 sec trunk r12087 ~ 8 sec trunk r12108 ~14 sec
By now I have also reproduced the difference on Ubuntu with new builds after reverting the local branch to r12104 (fast) and r12105 (slower).
Hi,
I am surprised that the r12105 check-in has such a big effect. It does add a function determine where to insert a separator. The function is called at start up once per font family (why?). It does include a strcmp() but I can't see that that would be so slow. If this function is causing a slow down at start up then it should also cause a slow down in scrolling the font list where it is also called. I have less than 100 fonts on my system so I can't really test.
Tav
On Sat, 2013-02-09 at 02:17 +0100, ~suv wrote:
On 2013-02-06 15:15 +0100, Josh Andler wrote:
On Wed, Feb 6, 2013 at 1:24 AM, Tavmjong Bah <tavmjong@...8...> wrote:
I've just checked in code that inserts a list of fonts (and font-fallback lists) that are in a document at the top of the font-family drop-down menu that is in the Text toolbar. The fonts that are in the document are rendered with a blue fill to help distinguish them from the normal list of fonts. If a font is not present on the users system, a red line is drawn on top of the font name.
Let me know what you think of this.
From what I can see, I think it's a great enhancement (haven't tried with a font that doesn't exist yet). The only thing I would suggest adding would be a divider line at the bottom of the list of specially recognized fonts (below the blue and I'm assuming red-lined section) that really adds an extra visual separation from the main list of not used fonts. Effectively the way most word processors do it.
The changes between r12104 and r12105 seem to increase launch time of inkscape trunk noticeably (it now takes longer than current stable): http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12105
Tools: installed fonts count: 'fc-list | wc -l' timing of inkscape: 'time inkscape --verb=FileQuit' (multiple runs -> average of 'real' times)
Inkscape settings: Preferences: default (new) Icons: separate $XDG_CACHE_HOME for each tested revision (trunk)
On Ubuntu 12.10 (Unity, 64bit, VM), ~1500 fonts: stable 0.48.3.1 ~10 sec trunk r11087 ~ 8 sec trunk r12108 ~14 sec
On OS X 10.7 (64bit, X11 backend), ~2700 fonts: stable 0.48.4 ~13.5 sec trunk r12104 ~12.5 sec trunk r12105 ~20.5 sec
On OS X 10.7 (64bit, Quartz backend), ~1750 fonts: stable 0.48.4 ~10 sec trunk r12104 ~ 9 sec trunk r12105/8 ~14 sec
On OS X 10.5 (32bit, X11 backend), ~1300 fonts: stable 0.48.4 ~14 sec trunk r12104 ~13 sec trunk r12106/8 ~22 sec
Questions:
- Can others reproduce these results?
- How much of a concern are these increased launch times?
i would have unlinked it for a while :)
pygmee
----- Mail original ----- De: "Tavmjong Bah" <tavmjong@...8...> À: "~suv" <suv-sf@...58...> Cc: "inkscape-devel" inkscape-devel@lists.sourceforge.net Envoyé: Samedi 9 Février 2013 07:24:07 Objet: Re: [Inkscape-devel] Font-family drop-down menu change.
Hi,
I am surprised that the r12105 check-in has such a big effect. It does add a function determine where to insert a separator. The function is called at start up once per font family (why?). It does include a strcmp() but I can't see that that would be so slow. If this function is causing a slow down at start up then it should also cause a slow down in scrolling the font list where it is also called. I have less than 100 fonts on my system so I can't really test.
Tav
On Sat, 2013-02-09 at 02:17 +0100, ~suv wrote:
On 2013-02-06 15:15 +0100, Josh Andler wrote:
On Wed, Feb 6, 2013 at 1:24 AM, Tavmjong Bah <tavmjong@...8...> wrote:
I've just checked in code that inserts a list of fonts (and font-fallback lists) that are in a document at the top of the font-family drop-down menu that is in the Text toolbar. The fonts that are in the document are rendered with a blue fill to help distinguish them from the normal list of fonts. If a font is not present on the users system, a red line is drawn on top of the font name.
Let me know what you think of this.
From what I can see, I think it's a great enhancement (haven't tried with a font that doesn't exist yet). The only thing I would suggest adding would be a divider line at the bottom of the list of specially recognized fonts (below the blue and I'm assuming red-lined section) that really adds an extra visual separation from the main list of not used fonts. Effectively the way most word processors do it.
The changes between r12104 and r12105 seem to increase launch time of inkscape trunk noticeably (it now takes longer than current stable): http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12105
Tools: installed fonts count: 'fc-list | wc -l' timing of inkscape: 'time inkscape --verb=FileQuit' (multiple runs -> average of 'real' times)
Inkscape settings: Preferences: default (new) Icons: separate $XDG_CACHE_HOME for each tested revision (trunk)
On Ubuntu 12.10 (Unity, 64bit, VM), ~1500 fonts: stable 0.48.3.1 ~10 sec trunk r11087 ~ 8 sec trunk r12108 ~14 sec
On OS X 10.7 (64bit, X11 backend), ~2700 fonts: stable 0.48.4 ~13.5 sec trunk r12104 ~12.5 sec trunk r12105 ~20.5 sec
On OS X 10.7 (64bit, Quartz backend), ~1750 fonts: stable 0.48.4 ~10 sec trunk r12104 ~ 9 sec trunk r12105/8 ~14 sec
On OS X 10.5 (32bit, X11 backend), ~1300 fonts: stable 0.48.4 ~14 sec trunk r12104 ~13 sec trunk r12106/8 ~22 sec
Questions:
- Can others reproduce these results?
- How much of a concern are these increased launch times?
------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2013-02-09 07:24 +0100, Tavmjong Bah wrote:
On Sat, 2013-02-09 at 02:17 +0100, ~suv wrote:
On 2013-02-06 15:15 +0100, Josh Andler wrote:
On Wed, Feb 6, 2013 at 1:24 AM, Tavmjong Bah <tavmjong@...8...> wrote:
I've just checked in code that inserts a list of fonts (and font-fallback lists) that are in a document at the top of the font-family drop-down menu that is in the Text toolbar. The fonts that are in the document are rendered with a blue fill to help distinguish them from the normal list of fonts. If a font is not present on the users system, a red line is drawn on top of the font name.
Let me know what you think of this.
From what I can see, I think it's a great enhancement (haven't tried with a font that doesn't exist yet). The only thing I would suggest adding would be a divider line at the bottom of the list of specially recognized fonts (below the blue and I'm assuming red-lined section) that really adds an extra visual separation from the main list of not used fonts. Effectively the way most word processors do it.
The changes between r12104 and r12105 seem to increase launch time of inkscape trunk noticeably (it now takes longer than current stable): http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12105
Tools: installed fonts count: 'fc-list | wc -l' timing of inkscape: 'time inkscape --verb=FileQuit' (multiple runs -> average of 'real' times)
Inkscape settings: Preferences: default (new) Icons: separate $XDG_CACHE_HOME for each tested revision (trunk)
On Ubuntu 12.10 (Unity, 64bit, VM), ~1500 fonts: stable 0.48.3.1 ~10 sec trunk r11087 ~ 8 sec trunk r12108 ~14 sec
On OS X 10.7 (64bit, X11 backend), ~2700 fonts: stable 0.48.4 ~13.5 sec trunk r12104 ~12.5 sec trunk r12105 ~20.5 sec
On OS X 10.7 (64bit, Quartz backend), ~1750 fonts: stable 0.48.4 ~10 sec trunk r12104 ~ 9 sec trunk r12105/8 ~14 sec
On OS X 10.5 (32bit, X11 backend), ~1300 fonts: stable 0.48.4 ~14 sec trunk r12104 ~13 sec trunk r12106/8 ~22 sec
Questions:
- Can others reproduce these results?
- How much of a concern are these increased launch times?
I am surprised that the r12105 check-in has such a big effect. It does add a function determine where to insert a separator. The function is called at start up once per font family (why?). It does include a strcmp() but I can't see that that would be so slow. If this function is causing a slow down at start up then it should also cause a slow down in scrolling the font list where it is also called. I have less than 100 fonts on my system so I can't really test.
Tests measuring launch times are reproducible here: I rebuilt and timed repeated runs of the relevant revisions (r12103-12107, 12111) on my main system (OS X 10.7, both backends) again, with the same results (noticeably slower to launch with revision >= 12105, compared to stable and revision <= 12104).
Opening the font list drop-down the first time, or scrolling the font list later on is more difficult to measure for comparison... - AFAICT in a new document just opened, scrolling the font list once it has been filled (including the previews) is not noticeably slower (comparing r12104 with r12105 and r12111), but I wouldn't know how to precisely time CPU activity if the list is opened for the first time in the current session (since the list doesn't show the full length and no scrollbar the first time it is opened during a session, monitoring CPU activity seems to be the only indicator of internal font-related activities (building/sorting the list, creating the reviews?)).
Sorry if my concerns seem exaggerated: I'm a bit wary of launch times because concerns/complaints about about font-related delays when launching inkscape trunk are still regularly voiced on the irc channel (e.g. reports about 40-60 sec until the document window opens, on linux systems with 1000-2000 fonts installed, are not uncommon - and these are numbers from before the most recent changes to the font list.)
@Vlada - IIRC you just recently (2013-02-04) reported launch times of 40 or more seconds: did you notice any difference with the most recent builds since then (revision >= 12105)?
On Sat, 2013-02-09 at 13:00 +0100, ~suv wrote:
On 2013-02-09 07:24 +0100, Tavmjong Bah wrote:
I am surprised that the r12105 check-in has such a big effect. It does add a function determine where to insert a separator. The function is called at start up once per font family (why?). It does include a strcmp() but I can't see that that would be so slow. If this function is causing a slow down at start up then it should also cause a slow down in scrolling the font list where it is also called. I have less than 100 fonts on my system so I can't really test.
Tests measuring launch times are reproducible here: I rebuilt and timed repeated runs of the relevant revisions (r12103-12107, 12111) on my main system (OS X 10.7, both backends) again, with the same results (noticeably slower to launch with revision >= 12105, compared to stable and revision <= 12104).
Opening the font list drop-down the first time, or scrolling the font list later on is more difficult to measure for comparison... - AFAICT in a new document just opened, scrolling the font list once it has been filled (including the previews) is not noticeably slower (comparing r12104 with r12105 and r12111), but I wouldn't know how to precisely time CPU activity if the list is opened for the first time in the current session (since the list doesn't show the full length and no scrollbar the first time it is opened during a session, monitoring CPU activity seems to be the only indicator of internal font-related activities (building/sorting the list, creating the reviews?)).
Sorry if my concerns seem exaggerated: I'm a bit wary of launch times because concerns/complaints about about font-related delays when launching inkscape trunk are still regularly voiced on the irc channel (e.g. reports about 40-60 sec until the document window opens, on linux systems with 1000-2000 fonts installed, are not uncommon - and these are numbers from before the most recent changes to the font list.)
In r12111 I got rid of the construction of a std::map that linked font-family name to an iterator in the GtkTreeModel. It was no longer useful since a map can have only a one to one mapping while a font-family name may now appear twice in the font-family list. This may speed up start up. In r12112 I changed the "tag" used to mark a separator row from "separatoR" to "#". This should speed up start up too but I can't believe it will make that big of a difference.
Tav
With the latest changes (r12110 and r12112 tested), I get many warnings on windows vista 64 bit similar to the ones below (just copy pasted only a few of them). Besides that they could not be loaded, maybe the overhead related to the warnings could also be a reason for the slowing down suv noticed?
------------ (inkscape.exe:3476): Pango-WARNING **: couldn't load font "8514fix 10", falling back to "Sans 10", expect ugly output.
(inkscape.exe:3476): Pango-WARNING **: couldn't load font "8514oem 10", falling back to "Sans 10", expect ugly output.
(inkscape.exe:3476): Pango-WARNING **: couldn't load font "CommonBullets 10", fa lling back to "Sans 10", expect ugly output. ------------
On 2013-02-09 21:08 +0100, Kris De Gussem wrote:
With the latest changes (r12110 and r12112 tested), I get many warnings on windows vista 64 bit similar to the ones below (just copy pasted only a few of them). Besides that they could not be loaded, maybe the overhead related to the warnings could also be a reason for the slowing down suv noticed?
(inkscape.exe:3476): Pango-WARNING **: couldn't load font "8514fix 10", falling back to "Sans 10", expect ugly output.
(inkscape.exe:3476): Pango-WARNING **: couldn't load font "8514oem 10", falling back to "Sans 10", expect ugly output.
(inkscape.exe:3476): Pango-WARNING **: couldn't load font "CommonBullets 10", fa lling back to "Sans 10", expect ugly output.
I see the same warnings (for different fonts though) since revision 12105/6 with only one of the five different builds envs I'm regularly building trunk with:
- Mac OS X 10.5.8, 32bit Intel, Quartz backend with glib 2.28.8, glibmm 2.28.2, cairo 1.11.4, cairomm 1.10.0, pango 1.28.4 (ATSUI), pangomm 2.28.3 freetype 2.4.7, fontconfig 2.8.0
but not with any of the X11-based build envs (Mac OS X 10.5.8, OS X 10.7.4, Ubuntu 12.10) nor with a 64bit Quartz-based build env using more recent versions of the dependencies:
- OS X 10.7.4, 64bit Intel, Quartz backend with glib 2.34.3, glibmm 2.34.1 cairo 1.12.12, cairomm 1.10.0 pango 1.32.5 (CoreText), pangomm 2.28.4 freetype 2.4.10, fontconfig 2.9.0
Since those pango warnings with one of my own build envs only occur with rather dated versions of the dependencies (glib, cairo, pango (ATSUI)) for a specific backend (Quartz), and AFAICT do not prevent loading and using of the fonts mentioned in the warnings, I did not take those builds into account at all when comparing the launch times of trunk builds >= revision 12105.
On 2013-02-09 14:05 +0100, Tavmjong Bah wrote:
In r12111 I got rid of the construction of a std::map that linked font-family name to an iterator in the GtkTreeModel. It was no longer useful since a map can have only a one to one mapping while a font-family name may now appear twice in the font-family list. This may speed up start up. In r12112 I changed the "tag" used to mark a separator row from "separatoR" to "#". This should speed up start up too but I can't believe it will make that big of a difference.
No significant difference with r12111, r12112 and r12113.
Attached are timed results in detail from - Ubuntu 12.10 (64bit, VM) - OS X 10.7.4, X11 backend - OS X 10.7.4, Quartz backend (script runs the timed command 10 times, with 10s sleep inbetween)
If no one else can reproduce similar delays (40-50% longer launch times relative to <= r12104), there's probably no reason to further investigate (in this case: sorry for the noise on the list, I'll adjust.)
On Sun, 2013-02-10 at 16:53 +0100, ~suv wrote:
On 2013-02-09 14:05 +0100, Tavmjong Bah wrote:
In r12111 I got rid of the construction of a std::map that linked font-family name to an iterator in the GtkTreeModel. It was no longer useful since a map can have only a one to one mapping while a font-family name may now appear twice in the font-family list. This may speed up start up. In r12112 I changed the "tag" used to mark a separator row from "separatoR" to "#". This should speed up start up too but I can't believe it will make that big of a difference.
No significant difference with r12111, r12112 and r12113.
Attached are timed results in detail from
- Ubuntu 12.10 (64bit, VM)
- OS X 10.7.4, X11 backend
- OS X 10.7.4, Quartz backend
(script runs the timed command 10 times, with 10s sleep inbetween)
If no one else can reproduce similar delays (40-50% longer launch times relative to <= r12104), there's probably no reason to further investigate (in this case: sorry for the noise on the list, I'll adjust.)
The thing to do is to try to profile the code to see where the time is being spent. I won't attempt this now as I am planning on some major changes as I try to merge various font handling code.
Tav
~suv: I can confirm that big of a difference. On my Ubuntu install (these were run multiple times, I just grabbed the most average looking ones):
12104: real 0m7.352s user 0m7.120s sys 0m0.064s
12114: real 0m11.213s user 0m10.901s sys 0m0.100s
Cheers, Josh
On Sun, Feb 10, 2013 at 7:53 AM, ~suv <suv-sf@...58...> wrote:
On 2013-02-09 14:05 +0100, Tavmjong Bah wrote:
In r12111 I got rid of the construction of a std::map that linked font-family name to an iterator in the GtkTreeModel. It was no longer useful since a map can have only a one to one mapping while a font-family name may now appear twice in the font-family list. This may speed up start up. In r12112 I changed the "tag" used to mark a separator row from "separatoR" to "#". This should speed up start up too but I can't believe it will make that big of a difference.
No significant difference with r12111, r12112 and r12113.
Attached are timed results in detail from
- Ubuntu 12.10 (64bit, VM)
- OS X 10.7.4, X11 backend
- OS X 10.7.4, Quartz backend
(script runs the timed command 10 times, with 10s sleep inbetween)
If no one else can reproduce similar delays (40-50% longer launch times relative to <= r12104), there's probably no reason to further investigate (in this case: sorry for the noise on the list, I'll adjust.)
On Feb 10, 2013, at 1:48 PM, Josh Andler wrote:
~suv: I can confirm that big of a difference. On my Ubuntu install (these were run multiple times, I just grabbed the most average looking ones):
12104: real 0m7.352s user 0m7.120s sys 0m0.064s
12114: real 0m11.213s user 0m10.901s sys 0m0.100s
Cheers, Josh
I'm getting ready to poke about in that a bit, but I think I have an idea of one of the problems.
I know a list using markup was a problem in GTK 2.x... might be for 3 also.
On Sun, Feb 10, 2013 at 6:12 PM, Jon Cruz <jon@...18...> wrote:
I'm getting ready to poke about in that a bit, but I think I have an idea of one of the problems.
I know a list using markup was a problem in GTK 2.x... might be for 3 also.
I recall us discussing this in relation to the customizable keyboard shortcuts in the preferences dialog. Would you mind having a look there too? The difference here though is that I don't believe the startup time was affected by the list with markup in the prefs dialog... only major performance hit is when it's being fully populated/updated.
As an aside, is it possible to make it run the font list "population routine" when the text tool is first invoked rather than when you first try to bring up the list? If we could eliminate that delay the first time you try to bring up the list of fonts, it would be a huge user-perceived win.
Cheers, Josh
On Feb 10, 2013, at 7:43 PM, Josh Andler wrote:
I recall us discussing this in relation to the customizable keyboard shortcuts in the preferences dialog. Would you mind having a look there too? The difference here though is that I don't believe the startup time was affected by the list with markup in the prefs dialog... only major performance hit is when it's being fully populated/updated.
Given a start-up timeframe slowdown, we might get some other issue happening here. Definitely worth me looking at.
As an aside, is it possible to make it run the font list "population routine" when the text tool is first invoked rather than when you first try to bring up the list? If we could eliminate that delay the first time you try to bring up the list of fonts, it would be a huge user-perceived win.
Yes, in theory we can do that. Also we can do things like with the icons and incrementally work on it during an idle callback.
*maybe*
If we hit that GTK issue, then it was the act of gtk instantiating the new list widget per window that would hit the issue.
On Sun, 2013-02-10 at 18:12 -0800, Jon Cruz wrote:
On Feb 10, 2013, at 1:48 PM, Josh Andler wrote:
~suv: I can confirm that big of a difference. On my Ubuntu install (these were run multiple times, I just grabbed the most average looking ones):
12104: real 0m7.352s user 0m7.120s sys 0m0.064s
12114: real 0m11.213s user 0m10.901s sys 0m0.100s
Cheers, Josh
I'm getting ready to poke about in that a bit, but I think I have an idea of one of the problems.
I know a list using markup was a problem in GTK 2.x... might be for 3 also.
The list was already using markup (to get the font sample). One thing that did appear to slow down start-up was adding the separator function.
Tav
On 2013-02-11 11:10 +0100, Tavmjong Bah wrote:
On Sun, 2013-02-10 at 18:12 -0800, Jon Cruz wrote:
On Feb 10, 2013, at 1:48 PM, Josh Andler wrote:
~suv: I can confirm that big of a difference. On my Ubuntu install (these were run multiple times, I just grabbed the most average looking ones):
12104: real 0m7.352s user 0m7.120s sys 0m0.064s
12114: real 0m11.213s user 0m10.901s sys 0m0.100s
Cheers, Josh
I'm getting ready to poke about in that a bit, but I think I have an idea of one of the problems.
I know a list using markup was a problem in GTK 2.x... might be for 3 also.
The list was already using markup (to get the font sample). One thing that did appear to slow down start-up was adding the separator function.
One aspect I missed with my earlier tests: AFAICT it's not just affecting launch time, it also noticeably delays opening additional document windows from within the running inkscape instance (starting with r12105).
participants (11)
-
unknown＠example.com -
Alexandre Prokoudine -
Andy Fitzsimon -
Guillermo Espertino (Gez) -
John Smith -
Jon Cruz -
Josh Andler -
Kris De Gussem -
Tavmjong Bah -
Vladimir Savic -
~suv