On Apr 18, 2006, at 5:51 AM, jiho wrote:
Improving "Inkscape I/O": this is in fact several "small" (or not) things. First would be to finalize the inkjar/zip file formats and use this by default so that inkscape new comers are not bothered with the red cross again. I don't know if it is easy or even possible but embedding fonts into the document would be great too. I was perfectly happy with the link behavior but got to work with people who didn't understand it... and I changed my mind ;-) This would call for a way to edit embedded bitmaps but this was already mentioned (Verse plugin to link to Gimp or direct editing). In parallel a rework of the import/ export/save as dialogs could be achieved with:
- link or embed in import (if possible with bitmap _and_ vector, so
that it's possible to link to SVG files too, click on the linked file and have it open in a new instance of inkscape)
- restrict to selection or to any part of the drawing in export
with bitmap _and_ vector. For vector this look like just clipping the SVG to the selection and export it so it seems straightforward now that clipping exists. then all non conserving vector file formats (EPS, POV, TEX etc.) could be moved to the export dialog
- the save as dialog keeps only inkjar/zip, inkscape svg and
inkscape svgz (and plain svg and compressed plain svgz?)
There's one main caveat I would point out in regards to save-all-in- one behavior. The main argument in favor of it is "Users have complained when they move their SVG file around and the images break"
However, I'd break it down to be "Users are expecting A and instead getting B" those users complain "Users are expecting B and are getting B" those users are silent as things work the way they expect them to.
So... if we switch our behavior from B to A, then those first users will be quiet, but the second group will start to complain.
The solution here is probably not to just toss things one way or the other, but instead to manage user expectations. Some base UI and workflow tweaks to make it clear to users what exactly is going on. And the way things are looking to me, a subtle overall approach might be best
Improving the color panel: This would require to fix some UI things:
- "small" size does not look like small when first opening
inkscape, you have to switch to an other size and then witch back to small to have them small
- the rolling menu on the right of the panel is small when first
opening inkscape but as soon as something is changed inside it, it becomes larger. while becoming larger it eats a lot of space so it might not be the best choice for a menu. right click? there was some discussion about it earlier on the mailing list.
These have been addressed in SVN already.
- add the possibility to resize the panel and/or have it to the
right of the desktop Then adding some functionality:
- save the state of the panel (size, position, size of the color
swatches, which palette was selected) on a per document basis
- add a way to build some custom palettes, which would be stored as
a (xml?) file. The intend of this is to have to possibility to post them somewhere on the web site and exchange color palettes between users. So this requires also a simple interface to add a downloaded palette to the menu (like a Add palette... menu item). [Side note: this could be extended to effects too, when there will be too many of them to include them all in the menu and this would add a nice community aspect to the website ;-)]
- add a style palette, renewed on a per document basis where the
user can store fill, stroke and font properties of objects in the drawing by dragging and dropping them on the panel. It would also be nice to have the possibility to exchange those and to import styles from another document into a new one. I think there is a large potential for those in a company or any communication agency which works with some specific templates (in terms of colors, fonts...) for each product.
- maybe add a "current styles" palette which is dynamically filled
with all styles of objects in the document. OmniGraffle does this and I find this occasionally useful. But it might be memory/CPU hungry.
All planned and very doable. To get the last few we'll need good non- RGB color support and a few other things in, but this might be a good SoC project.
Improving the Text Tool: I use text and flowed text a lot and these are things that could be improved IMHO:
- flowed text does not respect the default style of the text tool
- when flowing a text which already contains line breaks, the line
breaks are not conserved and are converted to spaces. It would be better to conserve them.
- when the style selected in the the Text and Font dialog is
applied it erases any other style applied to some part of the text (like italics on some words, bold on others...), it would also be better to keep them. A general way to address this would be to rework the Text and Font dialog (and I think it was planned anyway):
- It could include some kind of "story editor" a la Scribus instead
of the Text tab. Then text editing and formatting could be done there avoiding the style erase mentioned above.
- I don't know a font manager on linux but I guess there should be
at least one. It would be nice to have some font collections before the font family selector, in order to narrow the search. I have over 300 fonts on my system (and I guess this is not much compared to some graphic designer) and it is already difficult to find the one I want in the Text and Font dialog. BTW: the Font family list is not searchable with the keyboard while every other GTK list I have seen is.
Much of that seems to be a good-sized chunk that would work for SoC. Some of the style re-work could be cross-leveraged with the palette stuff. And actually, the palette classes themselves are not tied to colors, and are intended to be used for styles, patterns, layers, etc.