thanks to everybody for the interest in my suggestions. here are my answers, suggestion by suggestion.
Improving "Inkscape I/O":
On 19 Apr 2006, at 02:30 , Jon A. Cruz wrote:
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. [...]
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.
my opinion is that users in group 1 and 2 are not the same. basically: - the new comer/unexperienced user expects everything to be embedded and things to work even if he moves things around. this is why I thought that the default should be a self contained file format. - the more experienced user might like the flexibility and smaller disk usage provided by the link behavior. he will be able to save his work as inkscape svg and to click a "link" button in the import dialog. IMHO the problem is not which behavior is the best because they have different intent but which should be the default. and I think that save-all-in-one should be, hence my suggestion. I thought that the two attempts to implement this behavior were pretty advanced and that technical issues (which I am not able to judge) were sorted out. From Alan answer:
From: Alan Horkan <horkana@...44...> 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.
it seems that this still needs some work and some delicate decisions from adequate people (which I am obviously not) so indeed this might not be suited for the SoC.
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
subtle, delicate... all this seems to be complicated! anyway, I like current behavior, it is just more complicated to explain to other people in my lab in order to spread Inkscape a bit more widely.
From: Alan Horkan <horkana@...44...>
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).
I recently ran into some font issues, hence my suggestion. it would be great it this is possible.
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.
cool!
From: Alan Horkan <horkana@...44...> 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.
[...]
Not sure if the collection of smaller issues you mention can be made into a single workable project.
it was intended as some preliminary work for the rest to be doable... but it appears that the problems vanished :-)
- add the possibility to resize the panel and/or have it to the
right of the desktop Then adding some functionality: [some new palletes suggested]
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.
From: Alan Horkan <horkana@...44...> 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.
Given Nicu's answer:
From: Nicu Buculei <nicu@...398...> You can do this right now:
- the color palettes are defined in a simple text file, the same
format used also by GIMP (very important!). the structure is so simple, that making a program to edit them is trivial;
- you can already post those files (*.gpl) on a website, all an
user needs to do is to download the file in ~/inkscape/palettes/ and restart Inkscape
I tried to generate some new palettes with the Gimp and it is fairly easy. Nevertheless, colors still cannot be moved around. The answer to this is probably, as Alan mentioned, some third party color management software. It would benefit Inkscape as well as Gimp and unify the appearance of color management between the two. But I guess I am dreaming of a very large project that will probably be out of the scope of the SoC once more ;-)
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.
OK, I got at least one right then ;-)
thank you again for all the suggestions and what will likely become an even greater software.
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
Begin forwarded message:
From: Alan Horkan <horkana@...44...> Date: 19 April 2006 01:39:19 CEDT Cc: List Devel Inkscape inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [Fwd: Invitation to Participate in Summer of Code 2006]
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.
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.
-- Alan H.
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel? cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Begin forwarded message:
From: Alan Horkan <horkana@...44...> Date: 19 April 2006 01:39:19 CEDT Cc: List Devel Inkscape inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [Fwd: Invitation to Participate in Summer of Code 2006]
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.
-- Alan H.
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel? cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Begin forwarded message:
From: Nicu Buculei <nicu@...398...> Date: 18 April 2006 16:06:10 CEDT To: List Devel Inkscape inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [Fwd: Invitation to Participate in Summer of Code 2006]
jiho wrote:
- 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).
You can do this right now:
- the color palettes are defined in a simple text file, the same
format used also by GIMP (very important!). the structure is so simple, that making a program to edit them is trivial;
- you can already post those files (*.gpl) on a website, all an
user needs to do is to download the file in ~/inkscape/palettes/ and restart Inkscape
-- nicu
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel? cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel