Carsten Haitzler (The Rasterman) ha scritto:
On Wed, 28 Nov 2007 08:08:56 +0100 Dave [EMAIL PROTECTED] babbled:
Hi all
I'm working hard on the edje_editor in the last day, and my opinion now
is that
engrave can't render as edje does, and probablly will never. As
reproducing the edje
[EMAIL PROTECTED] ha scritto:
Dave wrote:
Nothing more for now as this require some addition to the edje
library and first I want to hear the voice of the mantiners:
This is the first stub I have done of the new api
I'm not one of those voices, but there's
[EMAIL PROTECTED] ha scritto:
I wrote:
Isn't what you're after (in full) something akin to a 'DOM'
kind of capability for edje/edc? I believe Brian and Chady had
expressed an interest in this at some point as well.
Just to add a bit to that.. Hisham had also
Gustavo Sverzut Barbieri ha scritto:
On Nov 28, 2007 4:08 AM, Dave [EMAIL PROTECTED] wrote:
Hi all
I'm working hard on the edje_editor in the last day, and my opinion now
is that
engrave can't render as edje does, and probablly will never. As
reproducing the edje
calculation is really
[EMAIL PROTECTED] ha scritto:
I wrote:
Things like edje-editor and evolve could've been much further
along if these kinds of issues weren't there.. and it's where having
used already existing tools for 'edje' could've helped.
One could have other formats/scripts as inputs
I would also suggest searching the list for other times this topic has
come up. This would not be the first time Edje_Edit.h would exist. I'm
not saying it will change the end result, but it might prepare you for
arguments on the topic.
On Nov 29, 2007 8:06 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]
One 'problem' with an edje api for getting/setting properties
is that it exposes edje's internal structure more and more.. which
may or may not be desirable.
The api I have in mind don't have this exposure problem:
I don't want to return pointer to the internal structs,
but only the
Dave, this is great news!
I have filed a patch to bgzilla with this first implementation. bug#294
Uh oh... Raster, please consider looking at the bugzilla this time ;)
If you want to try it simply patch edje and set
#define TEST_DIRECT_EDJE 1
in edje_editor/src/bin/main.h on line 15
then
I wrote:
Isn't what you're after (in full) something akin to a 'DOM'
kind of capability for edje/edc? I believe Brian and Chady had
expressed an interest in this at some point as well.
Just to add a bit to that.. Hisham had also expressed a
similar interest as well. For
I wrote:
Things like edje-editor and evolve could've been much further
along if these kinds of issues weren't there.. and it's where having
used already existing tools for 'edje' could've helped.
One could have other formats/scripts as inputs to create
eet-encoded .edj
Yet one more bit here (as I slowly regain my E memory),
One other thing of relevance here is the notion of styling.
Just as xml based formats like xhtml, svg, ... allow for styling
via css, ie. allow for one to vary certain values of properties of
a 'src document' (but not the
Hi all
I'm working hard on the edje_editor in the last day, and my opinion now
is that
engrave can't render as edje does, and probablly will never. As
reproducing the edje
calculation is really hard. and also stupid to do the same thing 2 times.
So I started to play with edje to modify it
On Nov 28, 2007 4:08 AM, Dave [EMAIL PROTECTED] wrote:
Hi all
I'm working hard on the edje_editor in the last day, and my opinion now
is that
engrave can't render as edje does, and probablly will never. As
reproducing the edje
calculation is really hard. and also stupid to do the same
Dave wrote:
Nothing more for now as this require some addition to the edje
library and first I want to hear the voice of the mantiners:
This is the first stub I have done of the new api
I'm not one of those voices, but there's something curious
here.
14 matches
Mail list logo
