David writes:
> One thing that will help with the icons is that some of those
> are SVG, and we have no SVG support. Probably because it's
> another sucky XML standard. I'm thinking of using xmlame to
> parse those and convert into bitmaps for generating .eaps.
Writing your own svg parser would not be particularly
*directly* useful to evas since it currently doesn't have support
for many of the elements - so you would have to pass the result
to a lib that could render that to a bitmap, as you mention.
Even if evas did support all needed elements for capturing
a svg doc directly, there's a big difference between "loading" a
static svg document as an evas image object that holds a rendering
of the document.. vs "loading" the same doc as tree of suitable
evas vgx objects..
[note though that svg also allows for 'animating' of
various aspects, and in a full xml world it also involves such
things as 'DOM events', scripting, and other complexities that
a single static rendering cannot capture]
As raster mentioned, using say librsvg to render the doc,
and thus load it as an evas image obj, is far more useful now --
especially if we're talking about static svg docs.
There is still the problem of determining the scale to
render the svg at, which could be handled as raster suggested..
or even by using the "key" part of the 'file/key' for setting
the size (rel to evas coord units). The key can also be used
to load document 'fragments' say (if librsvg supports this,
I don't know).
Since one wants to avoid re-rendering the doc, it would
be best to render it at the largest reasonable size and image-
scale down as needed.
> Supporting .desktop files (and the fdo icon themes that go with
> them) as well as (possibly animated) .edj icons is a good idea.
> Currently there are no icon themes on get-e.org, since they where\
> all taken down to be redone. That apparently is a very hard job
> as it has taken months with no result in sight. By leveraging
> fdo icon themes via .desktop files, we can make use of existing
> icon themes, some of which the average user probably already has
> installed by their distro. If we incorporate a search for .edj
> icons into the fdo search algorithm for .desktop files, we can
> have the best of both worlds. Then if the user happens to have
> a suitable .edj, it is used, otherwise use the fdo icon that
> would have been used anyway.
Support for fdo 'standards/specs' is one of the most
important things e needs to do, and I would say that you have a
very 'enlightened' outlook on things here :) :)
> That means code to handle .desktop files needs to be used by E
> and those menu tools. Since I have already written the bulk of
> the code to deal with fdo .desktop files and icons I'm quite
> happy to shift it about so that it can be used by E and
> e17genmenu. Although if we put it into e_desktopfile.[ch]
> e17genmenu won't be able to access it unless I recast e17genmenu
> as a module. So the real questions becomes, where is the best
> place for .desktop support code so that E and other code can
> use it? IPC (here's the path to a .desktop, give me back a .eap)?
> In a library? I'm not real fussy, I just want to avoid
> duplicating the code.
Ummm... here's my view on these kinds of issues:
There's really no reason why edje itself cannot "load"
any file format that evas can load as an image object. There's
no reason why one needs to externally create .edj files out
of jpg/png/xpm/svg/... files in order for edje to use them.
One can even imagine using say a (file,key) pair of the
form ("image_file.png","fill { .... }") to load the image and
give it 'fill' properties..
The magic for this would of course be in edje having
support for its own kind of loaders, in conjuction with evas'
image loading.
In e17 for example, there's no reason to have two
different interfaces for setting a 'generic' theme object;
one for plain image files, and another for edj files --
edje should be able to use both file types as valid inputs
to set on an obj.
In a similar vein, there's really no need to have to
"transform" .desktop files to .eap files in order for e17 to be
able to "load" them for all its needs... If you can write a
program that carries out such a transformation, then you can
also write a lib to do the same (as you mentioned), and if e
had 'loaders' for this, then it would only need a single
"load app data" interface for obtaining what it needs --
wether the input is a .desktop file or an .eap file.
Yet, it would still be desirable to have such transform
programs (and/or shared libs -- a shared lib version can be used
to write the program version), for others, or other parts of e,
to use...
I would argue that both, external tools (execs and/or
shared libs) *and* internal loaders, would be useful to have :)
jose.
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
