Participate the project

[ekondrashev]

Hi, I'm very interested in your project. This exactly what I was
looking for about several months. I want to know how can I participate
your project? I have some free time - near few days a week - that i
can spent to help you in this project, because, as I said, this is
exactly what i was looking for for my purposes.
The problem is that i'm a java developer, and have only beginner
knowledge in python programming, but this only question of time.
Thx!

[Jayesh Salvi]

On Fri, Mar 13, 2009 at 6:27 PM, ekondrashev <ekond...@rambler.ru> wrote:

Hi, I'm very interested in your project. This exactly what I was
looking for about several months. I want to know how can I participate
your project? I have some free time - near few days a week - that i
can spent to help you in this project, because, as I said,  this is
exactly what i was looking for for my purposes.

Glad to hear you are interested.

To start, you can download the tarball and play with the test apps. There are several test apps under "inkface-pygame/tests". Check inkface-pygame/tests/regression.sh file, which will tell you how to run those test apps.

Full fledged apps will be available under "inkface-pygame/apps" subdirectory. At present there is only one - twitter-inkface. You can try running these too.

If you have any apps in mind (existing or brand new) whose GUI you would like to write using inkface, then that will also be very helpful in testing inkface.

Once you get comfortable with these apps, you are welcome to dive inside the library code too. Feel free to ask any questions you may have.

The problem is that i'm a java developer, and have only beginner
knowledge in python programming, but this only question of time.

Sure. Python is easy to pick up!
 

Thx!

[ekondrashev]

Yes, I've already played with this code, I was looking at you project
during couple of weeks. So it is quite clear for me how it works. And
yes I have some svgs that i wanted to test inkface with, but faced
with unimplemented svg tags exceptions. I was very surprised when you
decided to deny(sorry for my english:)) the librsvg, because i think
it will take long time to implement svg tiny at least.
Here some questions:
What version of svg spec you're planning to implement?
When you are planning to implement clutter backend? I need do build
rich gui with svg, and it would be nice to use clutter features.
And in general, what are priority tasks for now?

On Mar 13, 5:37 pm, Jayesh Salvi <jayeshsa...@gmail.com> wrote:

[Jayesh Salvi]

Good questions! inline...

On Fri, Mar 13, 2009 at 10:27 PM, ekondrashev <ekond...@rambler.ru> wrote:

Yes, I've already played with this code, I was looking at you project
during couple of weeks. So it is quite clear for me how it works. And
yes I have some svgs that i wanted to test inkface with, but faced
with unimplemented svg tags exceptions. I was very surprised when you
decided to deny(sorry for my english:)) the librsvg, because i think
it will take long time to implement svg tiny at least.

Yes the decision to move away from librsvg was tricky. I had put all pros and cons of my decision on my blog. You can find the post here: http://jyro.blogspot.com/2009/02/planning-inkface-v02.html (Don't take the block diagram too literally, there have been and will be different changes to it as we code different backends and renderers.) So far I haven't regretted the decision to move away from librsvg.

The librsvg's C code was very rigid and I found it too time-consuming to implement couple of very important features I wanted to implement (label based identification of elements and use of SVG's in-built order of elements). You can read other benefits from the post.
 

Here some questions:
What version of svg spec you're planning to implement?

As I mention in the post, the goal is to implement the SVG spec incrementally. As you can see, only with 3-4 weeks' work the completely rewritten library can design simple GUIs. My goal is to implement the missing SVG features as and when we encounter them. The priority will be to common features in the images created with two main SVG editors - Inkscape, Adobe illustrator; rather than passing any SVG spec compliance test.

On the SVG implementaion feature list, I have following things on my priority list
1. Implement the matrix transformation - Currently the "labeled" elements that have matrix attribute to them (due to rotation/shearing) can not be rendered properly as individual elements. They can be rendered properly if they are part of the background (that's how the traditional SVG rendering works), but recalculating the matrices to get the shape on an individual surface of different dimension has proved very tricky. My explanation here is not sufficient to understand the problem - I might file a proper bug report as I proceed with this problem.
2. There is little descripancy in handling of gradient definitions, I will be taking care of that soon.
3. Implementing gaussian blur - I haven't started on this yet, but plan is to study librsvg's algorithm and reimplement it in python.
4. Take care of all important units of length - currently absence of units and "px" works.
5. Implementation of other filters.
 

When you are planning to implement clutter backend?

I am planning to implement basic clutter backend within a week. You can see the structure in this checkin (http://code.google.com/p/altcanvas/source/detail?r=1070)
 

I need do build
rich gui with svg, and it would be nice to use clutter features.
And in general, what are priority tasks for now?

So far the priority has been as I described above. But as developers start coding against the inkface library, the priorities will keep changing.
 
Hope that helps!

Jayesh

[ekondrashev]

Hi again, I have following svg:
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1">
<g
id="button1"
inkscape:label="button1">
<g
transform="translate(104.85714,-141.42857)"
inkscape:label="default_view"
id="default_view">
<path
style="fill:#008000;fill-opacity:
0.84722218;stroke:#000000;stroke-width:1.35399997;stroke-miterlimit:
4;stroke-opacity:1"
d="M 147.14286,591.08929 C 216.19047,523.97768
348.09524,632.58036 418.57143,595.46875 C 450.39511,557.33598
411.47681,519.49114 375.71429,485.25 C 316.66667,502.38244
256.19047,453.8006 194.28572,483.79018 C 155.71429,517.1756
182.85714,554.84672 147.14286,591.08929 z"
id="rect5036"
sodipodi:nodetypes="ccccc" />
<text
xml:space="preserve"
style="font-size:40px;font-style:normal;font-
weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:
1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-
family:Bitstream Vera Sans"
x="231.42859"
y="546.64783"
id="text5038"><tspan
sodipodi:role="line"
id="tspan5040"
x="231.42859"
y="546.64783">Default</tspan></text>
</g>
<g
transform="translate(198.57143,-287.14286)"
inkscape:label="clicked_view"
id="clicked_view">
<path
style="fill:#00ffff;fill-opacity:
0.84722218;stroke:#000000;stroke-width:1.35399997;stroke-miterlimit:
4;stroke-opacity:1"
d="M 52.684011,736.28232 C 121.73162,669.17071
253.63639,777.77339 324.11258,740.66178 C 355.93626,702.52901
317.01796,664.68417 281.25544,630.44303 C 222.20782,647.57547
161.73162,598.99363 99.826871,628.98321 C 61.255441,662.36863
88.398291,700.03975 52.684011,736.28232 z"
id="path5043"
sodipodi:nodetypes="ccccc" />
<text
xml:space="preserve"
style="font-size:40px;font-style:normal;font-
weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:
1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-
family:Bitstream Vera Sans"
x="136.96974"
y="691.84088"
id="text5045"><tspan
sodipodi:role="line"
id="tspan5047"
x="136.96974"
y="691.84088">Clicked</tspan></text>
</g>
<g
transform="translate(-129.42857,-285.14286)"
inkscape:label="disabled_view"
id="disabled_view">
<path
style="fill:#808000;fill-opacity:
0.84722218;stroke:#000000;stroke-width:1.35399997;stroke-miterlimit:
4;stroke-opacity:1"
d="M 381.25544,734.85374 C 450.30305,667.74213
582.20782,776.34481 652.68401,739.2332 C 684.50769,701.10043
645.58939,663.25559 609.82687,629.01445 C 550.77925,646.14689
490.30305,597.56505 428.3983,627.55463 C 389.82687,660.94005
416.96972,698.61117 381.25544,734.85374 z"
id="path5049"
sodipodi:nodetypes="ccccc" />
<text
xml:space="preserve"
style="font-size:40px;font-style:normal;font-
weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:
1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-
family:Bitstream Vera Sans"
x="465.54117"
y="690.41229"
id="text5051"><tspan
sodipodi:role="line"
id="tspan5053"
x="465.54117"
y="690.41229">Disabled</tspan></text>
</g>
</g>
</g>

And the python code:

import sys
from inkface.canvas import PygameFace, PygameCanvas

class App:
def main(self):
self.canvas = PygameCanvas((800,480))
self.face = PygameFace("/home/jecl/Develop/altcanvas/inkface-
pygame/tests/data/b4.svg")
self.face.button1.onLeftClick = self.handleClick
self.face.default_view.unhide()
self.face.clicked_view.hide()
self.face.disabled_view.hide()
self.canvas.add(self.face)
try:
self.canvas.eventloop()
except KeyboardInterrupt, ki:
sys.exit(0)

def handleClick(self, elem):
print "Clicked"


App().main()

So why can't i access default_view, clicked_view and disabled_view
nodes, though button1 is available. Thx!

On Mar 13, 10:48 am, Jayesh Salvi <jayeshsa...@gmail.com> wrote:
> Good questions! inline...
>

> On Fri, Mar 13, 2009 at 10:27 PM, ekondrashev <ekondras...@rambler.ru>wrote:
>
>
>
> > Yes, I've already played with this code, I was looking at you project
> > during couple of weeks. So it is quite clear for me how it works. And
> > yes I have some svgs that i wanted to test inkface with, but faced
> > with unimplemented svg tags exceptions. I was very surprised when you
> > decided to deny(sorry for my english:)) the librsvg, because i think
> > it will take long time to implement svg tiny at least.
>
> Yes the decision to move away from librsvg was tricky. I had put all pros

> and cons of my decision on my blog. You can find the post here:http://jyro.blogspot.com/2009/02/planning-inkface-v02.html(Don't take the

[ekondrashev]

And one more question:
Why you using inkscape:label attribute to identify elements, wouldn't
it be more universal to use id attribute?

On Mar 13, 10:48 am, Jayesh Salvi <jayeshsa...@gmail.com> wrote:

> Good questions! inline...

>
> On Fri, Mar 13, 2009 at 10:27 PM, ekondrashev <ekondras...@rambler.ru>wrote:
>
>
>
> > Yes, I've already played with this code, I was looking at you project
> > during couple of weeks. So it is quite clear for me how it works. And
> > yes I have some svgs that i wanted to test inkface with, but faced
> > with unimplemented svg tags exceptions. I was very surprised when you
> > decided to deny(sorry for my english:)) the librsvg, because i think
> > it will take long time to implement svg tiny at least.
>
> Yes the decision to move away from librsvg was tricky. I had put all pros

> and cons of my decision on my blog. You can find the post here:http://jyro.blogspot.com/2009/02/planning-inkface-v02.html(Don't take the

[Jayesh Salvi]

Is this the whole of SVG file? It lacks the standard "svg" tag (which inkscape sets and is also part of spec), the inkface library gets the image size info from that tag, so it is needed. If this is just part of the file, then please reply with the whole file and please post it as an attachment.

I also see you have changed the id fields in addition to inkscape:label, that's not needed, check my answer to your next email.

[Jayesh Salvi]

On Sun, Mar 15, 2009 at 9:05 PM, ekondrashev <ekond...@rambler.ru> wrote:

And one more question:
Why you using inkscape:label attribute to identify elements, wouldn't
it be more universal to use id attribute?

The reason to use inkscape:label attribute as an handle is mainly UI usability for designers: the Inkscape image editor (which we are primarily aiming at for now) gives a simple front end GUI to manipulate that. It is very important from a designer's point of view (not necessarily programmer's point of view). For changing any other attribute of element, the designer will have to change the XML; that can't be expected of an artist.

As for "inkscape:label" not being universal - that's true. Maybe Illustrator will have its own separate tag, or some other SVG editor might have its own. We will have to encorporate those special cases - mainly because that will improve the usability during GUI design phase.

The reason not to use "id" is: it's "the" unique IDentity of an element. When it comes to UIDs, it's better to let the software handle it. So it will be dangerous to ask designers to change the "id" attribute. Maybe if they don't make sure it is unique, the SVG file will violate SVG specs and will be no good for other SVG viewers/editors. Also I don't know how Inkscape is dependent on the uniqueness of the "id" attribute, so better to leave it alone.
 

[ekondrashev]

It's a part of svg.
Here the hole svg
http://groups.google.com/group/inkface/web/b4.svg
I got such an error:
Traceback (most recent call last):
File "/home/jecl/NetBeansProjects/NewPythonProject2/
incface_test.py", line 26, in <module>
App().main()
File "/home/jecl/NetBeansProjects/NewPythonProject2/
incface_test.py", line 10, in main
self.face.default_view.unhide()
File "/usr/lib/python2.6/site-packages/inkface/canvas/canvas.py",
line 31, in __getattr__
raise AttributeError('Unknown Attribute %s'%str(key))
AttributeError: Unknown Attribute default_view

By the way, what IDE are you using for python coding, if not a simple
editor? thx!

On Mar 15, 8:48 am, Jayesh Salvi <jayeshsa...@gmail.com> wrote:
> Is this the whole of SVG file? It lacks the standard "svg" tag (which
> inkscape sets and is also part of spec), the inkface library gets the image
> size info from that tag, so it is needed. If this is just part of the file,
> then please reply with the whole file and please post it as an attachment.
>
> I also see you have changed the id fields in addition to inkscape:label,
> that's not needed, check my answer to your next email.
>

> >http://jyro.blogspot.com/2009/02/planning-inkface-v02.html(Don't<http://jyro.blogspot.com/2009/02/planning-inkface-v02.html%28Don%27t>take the

[ekondrashev]

I understand you, but Inkscape for instance, gives ability to change
id of an element and alerts user if he entered existing id, so working
with Inkface you can't assign one id to several elements, don't know
how about other editors.
And if we need a unique attribute, why don't we use the id, if it
desined for such purposes.
But it's only my oponion, I see more disadvantages of using separate
attribute per svg editor.
Just my thoughts!

On Mar 15, 8:59 am, Jayesh Salvi <jayeshsa...@gmail.com> wrote:

> >http://jyro.blogspot.com/2009/02/planning-inkface-v02.html(Don't<http://jyro.blogspot.com/2009/02/planning-inkface-v02.html%28Don%27t>take the

[Jayesh Salvi]

Great. Your image uncovered couple of unimplemented features.

I have checked in the fix to implement them - r1109 and r1110.

With these fixes and a fix in r1111 - you should be able to view your image using either inkface/altsvg/tests or /inkface-viewer.py tests/pygame/basic.py - they are basically plaing SVG renderers.

Could you tell what SVG editor are you using? Is it Inkscape or something else? If Inkscape, what version and what OS are you on? I am just curious, because in all the images I have created using Inkscape, I never hit these cases.

However your program still won't work, because the way you have named the labels.

You have labeled elements in hierarchy. You can name them anyway you want; but you cannot access them that way.

You should give a label to a node that is not a subelement of any other node. You can draw shapes that have groups and subgroups - they will be rendered alright; but you have to label on the topmost element. So that's the one you will be able to handle from the program. That is why in your case, you can access "face.button1", but you will get an AttributeError if you try to access "face.default_view". Logically one would expect that default_view will be accessible as "face.button1.default_view". I have toyed with that idea; but it makes things complicated and I think it is not needed at this stage.

Does that make sense?

Let me know.

Jayesh

[Jayesh Salvi]

On Sun, Mar 15, 2009 at 11:07 PM, ekondrashev <ekond...@rambler.ru> wrote:

I understand you, but Inkscape for instance, gives ability to change
id of an element and alerts user if he entered existing id, so working
with Inkface you can't assign one id to several elements, don't know
how about other editors.

 

Good to know that.

There is one more reason behind using label that I forgot to mention. If you notice: every element has "id" attr, but not every element will have "inkscape:label" attr. This fact is made use of. A designer while designing a GUI will draw it as an ordinary image. He can draw any complex background or embed images. But the programmer doesn't need to access them. So the designers only labels the elements that will be used by programmer. The rest need not be named.

This fact is also used to optimize memory requirements. The way inkface works is, it draws labeled elements on separate surfaces and handles them separately (that's how you can access those elements as separate pygame sprites OR clutter actors). But each new surface needs memory. Therefore the elements that are not labeled need not be rendered on different surfaces. So inkface library draws them on single surface, whenever possible.

[ekondrashev]

>Does that make sense?
Yep,thanks for your time.
I'm usink Inkface v0.46, OS Linux Arch.

> ...
>
> read more »