On Apr 7, 2010, at 11:08 AM, Matthew Todd wrote:
Second idea (layers dialog): I find the layers dialog to be a little cumbersome.
Its not possible to simply move layers up and down by dragging them. Instead an user has to click a button or press a key combination. I think adding this small feature will increase ease of use because then the user doesn't have to click multiple times if there are many layers. He or she could simply just drag the layer to the desired location.
The layer dialog doesn't show what is in a layer. So currently, the only option is to hide all other layers, which still isn't a great solution. Adding the ability to inspect items in a layer and move them in z-order or perhaps even move them to other layers, would make layers work better. I'm thinking of something would look like a tree view. Again, I came over from Adobe Illustrator, so my idea of what it would like is similar to how Illustrator's layer dialog, but it need not be.
Hi. I do like the layer dialog idea.
I think the proposal needs a little more work as it stands. One thing is that we like to be sure that students can succeed with their projects, and a top factor is involvement in the project community. Submitting small patches is one way to show some involvement and capability (being able to successfully build the code is a big must). Participating in the chat room and/or mailing lists is also very good.
One thing I think is missing from the proposal is something to help us know what your actual coding abilities are. Some mention would help. Working to fix bugs in Inkscape also really helps here, but I do understand that school schedules can get a bit pressing. So at least some mention of experience in different coding areas, languages, etc. can help.
Laying out some detail of what Inkscape will gain from this project can also help. A breakdown of research, documenting and coding might be good. For your proposal in particular it sounds like the experience with other tools can be used to create some base design documents that will help even for features that you don't have time to code within the GSoC project itself. Bringing in an aspect of agile development, it might be good to start with working up a rough design/spec document as the first step in the project, and include refinement of that documentation to include it as part of the final deliverables.