On Sun, 13 Aug 2006 18:46:40 +1000 David Seikel [EMAIL PROTECTED] babbled:
Given that svg files designed for fdo icon themes are likely to be
simple things compared to all the fancy functionality that the svg spec
allows, I'll be happy with a simple svg loader that I can request
render this
On Sat, 12 Aug 2006 18:13:23 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] wrote:
right now i'd want to go for the solution of - if we can't load an
svg, we fall back to finding a png or some other format icon - or
just display a placeholder image.
Right now the parsing and loading
On Sat, 12 Aug 2006 18:10:15 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] wrote:
On Fri, 11 Aug 2006 00:53:28 GMT [EMAIL PROTECTED]
[EMAIL PROTECTED] babbled:
Carsten writes:
XPM is not hard - loader is in imlbi2 - can be snarfed in.
svg - well - a bigger issue -
On Fri, 11 Aug 2006 02:48:45 GMT [EMAIL PROTECTED] [EMAIL PROTECTED]
babbled:
David writes:
In the context of this thread, the freedesktop.org specs say that
the user specifies the size in pixels of icons that they want, and
for svg's, that means we need to render to that
On Thu, 10 Aug 2006 18:01:19 GMT [EMAIL PROTECTED] [EMAIL PROTECTED]
babbled:
actually - cairo is unlikely to become a main engine - just
because it's extra work with no gain. we use what cairo uses
directly ourselves already. this gives us better control and
better performance.
On Thu, 10 Aug 2006 18:39:37 -0700 Blake Barnett [EMAIL PROTECTED] babbled:
On Aug 11, 2006, at 12:53 AM, [EMAIL PROTECTED] wrote:
Carsten writes:
XPM is not hard - loader is in imlbi2 - can be snarfed in.
svg - well - a bigger issue - but i think we can avoid it for
now and
XPM is not hard - loader is in imlbi2 - can be snarfed in.
svg - well - a bigger issue - but i think we can avoid it for
now and just display default icons in place. as long the the
icon finder routine will return null when no icon can be
found given the params - the code can fall back :)
As far as the svg loading: We've already mentioned using
librsvg for that - I can give it a try and see how well it can
be made to work if no one else wants to do so..
I don't think anyone would be happy to see Evas depending on GTK/GDK
etc. Like Raster said, Evas already does 90% of
On Fri, 11 Aug 2006 10:23:50 +1000 David Seikel [EMAIL PROTECTED] babbled:
On Fri, 11 Aug 2006 09:17:15 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] wrote:
On Fri, 11 Aug 2006 09:45:31 +1000 David Seikel [EMAIL PROTECTED]
babbled:
On Fri, 11 Aug 2006 08:01:33 +0900
On Wed, 9 Aug 2006 03:18:41 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled:
David writes:
According to the fdo specs, the user is allowed to select an
icon size and theme. The spec contains methods of looking
through the search paths to determine what icon themes and
sizes
On Wed, 9 Aug 2006 07:23:28 +1000 David Seikel [EMAIL PROTECTED] babbled:
There are a few TODO items for E17 -
* fm2 .desktop parser needs to handle i18n
* use .desktop files and move eap editor to edit them etc. etc.
instead to fix
* if we want to do icons on the desktop - and as part of
actually - cairo is unlikely to become a main engine - just
because it's extra work with no gain. we use what cairo uses
directly ourselves already. this gives us better control and
better performance. :)
One never knows.. Always keep an open mind! :)
sure - i did -
On Thu, 10 Aug 2006 23:13:50 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] wrote:
well i lean to the put it in e and put another copy in entrance for
now - not another ecore_desktop thing - but i do see a point of it
being sharable.
i can be tipped to ecore given some arguments
BTW, raster is pulling my strings behind the scenes to get me to do
this changeover, so I'll be coping all the flak coz people in here
tend to ignore discussion until code is committed, then bitch about it
afterwards.
So I just want you all to know that I will be letting .eaps
and .desktop files
On Fri, 11 Aug 2006 08:07:56 +1000 David Seikel [EMAIL PROTECTED] babbled:
On Thu, 10 Aug 2006 23:13:50 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] wrote:
well i lean to the put it in e and put another copy in entrance for
now - not another ecore_desktop thing - but i do see
On Fri, 11 Aug 2006 08:01:33 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] wrote:
On Fri, 11 Aug 2006 08:07:56 +1000 David Seikel [EMAIL PROTECTED]
babbled:
On Thu, 10 Aug 2006 23:13:50 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] wrote:
i can be tipped to
On Fri, 11 Aug 2006 09:45:31 +1000 David Seikel [EMAIL PROTECTED] babbled:
On Fri, 11 Aug 2006 08:01:33 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] wrote:
On Fri, 11 Aug 2006 08:07:56 +1000 David Seikel [EMAIL PROTECTED]
babbled:
On Thu, 10 Aug 2006 23:13:50 +0900
On Fri, 11 Aug 2006 09:17:15 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] wrote:
On Fri, 11 Aug 2006 09:45:31 +1000 David Seikel [EMAIL PROTECTED]
babbled:
On Fri, 11 Aug 2006 08:01:33 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] wrote:
On Fri, 11 Aug 2006
Carsten writes:
XPM is not hard - loader is in imlbi2 - can be snarfed in.
svg - well - a bigger issue - but i think we can avoid it for
now and just display default icons in place. as long the the
icon finder routine will return null when no icon can be
found given the params - the
On Fri, 11 Aug 2006 00:53:28 GMT [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Carsten writes:
XPM is not hard - loader is in imlbi2 - can be snarfed in.
svg - well - a bigger issue - but i think we can avoid it for
now and just display default icons in place. as long the the
icon
On Aug 11, 2006, at 12:53 AM, [EMAIL PROTECTED] wrote:
Carsten writes:
XPM is not hard - loader is in imlbi2 - can be snarfed in.
svg - well - a bigger issue - but i think we can avoid it for
now and just display default icons in place. as long the the
icon finder routine will
David writes:
In the context of this thread, the freedesktop.org specs say that
the user specifies the size in pixels of icons that they want, and
for svg's, that means we need to render to that particular size.
There is a default icon size of 48x48 if the user didn't specify
a
On Fri, 11 Aug 2006 02:48:45 GMT [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
David writes:
In the context of this thread, the freedesktop.org specs say that
the user specifies the size in pixels of icons that they want, and
for svg's, that means we need to render to that
Blake writes:
As far as the svg loading: We've already mentioned using
librsvg for that - I can give it a try and see how well it can
be made to work if no one else wants to do so..
I don't think anyone would be happy to see Evas depending on
GTK/GDK etc. Like Raster said,
On 8/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Loading 'SVG icons', at this point in time, really just
means rendering some static SVG doc at some scale and then using
that rendered image.. There are libs that can do that, the most
commonly used by some seems to be 'librsvg',
On Wed, 9 Aug 2006 03:18:41 GMT [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Loading 'SVG icons', at this point in time, really just
means rendering some static SVG doc at some scale and then using
that rendered image.. There are libs that can do that, the most
commonly used by some seems
On Thu, Aug 10, 2006 at 02:33:29AM +1000, David Seikel wrote:
On Wed, 9 Aug 2006 03:18:41 GMT [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Loading 'SVG icons', at this point in time, really just
means rendering some static SVG doc at some scale and then using
that rendered image..
Loading 'SVG icons', at this point in time, really just
means rendering some static SVG doc at some scale and then
using that rendered image.. There are libs that can do that,
the most commonly used by some seems to be 'librsvg', which
latest version seems to use Cairo for the
On Wed, 9 Aug 2006 21:36:04 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled:
Loading 'SVG icons', at this point in time, really just
means rendering some static SVG doc at some scale and then
using that rendered image.. There are libs that can do that,
the most commonly
The cairo dependency is fine since hopefully it'll become
a 'main' evas engine.. But it's unfortunate that librsvg has to go
thru glib and gdk.. ideally it would keep to a min of xml related
libs say, and draw to a cairo surface say.
actually - cairo is unlikely to become a main
On Thu, 10 Aug 2006 03:58:39 GMT [EMAIL PROTECTED] [EMAIL PROTECTED]
babbled:
The cairo dependency is fine since hopefully it'll become
a 'main' evas engine.. But it's unfortunate that librsvg has to go
thru glib and gdk.. ideally it would keep to a min of xml related
libs say,
There are a few TODO items for E17 -
* fm2 .desktop parser needs to handle i18n
* use .desktop files and move eap editor to edit them etc. etc.
instead to fix
* if we want to do icons on the desktop - and as part of efm, i am
thinking that we have little choice but to implement a .desktop file
David Seikel wrote:
It seems there are two things going on here, 1) parsing and 2)loading
with the parsed information. I think striving to keep the two seperate
will be good overall (i'm saying this without having a clear view of the
situation that you have). Next below...
snip
I already
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Seikel schreef:
snip stuff about .desktop files
Please think about having a cache (or db) for parsed .desktop files,
since accessing a gazillion files is slow, especially on jffs2 where
everything needs to go through gzip as well on load.
The
On Tue, 08 Aug 2006 22:59:23 +0100 Essien Ita Essien
[EMAIL PROTECTED] wrote:
IMOHO, i think the parsing part belongs to ecore, and the loading
part to evas
I agree, parsing and loading. We already have plenty of code for
loading images from a file, that's the easy bit. I've spent most of
David Seikel wrote:
On Tue, 08 Aug 2006 22:59:23 +0100 Essien Ita Essien
[EMAIL PROTECTED] wrote:
IMOHO, i think the parsing part belongs to ecore, and the loading
part to evas
I agree, parsing and loading. We already have plenty of code for
loading images from a file, that's
David writes:
According to the fdo specs, the user is allowed to select an
icon size and theme. The spec contains methods of looking
through the search paths to determine what icon themes and
sizes are available. There is a fallback size and theme that
every system must supply,
37 matches
Mail list logo