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)
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.
Orthogonal lines best-fit to a pen path would be useful for quickly sketching diagrams.
Appply transform function is something I'd really like to see.
-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.
when creating a new object, it should have the same attributes as the last I mean: drawind shapes, if I set one to stroke and fill of a certin kind, each after that should start with the same until I change it. a palette would be nice, but this is a little different. if I draw a rect, then set it to blue, 1px black stroke, then draw another, it should be blue, 1px black stroke these are not settings that are save from session to session, just while working. small detail, but it'd make things much easier. in minimum it should behave differently for shapes/text You definitely do not want text to appear colored/filled by default
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...
BTW, is there already some good user-documentation for Sodipodi/Inkscape? Because as a user, I don't mind how bad the code is and how much dead code there is, all I need is a manual to learn that other 90% of the app. With a manual I can really *use* the program, find bugs, and file bugreports....
Sodipodi is very nice, although I have a huge dislike for the interface - while original, it feels very "cludgy" to use. I would love to see a gimp-1.3 inspired interface (1.2 wasn't very nice with it's window juggling but 1.3 has a much nicer drag and drop way of organising & grouping the windows you use more often). With a ui overhaul Sodipodi/Inkscape could be very, very nice.
There are still many artists who use very old versions of Illustrator and Corel Draw so as to get the very most out of cheap hardware and hopefully that is a market that InkScape can soon grab. Jasc Web Draw is adequate but if InkScape can provide a consumer friendly user interface it will serve as a big kick in the Pants for Jasc and hopefully force them to improve their low budget Vector Graphics toy.
If you want to add new features, think about layers a la gimp. Sketh 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
I also found the menus particularly hard to use.
I find the whole concept of a "dialogs" menu to be extremely abberent and a rather useless nonsense grouping about as much use as dumping them under "miscellanous". There is also a whole lot of functionality in the Toolbox and various dialogs that I expected to find as a menu item but did not which rather threw me for a curve ball.
I'd like the menus to be at least similar to Adobe Illustrator so that I any learning I do can be reapplied and put on my CV as a skill that managment types will recognise rather than give me funny looks for (the GIMP is still not a funny name, it is just embarassing).
I cant wait to see Sodipodi and Inkscape compete and improve each other.
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.
3. Is item visibility supported? I see the checkbox in Item Properties but it appears to always be disabled. However, even if it did work, having to open up and mouse over to extra dialogs is very time consuming. When working with complex images in Illustrator I am all the time flipping visibility and sensitivity on/off and it's a quick process because you can toggle it directly from the layer view. It would be nice if the XML viewer had a check-box or something right next to each item for quick visibility and sensitivity changes (see how Layers work in The Gimp, Illustrator, and Photoshop).
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. :)
7. Sodipodi seems to crash a good bit. I get afraid to use certain operations. For most normal work (when just working with nodes and paths) it seems very stable but when I start combining paths, importing files, and dragging stuff around in the XML viewer it doesn't take long before the crash happens. It's usually not a crash that brings up the crash dialog. It's the kind where you blink and Sodipodi is just gone. I have also had it crash when I accidentally randomly and quickly click 3 or 4 times on the artboard while drawing. Actually, just doing anything randomly or quickly seems to make it crash (zooming in/out, clicking lots of buttons and hotheys). Sorry I can't be more specific, I'll try to follow more closely what's going on when it crashes.
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?
Again, I really like how Sodipodi feels. For me it's much faster than Illustrator when creating and tweaking paths. Especially when vectorizing raster art where I'm trying to line everything up correctly. Good stuff, great work, and thanks!
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
auto "add" new gradient when switching an object to gradient in fill&stroke, instead of reusing the last one used
better gradient editor: ideally arbitrary stops, one color widget that switches to the selected stop
1 When opening a file from an empty unchanged document, replace it with the opened one instead of opening a new window; 2 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. Textboxes (multiple shapes, and text-box linking to make the text-flow)
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.
Write a function to compare two reprs' positions regardless of their parents, by scanning the entire tree (unless they have the same parent, in which case the sp_repr_compare_position() is used) and declaring the one that is run across first to be the lower in z-order. Use it whenever z-order matters (in booleans, in selection-chemistry, etc.). Then make a function next-overlapping and prev-overlapping which finds only overlapping objects; use them in raise/lower commands so that the selection cycles through only the objects that overlap it, not all the objects of the document as now (this presently makes lower/raise almost unusable in large documents). Then implement "select under" by ctrl-alt-clicking in selector: Stay in one place and ctrl-alt-click repeatedly watching the statusbar that shows what is selected, it will cycle through the entire stack of objects _at this point_ (not all objects in the document).
Store/guess export filenames for objects; an attribute of spitem, inkscape:export-as=, settable when exports selection and selection contains only one item; fill it in in the dialog; when not set, guess it from prev/next siblings by in/decrementing their filenames' numeric parts.
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...
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 or (un)printable only.
Plan for fill&stroke:
- remove "get from dropper" (always on, via SetColorSignal)
- remove "mode", make global preference "Store colors as rgb/cmyk"
- remove redundant color picker selector
- transientize, remember size&position, remove Close in the color selector window from Doc props; find if there are others like it
- 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".
- add master opacity from object props
- maybe separate it into Color and Stroke dialogs
In selector top panel, make a frame titled "Transform" and covering 4 toggle buttons: stroke (works), gradient, pattern (need to fix for paths stored-optimized, then add optional compensation in item_write_transform), and 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)