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
>> reproduc
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,
> bu
[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
[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 ha
[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 v
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
>> calculat
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
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 .e
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. F
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
>
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.
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 sa
13 matches
Mail list logo
