Summary at bottom. [22:57] kyin: re 1361020: the tooltips also need to reflect the "easy" tool shortcut [22:57] Like B vs. Shift+F6 [22:57] Which one would you prefer to key? [22:57] B [22:59] kyin: furthermore the icons need to be localized too :P [23:01] the shortcuts would not be inherent to the icons [23:01] they would be bound to the shortcut editor, since shortcuts can change [23:01] so it would be display-text-over-icon [23:02] We push GtkActions into GtkToolbars, they don't like that very much [23:03] I know nothing about GTK so that is as far as my input can go [23:03] well, as for the icons, can't you simply overlay two icons? [23:03] one of the icons will be a dynamically generated text svg [23:04] since you're already displaying icons through svgs [23:04] You can but you get this horribly aliased GdkPixbuf [23:04] Looks like shit [23:04] well, you can composite svgs also [23:04] so create the SVG by overlay, then shove that straight into the current display mechanism [23:06] I know that editing icons.svg changes what icons are displayed, so you can generate an intermediate icons_with_shortcuts.svg on Inkscape load/shortcut change, then display that instead. [23:08] We don't have much control over the rendering of any icon [23:08] That's why custom gtk themes like Oxygen can override certain Inkscape icons [23:09] that's not really what I'm saying [23:09] We open up the icons.svg file and ask GTK to make icons accessible for us [23:09] That comes in the form of GdkPixbuf icons [23:09] ok, imagine renaming icons.svg to raw_icons.svg [23:09] then as Inkscape starts, it produces icons.svg dynamically from raw_icons.svg [23:10] by just adding text in [23:10] Which takes a 3 second delay i.e. unacceptable [23:10] Worse the more fonts you have [23:10] ok, then you can precompute it and change it only when the user changes shortcuts [23:10] is the fact that it's loading fonts the problem? [23:11] Techinically yes but there is nothing left we can do about it [23:11] fonts can also be converted to paths very nicely [23:11] I already did what was possible without patching GTK to speed launch times [23:12] if you precomputed icons.svg, and used Object to Path, there would be no fonts loaded except when changing shortcuts [23:12] this would add zero overhead except in the case of changing shortcuts [23:13] That introduces a whole 'nother architectural problem [23:13] When pushing GtkActions, why should they have to know what a "keyboard shortcut" is? [23:14] They don't care [23:14] There's no special way for GtkAction to respond to keyboard events unless triggered by a child widget [23:15] my proposal is limited only to the icon, so the only thing that changes should be the icon display, right? [23:15] I don't see where a GtkAction comes into it [23:15] except when you are rebinding shortcuts, you have to refresh the icon [23:16] GtkAction creates the toolbars and the widgets you see in them [23:16] Shrink a window down to the smallest possible size [23:16] Look for the overflow menus [23:16] yes, but isn't my proposal totally transparent to that? you are still feeding in an icons.svg directly, same as the current behavior [23:17] only difference is that you are modifying the icons.svg before feeding it in [23:17] I give up, I need sleep [23:17] ok, good night :) Ok, so: 1. Liam says that bringing in fonts leads to big loading problems. Thus, no fonts on Inkscape load. 2. You can't render text over other stuff by rendering twice, or else there are aliasing problems. 3. Shortcuts should be the "easy" ones - F# keys are undesirable. 4. The displayed shortcut depends on the key the user has chosen. That means it cannot be hardcoded. Possible implementation solution: On the very first startup of Inkscape, Inkscape takes icons.svg and creates a new icons_with_shortcuts.svg. To do this, it places shortcut text over each icon and uses "Object to Path" on the text. This procedure happens only on the very first startup and when keyboard shortcuts change. Then, icons_with_shortcuts.svg becomes a drop-in replacement for icons.svg. When the keyboard shortcuts are changed, the icons are refreshed, and GTK reloads all the icons. No change in loading times occurs because icons_with_shortcuts.svg contains no text, only paths. No rendering problems are introduced because each icon is rendered through exactly the same pathway that is currently used. I don't know if GTK renders text in SVGs better than text-converted-to-paths, but it shouldn't be a significant difference.