Difference between revisions of "FeatureNotePad"
(Added two "working with text" ideas fixed someone's rudeness) |
m (link fix) |
||
(5 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
Here is a notepad for quickly noting down good ideas (newest first please). If you're bored, feel free to write these as full feature requests and add to the tracker, or as separate Wiki pages. | Here is a notepad for quickly noting down good ideas (newest first please). If you're bored, feel free to write these as full feature requests and add to the tracker, or as separate Wiki pages. | ||
FeatureNotePadArchive (dupes, already implemented ideas, those with acceptable workarounds, those that cannot be implemented at all) | [[FeatureNotePadArchive]] (dupes, already implemented ideas, those with acceptable workarounds, those that cannot be implemented at all) | ||
---------- | ---------- | ||
<i>wwwwolf writeth:</i> | |||
An XSL stylesheet to convert from [[InkscapeSVG]] to [[PlainSVG]] | |||
If we had that, it wouldn't be necessary to use Inkscape's exporter in all situations - it could be used to make plain SVG without user intervention, automatically, and in places where Inkscape isn't even installed - all you need is an XSLT processor. This would be highly cool since some of the programs (I'm looking at YOU, Scribus *and* rsvg) at times choke randomly on Inkscape markup but render Inkscape's plain SVG without problems. | |||
---------- | |||
Extend stroke rendering capabilities | |||
Make it possible for the definition of the rendering of a stroke to be scriptable (at stroke time). For instance, I might want to render a path as a series of flames - the size of the flames somewhat randomized, perhaps, along the stroke. Because they are flames, my script would make sure they're always pointing the same direction (up) along the stroke. Similarly, a series of water droplets would always be rendered dripping in a downward direction. | |||
Note that much of this functionality could also be done outside of scripting, using an approach similar to tiled clones. | |||
---------- | |||
<i>wwwwolf writeth:</i> | |||
WIREFRAME MODE | WIREFRAME MODE | ||
Line 23: | Line 38: | ||
* Visual cues for Pen tool cursor in append mode, and other modes (i.e., +, -, ^, etc.) | * Visual cues for Pen tool cursor in append mode, and other modes (i.e., +, -, ^, etc.) | ||
* Visual cue for selected groups (i.e., solid marquee instead of dashed) | * Visual cue for selected groups (i.e., solid marquee instead of dashed) | ||
* Terminiate continuous draw mode when a path is closed in append mode | * (DONE) Terminiate continuous draw mode when a path is closed in append mode | ||
* Undo in draw mode removes last node, not the entire path, same as backspace key | * Undo in draw mode removes last node, not the entire path, same as backspace key | ||
* Set the ruler 0, 0 coordinates by dragging a cross out of the rulers' corner / double click to set precisely, according to 0,0 index of page dimensions. | * Set the ruler 0, 0 coordinates by dragging a cross out of the rulers' corner / double click to set precisely, according to 0,0 index of page dimensions. | ||
Line 30: | Line 44: | ||
Bulia: I'm not seeing the DONE features in current builds. What am I missing? -kw | Bulia: I'm not seeing the DONE features in current builds. What am I missing? -kw | ||
:only one is marked DONE, actually, so I changed formatting to make this clear | |||
<HR> | <HR> | ||
Line 86: | Line 101: | ||
Sketch | Sketch | ||
(written in Python) possibilities in Inkscape. | (written in Python) possibilities in Inkscape. | ||
- Also Scribus has good NodeTool, and good text tool featuring textbox (frame) | - Also Scribus has good [[NodeTool]], and good text tool featuring textbox (frame) | ||
or text on a path. | or text on a path. | ||
Line 98: | Line 113: | ||
What I can expect from this project is a better integration with gnome-office. | What I can expect from this project is a better integration with gnome-office. | ||
I dream for a really integrated gnome-office with a lot of code sharing via libraries. | I dream for a really integrated gnome-office with a lot of code sharing via libraries. | ||
For example, a vectorial drawing soft has lot of things in common with glabels, AbiShow, etc ... | For example, a vectorial drawing soft has lot of things in common with glabels, [[AbiShow]], etc ... | ||
We have a lot to learn from Koffice in this respect. | We have a lot to learn from Koffice in this respect. | ||
So please create a fully capable GtkVectDraw library ! | So please create a fully capable [[GtkVectDraw]] library ! | ||
------------------------- | ------------------------- | ||
''Emphasis on a small core plus modular extensions for features (a la Mozilla Firebird)'' | ''Emphasis on a small core plus modular extensions for features (a la Mozilla Firebird)'' | ||
Line 217: | Line 232: | ||
Ming library: [[http://ming.sourceforge.net/]] | Ming library: [[http://ming.sourceforge.net/]] | ||
Svg2Swf python script (uses Ming): [[http://www.eskimo.com/~robla/svg2swf/]] | [[Svg2Swf]] python script (uses Ming): [[http://www.eskimo.com/~robla/svg2swf/]] | ||
------- | ------- | ||
Line 224: | Line 239: | ||
I have used the Mentor Graphics CAD tools for editing | I have used the Mentor Graphics CAD tools for editing | ||
schematics and PCB layouts, and the built-in support for mouse | schematics and PCB layouts, and the built-in support for mouse | ||
gesture has helped the productivity a lot. Granted CAD drawing | gesture has helped the productivity a lot. Granted CAD drawing | ||
is not exactly vector drawing, but it is not too far apart. | is not exactly vector drawing, but it is not too far apart. | ||
Line 239: | Line 255: | ||
First: | First: | ||
* remove "get from dropper" (always on, via SetColorSignal) (DONE, no signal necessary, just picks new color from selection) | * remove "get from dropper" (always on, via [[SetColorSignal]]) (DONE, no signal necessary, just picks new color from selection) | ||
* remove "mode", make global preference "Store colors as rgb/cmyk" (DONE, it's not about storing color actually, so just removed) | * remove "mode", make global preference "Store colors as rgb/cmyk" (DONE, it's not about storing color actually, so just removed) | ||
Line 260: | Line 276: | ||
* change gradient display/controls to match those of the toolbar! | * change gradient display/controls to match those of the toolbar! | ||
--------- | --------- | ||
A new "transform with selection" toggle: font (see FontKerning, toggle between [0 or 1, depending on optimize/preserve] and 2). | A new "transform with selection" toggle: font (see [[FontKerning]], toggle between [0 or 1, depending on optimize/preserve] and 2). | ||
---------- | ---------- | ||
Line 270: | Line 287: | ||
:Probabbly to dificult to do well, just export to svg | :Probabbly to dificult to do well, just export to svg | ||
---------- | |||
On export to Postscript, special-case treatment of text/fonts so that, instead of outputting each instance of a character as a separate set of coordinates, output the definition of the character once, and then use it (with matrix transforms) for each instance of that character. | |||
On export to Postscript, allow for specifying use of fonts-and-text (particularly useful when planning to create PDFs). | |||
On export to Postscript a) warn about transparencies, b) attempt to automatically correct for transparencies by i) converting underlying fragments to transformed values (complex) or ii) embed a bitmap-based fill. Possibly allowing optional choice of approach. | |||
Possibly provide a direct-to-PDF export as well? | |||
Possibly allow for a UI mechanism that lets any code in the system define a selection set of objects, displaying their IDs in a floating dialog. Clicking on the IDs would select the object. The postscript export warning about transparent objects, then, would be able to return with a selection set through which the user could iterate in order to fix each transparent object. | |||
Provide a saving option which gathers the fonts used by the SVG file (as well as any other externally referenced files) for transfer to another machine. Preferably stored in a zip or similar mechanism so that they're easy to share. This is basically a "collect resources" feature. | |||
---------- | |||
Provide a print-preview, print-settings, page-setup style printing framework (a-la Corel, Adobe, etceteras). | |||
---------- | |||
Provide a UI mechanism where one can cycle through just those object intersected by a pick point. That is, in a large, heavily overlapping graphic, you could point at the thing you want (even though it's behind three or four other things) and quickly choose that object, either from a menu, or by some form of constrained "tab-key" operation. | |||
---------- | |||
On right-click menu selection of a dialog (fill and stroke, or object properties, for instance), set focus to the dialog selected to avoid the need for a mouse-seek-and-click to do the set-focus. |
Revision as of 02:33, 22 January 2006
Here is a notepad for quickly noting down good ideas (newest first please). If you're bored, feel free to write these as full feature requests and add to the tracker, or as separate Wiki pages.
FeatureNotePadArchive (dupes, already implemented ideas, those with acceptable workarounds, those that cannot be implemented at all)
wwwwolf writeth:
An XSL stylesheet to convert from InkscapeSVG to PlainSVG
If we had that, it wouldn't be necessary to use Inkscape's exporter in all situations - it could be used to make plain SVG without user intervention, automatically, and in places where Inkscape isn't even installed - all you need is an XSLT processor. This would be highly cool since some of the programs (I'm looking at YOU, Scribus *and* rsvg) at times choke randomly on Inkscape markup but render Inkscape's plain SVG without problems.
Extend stroke rendering capabilities
Make it possible for the definition of the rendering of a stroke to be scriptable (at stroke time). For instance, I might want to render a path as a series of flames - the size of the flames somewhat randomized, perhaps, along the stroke. Because they are flames, my script would make sure they're always pointing the same direction (up) along the stroke. Similarly, a series of water droplets would always be rendered dripping in a downward direction.
Note that much of this functionality could also be done outside of scripting, using an approach similar to tiled clones.
wwwwolf writeth:
WIREFRAME MODE
"Outline" mode. "Draft" mode. "X-Ray" mode. You know what I'm talking about. The mode where only the edges of the paths are drawn, stroked at constant width. Turn it off, and you have everything visible normally again.
I've seen this in Adobe Illustrator (Ctrl+Y), Sketch, Corel Draw!, even the good ole 1991 vintage Arts & Letters.
I think this is pretty important because I love to work with lots of overlapping, same-or-nearly-same-color objects that don't have strike at all. Would make drawing easier...
kwixson writes:
Some little ideas that I haven't had time to fully spec yet, but I don't want to forget...
- Text tool can optionally draw (with click and drag, as opposed to just click) a text box of defined dimensions, into which text is flowed automatically.
- Edge offsets in flowed text with automatically drawn linked offsets of the object with no fill or stroke properties.
- Cursor icons for Pen, Pencil and Calligraphy tools
- Visual cues for Pen tool cursor in append mode, and other modes (i.e., +, -, ^, etc.)
- Visual cue for selected groups (i.e., solid marquee instead of dashed)
- (DONE) Terminiate continuous draw mode when a path is closed in append mode
- Undo in draw mode removes last node, not the entire path, same as backspace key
- Set the ruler 0, 0 coordinates by dragging a cross out of the rulers' corner / double click to set precisely, according to 0,0 index of page dimensions.
- Make space bar held down transform cursor to Selector tool until spacebar is released, with any tool except Text.
Bulia: I'm not seeing the DONE features in current builds. What am I missing? -kw
- only one is marked DONE, actually, so I changed formatting to make this clear
Björn writes: 1.) _Pressure sensitivity_
- Everybody else got it (Xara, Illustrator, even Gimp) and it is almost necessary for professional drawing.
2.) Sub-pixel resolution in drawing, is possible with XInput i think?
- Again, improves drawing by hand
3.) Smooth drawing, smooth over small irrelegularities from mouse/drawing board
- Same as all of the above, improves drawing, makes it a whole lot more fun! :)
It doesn't seem so hard to implement but it would make a huge diffrence!
Aside from that, I love where Inkscape is going, the interface is great to work with and it just keeps getting better! I find myself building from CVS so I dont't miss out.
GREAT WORK GUYS! :)
Ilja writes:
1.) Extrusion of Objects 2.) Dropshadow, kind of a clone - a bit fuzzy and little shifted behind
Daddio writes:
A couple of Small features that would help those of us a lot that like to draw a basic shape and then tweak it in the xml editor:
1) the ablility to convert the SVG coordinates in a path to and fromrelative coordinates (small case m's l's c's a's) except perhaps the initial M
2) the ability to truncate (or even better, round) the SVG coordinates to 1, 2 or zero (etc) decimal places.
3) Set a decimal place limit so the generated SVG will stay within that limit. I don't usually need or want 0.0006 precision!
fantasai seconds these and suggests a way of saving as Plain SVG with metadata, since things like the title, author, and license terms -- which are applicable to published images but not so much to in-process drafts -- shouldn't be thrown out with the "last used zoom level" data, which are just junk in a publication-ready image.
Slapo writes:
it would be nice to have features like obejct shadows, round corners and square gradient in Sodipodi. I think those are the things I am missing in it and other users would appreciate as well. If you need some SVG code examples, I'll e-mail it to you.
njh writes:
Orthogonal lines best-fit to a pen path would be useful for quickly sketching diagrams.
-Scribus is a DTP coded in C++ (but with Qt). it can work with Python Script. May be have a look at this could help doing the same in Inkscape. -If the later can be done, this will help eventually include some of good Sketch (written in Python) possibilities in Inkscape. - Also Scribus has good NodeTool, and good text tool featuring textbox (frame) or text on a path.
cheers Cédric
plugins for ways to warp and bend things
What I can expect from this project is a better integration with gnome-office. I dream for a really integrated gnome-office with a lot of code sharing via libraries. For example, a vectorial drawing soft has lot of things in common with glabels, AbiShow, etc ... We have a lot to learn from Koffice in this respect.
So please create a fully capable GtkVectDraw library !
Emphasis on a small core plus modular extensions for features (a la Mozilla Firebird)
But *please* maintain a plugin-pack, and ship it with Inkscape. The way Firebird works sucks. Firebird has poor tab-implementation, and there are >10 extensions that try to improve it, while only 1 good version is needed. The list with extensions is chaos, don't let it be so with Inkscape...
If you want to add new features, think about layers a la gimp. Sketch uses them and it's very convenient.
- In a vector drawing program, what would be the actual difference between a "layer" and a "group"? -- kaj
Ease of use mostly. If you have a complicated drawing, layers are very usefull to organize your work, move them up or down, make them invisible, apply layer transformations, etcetera. Groups could be used in theory to make a Gimp-like layer toolbox, but its not very practical.
If, for example, you have an image with layers and want to save it to SVG, you just export it whilst flattening the layers, just like you export a PNG from the Gimp today.
I'm I alone in thinking that a Vectorbased drawing program, with the interface built like the Gimp 1.3 series, would be very wanted and usefull? Similar to how Adobe's Photoshop and Illustrator have a similar GUI concept? -- anonymous
- I disagree... all they need is a little widget that shows all the groups as a tree of layers. And if you group, two groups, : you'd create a new layer, with the two original groups/layers as a child of the new layer....
- voila, best of all worlds.
This behaviour of hierarchycal tree of objects, calling the highest hierarchycal level the 'layers' level, and the other hierarchical levels called 'groups' or 'subgroups'. It would be good some layer/group operations like changing the visibility of the hole layer/group, being capable of selecting on subelement, working with the hole layer or with a group or with an element. With all these behaviour and a hierarchical tree to work with it, it would resemble the Adobe Illustrator object model that (I think) is the most powerfull and flexible one.
I asked a very similar question about why use layers to the Dia project and here is one of the responses
The ability to be able to easily hide, move and remove layers is certainly a factor that could be mitigated by a more powerful tree view of the document but at the very least there are users who find it convenient so no vector program should remove Layers without adding a bettter alternative
http://www.mail-archive.com/dia-list@gnome.org/msg05072.html
The below is in regards to Sodipodi 0.32:
2. The XML viewer doesn't appear to allow selecting multiple items. Often times I want to makes changes to many items at once and sometimes I'll be working in the XML viewer. Since this was the only way I could figure out how to select individual items in a group it seems completely impossible to select several items in a group.
Some notes on feel:
4. The mouse event system feels a bit wonky. For example, if I take a fairly complex design which can be a little bit sluggish when editing and
make adjustments to a path node the cursor doesn't release as soon as I let go of the mouse button. So when I'm working quickly what happens is I tweak a node, let go of the mouse button, then move the mouse and it keeps adjusting the node even though I'm not holding the button. This slows me down considerably because I have to wait after letting go of the mouse button each time. It also does this when scrolling the main view using the middle mouse button. I'll scroll the view over, let go of the mouse button, then when I move the mouse the view still scrolls for a second or two. Very annoying. :)
Feature "wants":
9. More powerful selection commands. Some examples (from Illustrator):
Select by fill color Select by same stroke and fill etc...
11. More and user defined hot-keys. Can I set any command/mode to a
hot-key?
I noticed that gimp does a cool hack today, they use an image thumbnail of the drawing as the window manager icon for the drawing window, you should do that with inkscape too and it is actually usefull, consider I have fix inkscape windows with different flags, with this hack I will be able to identify each window in the tasklist and don't have to search so much
Also, I really wish inkscape where session aware like gedit, so that when I asks nautilus to open a new image it does so in the existing inkscape session instead of starting a new instance
http://bugzilla.gnome.org/show_bug.cgi?id=107668 - the discussion in that bug report might be of interest to you guys too. the participants are Dom (librsvg), Owen and the Gimp guys
-- Uraeus
when given a nonexisting file name on the command line, create that file (with an error report too)
Ability to export to uncompressed TIFF.
Add multi-page support, default layouts for all pages, etc.
Ability to import Dia objects.
Restricted Inkscape mode to work like Dia. There's nothing that Dia can do that is not possible to
do in Inkscape.
Export .eps. Enough said.
However you gave me an idea: I can store past viewport not only before I do zoom, but also after that; later, when a next zoom is started, I will compare the current viewport with the last stored and, if it's the same, not store it. This way I will be adding one viewport record if there was no panning between zooms and two records if there was panning, these records storing the first and last viewports at this zoom. I think it will be a bit more convenient this way.
- Well, what I had in mind is that viewport undo steps would be separated by editing operations -- so e.g. consecutive pans/zooms with no edits in between them would be coalesced into a single zoom undo step.
Exporting vectors as swf files. While this is probably not on the top of everyone's wishlist, it would make inkscape the tool of choice for editing shapes for flash, which is an area where the flash editor does a horrible job. Flash import capabilities for vectors are also very limited, making AI a requirement in order to convert between flash and svg.
Given that svg is going to be replacing flash very (very) soon, a flash import capability would also make life easier for a lot of people...
Ming library: [[1]] Svg2Swf python script (uses Ming): [[2]]
Add support for mouse gestures. I have used the Mentor Graphics CAD tools for editing schematics and PCB layouts, and the built-in support for mouse
gesture has helped the productivity a lot. Granted CAD drawing is not exactly vector drawing, but it is not too far apart. There is a library libstroke that provides gestures support, but I don't have any idea how usable that would be for inkscape.
Find dialog: collapsable panes: Size & Position (X, Y, W, H; tolerance), Attribute (Name, Value). Pasting in the id, style, size/position fields (add buttons for pasting?) pastes the id, style, size/position of the object on clipboard. Add a regexp checkbox, when it's on matches are always exact but with a regexp matcher. Checkboxes: limit search to selection, (later) to current layer, possibly in (in)visible or (in)sensitive only.
Plan for fill&stroke:
First:
- remove "get from dropper" (always on, via SetColorSignal) (DONE, no signal necessary, just picks new color from selection)
- remove "mode", make global preference "Store colors as rgb/cmyk" (DONE, it's not about storing color actually, so just removed)
- remove redundant color picker selector (DONE)
- transientize, remember size&position, remove Close in the color selector window from Doc props; find if there are others like it (DONE)
- Make evenodd switch a pair of toggle buttons inside colorselector
Then:
- remove "apply to"; make all shapes use current color, but on prefs page for each tool, make a switch between "use current" (default on for shapes) or "use its own style" (default on for pens & text), plus a button "take style from the selection". (DONE)
- enable partial color settings (bug http://sourceforge.net/tracker/index.php?func=detail&aid=937393&group_id=93438&atid=604306; actually that will be a separate "adjust colors" dialog)
- add master opacity from object props (DONE), add fill opacity/stroke opacity sliders common to all fill/stroke types (gradients, patterns, color)
- maybe separate it into Color and Stroke dialogs
- change gradient display/controls to match those of the toolbar!
A new "transform with selection" toggle: font (see FontKerning, toggle between [0 or 1, depending on optimize/preserve] and 2).
Filter to import Corel Draw Files and Adobe Illustrator Files (very important at my opinion)
- Probabbly to dificult to do well, just export to svg
On export to Postscript, special-case treatment of text/fonts so that, instead of outputting each instance of a character as a separate set of coordinates, output the definition of the character once, and then use it (with matrix transforms) for each instance of that character.
On export to Postscript, allow for specifying use of fonts-and-text (particularly useful when planning to create PDFs).
On export to Postscript a) warn about transparencies, b) attempt to automatically correct for transparencies by i) converting underlying fragments to transformed values (complex) or ii) embed a bitmap-based fill. Possibly allowing optional choice of approach.
Possibly provide a direct-to-PDF export as well?
Possibly allow for a UI mechanism that lets any code in the system define a selection set of objects, displaying their IDs in a floating dialog. Clicking on the IDs would select the object. The postscript export warning about transparent objects, then, would be able to return with a selection set through which the user could iterate in order to fix each transparent object.
Provide a saving option which gathers the fonts used by the SVG file (as well as any other externally referenced files) for transfer to another machine. Preferably stored in a zip or similar mechanism so that they're easy to share. This is basically a "collect resources" feature.
Provide a print-preview, print-settings, page-setup style printing framework (a-la Corel, Adobe, etceteras).
Provide a UI mechanism where one can cycle through just those object intersected by a pick point. That is, in a large, heavily overlapping graphic, you could point at the thing you want (even though it's behind three or four other things) and quickly choose that object, either from a menu, or by some form of constrained "tab-key" operation.
On right-click menu selection of a dialog (fill and stroke, or object properties, for instance), set focus to the dialog selected to avoid the need for a mouse-seek-and-click to do the set-focus.