Merging the Cairo branch
by Josh Andler
Hey,
So, I really think that we should entertain the idea of merging the cairo
branch into trunk. The plan has been for us to not release 0.49 until it is
ready, so the couple outstanding bugs in cairo shouldn't be a huge
deterrent. We could also set up a PPA to produce the trunk builds of cairo &
pixman so that fixed libs are easily installable in the meantime (at least
for people using debian-based systems). I was talking to John Cliff and he
put forth a very good point which is that we really need to get as much
testing as possible on it prior to a release.
Before it gets asked, yes Jon, color management is broken in it atm. The
likelihood of it getting fixed in a branch as opposed to trunk is next to
non-existent though...
So, would people be okay with a little breakage of existing functionality to
get more testing of a cairofied Inkscape? bulia, I included you in the to
line here to help gauge the acceptability of this proposal.
Cheers,
Josh
12 years, 2 months
GSoC project ideas
by Krzysztof Kosiński
Hello
I'm not 100% sure yet whether I'll be able to participate in GSoC
2011, but here are my ideas. They can be used by other potential
participants.
1. Selections
A lot of functions in Inkscape operate on the current selection. This
includes things like moving objects to another layer, creating a
bitmap copy, etc. This leads to a lot of unnecessary code duplication
when some other function needs to reuse selection-specific logic in a
way that is not tied to the UI. It also precludes any useful
implementation of scripting (e.g. one that does not need to modify the
user's selection every time a script is run). In order to rectify
this, we should create an object that represents an arbitrary
collection of SVG elements. It would work like the selection we have
now, but would not be tied to any UI elements - it would just
represent an ordered set of elements that can be passed to functions.
2. Fix flowtext
Use svg:switch to fix flowtext. Make svg:switch transparent to the SP
tree - e.g. a switch should not have its own SP element, the active
part of the switch should be transparently included into the SP tree.
This can be accomplished by allowing every object to have more than
one representation.
3. Make XML private
Discussed before. Was the object of a previous year project, but the
main effect of that was mass renaming and moving of code into classes
rather than any meaningful improvement in encapsulation. The main
thing we need is an ability to create SP nodes. Right now we create
XML nodes and rely on SP tree callbacks to construct the SP node for
us.
4. Typed XML tree
The XML tree stores strings, which is rather wasteful and leads to a
lot of boilerplate in SP object implementations. We have enough
knowledge about the document at the XML level to know the type of each
attribute and CSS property based on its name. Storing parsed values
would save space, particularly for embedded images, at the cost of
slightly more expensive saving. GVariant could be used.
5. GTK3 compatibility
This would involve removal of deprecated code, so that Inkscape
compiles with both GTK2 and GTK3.
6. 2geom improvements
Move and rewrite code 2geom to the point where it can take over the
job of livarot, libavoid, etc. Document the new code and make sure it
fits nicely with existing code. The scope of the project could be
limited to implementing Boolean operations on paths.
7. Rendering speed improvements
Further work on the Cairo branch in several small sub-projects:
a) Instead of re-rendering the same pixels every time a new tile of a
filter is rendered, cache them until the rendering is done. The
implementation could involve allocating screen-size bitmaps for each
layer of a filtered object and filling them with data in small
increments.
b) Render editing controls to a separate image that is composited on
top of the drawing, so that what a path outline is highlighted, there
is no need to re-render the object under it.
c) Render each layer of the drawing to a separate image;
alternatively, render 3 images: everything below current layer,
current layer and everything above. This would allow the user to give
us some hints.
Regards, Krzysztof
12 years, 2 months
Greetings
by Eric Kuzmenko
Hello there fellow inkscape-devel mailing list subscribers, I'm Eric
Kuzmenko, a programmer want-to-be. Almost none of you have met me, I just
want to establish a position in your community, hopeful I can obtain
someone's friendship here. Anyway, I just wanted to state that I am going to
attempt to apply for gsoc sometime late next week. I'm currently trying to
get a grasp of the gtkmm wrapper in order to press that knowledge to fixing
some bugs and getting those two patches in before April 8, though there's a
great chance I won't be able to due to the amount I need to learn. Even if I
fail to get that far this soon I will continue attempting to help patch up
the code during the summer, whether it with gsoc or not, hopefully I can be
of some help. If you've read this far then thank you. =)
12 years, 2 months
GTK3
by Inti Alonso
Hi, Im a regular Inkscape user, and with all the noise about the coming of the
new GTK3, I want to know if Inkscape is already working in the GTK3 port, or
when will that happen.
I guess GTK3 can bring some improves to or beloved Inkscape.
12 years, 2 months
[GSoC] SVG + javascript
by Fernando Lucchesi
Hi inkscape-devels,
I've been lurking for a while, but didn't introduce myself yet.
I'm Fernando Lucchesi, and I am at my third year studying Computer Engineering
at Unicamp, Brazil. I am a member of the CS/CE Students' Union of Unicamp(CACo),
where my role is roughly to do "graphical stuff", almost always using inkscape.
That includes posters[1], t-shirts, etc.
Since I rely on Inkscape so much, it was about time I got to contribute with
some code. For that, I am willing to participate on this year's GSoC.
(I realize that only using Inkscape doesn't mean I can hack it, but it means I
want to see it get even better)
Last year, I was playing with SVG/JSONP trying to make a widget to show the
cafeteria menu[2]. While doing that, I realized that the javascript support
could use some love. Searching a little, I've found this blueprint:
https://blueprints.launchpad.net/inkscape/+spec/scripting-ui
So I would like to work at something along those lines.
I've chatted a little at the Inkscape Brazil mailing list, and already got some
pointers. These are the ideas so far:
-Enhance "Object properties > interactivity" by replacing the text boxes with
combo boxes containing every javascript function/method available. To do that,
it would be necessary to parse both external and embedded scripts.
-Open embedded scripts on an external editor (perhaps blocking the svg edition
while doing that). It would be a way to follow the unix philosophy of using the
best tool for every job (inkscape - graphics; vim/emacs/some ide - code).
That script list would be located at "document properties > scripting", under
the external scripts.
As Aurium pointed out, the name of the tmp file would have to be meaningful not
to scare the user, so perhaps using the script id could be an option. Also, the
way to create new scripts would be at the same interface, you'd just need to
define the script name/id at its creation.
-At the same place there could be a list of svg elements using script events.
-We could encourage people to use .js files for scripts, since it is good
practice to separate the structure from the action (like with html/js).
The problem, however, is that by doing that there would be 2+ files instead of a
single svg, making the distribution more difficult.
As a way to solve that, inkscape could have an option to automatically embed
external scripts, so there would be only one file. There should be some config
regarding scripts on another server (so you don't save a static version of JSONP
data, for example).
Then, there would be the opposite direction, taking the embedded scripts out to
the corresponding .js files. This wouldn't be restricted to scripts previously
inserted by inkscape, but all embedded scripts.
The name of each file to be created would be asked, except for those that came
from a .js in the first place, since its name would be saved on the tag. Another
option is to use the id defined by the other interface instead of asking.
So, how could this fit into a GSoC project?
(I'm yet to send the 2 patches, but I've already pulled the code from bazaar,
successfully compiled it and am having a look at the bugs at launchpad).
[1]: http://www.students.ic.unicamp.br/~ra091187/etc/reuniao.png
[2]: http://www.students.ic.unicamp.br/~ra091187/teste/bandeco.svg
--
Fernando Lucchesi Bastos Jurema
UNICAMP - Engenharia de Computação 09
CACo - Centro Acadêmico da Computação
Coordenador de Marketing e Produtos - gestão 2010/2011
12 years, 2 months
Brightness and Lightness
by Kris De Gussem
Hi all
The latest inkscape.pot update draw my attention on the terms
"Brightness" and "Lightness". I supposed they were the same, but
according to the filter names "Brightness, custom (color)" en
"Lightness, custom (color)" in the menu "Filters" > "Experimental",
there is a difference between brightness and lightness. Can anyone
explain the difference, if there is any: is it a different concept,
related to color space, different mathematical formula, ... ?
Thanks a lot.
Regards
Kris
12 years, 2 months
Some progress on OSX/aqua, and how to go further?
by Gellule Xg
Hi,
I have made some little progress in a local branch on an OSX?aqua
version of inkscape. I would like to know what the best way is to give
these changes back to inkscape. Many patches? A branch on launchpad?
Would a branch ~gellule-xg/inkscape/aqua work for now? Can it be made
available to others later, before a merge back in master?
So far, I have workarounds for:
https://bugs.launchpad.net/bugs/487144
https://bugs.launchpad.net/bugs/721448
I am also able to get rid of the launcher script used for the X11
version and put the inkscape executable directly in the application
bundle. I have also started using ige-mac-integration to determine the
correct paths to use throughout inkscape. I am currently working on the
relocation of the libraries into the application package, one step
before the production of the disk image.
Is anyone familiar with install_name_tool and the
-headerpad_max_install_name or -headerpad linker flags? I might need a
little help there.
-Gellule/Julien
12 years, 2 months
GSoC 2011
by Josh Andler
Hey All,
Since we were accepted for GSoC again this year. Is anyone interested in
mentoring that has not already stated so? Please let me know either on-list
or directly. We can't add mentors yet as they are updating Melange this
week, but I just want to get the ball rolling on discussion.
Cheers,
Josh
12 years, 2 months
