On Tue, 18 Apr 2006, jiho wrote:
On 15 Apr 2006, at 19:38 , Bryce Harrington wrote:
On Fri, Apr 14, 2006 at 07:46:35PM -0500, ted@...11... wrote:
On Fri, 14 Apr 2006, Bryce Harrington wrote:
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
Projects really need to be self contained tasks (both in time it would take to implment them and development scope) which can easily be carried out in parallel as much as possible and not be any great dissappointment if things dont work out.
Hi all,
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'm sure someone will disagree and have some good technical reasons for it but Inkscape SVG is different by necessity from Plain SVG and maybe more consideration should be given to this idea.
The inkjar format is intended to be largely compatible with OpenDocument to take advantage of existing tools. Dont understimate the network effects of the OpenDocument standard. There is some question of how much of OpenDocument to use but I think it should be possible to unzip an inkjar and have a working SVG. Perhaps careful use of xlinks will allow the incompatible bits to be put elsewhere in the archive, allowing the SVG to be relatively clean and have everything degrade gracefully as needed.
I guess the developers will feel this out as they go and strike the right balance but I do not see how it could be a Summer of Code project.
don't know if it is easy or even possible but embedding fonts into the document would be great too.
SVG Fonts will in effect give you this. The font licensing issues are sticky but that is a user problem more than an implementation issue. If the developers have a clear idea of what is wanted this would probably make a good project (in my humble opinion).
Improving the Text Tool:
Improving the color panel:
Not sure if the collection of smaller issues you mention can be made into a single workable project.
- 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.
Something like this to managed Predefined Styles (i.e. <defs>) will be needed eventually. (Incidentally how do we unabbreviate <defs> to Defines without making it any less confusing to users when they encounter this implementation detail?)
On second thoughts (having read other replies) I think a standalone palette editor (implemented in python maybe?) could be an excellent complementary project to Inkscape. I recall a mail to this list about a very advanced colour editor tool. Last year there was a clipart browser was developed complementary to the Openclipart project. Having smaller specialised tools orbiting inkscape alleviates the pressure to do absolutely everything inside Inkscape.
These are my 2 cents. Thank you for reading all this ;-)
With all these great suggestions I hope this year of Summer of Code will be even better for Inkscape. Hopefully inkscape will get a similar allocation of funds despite the added interest in competition.