[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] E CVS: apps/e raster



 
    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.