Re: [E-devel] Edje gradient rel1/rel2

[The Rasterman]

On Tue, 7 Oct 2008 13:37:39 +0200 (CEST) Dave Andreoli <[EMAIL PROTECTED]>
babbled:

> Hi all
> it seems to me that in edje the rel1 and rel2 properties of gradients are
> unused now. Gradient always use the fill properties, is this right? can I
> remove that unused props?

offset_x/y in the gradient rel1/2 are still used...
:)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction

[The Rasterman]

On Tue, 7 Oct 2008 08:55:59 -0300 "Gustavo Sverzut Barbieri"
<[EMAIL PROTECTED]> babbled:

> On Tue, Oct 7, 2008 at 2:57 AM, Enlightenment SVN
> <[EMAIL PROTECTED]> wrote:
> > Log:
> >  Some work on interaction settings:
> >  - group on a thumbscroll framelist;
> >  - threshhold ?\226?\134?\146 threshold;
> >  - add check changed.
> 
> 
> that's awesome, I see people liked the "check_changed", we should add
> this to other dialogs as well.
> 
> something else I'd like to see is to move, where possible, layouts to
> edje with swallow parts, that way we can have special layouts in
> embedded systems like illume. Side effect is to simplify code a lot.
> What do you think?
at some point - but edje doesnt solve it all - for embedded (small screen) uis'
u really need to possibly drop entire content and re-think it. i intend to do
this for a chunk of dialogs anyway so their default is more small-screen
friendly.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] EET crypto

[The Rasterman]

On Wed, 8 Oct 2008 16:12:13 +0200 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:

> On Wed, Oct 8, 2008 at 4:02 PM, Gustavo Sverzut Barbieri
> <[EMAIL PROTECTED]> wrote:
> > On Wed, Oct 8, 2008 at 10:19 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote:
> >> On Wed, Oct 8, 2008 at 3:00 PM, Viktor Kojouharov <[EMAIL PROTECTED]>
> >> wrote:
> >>> On Wed, 2008-10-08 at 14:46 +0200, Cedric BAIL wrote:
>  Hi,
> 
> As it seems like a good time to break the EFL agains :-). I would
>  like to discuss API/ABI break of eet. I am currently working on adding
>  crypto to eet. My current code only require a key and generate the
>  needed salt and IV for the encryption. So I need to add one more
>  parameter (the key) to all read and write operation of eet. I have
>  currently two possibilities, double the number of function, or just
>  change the existing one. Of course the later solution sounds a little
>  bit cleaner, but it will break all eet applications.
> 
> A quick search of eet_open in the svn give me 43 differents file
>  using it. Sounds like not a big deal to break it. This could be also
>  be a good time to cleanup the parameters of
>  eet_data_descriptor_element_add also.
> 
> So guys, what do you think of this move ?
> >>>
> >>> Wasn't eet 1.0 released a couple of weeks ago? Breaking the API after
> >>> the supposed stable 1.0 release just screams wrong in so many ways.
> >>
> >> Yeah, I know, that's why I asked. I just don't like the idea of not
> >> breaking the API/ABI and adding code to work around for marketing
> >> issue.
> >>
> >> Just looking at the TODO. We are planning to add :
> >>  - support for scripting langage to convert from their object type to
> >> eet data and from eet data to script object.
> >>  - streaming API for both audio and video.
> >>
> >> The only draw back on switching to 2.0 branch on Eet, is that we
> >> currently have one standing bug covered by the test case, that I can
> >> find a way to fix (bug in dump/undump) and this will mean that at some
> >> point we will need to make another release of the 1.0 branch.
> >
> > Do we need a different key for each read/write operation? I see this
> > being more a key per file, in that case make an eet_key_set(ef, key)
> > and check for the set pointer inside read/write operations.
> >
> > the existing parameters are really one per entry, like compression.
> 
> I am not really planning to cypher all the data of the file, but just
> on a entry basis. So you can cypher eet data, but not picture for
> example. And I want to add this to eet_data_descriptor_decode and
> encode too.
> 
> Between it will be a good time to also remove eet_data_descriptor2_new
> and eet_data_descriptor3_new.

hmm an api break... hmmm. hmmm. very soon after a 1.0.0 (i knew it was too
soon!).

ok - here's my deal. remove descriptor2/3 and merge that all into 1 so fix that
mess and you get your cypher key - as long as it doesnt break apps (eet using
apps and libs) :)

maybe you want to postpone this until all the eina stuff is done?

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] language module patch

[The Rasterman]

On Mon, 13 Oct 2008 09:45:53 -0700 Michael Jennings <[EMAIL PROTECTED]> babbled:

> On Monday, 13 October 2008, at 18:30:04 (+0200),
> Quaker wrote:
> 
> > Hi, i created a simple patch for the language module in E-MODULES-EXTRA.
> > The problem in default language module is that the module needs
> > /etc/X11/xkb/rules.
> > Some distros haven't got it, because it is only a symlink to
> > /usr/share/X11/xkb/rules - on Ubuntu this module works, because it has that
> > symlink, but on Debian Lenny not for example. That's why i created this
> > patch -> It modifes the source to read files from default
> > /usr/share/X11/xkb/rules.
> > Can any developer apply it please? :)
> 
> /etc/X11/xkb is the most correct path for portability.  But ultimately
> any patch which can only handle a single path (or merely changes the
> single path currently handled) is just the same problem all over again
> and should not be applied.  The correct fix is to support a series of
> possible paths.

correct. all this patch will do is fix for you, and then break for others. a
patch that adds a searchpath and a list of places to look would be right :)


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Is there any efl object instead of gtk.drawingarea ?

[dongmei zhou]

hi all,

   You  know  that  Gstreamer video often is displayed  in  drawingarea
which  is   created  by  "gtk.Drawingarea()" function,
Is  there  any  efl object  instead of  this function  to  create a
drawingarea  to display  Gstreamer  video.
Any  examples  would  be  welcome :)

Thanks!
BRS!
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] some questions/propositions on evas/ewl/epsilon

[Jose Gonzalez]

Carsten Haitzler (The Rasterman) wrote:
> On Sun, 21 Sep 2008 17:58:52 +0200 "Hendrik Siedelmann"
> <[EMAIL PROTECTED]> babbled:
>
>   
>> 2008/9/20 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>:
>> 
>>> ok basically scrolling. not likely to happen. the problem with the test
>>> code is
>>> - it may have the ability to detect "motion vectors" but it also adds
>>> constant overhead. in the end i am doubtful if it would be that useful in
>>> the long-run. right now as we are basically awaiting a lot of re-do in the
>>> engine-space i dont think i'll be touching this as it would directly fiddle
>>> with the engines and their api. really you suffer from the hardware
>>> platform being 1. very slow with the cpu and 2. with a really slow video
>>> bus. gtk apps only are smooth as scrolling is one of the few things
>>> accelerated and thus they use it. the problem is scrolling in a more
>>> general setup with alpha blending etc. ends up being a redraw - and evas
>>> just always does it this way.
>>>   
>> Okay that's a no-go for evas in general :(. But as it stands I am
>> programming for the FR. In fact I found the cpu pretty fast (if not
>> blocked by glamo...). So is there a way to upload pixmaps using evas
>> and ecore? I found ecore_x_pixmap_paste but don't know how to get
>> pixmap from evas, or the graphic context ...
>> 
>
> ok. it's possible - you're going to have to manually set up evas , a
> idle_enterer to render etc, (or just render whenever you want). you can render
> to a pixmap. ecore_evas oes this "for you" to handle backing pixmaps etc. so
> you can look there for setup, but just set the target drawable as the pixmap
> and evas will happily render to it. :)
>
>   
>>> as for epsilon, it does the "fdo standard", and this requires thumbnails to
>>> be png. yes - writing jpeg thumbnasils is faster, uses less space etc. -
>>> it'd be possible to extend espilon to write .eet thumbs using jpeg lossy
>>> encoding (and thus also have an alpha channel available), but then you'd
>>> have thumbnails "not according to the spec". so it'd be possible to do
>>> this, just the png writing code in epsilon needs a little abstraction -
>>> patches accepted! (sorry - this isn't on my focus right now so will have to
>>> just wait for patches):)
>>>   
>> No problem, I have some patches which convert epsilon to simple jpeg
>> writing with fdo  naming conventions. Making it a runtime option like
>> the size looks simple. But it's not finished, I don't quite get
>> epsilon_thumbd, it completely breaks.
>>
>> 
>>> as for evas loaders, documentation - no, except samples - many of them. they
>>> are very simple though. look at the ppm ones (pmaps). they are simple file
>>> formats. doesnt include a saver there. but.. for the jpeg loader using
>>> embedded thumbnails - no support (would need to know about all the exif
>>> tags and extension data), BUT you can use the more generic load options
>>> which can play a trick of pre-scaling on load ANY jpeg image (embedded
>>> thumbnail or not) and it basically just loads and decodes only part of the
>>> jpeg data. you can get up to a 1/8th scale "for free" (in fact it loads
>>> much faster than a full load). e17's e_thumb uses this
>>> (evas_object_image_load_size_set for example). it requests the image to be
>>> loaded at that size (scaling done on load). :)
>>>   
>> Jep I know of that. And using it (evas is simply great). Still slow
>> (actually fast enough, but but faster thumbnails never hurt). I'll
>> look at the  samples, used libexif before to extract thumbnails, and
>> also dcraw and I'd love to do a extract-loader with libexif and dcraw,
>> which would itself then utilize the jpeg and ppm loaders. Well in some
>> distant future ;).
>> 
>
> wouldn't we all love more features! :) only so many hours a day... :)
>   


Yeah. And btw, remember to warn people when using the image load
options, that like the jpg lib itself, though you can set any scaling 
fraction
you want, you might not always get the output size intended.. or at least
that that might not be implemented anytime soon. :)




Click here for free search of religious schools located near you.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oJxrJ7dnvwzIn5l7IED9uLo0rdOnWc08zKuiUZwJLeRbSqQ/

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] e_fm: fix single-click on folders

[The Rasterman]

On Tue, 28 Oct 2008 20:36:06 +0100 thomasg <[EMAIL PROTECTED]> babbled:

> Hi,
> 
> the attached patch fixes the single-click feature of e_fm, so you can use
> single-click on folders, not just on files.
> It also removes the strdup in the affected functions that seems useless
> here.
> 
> Would be nice if someone could check/review and commit it.

in svn :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17 dbus support

[Luca De Marini]

2008/11/3 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>

> On Sat, 27 Sep 2008 11:37:34 +0200 "Albin Tonnerre" <
> [EMAIL PROTECTED]>
> babbled:
>
> the real problem is the enlightenment.desktop file - the way we ship it it
> JUST
> runs enlightenment_start. enlightenment_start (its a front-end binary to
> launch
> the real e that doesnt have library dependencies etc.) probably should be
> in
> charge of doing this. the problem is dbus-launch may not be installed, so
> i'd
> say what we need are patches to enlightenment_start to launch e itself with
> dbus-launch if it exists or just e raw (like now) if it doesn't
> :)
>

Uhm, yes, I really believe it would be great to have it. Completely agree :)

Luca
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efreet mime default application patch

[The Rasterman]

On Tue, 28 Oct 2008 23:06:58 +0100 (CET) Dave Andreoli <[EMAIL PROTECTED]>
babbled:

> 
> - "Nick Hughart" <[EMAIL PROTECTED]> ha scritto:
> 
> > This is not yet an fdo specification so I'm not going to put it in
> > just 
> > yet.  It seems to have promise and is a fairly simple format, but for
> > 
> > now we have our own methods of choosing default applications and it is
> > 
> > similar to how they choose as well (given the user is not making this
> > 
> > file on their own). 
> > 
> > When opening a file in EFM, if that mimetype has not been opened 
> > previously you will be given a list of apps that support that mimetype
> > 
> > and a list of all apps as well just in case.  Once you have chosen an
> > 
> > app, EFM remembers this and will use that app until you pick a
> > different 
> > app by using Open With.  So for now we have our own methods of doing 
> > this, but if it does become a specification it may be good to adopt
> > this 
> > as it would help with those doing packaging and distribution.
> 
> Where EFM store the user preference, is it possible to others to access
> this data? 
> I think we need a centralised way to keep this information, or the user
> need to choose a preferred application for every apps/module that need
> to open a filemanager or a browser.
> I know this is not a standard yet. But this doesn't mean we can't have
> our method to storing this user preference.
> 
> I have also done a module that add a configuration dialog to set your
> preferred apps. Its very simple, but it make no sense if there are
> not a shared place to store the informations.
> Don't you think this is a must have module??
> 
> So IMHO we need to define witch is the E way to store the mime/application
> associations, and have the code in some lib (maybe not efreet for now).
> In this way we can have all the apps/module work the same way and we 
> can also change the lib to fit a final freedesktop standard without 
> touching modules.
> If we don't do this now all the apps/modules will do the associations 
> in a different way and when the fdo standard will become a reality we 
> need to redo everything.

well within e it's easy - there are calls to find this info, but outside of e +
modules it's buried deep in e's own config somewhere. now how do we want to do
this?

1. config everyone cal look at
OR
2. "opening service". e.g. a dbus call- u send an array (list) of file paths
and say "open them please" - e will open them for you. this way you also
recycle the exec method and child process tracking etc. if the target file is a
directory - it opens a directory window, etc.

is #2 perhaps not better?

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EWL fb engine won't compile - patch

[The Rasterman]

On Wed, 29 Oct 2008 09:23:17 + Quaker <[EMAIL PROTECTED]> babbled:

i don't see how it wouldn't work. code seems ok to me - builds for me too... :/

> Hi,
> 
> i tried to compile EWL with sources from 26.10, it didn't work..
> 
> i am not a C coder, but i tried to correct it, i modifed a source file of
> EWL framebuffer engine and it compiled without errors.. so here is the
> patch:
> 
> --- ewl_engine_evas_fb.c2008-10-29 09:55:51.0 +
> +++ ewl_engine_evas_fb.c2008-10-29 09:47:05.0 +
> @@ -50,7 +50,7 @@
>  if (!engine)
>  DRETURN_PTR(NULL, DLEVEL_STABLE);
> 
> -if (!ee_init(EWL_ENGINE(engine), argc, argv))
> +if (!ee_init(EWL_ENGINE(engine)))
>  {
>  FREE(engine);
>  DRETURN_PTR(NULL, DLEVEL_STABLE);
> @@ -60,7 +60,7 @@
>  }
> 
>  static int
> -ee_init(Ewl_Engine *engine, int *argc, char ** argv)
> +ee_init(Ewl_Engine *engine)
>  {
>  Ewl_Engine_Info *info;
>  char *display = "0";
> @@ -71,19 +71,6 @@
>  if (ee_key_down_handler)
>  DRETURN_INT(TRUE, DLEVEL_STABLE);
> 
> -if (argc && argv)
> -{
> -int i;
> -for (i = 1; i < *argc; i++)
> -{
> -if (!strcmp(argv[i], "-display"))
> -{
> -if (++i < *argc)
> -display = argv[i];
> -}
> -}
> -}
> -
>  if (!ecore_fb_init(display))
>  {
>  fprintf(stderr, "Unable to initialize Ecore FB.\n"
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Theme/Wallpaper dialog suggestion

[Toma]

This has been fixed anyway!
Toma

2008/11/3 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>:
> On Mon, 22 Sep 2008 13:46:23 +0800 Toma <[EMAIL PROTECTED]> babbled:
>
>> Howdee,
>> Since these 2 dialogs are most probably the most used ones around, it
>> would be a good idea to have them operate in mostly the same way.
>>
>> Heres the dialogs at smallest size.
>> http://members.iinet.net.au/~haste/e17/e17-ui1.png
>>
>> The only issue really is the centre aligned buttons for Import and online.
>>
>> Here are the same dialogs sized bigger.
>> http://members.iinet.net.au/~haste/e17/e17-ui2.png
>>
>> As you can see, the sizing in inconsistent, with wallpaper doing the better
>> job.
>>
>> Here is a mockup of what they should do.
>> http://members.iinet.net.au/~haste/e17/e17-ui3.png
>>
>> The preview widget gets resized, and the file list grows too. This way
>> you get to see the long filenames and the preview in a bigger view.
>> There might be some issues making the preview widget work properly
>> with resize.
>
> yeah. dialogs need some love. i intend to give the wallpaper and theme dialogs
> a lot of love and re-org before release. for the moment - let's let the rough
> bits slide as it's going to get an overhaul :)
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
>
>

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[Vincent Torri]

On Mon, 3 Nov 2008, thomasg wrote:

> Emotion is an Evas Smartobject and can do what you're looking for (it has
> gstreamer support).
> However, it's not well maintained, so you might not only run into problems,
> it might not even work at all (depends I guess).
> I can only quote raster: 'i think it needs a "weekend of love" sometime'.

a weekend of 4 or 5 days... There are lots of things to do in the 
gstreamer backend. The first one is to use the new ecore_pipe :)

Vincent

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[dongmei zhou]

hi,
  thanks,  I  think you  should  know about  canola I think  the media part
of it is  implemented  by  Gstreamer.
  Am  I  right ?
BRS!

2008/11/3 Vincent Torri <[EMAIL PROTECTED]>

>
>
> On Mon, 3 Nov 2008, thomasg wrote:
>
>  Emotion is an Evas Smartobject and can do what you're looking for (it has
>> gstreamer support).
>> However, it's not well maintained, so you might not only run into
>> problems,
>> it might not even work at all (depends I guess).
>> I can only quote raster: 'i think it needs a "weekend of love" sometime'.
>>
>
> a weekend of 4 or 5 days... There are lots of things to do in the gstreamer
> backend. The first one is to use the new ecore_pipe :)
>
> Vincent
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[Dave Andreoli]

- "Nicolas Aguirre" <[EMAIL PROTECTED]> ha scritto:

> 2008/11/3 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>:
> 
> > Gstreamer just sucks to play video on nokia devices, and doing
> extra
> > copies or transformation from YUV to RGB is no-go on those
> hardwares.
> > That's why canola uses atakabe to play media, it will handle
> mplayer,
> > gstreamer...  mplayer is optimized and outputs YUV at half
> resolution
> > using double-pixel directly to framebuffer (in fullscreen mode).
> While
> > in windowed mode, Canola just use ecore_x to reparent MPlayer's
> window
> > to the required position (it's a black rectangle in the theme).
> >
> >
> 
> Exactly what I do with libplayer/mplayer in Enna :)
> 

But in this way you can't have evas objects on top of the mplayer 
window...
What about the vlc backend? It seem the better way for me as, for
what I have understand, vlc doesn't use gstreamer.
Someone have tryed it?


> -- 
> Nicolas Aguirre
> Mail: [EMAIL PROTECTED]
> Web: http://www.digital-corner.org
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[Gustavo Sverzut Barbieri]

On Mon, Nov 3, 2008 at 11:44 AM, Dave Andreoli <[EMAIL PROTECTED]> wrote:
>
> - "Nicolas Aguirre" <[EMAIL PROTECTED]> ha scritto:
>
>> 2008/11/3 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>:
>>
>> > Gstreamer just sucks to play video on nokia devices, and doing
>> extra
>> > copies or transformation from YUV to RGB is no-go on those
>> hardwares.
>> > That's why canola uses atakabe to play media, it will handle
>> mplayer,
>> > gstreamer...  mplayer is optimized and outputs YUV at half
>> resolution
>> > using double-pixel directly to framebuffer (in fullscreen mode).
>> While
>> > in windowed mode, Canola just use ecore_x to reparent MPlayer's
>> window
>> > to the required position (it's a black rectangle in the theme).
>> >
>> >
>>
>> Exactly what I do with libplayer/mplayer in Enna :)
>>
>
> But in this way you can't have evas objects on top of the mplayer
> window...

yes, that's the problem with such approach, but on that platform it's
the only option, really, you don't have much cpu power.

> What about the vlc backend? It seem the better way for me as, for
> what I have understand, vlc doesn't use gstreamer.
> Someone have tryed it?

it's totally buggy, needs fixing. AFAIR it calls back from thread,
which is not allowed in EFL, but people spotted different problems as
well.

Also, vlc is not an option on that platform, gstreamer is the
"official" media player and uses dsp for audio decoding, but mplayer
is was optimized by a guy and is the best, it does this framebuffer
tricky and also have an ARM JIT compiler for scale.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore

[Gustavo Sverzut Barbieri]

On Mon, Nov 3, 2008 at 11:13 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
> Gustavo Sverzut Barbieri schrieb:
>>
>> On Mon, Nov 3, 2008 at 3:42 AM, Enlightenment SVN
>> <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Log:
>>>  add patch to add a pipe handler for glueing threads to the core main
>>> loop via
>>>  pipes - makes it save for a thread to send a message to the main loop
>>> and not
>>>  need lots of thread locks etc.
>>>
>>
>> ok, this code have some minor problems, I should have looked at it
>> before, maybe I can fix it during my flight tomorrow, but:
>>  - read/write need to catch errors, be them EINTR and EAGAIN since fd
>> is marked non-blocking. For EAGAIN we could either just retry or we
>> must keep size and "todo" in Ecore_Pipe as well as an allocated buffer
>> of required size, just dispatch when everything is read. (same for
>> write).
>>
>
> As Sachiel said, raster took the wrong patch. I'll commit the other one this
> evening. I don't claim that that one is perfect, but it does some error
> checking.
>>
>>  - for consistency, we should have handler() to return an int and
>> return that int in _ecore_pipe_read().
>>
>
> And what should we do if the handler returns ECORE_CALLBACK_CANCEL? Should
> we only cancel the callback or also del (free) the whole pipe?

I guess so, like other ecore functions do.


>>  - example contais code that does not even compile, I spotted at
>> least "ecore_pipe_write(pipe, arg0);" but that function takes 3
>> parameters, last one must be sizeof(void *) since you're writing the
>> pointer, but possible more stuff is missing.
>>
>
> Yes, I changed the examples in the other patch, too.

good!


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EWL fb engine won't compile - patch

[Peter Wehrfritz]

Carsten Haitzler (The Rasterman) schrieb:
> On Wed, 29 Oct 2008 09:23:17 + Quaker <[EMAIL PROTECTED]> babbled:
>
> i don't see how it wouldn't work. code seems ok to me - builds for me too... 
> :/
>   

Sorry, my bad. I haven't answered to the list. I fixed it some days ago. 
So indeed it should work fine now :).


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: pfritz trunk/ecore/src/lib/ecore

[Gustavo Sverzut Barbieri]

On Mon, Nov 3, 2008 at 11:57 AM, Enlightenment SVN
<[EMAIL PROTECTED]> wrote:
> +   /* first write the len into the pipe */
> +   do
> + {
> +   ret = pipe_write(p->fd_write, &nbytes, sizeof(nbytes));
> +   if (ret == sizeof(nbytes))
> + {
> +retry = ECORE_PIPE_WRITE_RETRY;
> +break;
> + }
> +   else if (ret > 0)
> + {
> +/* XXX What should we do here? */
> +fprintf(stderr, "The length of the data was not written complete"
> + " to the pipe\n");

try to read what's missing, you'll end with EAGAIN if there is no data
yet. In that case you either try a busy loop or you save number of
read bytes and what's missing and continue on next next fd_handler.

> +   else
> + {
> +fprintf(stderr, "An unhandled error (ret: %d errno: %d)"
> +  "occured while writing to the pipe the length\n",
> +  ret, errno);

please, use strerror(errno) to make it easier to figure out what's happened.


> + }
> + }
> +   while (retry--);
> +
> +   if (retry != ECORE_PIPE_WRITE_RETRY)
> + return 0;

this termination condition is weird, if it's "retry" it should mean we
should retry, not that it finished fine.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[Nicolas Aguirre]

2008/11/3 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>:

> Gstreamer just sucks to play video on nokia devices, and doing extra
> copies or transformation from YUV to RGB is no-go on those hardwares.
> That's why canola uses atakabe to play media, it will handle mplayer,
> gstreamer...  mplayer is optimized and outputs YUV at half resolution
> using double-pixel directly to framebuffer (in fullscreen mode). While
> in windowed mode, Canola just use ecore_x to reparent MPlayer's window
> to the required position (it's a black rectangle in the theme).
>
>

Exactly what I do with libplayer/mplayer in Enna :)

-- 
Nicolas Aguirre
Mail: [EMAIL PROTECTED]
Web: http://www.digital-corner.org

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore

[Gustavo Sverzut Barbieri]

On Mon, Nov 3, 2008 at 3:42 AM, Enlightenment SVN
<[EMAIL PROTECTED]> wrote:
> Log:
>  add patch to add a pipe handler for glueing threads to the core main loop via
>  pipes - makes it save for a thread to send a message to the main loop and not
>  need lots of thread locks etc.

ok, this code have some minor problems, I should have looked at it
before, maybe I can fix it during my flight tomorrow, but:
  - read/write need to catch errors, be them EINTR and EAGAIN since fd
is marked non-blocking. For EAGAIN we could either just retry or we
must keep size and "todo" in Ecore_Pipe as well as an allocated buffer
of required size, just dispatch when everything is read. (same for
write).
  - for consistency, we should have handler() to return an int and
return that int in _ecore_pipe_read().
  - example contais code that does not even compile, I spotted at
least "ecore_pipe_write(pipe, arg0);" but that function takes 3
parameters, last one must be sizeof(void *) since you're writing the
pointer, but possible more stuff is missing.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[Gustavo Sverzut Barbieri]

On Mon, Nov 3, 2008 at 1:20 PM, thomasg <[EMAIL PROTECTED]> wrote:
> Because of that and many many other reasons it would be really cool,
> to have a mplayer backend for emotion. :)
> But I know, it's really tricky to find a good solution, because
> mplayer isn't meant to be just a backend.

you'd have to write an Evas "vo" for mplayer and do sync of both
processes somehow.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[thomasg]

On Mon, Nov 3, 2008 at 9:49 AM, dongmei zhou <[EMAIL PROTECTED]>wrote:

> hi all,
>
>   You  know  that  Gstreamer video often is displayed  in  drawingarea
> which  is   created  by  "gtk.Drawingarea()" function,
> Is  there  any  efl object  instead of  this function  to  create a
> drawingarea  to display  Gstreamer  video.
> Any  examples  would  be  welcome :)
>
>
Emotion is an Evas Smartobject and can do what you're looking for (it has
gstreamer support).
However, it's not well maintained, so you might not only run into problems,
it might not even work at all (depends I guess).
I can only quote raster: 'i think it needs a "weekend of love" sometime'.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efreet mime default application patch

[Dave Andreoli]

- "Carsten Haitzler (The Rasterman)" <[EMAIL PROTECTED]> ha scritto:

> On Tue, 28 Oct 2008 23:06:58 +0100 (CET) Dave Andreoli
> <[EMAIL PROTECTED]>
> babbled:
> 
> > 
> > - "Nick Hughart" <[EMAIL PROTECTED]> ha scritto:
> > 
> > > This is not yet an fdo specification so I'm not going to put it
> in
> > > just 
> > > yet.  It seems to have promise and is a fairly simple format, but
> for
> > > 
> > > now we have our own methods of choosing default applications and
> it is
> > > 
> > > similar to how they choose as well (given the user is not making
> this
> > > 
> > > file on their own). 
> > > 
> > > When opening a file in EFM, if that mimetype has not been opened 
> > > previously you will be given a list of apps that support that
> mimetype
> > > 
> > > and a list of all apps as well just in case.  Once you have chosen
> an
> > > 
> > > app, EFM remembers this and will use that app until you pick a
> > > different 
> > > app by using Open With.  So for now we have our own methods of
> doing 
> > > this, but if it does become a specification it may be good to
> adopt
> > > this 
> > > as it would help with those doing packaging and distribution.
> > 
> > Where EFM store the user preference, is it possible to others to
> access
> > this data? 
> > I think we need a centralised way to keep this information, or the
> user
> > need to choose a preferred application for every apps/module that
> need
> > to open a filemanager or a browser.
> > I know this is not a standard yet. But this doesn't mean we can't
> have
> > our method to storing this user preference.
> > 
> > I have also done a module that add a configuration dialog to set
> your
> > preferred apps. Its very simple, but it make no sense if there are
> > not a shared place to store the informations.
> > Don't you think this is a must have module??
> > 
> > So IMHO we need to define witch is the E way to store the
> mime/application
> > associations, and have the code in some lib (maybe not efreet for
> now).
> > In this way we can have all the apps/module work the same way and we
> 
> > can also change the lib to fit a final freedesktop standard without
> 
> > touching modules.
> > If we don't do this now all the apps/modules will do the
> associations 
> > in a different way and when the fdo standard will become a reality
> we 
> > need to redo everything.
> 
> well within e it's easy - there are calls to find this info, but
> outside of e +
> modules it's buried deep in e's own config somewhere. now how do we
> want to do
> this?
> 
> 1. config everyone cal look at
> OR
> 2. "opening service". e.g. a dbus call- u send an array (list) of file
> paths
> and say "open them please" - e will open them for you. this way you
> also
> recycle the exec method and child process tracking etc. if the target
> file is a
> directory - it opens a directory window, etc.
> 
> is #2 perhaps not better?

The #2 is powerfull but will work only if E is running, and this is bad
for applications, that should work also outside E. 

I prefer the #1, put the config where everyone can look...what about
the defaults.list file ? ;) (it's not yet a fdo standard, but it's a 
simple and clear way to store the info)

> -- 
> - Codito, ergo sum - "I code, therefore I am"
> --
> The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: pfritz trunk/ecore/src/lib/ecore

[Peter Wehrfritz]

Gustavo Sverzut Barbieri schrieb:

On Mon, Nov 3, 2008 at 11:57 AM, Enlightenment SVN
<[EMAIL PROTECTED]> wrote:
  

+   /* first write the len into the pipe */
+   do
+ {
+   ret = pipe_write(p->fd_write, &nbytes, sizeof(nbytes));
+   if (ret == sizeof(nbytes))
+ {
+retry = ECORE_PIPE_WRITE_RETRY;
+break;
+ }
+   else if (ret > 0)
+ {
+/* XXX What should we do here? */
+fprintf(stderr, "The length of the data was not written complete"
+ " to the pipe\n");



try to read what's missing, you'll end with EAGAIN if there is no data
yet. In that case you either try a busy loop or you save number of
read bytes and what's missing and continue on next next fd_handler.

  
It is actually a case that should never happen, i think. Anyway I added 
code to pass the rest of the length again.

+   else
+ {
+fprintf(stderr, "An unhandled error (ret: %d errno: %d)"
+  "occured while writing to the pipe the length\n",
+  ret, errno);



please, use strerror(errno) to make it easier to figure out what's happened.
  

k

+ }
+ }
+   while (retry--);
+
+   if (retry != ECORE_PIPE_WRITE_RETRY)
+ return 0;



this termination condition is weird, if it's "retry" it should mean we
should retry, not that it finished fine.
  


Indeed, it was not very readable. I changed the logic abit.

Index: ecore_pipe.c
===
--- ecore_pipe.c	(Revision 37441)
+++ ecore_pipe.c	(Arbeitskopie)
@@ -326,7 +326,8 @@
 	  "ecore_pipe_del");
 	return NULL;
  }
-   ecore_main_fd_handler_del(p->fd_handler);
+   if (p->fd_handler)
+ ecore_main_fd_handler_del(p->fd_handler);
close(p->fd_read);
close(p->fd_write);
data = (void *)p->data;
@@ -348,7 +349,13 @@
ssize_t ret;
size_t already_written = 0;
int retry = ECORE_PIPE_WRITE_RETRY;
+   union {
+	unsigned int isize;
+	unsigned char bytes[sizeof(nbytes)];
+   } size;
 
+   size.isize = nbytes;
+
if (!ECORE_MAGIC_CHECK(p, ECORE_MAGIC_PIPE))
  {
 	ECORE_MAGIC_FAIL(p, ECORE_MAGIC_PIPE,
@@ -358,35 +365,30 @@
/* first write the len into the pipe */
do
  {
-	ret = pipe_write(p->fd_write, &nbytes, sizeof(nbytes));
-	if (ret == sizeof(nbytes))
-	  {
-	 retry = ECORE_PIPE_WRITE_RETRY;
-	 break;
-	  }
-	else if (ret > 0)
-	  {
-	 /* XXX What should we do here? */
-	 fprintf(stderr, "The length of the data was not written complete"
-		  " to the pipe\n");
-	 return 0;
-	  }
+	ret = pipe_write(p->fd_write, &size.bytes[already_written],
+sizeof(nbytes) - already_written);
+	if (ret == (ssize_t)(sizeof(nbytes) - already_written))
+	  break;
+	else if (ret >= 0)
+	  already_written += ret;
 	else if (ret == -1 && errno == EINTR)
 	  /* try it again */
 	  ;
 	else
 	  {
-	 fprintf(stderr, "An unhandled error (ret: %d errno: %d)"
+	 fprintf(stderr, "An unhandled error (ret: %d errno: %s)"
 		   "occured while writing to the pipe the length\n",
-		   ret, errno);
+		   ret, strerror(errno));
 	  }
  } 
while (retry--);
 
-   if (retry != ECORE_PIPE_WRITE_RETRY)
+   if (retry < 0)
  return 0;
 
/* and now pass the data to the pipe */
+   already_written = 0;
+   retry = ECORE_PIPE_WRITE_RETRY;
do
  {
 	ret = pipe_write(p->fd_write, 
@@ -397,7 +399,7 @@
 	  return 1;
 	else if (ret >= 0)
 	  {
-	 already_written -= ret;
+	 already_written += ret;
 	 continue;
 	  }
 	else if (ret == -1 && errno == EINTR)
@@ -405,9 +407,9 @@
 	  ;
 	else
 	  {
-	 fprintf(stderr, "An unhandled error (ret: %d errno: %d)"
+	 fprintf(stderr, "An unhandled error (ret: %d errno: %s)"
 		   "occured while writing to the pipe the length\n",
-		   ret, errno);
+		   ret, strerror(errno));
 	  }
  } 
while (retry--);
@@ -435,28 +437,48 @@
 	 */
 	if (p->len == 0)
 	  {
-	 /* read the len of the passed data */
-	 ret = pipe_read(p->fd_read, &p->len, sizeof(p->len));
+	 union {
+		  unsigned int isize;
+		  unsigned char bytes[sizeof(unsigned int)];
+	 } size;
+	 size_t already_read_len = 0;
 
-	 /* catch the non error case first */
-	 if (ret == sizeof(p->len))
-	   ;
-	 else if (ret > 0)
+	 for (;;)
 	   {
-		  /* XXX What should we do here? */
-		  fprintf(stderr, "Only read %d bytes from the pipe, although"
-			" we need to read %d bytes.\n", ret, sizeof(p->len));
+		  /* read the len of the passed data */
+		  ret = pipe_read(p->fd_read, &size.bytes[already_read_len], 
+			sizeof(p->len) - already_read_len);
+
+		  /* catch the non error case first */
+		  if (ret == sizeof(p->len))
+		{
+		   p->len = size.isize;
+		   break;
+		}
+		  else if (ret > 0)
+		already_read_len += ret;
+		  else if (ret == 0 
+			|| (ret == -1 && (errno == EINTR || errno == EAGAIN)))
+		{
+		   if (!already_read_len)

Re: [E-devel] Rage TODO items

[The Rasterman]

On Sat, 01 Nov 2008 20:13:21 +0100 Tim Felgentreff <[EMAIL PROTECTED]>
babbled:

> Hi, I am atm trying to help a little for the first time, working on the
> TODO list of Rage. I have started on two items already. One is simple

oh cool! rage has been on the backburner for a long time. i really wrote it to
solve my "i can watch movies" problem then stopped :)

> mouse control for rage, and the other is work on the settings menu. I
> would like to hear what you think. I would also like to add support for
> an eet configfile to rage, if that's okay with the maintainer. Both
> patches apply cleanly to revision 37377, they're not interrelated.
> Regards, Tim

patches seem cool - i'll put them in svn. :) continue merrily with your work! :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] EET crypto

[Cedric BAIL]

On Mon, Nov 3, 2008 at 9:05 AM, The Rasterman Carsten Haitzler
<[EMAIL PROTECTED]> wrote:
> On Wed, 8 Oct 2008 16:12:13 +0200 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:
>> On Wed, Oct 8, 2008 at 4:02 PM, Gustavo Sverzut Barbieri
>> <[EMAIL PROTECTED]> wrote:
>> > On Wed, Oct 8, 2008 at 10:19 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote:
>> >> On Wed, Oct 8, 2008 at 3:00 PM, Viktor Kojouharov <[EMAIL PROTECTED]>
>> >> wrote:
>> >>> On Wed, 2008-10-08 at 14:46 +0200, Cedric BAIL wrote:
>>  Hi,
>> 
>> As it seems like a good time to break the EFL agains :-). I would
>>  like to discuss API/ABI break of eet. I am currently working on adding
>>  crypto to eet. My current code only require a key and generate the
>>  needed salt and IV for the encryption. So I need to add one more
>>  parameter (the key) to all read and write operation of eet. I have
>>  currently two possibilities, double the number of function, or just
>>  change the existing one. Of course the later solution sounds a little
>>  bit cleaner, but it will break all eet applications.
>> 
>> A quick search of eet_open in the svn give me 43 differents file
>>  using it. Sounds like not a big deal to break it. This could be also
>>  be a good time to cleanup the parameters of
>>  eet_data_descriptor_element_add also.
>> 
>> So guys, what do you think of this move ?
>> >>>
>> >>> Wasn't eet 1.0 released a couple of weeks ago? Breaking the API after
>> >>> the supposed stable 1.0 release just screams wrong in so many ways.
>> >>
>> >> Yeah, I know, that's why I asked. I just don't like the idea of not
>> >> breaking the API/ABI and adding code to work around for marketing
>> >> issue.
>> >>
>> >> Just looking at the TODO. We are planning to add :
>> >>  - support for scripting langage to convert from their object type to
>> >> eet data and from eet data to script object.
>> >>  - streaming API for both audio and video.
>> >>
>> >> The only draw back on switching to 2.0 branch on Eet, is that we
>> >> currently have one standing bug covered by the test case, that I can
>> >> find a way to fix (bug in dump/undump) and this will mean that at some
>> >> point we will need to make another release of the 1.0 branch.
>> >
>> > Do we need a different key for each read/write operation? I see this
>> > being more a key per file, in that case make an eet_key_set(ef, key)
>> > and check for the set pointer inside read/write operations.
>> >
>> > the existing parameters are really one per entry, like compression.
>>
>> I am not really planning to cypher all the data of the file, but just
>> on a entry basis. So you can cypher eet data, but not picture for
>> example. And I want to add this to eet_data_descriptor_decode and
>> encode too.
>>
>> Between it will be a good time to also remove eet_data_descriptor2_new
>> and eet_data_descriptor3_new.

> hmm an api break... hmmm. hmmm. very soon after a 1.0.0 (i knew it was too
> soon!).

> ok - here's my deal. remove descriptor2/3 and merge that all into 1 so fix 
> that
> mess and you get your cypher key - as long as it doesnt break apps (eet using
> apps and libs) :)

> maybe you want to postpone this until all the eina stuff is done?

I need crypto support soon, so I will provide a patch that doesn't
break API. Before breaking eet API, I agree that we should first
finish this move to eina, currently postponed for around 2 weeks as I
have some deadline.

But I have a little bad news, we will need more than just breaking eet
API. There are currently 2 bugs regarding eet dump/undump function,
one that I almost know how to solve and another one that I don't
understand yet what is going on. The first one is just the dump/undump
part of list/array/hash of strings bug.

The problem is in that case that we loose the information in the eet
data that the chunk is an item part of a list/array/hash and not only
a string. Solving it is easy... we just need to change eet data format
so we always store simple type and the group type. I think we can make
it backward compatible, by just handling both current and new format
with a new magic string. I have just starting to work on a fix, but
it's not high enough on my TODO list at the moment. So don't expect
complete fix before a few weeks.

The second bug is due to undumping struct of struct which doesn't
result in the same eet data as the dumped one. My guess is that this
bug is related to EET_G_UNKNOWN case in _eet_data_dump_encode. But I
wasn't able to find a fix nor really understand what is going on in
that case.

So eet TODO list is quite nice at the moment and need a little bit of
work before any major release :-)
-- 
Cedric BAIL

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[thomasg]

Because of that and many many other reasons it would be really cool,
to have a mplayer backend for emotion. :)
But I know, it's really tricky to find a good solution, because
mplayer isn't meant to be just a backend.

On 11/3/08, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 3, 2008 at 11:44 AM, Dave Andreoli <[EMAIL PROTECTED]>
> wrote:
>>
>> - "Nicolas Aguirre" <[EMAIL PROTECTED]> ha scritto:
>>
>>> 2008/11/3 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>:
>>>
>>> > Gstreamer just sucks to play video on nokia devices, and doing
>>> extra
>>> > copies or transformation from YUV to RGB is no-go on those
>>> hardwares.
>>> > That's why canola uses atakabe to play media, it will handle
>>> mplayer,
>>> > gstreamer...  mplayer is optimized and outputs YUV at half
>>> resolution
>>> > using double-pixel directly to framebuffer (in fullscreen mode).
>>> While
>>> > in windowed mode, Canola just use ecore_x to reparent MPlayer's
>>> window
>>> > to the required position (it's a black rectangle in the theme).
>>> >
>>> >
>>>
>>> Exactly what I do with libplayer/mplayer in Enna :)
>>>
>>
>> But in this way you can't have evas objects on top of the mplayer
>> window...
>
> yes, that's the problem with such approach, but on that platform it's
> the only option, really, you don't have much cpu power.
>
>> What about the vlc backend? It seem the better way for me as, for
>> what I have understand, vlc doesn't use gstreamer.
>> Someone have tryed it?
>
> it's totally buggy, needs fixing. AFAIR it calls back from thread,
> which is not allowed in EFL, but people spotted different problems as
> well.
>
> Also, vlc is not an option on that platform, gstreamer is the
> "official" media player and uses dsp for audio decoding, but mplayer
> is was optimized by a guy and is the best, it does this framebuffer
> tricky and also have an ARM JIT compiler for scale.
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: [EMAIL PROTECTED]
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore

[Iván Briano (Sachiel)]

On Mon, Nov 3, 2008 at 8:46 AM, Gustavo Sverzut Barbieri
<[EMAIL PROTECTED]> wrote:
> On Mon, Nov 3, 2008 at 3:42 AM, Enlightenment SVN
> <[EMAIL PROTECTED]> wrote:
>> Log:
>>  add patch to add a pipe handler for glueing threads to the core main loop 
>> via
>>  pipes - makes it save for a thread to send a message to the main loop and 
>> not
>>  need lots of thread locks etc.
>
> ok, this code have some minor problems, I should have looked at it
> before, maybe I can fix it during my flight tomorrow, but:
>  - read/write need to catch errors, be them EINTR and EAGAIN since fd
> is marked non-blocking. For EAGAIN we could either just retry or we
> must keep size and "todo" in Ecore_Pipe as well as an allocated buffer
> of required size, just dispatch when everything is read. (same for
> write).

There was another patch that did check for errors.

>  - for consistency, we should have handler() to return an int and
> return that int in _ecore_pipe_read().
>  - example contais code that does not even compile, I spotted at
> least "ecore_pipe_write(pipe, arg0);" but that function takes 3
> parameters, last one must be sizeof(void *) since you're writing the
> pointer, but possible more stuff is missing.
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: [EMAIL PROTECTED]
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[Gustavo Sverzut Barbieri]

On Mon, Nov 3, 2008 at 9:58 AM, dongmei zhou <[EMAIL PROTECTED]> wrote:
> hi,
>  thanks,  I  think you  should  know about  canola I think  the media part
> of it is  implemented  by  Gstreamer.
>  Am  I  right ?

Gstreamer just sucks to play video on nokia devices, and doing extra
copies or transformation from YUV to RGB is no-go on those hardwares.
That's why canola uses atakabe to play media, it will handle mplayer,
gstreamer...  mplayer is optimized and outputs YUV at half resolution
using double-pixel directly to framebuffer (in fullscreen mode). While
in windowed mode, Canola just use ecore_x to reparent MPlayer's window
to the required position (it's a black rectangle in the theme).


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E moudule API BREAK proposal

[The Rasterman]

On Sat, 11 Oct 2008 20:48:04 +0200 (CEST) Dave Andreoli
<[EMAIL PROTECTED]> babbled:

> Hi all,
> 
> I want to make an e17 module that expose simple edje objects as gadgets.
> The idea is that people can download edje file from the net(calculator,
> clocks and whatever next), put it in the right directory and then my module
> can expose this objects as they was gadgets (they must appear in the available
> gadgets list of the shelf or the gadman). So that the user can use the object
> where they want.
> 
> This can be a really easy way to create and distribute simple gadgets as you
> don't have to compile the edje object for different arch (thinking about
> exchange can also host gadgets, without platform problem!).
> In the future my module can also make some advanced stuff, for example execute
> a bash, python (or what you like) script that is contained in the edje file,
> making the simple gadgets more functional... but this is another story...
> 
> This was the good part of the post, now comes the bad :(
> I can't find a way to do this module without changing the E GADCON API.
> From the module I create an E_Gadcon_Client_Class for each 'simple widget'
> found in the right directory, and I call e_gadcon_provider_register()
> as many times as needed. But then when E ask me for the label, the icon and
> the id I can't know for witch 'simple widget' he need the information.
> 
> 
> This is how it is done now:
> 
> struct _E_Gadcon_Client_Class
> {
>    int   version;
>    const char *name;
>    struct 
>      {
> E_Gadcon_Client *(*init)     (E_Gadcon *gc, const char *name, const
> char *id, const char *style); void             (*shutdown) (E_Gadcon_Client
> *gcc); void             (*orient)   (E_Gadcon_Client *gcc);
> char            *(*label)    (void);
> Evas_Object     *(*icon)     (Evas *evas);
> const char      *(*id_new)   (void);
> void             (*id_del)   (const char *id);
>      } func;
>    char *default_style;
> };
> 
> 
> As you can see the function label(void) don't have params and my module 
> is lost on this (for witch widget you want the label??). The same apply
> to the icon and id_new functions.
> So this is my proposed API
> 
> struct _E_Gadcon_Client_Class
> {
>    int   version;
>    const char *name;
>    struct 
>      {
> E_Gadcon_Client *(*init)     (E_Gadcon *gc, const char *name, const
> char *id, const char *style); void             (*shutdown) (E_Gadcon_Client
> *gcc); void             (*orient)   (E_Gadcon_Client *gcc);
> char            *(*label)    (E_Gadcon_Client_Class *class);
> Evas_Object     *(*icon)     (Evas *evas, E_Gadcon_Client_Class
> *class); const char      *(*id_new)   (E_Gadcon_Client_Class *class);
> void             (*id_del)   (const char *id);
>      } func;
>    char *default_style;
> };
> 
> I simple add the E_Gadcon_Client_Class *class params to some functions.

ok one thng. for consistency make E_Gadcon_Client_Class the first param for icon
() and also for id_del() even if we don't use it - at least it's consistent :)

> I think that this kind of functionality (a single module that expose more
> than one gadgets) could be useful in future, for example  we can then make a
> module that handle gadgets from different source (think of google_gadgets,
> OSX dashbord widget...and so on) like KDE4 seems to do. WE then access a
> really HUGE set of just done gadgets :)
> 
> 
> What do you think about all this? It make sense? 
> maybe someone know how to do this without the break?
> 
> Hope you like my idea, and also hope that this mail is clear enough...
> as always my English is not so good ;)

hmm - it makes sense. i guess if we break - break before e17 is released. so
lets do it. i'm in. do your stuff! :)

> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event a

Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore

[Peter Wehrfritz]

Gustavo Sverzut Barbieri schrieb:
> On Mon, Nov 3, 2008 at 3:42 AM, Enlightenment SVN
> <[EMAIL PROTECTED]> wrote:
>   
>> Log:
>>  add patch to add a pipe handler for glueing threads to the core main loop 
>> via
>>  pipes - makes it save for a thread to send a message to the main loop and 
>> not
>>  need lots of thread locks etc.
>> 
>
> ok, this code have some minor problems, I should have looked at it
> before, maybe I can fix it during my flight tomorrow, but:
>   - read/write need to catch errors, be them EINTR and EAGAIN since fd
> is marked non-blocking. For EAGAIN we could either just retry or we
> must keep size and "todo" in Ecore_Pipe as well as an allocated buffer
> of required size, just dispatch when everything is read. (same for
> write).
>   
As Sachiel said, raster took the wrong patch. I'll commit the other one 
this evening. I don't claim that that one is perfect, but it does some 
error checking.
>   - for consistency, we should have handler() to return an int and
> return that int in _ecore_pipe_read().
>   
And what should we do if the handler returns ECORE_CALLBACK_CANCEL? 
Should we only cancel the callback or also del (free) the whole pipe?
>   - example contais code that does not even compile, I spotted at
> least "ecore_pipe_write(pipe, arg0);" but that function takes 3
> parameters, last one must be sizeof(void *) since you're writing the
> pointer, but possible more stuff is missing.
>   
Yes, I changed the examples in the other patch, too.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction

[Gustavo Sverzut Barbieri]

On Mon, Nov 3, 2008 at 5:56 AM, The Rasterman Carsten Haitzler
<[EMAIL PROTECTED]> wrote:
> On Tue, 7 Oct 2008 08:55:59 -0300 "Gustavo Sverzut Barbieri"
> <[EMAIL PROTECTED]> babbled:
>
>> On Tue, Oct 7, 2008 at 2:57 AM, Enlightenment SVN
>> <[EMAIL PROTECTED]> wrote:
>> > Log:
>> >  Some work on interaction settings:
>> >  - group on a thumbscroll framelist;
>> >  - threshhold ?\226?\134?\146 threshold;
>> >  - add check changed.
>>
>>
>> that's awesome, I see people liked the "check_changed", we should add
>> this to other dialogs as well.
>>
>> something else I'd like to see is to move, where possible, layouts to
>> edje with swallow parts, that way we can have special layouts in
>> embedded systems like illume. Side effect is to simplify code a lot.
>> What do you think?
> at some point - but edje doesnt solve it all - for embedded (small screen) 
> uis'
> u really need to possibly drop entire content and re-think it. i intend to do
> this for a chunk of dialogs anyway so their default is more small-screen
> friendly.

sure, sure! but for some dialogs we can just make it vertical and it will work.

some dialogs will have to move to multi-step, like "choose something"
and then you're presented with options relevant to that mode, but
maybe this is good for desktops as well..

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eet wrapper

[Andreas Volz]

Am Mon, 3 Nov 2008 09:56:45 +0100 schrieb Jonathan MULLER:

Hello Jonathan,

would be nice if you do that. And best provide a path to integrate it
into eflpp.

BTW: Seems you're not a member of
enlightenment-devel@lists.sourceforge.net list. You should join the
list if you like to post anything

regards
Andreas

> Hi Andreas,
> 
> I understand those problematics of course.
> The dependency is on tuple classe with 3 elements ... we could in a
> first time considering a std::pair of std::pair
> 
> boost::tuple < Ty, int, bool > ~ std::pair < std::pair< Ty, int >,
> bool >
> 
> It will be a bit more heavy for the user ... but I can have a look to
> develop this.
> 
> I have to say adding a dependncy on boost would be a great idea.
> 
> Regards,
> 
> Jonathan Muller.
> 
> On Sun, Nov 2, 2008 at 12:03 PM, Andreas Volz
> <[EMAIL PROTECTED]> wrote:
> > Am Sat, 1 Nov 2008 21:14:57 +0100 schrieb Jonathan MULLER:
> >
> > Hello Jonathan,
> >
> > I reviewed the source code short and this it looks good. But
> > there's a little problem. Until now the eflpp library hasn't any
> > boost dependency.
> >
> > Using your eet wrapper would create a dependency to boost for all
> > applications based on eflpp. For me personal this isn't a big
> > problem as my main application is yet based on boost for some other
> > reasons.
> >
> > The positive would be that it allows to replace some other stuff in
> > eflpp with boost code. But as this is a design decision I'm not sure
> > about it. At least I like to discuss that topic on the list. I added
> > the list to Cc.
> >
> > Meanwhile you could think about if it's not possible to rewrite your
> > wrapper with STL classes.
> >
> > Any other opinions from the list?
> >
> > regards
> > Andreas
> >
> > BTW: I didn't attach the source code to this E-Mail. You've to ask
> > Jonathan about it.
> >
> >> Hi Andreas,
> >>
> >> You will find in as attached file the wrapper.
> >> execute
> >> make to build the 2 executables
> >>
> >> and make test to run first the writing test and the the readin
> >> test. And take a look at the code ;)
> >>
> >> I am waiting for your feedbacks.
> >> I do not have rights to commit in the SVN tree that's why I send
> >> you this first approach.
> >>
> >> Note : you have to have the boost tuple library.
> >>
> >>
> >> Regards,
> >>
> >> John aka Bhaal22.
> >>
> >> On Fri, Oct 31, 2008 at 9:09 PM, Andreas Volz
> >> <[EMAIL PROTECTED]> wrote:
> >> > Am Mon, 27 Oct 2008 16:01:30 +0200 schrieb Jonathan MULLER:
> >> >
> >> > Hello Jonathan,
> >> >
> >> > I'm interested in your wrapper. Do you've a patch based on
> >> > existing eflpp code base? It should fit into the eflpp design.
> >> >
> >> > regards
> >> > Andreas
> >> >
> >> >> Hi Andreas,
> >> >>
> >> >> I wrote a little C++ wrapper around Eet library compliant with
> >> >> STL. I can use STL algorithm to iterate over keys, entries ...
> >> >>
> >> >> I wrote some operators to access items in a user friendly way.
> >> >>
> >> >> I can show you if you want.
> >> >>
> >> >> Regards,
> >> >>
> >> >> Jonathan Muller.
> >> >>
> >> >>
> >> >> --
> >> >> Drylm Founder
> >> >> http://www.drylm.org
> >> >>
> >> >
> >> >
> >> > --
> >> > Technical Blog 
> >> >
> >>
> >>
> >>
> >> --
> >> Drylm Founder
> >> http://www.drylm.org
> >>
> >
> >
> > --
> > Technical Blog 
> >
> 
> 
> 
> -- 
> Drylm Founder
> http://www.drylm.org
> 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[Vincent Torri]

On Mon, 3 Nov 2008, Gustavo Sverzut Barbieri wrote:

> On Mon, Nov 3, 2008 at 1:20 PM, thomasg <[EMAIL PROTECTED]> wrote:
>> Because of that and many many other reasons it would be really cool,
>> to have a mplayer backend for emotion. :)
>> But I know, it's really tricky to find a good solution, because
>> mplayer isn't meant to be just a backend.
>
> you'd have to write an Evas "vo" for mplayer and do sync of both
> processes somehow.

i wanted to write one at some point, but i have so few time that i gave up


Vincent

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[Nicolas Aguirre]

2008/11/3 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>:
> On Mon, Nov 3, 2008 at 1:20 PM, thomasg <[EMAIL PROTECTED]> wrote:
>> Because of that and many many other reasons it would be really cool,
>> to have a mplayer backend for emotion. :)
>> But I know, it's really tricky to find a good solution, because
>> mplayer isn't meant to be just a backend.
>
> you'd have to write an Evas "vo" for mplayer and do sync of both
> processes somehow.
>

We should look at libplayer (libplayer.geexbox.org), which is a
wrapper that controls mplayer process in slave mode,
After that, as Gustavo said, write a buffer "vo" for mplayer like it's
done in vlc.
AFAIR mplayer can be only controlled in slave mode.

my 2 cents.

-- 
Nicolas Aguirre
Mail: [EMAIL PROTECTED]
Web: http://www.digital-corner.org

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efreet mime default application patch

[Nick Hughart]

On Mon, 3 Nov 2008 14:39:05 +0100 (CET)
Dave Andreoli <[EMAIL PROTECTED]> wrote:

> 
> - "Carsten Haitzler (The Rasterman)" <[EMAIL PROTECTED]> ha
> scritto:
> 
> > On Tue, 28 Oct 2008 23:06:58 +0100 (CET) Dave Andreoli
> > <[EMAIL PROTECTED]>
> > babbled:
> > 
> > > 
> > > - "Nick Hughart" <[EMAIL PROTECTED]> ha scritto:
> > > 
> > > > This is not yet an fdo specification so I'm not going to put it
> > in
> > > > just 
> > > > yet.  It seems to have promise and is a fairly simple format,
> > > > but
> > for
> > > > 
> > > > now we have our own methods of choosing default applications and
> > it is
> > > > 
> > > > similar to how they choose as well (given the user is not making
> > this
> > > > 
> > > > file on their own). 
> > > > 
> > > > When opening a file in EFM, if that mimetype has not been
> > > > opened previously you will be given a list of apps that support
> > > > that
> > mimetype
> > > > 
> > > > and a list of all apps as well just in case.  Once you have
> > > > chosen
> > an
> > > > 
> > > > app, EFM remembers this and will use that app until you pick a
> > > > different 
> > > > app by using Open With.  So for now we have our own methods of
> > doing 
> > > > this, but if it does become a specification it may be good to
> > adopt
> > > > this 
> > > > as it would help with those doing packaging and distribution.
> > > 
> > > Where EFM store the user preference, is it possible to others to
> > access
> > > this data? 
> > > I think we need a centralised way to keep this information, or the
> > user
> > > need to choose a preferred application for every apps/module that
> > need
> > > to open a filemanager or a browser.
> > > I know this is not a standard yet. But this doesn't mean we can't
> > have
> > > our method to storing this user preference.
> > > 
> > > I have also done a module that add a configuration dialog to set
> > your
> > > preferred apps. Its very simple, but it make no sense if there are
> > > not a shared place to store the informations.
> > > Don't you think this is a must have module??
> > > 
> > > So IMHO we need to define witch is the E way to store the
> > mime/application
> > > associations, and have the code in some lib (maybe not efreet for
> > now).
> > > In this way we can have all the apps/module work the same way and
> > > we
> > 
> > > can also change the lib to fit a final freedesktop standard
> > > without
> > 
> > > touching modules.
> > > If we don't do this now all the apps/modules will do the
> > associations 
> > > in a different way and when the fdo standard will become a reality
> > we 
> > > need to redo everything.
> > 
> > well within e it's easy - there are calls to find this info, but
> > outside of e +
> > modules it's buried deep in e's own config somewhere. now how do we
> > want to do
> > this?
> > 
> > 1. config everyone cal look at
> > OR
> > 2. "opening service". e.g. a dbus call- u send an array (list) of
> > file paths
> > and say "open them please" - e will open them for you. this way you
> > also
> > recycle the exec method and child process tracking etc. if the
> > target file is a
> > directory - it opens a directory window, etc.
> > 
> > is #2 perhaps not better?
> 
> The #2 is powerfull but will work only if E is running, and this is
> bad for applications, that should work also outside E. 
> 
> I prefer the #1, put the config where everyone can look...what about
> the defaults.list file ? ;) (it's not yet a fdo standard, but it's a 
> simple and clear way to store the info)

I agree, we should follow the spec on this one as it will ease the
burden on distributors who need to setup these types of options for all
desktops.  The proposed FDO specification needs some work, but
hopefully becomes useful.  We'll see :)

> 
> > -- 
> > - Codito, ergo sum - "I code, therefore I am"
> > --
> > The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Rage TODO items

[Tim Felgentreff]

On Mo, 2008-11-03 at 23:42 +1100, Carsten Haitzler wrote:
> 
> patches seem cool - i'll put them in svn. :) continue merrily with your work! 
> :)
> 
Thanks a lot!

I have extended the settings patch to use a eet-configfile now.
Also I have fixed a warning about evas_smart_new being deprecated by
replacing it with evas_smart_class_new as suggested in the warning.
Both patches apply cleanly here at revision 37444, compile and run fine
(as far as I've tested).
Please tell me what you think.

diff --git a/src/bin/Makefile.am b/src/bin/Makefile.am
index d72c001..88793d4 100644
--- a/src/bin/Makefile.am
+++ b/src/bin/Makefile.am
@@ -35,7 +35,9 @@ e_table.h \
 e_layout.c \
 e_layout.h \
 e_flowlayout.c \
-e_flowlayout.h
+e_flowlayout.h \
+conf_options.c \
+conf_options.h
 
 rage_LDADD = @my_libs@ @EVAS_LIBS@ @ECORE_LIBS@ @EDJE_LIBS@ @EMOTION_LIBS@
 
diff --git a/src/bin/conf_options.c b/src/bin/conf_options.c
new file mode 100644
index 000..3161b8f
--- /dev/null
+++ b/src/bin/conf_options.c
@@ -0,0 +1,90 @@
+#include "conf_options.h"
+#include "main.h"
+
+void 
+config_option_fullscreen(void *data)
+{
+   Ecore_Evas *ee = (Ecore_Evas *)data;
+   int *i = malloc(sizeof(int));
+
+   if (ecore_evas_fullscreen_get(ee))
+   {
+  i[0] = 0;
+  ecore_evas_fullscreen_set(ee, 0);
+  ecore_evas_cursor_set(ee, NULL, 0, 0, 0);
+  eet_write(eet_config, "/config/fullscreen", i, sizeof(int), 0);
+   }
+   else 
+   {
+  i[0] = 1;
+  ecore_evas_fullscreen_set(ee, 1);
+  ecore_evas_cursor_set(ee, "", 999, 0, 0);
+  eet_write(eet_config, "/config/fullscreen", i, sizeof(int), 0);
+   }
+}
+
+void 
+config_option_themes(void *data)
+{
+}
+
+void
+config_option_modes_switch(void* data)
+{
+   int mode = (int)data;
+   eet_write(eet_config, "/config/mode", &mode, sizeof(int), 0);
+   main_reset();
+}
+
+void 
+config_option_modes(void *data)
+{
+   menu_push("menu", "Modes", NULL, NULL);
+   if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_SOFTWARE_X11))
+  menu_item_add("icon/x11", "Software",
+		NULL, NULL, config_option_modes_switch,
+		(void*)0, NULL, NULL, NULL);
+   if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_OPENGL_X11))
+  menu_item_add("icon/mesa", "Mesa OpenGL",
+		NULL, NULL, config_option_modes_switch,
+		(void*)1, NULL, NULL, NULL);
+   if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_SOFTWARE_FB))
+  menu_item_add("icon/fb", "Software Framebuffer",
+		NULL, NULL, config_option_modes_switch,
+		(void*)2, NULL, NULL, NULL);
+   if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_XRENDER_X11))
+  menu_item_add("icon/xr", "XRender Extension",
+		NULL, NULL, config_option_modes_switch,
+		(void*)3, NULL, NULL, NULL);
+   if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_DIRECTFB))
+  menu_item_add("icon/dfb", "DirectFB",
+		NULL, NULL, config_option_modes_switch,
+		(void*)4, NULL, NULL, NULL);
+   if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_SDL))
+  menu_item_add("icon/sdl", "SDL Engine",
+		NULL, NULL, config_option_modes_switch,
+		(void*)5, NULL, NULL, NULL);
+   /* WINDOWS ENGINES - maybe later
+   if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_SOFTWARE_DDRAW)) 
+  menu_item_add("icon/x11", "Software",
+		NULL, NULL, config_option_modes_switch,
+		6, NULL, NULL, NULL);
+   if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_DIRECT3D))
+  menu_item_add("icon/x11", "Direct3D",
+		NULL, NULL, config_option_modes_switch,
+		7, NULL, NULL, NULL);
+   if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_SOFTWARE_16_WINCE))
+  menu_item_add("icon/x11", "Software",
+		NULL, NULL, config_option_modes_switch,
+		7, NULL, NULL, NULL);
+   */
+
+   menu_go();
+   menu_item_select("Software");
+}
+
+void 
+config_option_volumes(void *data)
+{
+}
+
diff --git a/src/bin/conf_options.h b/src/bin/conf_options.h
new file mode 100644
index 000..f991fae
--- /dev/null
+++ b/src/bin/conf_options.h
@@ -0,0 +1,10 @@
+#ifndef conf_options_h
+#define conf_options_h
+
+void config_option_fullscreen(void *data);
+void config_option_themes(void *data);
+void config_option_modes(void *data);
+void config_option_volumes(void *data);
+
+#endif
+
diff --git a/src/bin/main.c b/src/bin/main.c
index c366a4f..3a8d9bb 100644
--- a/src/bin/main.c
+++ b/src/bin/main.c
@@ -10,6 +10,7 @@ struct _Mode
 Evas*evas = NULL;
 char*theme = NULL;
 char*config = NULL;
+Eet_File*eet_config = NULL;
 Ecore_Timer* mouse_timeout = NULL;
 
 static double   start_time = 0.0;
@@ -35,13 +36,14 @@ static void main_menu_audio(void *data);
 static void main_menu_photo(void *data);
 static void main_menu_scan(void *data);
 static void main_menu_tv(void *data);
+static void main_get_config(void);
 
 int
 main(int argc, char **argv)
 {
Evas_Object *o;
-   int mode = 0, fullscreen 

Re: [E-devel] E moudule API BREAK proposal

[Dave Andreoli]

- "Carsten Haitzler (The Rasterman)" <[EMAIL PROTECTED]> ha scritto:

> On Sat, 11 Oct 2008 20:48:04 +0200 (CEST) Dave Andreoli
> <[EMAIL PROTECTED]> babbled:
> 
> > Hi all,
> > 
> > I want to make an e17 module that expose simple edje objects as
> gadgets.
> > The idea is that people can download edje file from the
> net(calculator,
> > clocks and whatever next), put it in the right directory and then my
> module
> > can expose this objects as they was gadgets (they must appear in the
> available
> > gadgets list of the shelf or the gadman). So that the user can use
> the object
> > where they want.
> > 
> > This can be a really easy way to create and distribute simple
> gadgets as you
> > don't have to compile the edje object for different arch (thinking
> about
> > exchange can also host gadgets, without platform problem!).
> > In the future my module can also make some advanced stuff, for
> example execute
> > a bash, python (or what you like) script that is contained in the
> edje file,
> > making the simple gadgets more functional... but this is another
> story...
> > 
> > This was the good part of the post, now comes the bad :(
> > I can't find a way to do this module without changing the E GADCON
> API.
> > From the module I create an E_Gadcon_Client_Class for each 'simple
> widget'
> > found in the right directory, and I call
> e_gadcon_provider_register()
> > as many times as needed. But then when E ask me for the label, the
> icon and
> > the id I can't know for witch 'simple widget' he need the
> information.
> > 
> > 
> > This is how it is done now:
> > 
> > struct _E_Gadcon_Client_Class
> > {
> >    int   version;
> >    const char *name;
> >    struct 
> >      {
> > E_Gadcon_Client *(*init)     (E_Gadcon *gc, const char
> *name, const
> > char *id, const char *style); void             (*shutdown)
> (E_Gadcon_Client
> > *gcc); void             (*orient)   (E_Gadcon_Client *gcc);
> > char            *(*label)    (void);
> > Evas_Object     *(*icon)     (Evas *evas);
> > const char      *(*id_new)   (void);
> > void             (*id_del)   (const char *id);
> >      } func;
> >    char *default_style;
> > };
> > 
> > 
> > As you can see the function label(void) don't have params and my
> module 
> > is lost on this (for witch widget you want the label??). The same
> apply
> > to the icon and id_new functions.
> > So this is my proposed API
> > 
> > struct _E_Gadcon_Client_Class
> > {
> >    int   version;
> >    const char *name;
> >    struct 
> >      {
> > E_Gadcon_Client *(*init)     (E_Gadcon *gc, const char
> *name, const
> > char *id, const char *style); void             (*shutdown)
> (E_Gadcon_Client
> > *gcc); void             (*orient)   (E_Gadcon_Client *gcc);
> > char            *(*label)    (E_Gadcon_Client_Class
> *class);
> > Evas_Object     *(*icon)     (Evas *evas,
> E_Gadcon_Client_Class
> > *class); const char      *(*id_new)   (E_Gadcon_Client_Class
> *class);
> > void             (*id_del)   (const char *id);
> >      } func;
> >    char *default_style;
> > };
> > 
> > I simple add the E_Gadcon_Client_Class *class params to some
> functions.
> 
> ok one thng. for consistency make E_Gadcon_Client_Class the first
> param for icon
> () and also for id_del() even if we don't use it - at least it's
> consistent :)

Ok and I will also add the param orientation to the function orient().
So we also can orient gadgets on the desktop :)

Dave



> 
> > I think that this kind of functionality (a single module that expose
> more
> > than one gadgets) could be useful in future, for example  we can
> then make a
> > module that handle gadgets from different source (think of
> google_gadgets,
> > OSX dashbord widget...and so on) like KDE4 seems to do. WE then
> access a
> > really HUGE set of just done gadgets :)
> > 
> > 
> > What do you think about all this? It make sense? 
> > maybe someone know how to do this without the break?
> > 
> > Hope you like my idea, and also hope that this mail is clear
> enough...
> > as always my English is not so good ;)
> 
> hmm - it makes sense. i guess if we break - break before e17 is
> released. so
> lets do it. i'm in. do your stuff! :)
> 
> >
> -
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in
> the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://

[E-devel] Python Binding Broken?

[Daniel Martins]

The python bindings are broken ?

I'm trying to compile the python binding for evas from trunk, but I get
this error:

building 'evas.c_evas' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -I/usr/local/include
-I/usr/local/include/eina-0 -I/usr/local/include/eina-0/eina -Iinclude
-I/usr/include/python2.5 -c evas/evas.c_evas.c -o
build/temp.linux-i686-2.5/evas/evas.c_evas.o
gcc: evas/evas.c_evas.c: No such file or directory
gcc: no input files
error: command 'gcc' failed with exit status 1


I already tried to use the python bindings of PyPi, they compile but
doen't work, I get this error:

File
"/usr/lib/python2.5/site-packages/python_ecore-0.3.0-py2.5-linux-i686.egg/ecore/evas/__init__.py",
 line 20, in 
import c_ecore_evas
  File "c_evas.pxd", line 585, in ecore.evas.c_ecore_evas
(ecore/evas/ecore.evas.c_ecore_evas.c:17576)
  File
"/usr/lib/python2.5/site-packages/python_evas-0.3.0-py2.5-linux-i686.egg/evas/__init__.py",
 line 20, in 
import c_evas
ImportError: 
/usr/lib/python2.5/site-packages/python_evas-0.3.0-py2.5-linux-i686.egg/evas/c_evas.so:
 undefined symbol: evas_list_free


Any help would be appreciated.

Regards,


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eet wrapper

[Jonathan MULLER]

Ok andreas,

I will do it with a pair of pair ... but I found the syntax very
heavier than with boost::tuple.

Take a look at the example in attached file, this is the approach I
will take to replace the boost::tuple.
And this approach is not very usable if we have to extend the "tuple".

Regards,

jonathan Muller.



On Mon, Nov 3, 2008 at 8:02 PM, Andreas Volz <[EMAIL PROTECTED]> wrote:
> Am Mon, 3 Nov 2008 09:56:45 +0100 schrieb Jonathan MULLER:
>
> Hello Jonathan,
>
> would be nice if you do that. And best provide a path to integrate it
> into eflpp.
>
> BTW: Seems you're not a member of
> enlightenment-devel@lists.sourceforge.net list. You should join the
> list if you like to post anything
>
> regards
> Andreas
>
>> Hi Andreas,
>>
>> I understand those problematics of course.
>> The dependency is on tuple classe with 3 elements ... we could in a
>> first time considering a std::pair of std::pair
>>
>> boost::tuple < Ty, int, bool > ~ std::pair < std::pair< Ty, int >,
>> bool >
>>
>> It will be a bit more heavy for the user ... but I can have a look to
>> develop this.
>>
>> I have to say adding a dependncy on boost would be a great idea.
>>
>> Regards,
>>
>> Jonathan Muller.
>>
>> On Sun, Nov 2, 2008 at 12:03 PM, Andreas Volz
>> <[EMAIL PROTECTED]> wrote:
>> > Am Sat, 1 Nov 2008 21:14:57 +0100 schrieb Jonathan MULLER:
>> >
>> > Hello Jonathan,
>> >
>> > I reviewed the source code short and this it looks good. But
>> > there's a little problem. Until now the eflpp library hasn't any
>> > boost dependency.
>> >
>> > Using your eet wrapper would create a dependency to boost for all
>> > applications based on eflpp. For me personal this isn't a big
>> > problem as my main application is yet based on boost for some other
>> > reasons.
>> >
>> > The positive would be that it allows to replace some other stuff in
>> > eflpp with boost code. But as this is a design decision I'm not sure
>> > about it. At least I like to discuss that topic on the list. I added
>> > the list to Cc.
>> >
>> > Meanwhile you could think about if it's not possible to rewrite your
>> > wrapper with STL classes.
>> >
>> > Any other opinions from the list?
>> >
>> > regards
>> > Andreas
>> >
>> > BTW: I didn't attach the source code to this E-Mail. You've to ask
>> > Jonathan about it.
>> >
>> >> Hi Andreas,
>> >>
>> >> You will find in as attached file the wrapper.
>> >> execute
>> >> make to build the 2 executables
>> >>
>> >> and make test to run first the writing test and the the readin
>> >> test. And take a look at the code ;)
>> >>
>> >> I am waiting for your feedbacks.
>> >> I do not have rights to commit in the SVN tree that's why I send
>> >> you this first approach.
>> >>
>> >> Note : you have to have the boost tuple library.
>> >>
>> >>
>> >> Regards,
>> >>
>> >> John aka Bhaal22.
>> >>
>> >> On Fri, Oct 31, 2008 at 9:09 PM, Andreas Volz
>> >> <[EMAIL PROTECTED]> wrote:
>> >> > Am Mon, 27 Oct 2008 16:01:30 +0200 schrieb Jonathan MULLER:
>> >> >
>> >> > Hello Jonathan,
>> >> >
>> >> > I'm interested in your wrapper. Do you've a patch based on
>> >> > existing eflpp code base? It should fit into the eflpp design.
>> >> >
>> >> > regards
>> >> > Andreas
>> >> >
>> >> >> Hi Andreas,
>> >> >>
>> >> >> I wrote a little C++ wrapper around Eet library compliant with
>> >> >> STL. I can use STL algorithm to iterate over keys, entries ...
>> >> >>
>> >> >> I wrote some operators to access items in a user friendly way.
>> >> >>
>> >> >> I can show you if you want.
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> Jonathan Muller.
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Drylm Founder
>> >> >> http://www.drylm.org
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Technical Blog 
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Drylm Founder
>> >> http://www.drylm.org
>> >>
>> >
>> >
>> > --
>> > Technical Blog 
>> >
>>
>>
>>
>> --
>> Drylm Founder
>> http://www.drylm.org
>>
>



-- 
Drylm Founder
http://www.drylm.org
#include 
#include 


template 
struct A
{
  typedef std::pair<_Ty, int> type;
};

template 
struct B
{
  typedef typename A<_Ty>::type internal_type;
  typedef std::pair< internal_type, bool> type;
};


template 
typename A<_Ty>::type make_a (_Ty ty, int i)
{
  //typename A<_Ty>::type f (ty, i);

  return typename A<_Ty>::type (ty, i);;
}

template 
typename B<_Ty>::type
make_b (_Ty ty, int i, bool b)
{
  return typename B<_Ty>::type ( make_a(ty, i), b);
}


int main (int argc, char **argv)
{
  A::type x = make_a (12, 12);
  B::type b;

  b.first = std::make_pair (12, 13);
  b.second = false;

  B::type b2 = make_b(12, 13, false);
  B::type b3 = make_b(25, 15, true);


  

  std::cout << x.first << " " << x.second << std::endl;

  std::cout << b2.first.first << " " << b2.first.second << " " << b2.second << std::endl;
  std::cout << b3.first.first << " " << b3.first.second << " " << b3.second << std::endl;
  return 0;
}

Re: [E-devel] FOSDEM 2009

[Sevcsik András]

Hi guys!

fosdem.org says:

FOSDEM will *NOT take place on 21st and 22nd February 2009*.

Do you know anything about this? It would be bad if they modified the date
since I've already bought my plane tickets...

Minden jót,
Sevcsik András


On Thu, Oct 23, 2008 at 8:49 PM, Vincent Torri <[EMAIL PROTECTED]> wrote:

>
>
>  My holiday just started, so I can get to coding now.
>>
>
> Great !
>
>  I've also described what to do for a symbian port of evas. Are you still
>>> motivated ? We can discuss about that when you have some time, if you
>>> want.
>>>
>>
>>
>> The main priority is on eyesight now (because of FOSDEM), but i'm still
>> motivated. I haven't had time to get familiar with the symbian sdk yet.
>>
>
> Ok. You're right, priority to eyesight. So first, i think that you should
> fix the events. There are some garbage in the code right now.
>
>  And what's up with you?
>>
>
> I'm pushing in the Windows CE direction, to obtain native code. The main
> part of the work is already done. It's more tweaking than really big code.
> But that OS is an horror. Evil, Eina, Eet, Evas and Embryo are compiling. It
> remains one problem in e, though. Next will be Ecore. Edje should be easy.
>
> Vincent
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Python Binding Broken?

[Gustavo Sverzut Barbieri]

On Mon, Nov 3, 2008 at 6:17 PM, Daniel Martins
<[EMAIL PROTECTED]> wrote:
> The python bindings are broken ?
>
> I'm trying to compile the python binding for evas from trunk, but I get
> this error:
>
> building 'evas.c_evas' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fPIC -I/usr/local/include
> -I/usr/local/include/eina-0 -I/usr/local/include/eina-0/eina -Iinclude
> -I/usr/include/python2.5 -c evas/evas.c_evas.c -o
> build/temp.linux-i686-2.5/evas/evas.c_evas.o
> gcc: evas/evas.c_evas.c: No such file or directory
> gcc: no input files
> error: command 'gcc' failed with exit status 1

you need both Cython AND Pyrex, that's due python setuptools assuming
pyrex is installed to be able to compile .pyx into .c, even if we use
Cython to do the proper work.


> I already tried to use the python bindings of PyPi, they compile but
> doen't work, I get this error:
>
> File
> "/usr/lib/python2.5/site-packages/python_ecore-0.3.0-py2.5-linux-i686.egg/ecore/evas/__init__.py",
>  line 20, in 
>import c_ecore_evas
>  File "c_evas.pxd", line 585, in ecore.evas.c_ecore_evas
> (ecore/evas/ecore.evas.c_ecore_evas.c:17576)
>  File
> "/usr/lib/python2.5/site-packages/python_evas-0.3.0-py2.5-linux-i686.egg/evas/__init__.py",
>  line 20, in 
>import c_evas
> ImportError: 
> /usr/lib/python2.5/site-packages/python_evas-0.3.0-py2.5-linux-i686.egg/evas/c_evas.so:
>  undefined symbol: evas_list_free
>
>
> Any help would be appreciated.

PyPI is too old for current SVN, we moved from evas_list to eina_list,
you need python-efl from svn as well.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] UDP client/server support

[Matt Barclay]

On Sun, Nov 2, 2008 at 11:53 PM, The Rasterman Carsten Haitzler
<[EMAIL PROTECTED]> wrote:
> On Sat, 4 Oct 2008 23:27:33 -0400 "Matt Barclay" <[EMAIL PROTECTED]> babbled:
>
> hmm - you know what might have been cleaner... on data in get a CLIENT_ADD
> event and literally add a client then instantly post data from that client in 
> a
> CLIENT_DATA and then a CLIENT_DEL immediately after. it sounds a big heavy
> BUT... it's clean.
>
> 1. it looks just like tcp/unix socket connections except the connection is 
> only
> alive for 1 packet (lump of data).
> 2. it solves your ability to preserve client info and all calls works just as
> if it were tcp or unix socket. you know just where to send the data back to as
> u have a client handle. :)
> 3. it's clean
>
> what do you think?

I like it, thanks for the feedback!  I'm traveling early this week,
but I will have a look on Wednesday.  I'll keep an eye on the list in
case someone beats me to it.

Regards,
Matt

>> Hello,
>>
>> With this patch, ecore will have full UDP client/server support.
>> Tooling UDP into the framework wasn't the easiest thing in the world
>> because a UDP server has a single socket (i.e. file handle) that is
>> used to handle all clients, whereas a TCP server generates a new
>> socket for each client that encapsulates all the details of the
>> connection.  So here's how I implemented it:
>>
>> UDP Server (Unicast and Multicast):
>> 1.  When there is data on the socket, the callback uses recvfrom() to
>> read the datagram and client address (struct sockaddr_in)
>> 2.  Create a new Ecore_Con_Client and save the client address
>> (sockaddr_in) details with the "data" field.  Leave the "fd", "buf",
>> and "fd_handler" fields NULL.
>> 3.  Create a new Ecore_Con_Event_Client_Data and save the datagram in
>> the "data" field, and the client in the "client" field
>> 4.  ecore_con_client_send() is updated to check for a
>> client->server->type of ECORE_CON_REMOTE_UDP and use sendto() with
>> client->data as the destination instead of appending the buffer to
>> client->buf
>> 5.  relevant portions of ecore_con_client_del() and
>> _ecore_con_event_client_data_free() are updated to ensure the client
>> and data memory are freed
>>
>> The use of recvfrom() and sendto() feels a little dirty to me, but I'm
>> not sure how else to preserve the client address so that packets can
>> be sent back to the client.  AFAIK, there isn't any way to do an
>> accept() on a UDP socket such that a new file handle is created that
>> encapsulates the end points of the UDP socket.  Would appreciate some
>> "enlightenment" on this topic if I'm wrong.  ;)
>>
>> UDP Client support fits nicely into the framework as a new socket is
>> created each time ecore_con_server_connect() is called.
>>
>> A UDP Server example program is included with the patch, and examples
>> of multicast and UDP client support can be found in SVN:
>> TEST/orig/ecore/
>>
>> Regards,
>> Matt
>>
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
>
>

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Evas fill-transform patch

[The Rasterman]

On Tue, 07 Oct 2008 19:05:16 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:

ok. in svn. just a summer (as in my svn log):

  1. nearest scaling is now broken - it's always linear interpolation. this
  will lead to slowdowns. i need to fix this - a must.
  2. i think it's time i put in a transformed image cache that can cache an
  image object at a transform (and share it) automatically.
  3. transforms in non-software-engines will not work - broken. need to at
  least do xrender and gl engines.
  
  any volunteers to help?

thanks jose! :)

> 
>Attached is a patch to add support for "fill transforms" to evas 
> image objects
> (plus new modifications to grad2s and some other minor things).
> 
>Let me note a few aspects of this, since it it a rather 'big' change 
> in some
> ways for evas internals.
> 
>First of all, ALL engines but the software based ones are broken by 
> this patch.
> It should be very easy to bring them all to doing what they did before, 
> but it
> would be much better for the various engineers to take this opportunity 
> (as with
> grda2) to enable this new capability for their engine of choice (I've 
> only mofified
> the relevant engine funcs for the gl-x11 and xrender-x11 engines to 
> build correctly,
> but they don't draw anything).
> 
>The semantics of the fill-transform for images is simple: It should 
> be equivalent
> to first scaling the image to the given fill size (preserving borders as 
> need be),
> and then apply the (inverse) transform to that, with the fill x,y being 
> an initial translation.
> Note that only affine transforms need be supported, and that the origin 
> is to be taken
> relative to the image object's top-left.
> 
>See raster, cedric, jorge, and gustavo for examples on how to use 
> this.. :)
> 
>The performance will vary somewhat here and there, but should be 
> roughly the same
> as before when restricted to un-transformed images.. The one exception 
> to that being
> the case of when the 'not-smooth-scale' property is set, since for now 
> the patch
> always does a certain amount of smoothness, with the 'smooth-scale' now 
> referring to
> whether or not to to a full sampling of the source when down-scaling.
>In a few days I'll add support for non-smooth scaling/transforming, 
> but it will be
> controlled via the general object 'anti-alias' property -- ie. if one 
> sets the image
> object to not anti-aliased, then all scaling/transforming will be 
> non-smooth, regardless
> of any separate setting on 'smooth-scale'.
>This may seen a more complex setup, but it actually gives somewhat 
> greater flexibility
> as regular 'smooth' (with aa on) is often a good substitute for fully 
> sampled downscaling
> but considerably faster.
> 
>The attached patch itself contains a diff against current svn evas, 
> plus additional files that
> need to be added to the evas 'canvas' and 'common' src dirs.
> 
>Good luck.. :)
> 
> 
> Click to book your dream cruise.
> http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nL6YNozEjo63hzckCPak13wUAemocABJ5VZntA2XthxICVq/


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] Evas: Abstract the engine calls

[The Rasterman]

On Tue, 28 Oct 2008 19:03:42 +0100 "Jorge Luis Zapata Muga"
<[EMAIL PROTECTED]> babbled:

> Hi all,
> 
> Here i attach a patch that wraps all the calls to
> obj->layer->evas->engine.func inside the objects into a function
> itself. So instead of doing evas->engine.func->image_border_set you
> should call evas_engine_image_border_set. It looks like a cosmetic
> patch, but is the base for a larger rewrite of Evas internals.
> 
> As Jose has been saying (and myself) for some time now, Evas *needs* a
> refactor on its internals, this is the first step in the path to allow
> objects to be built outside Evas which will imply to build a good and
> defined interface between objects, engines and the canvas system.
> Right now the evas_engine_xxx functions are just on a private header,
> later those can be as well exported and let users build their own
> objects based on this accelerated primitives.
> 
> I can commit myself this patch (the text objects are still missing
> btw), but i prefer to know your impressions before.

hmmm - missing formatting fixes too from the patch. also jose's patch broke a
chunk so u';ll have to fix those up :) in fact the transform stuff is going to
need a bit of work to bring evas back up to working again.

overall i dont mind the idea in the patch though - it makes sense to me.

and i do agree - the internals need a refactor. there are just too many engines
right now really. it makes it a daunting task to do anything :( i am really
tempted to drop lesser-used engnies into the dust pile. software-based engines
are simple to keep as they use the same core api and just change the target for
ARGB32 - the software-16 engines i think in the long run probably should be
left to die or become part of a "can do rendering in 16bpp colorspace" for the
generic software engine (or more to the point have a caching mechanism that
converts sources from native colorspace to "target colorspace" and then works
in target colorspace (eg 16bpp, same applies for yuv->rgb and also transform
caches with a already scaled/rotated copy of an image able to be cached).

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efreet mime default application patch

[The Rasterman]

On Mon, 3 Nov 2008 14:39:05 +0100 (CET) Dave Andreoli <[EMAIL PROTECTED]>
babbled:

> > 1. config everyone cal look at
> > OR
> > 2. "opening service". e.g. a dbus call- u send an array (list) of file
> > paths
> > and say "open them please" - e will open them for you. this way you
> > also
> > recycle the exec method and child process tracking etc. if the target
> > file is a
> > directory - it opens a directory window, etc.
> > 
> > is #2 perhaps not better?
> 
> The #2 is powerfull but will work only if E is running, and this is bad
> for applications, that should work also outside E. 
> 
> I prefer the #1, put the config where everyone can look...what about
> the defaults.list file ? ;) (it's not yet a fdo standard, but it's a 
> simple and clear way to store the info)

technically - any app/desktop/wm could provide the same dbus service... a
stand-alone app could too. the problem with #1 is that if e decides to change
config, format, versioning, keys, break it etc. every app is stuck catching up.
putting it into a lib and formalising it sets the config in stone as u cant go
change it as u are going to break format/api. a very limited config is
possible, but i think it's a bit premature to go formalising this - for e it is
i think. also this means the config now can't use e's normal config schemes.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] UDP client/server support

[The Rasterman]

On Mon, 3 Nov 2008 14:36:15 -0800 "Matt Barclay" <[EMAIL PROTECTED]> babbled:

> On Sun, Nov 2, 2008 at 11:53 PM, The Rasterman Carsten Haitzler
> <[EMAIL PROTECTED]> wrote:
> > On Sat, 4 Oct 2008 23:27:33 -0400 "Matt Barclay" <[EMAIL PROTECTED]>
> > babbled:
> >
> > hmm - you know what might have been cleaner... on data in get a CLIENT_ADD
> > event and literally add a client then instantly post data from that client
> > in a CLIENT_DATA and then a CLIENT_DEL immediately after. it sounds a big
> > heavy BUT... it's clean.
> >
> > 1. it looks just like tcp/unix socket connections except the connection is
> > only alive for 1 packet (lump of data).
> > 2. it solves your ability to preserve client info and all calls works just
> > as if it were tcp or unix socket. you know just where to send the data back
> > to as u have a client handle. :)
> > 3. it's clean
> >
> > what do you think?
> 
> I like it, thanks for the feedback!  I'm traveling early this week,
> but I will have a look on Wednesday.  I'll keep an eye on the list in
> case someone beats me to it.

:) i'm slow on catching up with my email backlog - but i've now done it - i'm
going to be busy cleaning up the aftermath of transforms :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17 dbus support

[The Rasterman]

On Mon, 3 Nov 2008 09:59:46 +0100 "Luca De Marini" <[EMAIL PROTECTED]>
babbled:

> 2008/11/3 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>
> 
> > On Sat, 27 Sep 2008 11:37:34 +0200 "Albin Tonnerre" <
> > [EMAIL PROTECTED]>
> > babbled:
> >
> > the real problem is the enlightenment.desktop file - the way we ship it it
> > JUST
> > runs enlightenment_start. enlightenment_start (its a front-end binary to
> > launch
> > the real e that doesnt have library dependencies etc.) probably should be
> > in
> > charge of doing this. the problem is dbus-launch may not be installed, so
> > i'd
> > say what we need are patches to enlightenment_start to launch e itself with
> > dbus-launch if it exists or just e raw (like now) if it doesn't
> > :)
> >
> 
> Uhm, yes, I really believe it would be great to have it. Completely agree :)

i just added it :)


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] EET crypto

[The Rasterman]

On Mon, 3 Nov 2008 11:03:38 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:

> > maybe you want to postpone this until all the eina stuff is done?
> 
> I need crypto support soon, so I will provide a patch that doesn't
> break API. Before breaking eet API, I agree that we should first
> finish this move to eina, currently postponed for around 2 weeks as I
> have some deadline.
> 
> But I have a little bad news, we will need more than just breaking eet
> API. There are currently 2 bugs regarding eet dump/undump function,
> one that I almost know how to solve and another one that I don't
> understand yet what is going on. The first one is just the dump/undump
> part of list/array/hash of strings bug.
> 
> The problem is in that case that we loose the information in the eet
> data that the chunk is an item part of a list/array/hash and not only
> a string. Solving it is easy... we just need to change eet data format
> so we always store simple type and the group type. I think we can make
> it backward compatible, by just handling both current and new format
> with a new magic string. I have just starting to work on a fix, but
> it's not high enough on my TODO list at the moment. So don't expect
> complete fix before a few weeks.
> 
> The second bug is due to undumping struct of struct which doesn't
> result in the same eet data as the dumped one. My guess is that this
> bug is related to EET_G_UNKNOWN case in _eet_data_dump_encode. But I
> wasn't able to find a fix nor really understand what is going on in
> that case.
> 
> So eet TODO list is quite nice at the moment and need a little bit of
> work before any major release :-)

well.. looks like we have a small reprieve then :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction

[The Rasterman]

On Mon, 3 Nov 2008 08:17:33 -0200 "Gustavo Sverzut Barbieri"
<[EMAIL PROTECTED]> babbled:

> On Mon, Nov 3, 2008 at 5:56 AM, The Rasterman Carsten Haitzler
> <[EMAIL PROTECTED]> wrote:
> > On Tue, 7 Oct 2008 08:55:59 -0300 "Gustavo Sverzut Barbieri"
> > <[EMAIL PROTECTED]> babbled:
> >
> >> On Tue, Oct 7, 2008 at 2:57 AM, Enlightenment SVN
> >> <[EMAIL PROTECTED]> wrote:
> >> > Log:
> >> >  Some work on interaction settings:
> >> >  - group on a thumbscroll framelist;
> >> >  - threshhold ?\226?\134?\146 threshold;
> >> >  - add check changed.
> >>
> >>
> >> that's awesome, I see people liked the "check_changed", we should add
> >> this to other dialogs as well.
> >>
> >> something else I'd like to see is to move, where possible, layouts to
> >> edje with swallow parts, that way we can have special layouts in
> >> embedded systems like illume. Side effect is to simplify code a lot.
> >> What do you think?
> > at some point - but edje doesnt solve it all - for embedded (small screen)
> > uis' u really need to possibly drop entire content and re-think it. i
> > intend to do this for a chunk of dialogs anyway so their default is more
> > small-screen friendly.
> 
> sure, sure! but for some dialogs we can just make it vertical and it will
> work.
> 
> some dialogs will have to move to multi-step, like "choose something"
> and then you're presented with options relevant to that mode, but
> maybe this is good for desktops as well..

yeah - this is something i want to try and solve more generically. i already
added an auto-scroll option where a dialog can automatically have its contents
scroll... :) that kind of is a brute-force approach that makes it work
everywhere... but its not clean.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Rage TODO items

[The Rasterman]

On Mon, 03 Nov 2008 21:06:51 +0100 Tim Felgentreff <[EMAIL PROTECTED]>
babbled:

> I have extended the settings patch to use a eet-configfile now.
> Also I have fixed a warning about evas_smart_new being deprecated by
> replacing it with evas_smart_class_new as suggested in the warning.
> Both patches apply cleanly here at revision 37444, compile and run fine
> (as far as I've tested).
> Please tell me what you think.

in svn :):):)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?

[The Rasterman]

On Mon, 3 Nov 2008 16:20:23 +0100 thomasg <[EMAIL PROTECTED]> babbled:

> Because of that and many many other reasons it would be really cool,
> to have a mplayer backend for emotion. :)

that is impossible as mplayer has no interface to provide yuv data to a caller.
thus no backend exists. until mplayer has such a facility (out of the box -
without patching mplayer) an emotion engine can never exist.

emotion is not the most efficient video player - in software rendering it does
software yuv->rgb(32) conversion then scales in rgba space. the performance is
actually quite astounding considering how much it actually does going the "long
way". if you use the gl engine its the same efficiency as mplayer/xine with xv.
the yuv->rgb + scaling is done in hardware (with a fragment shader) and the
upload to video mem is the same path as xv pretty much, so you'll see the same
cpu overhead there with full emotion + scaleable/fadable/layerable objects and
just regular boring xv.

> But I know, it's really tricky to find a good solution, because
> mplayer isn't meant to be just a backend.
> 
> On 11/3/08, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote:
> > On Mon, Nov 3, 2008 at 11:44 AM, Dave Andreoli <[EMAIL PROTECTED]>
> > wrote:
> >>
> >> - "Nicolas Aguirre" <[EMAIL PROTECTED]> ha scritto:
> >>
> >>> 2008/11/3 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>:
> >>>
> >>> > Gstreamer just sucks to play video on nokia devices, and doing
> >>> extra
> >>> > copies or transformation from YUV to RGB is no-go on those
> >>> hardwares.
> >>> > That's why canola uses atakabe to play media, it will handle
> >>> mplayer,
> >>> > gstreamer...  mplayer is optimized and outputs YUV at half
> >>> resolution
> >>> > using double-pixel directly to framebuffer (in fullscreen mode).
> >>> While
> >>> > in windowed mode, Canola just use ecore_x to reparent MPlayer's
> >>> window
> >>> > to the required position (it's a black rectangle in the theme).
> >>> >
> >>> >
> >>>
> >>> Exactly what I do with libplayer/mplayer in Enna :)
> >>>
> >>
> >> But in this way you can't have evas objects on top of the mplayer
> >> window...
> >
> > yes, that's the problem with such approach, but on that platform it's
> > the only option, really, you don't have much cpu power.
> >
> >> What about the vlc backend? It seem the better way for me as, for
> >> what I have understand, vlc doesn't use gstreamer.
> >> Someone have tryed it?
> >
> > it's totally buggy, needs fixing. AFAIR it calls back from thread,
> > which is not allowed in EFL, but people spotted different problems as
> > well.
> >
> > Also, vlc is not an option on that platform, gstreamer is the
> > "official" media player and uses dsp for audio decoding, but mplayer
> > is was optimized by a guy and is the best, it does this framebuffer
> > tricky and also have an ARM JIT compiler for scale.
> >
> > --
> > Gustavo Sverzut Barbieri
> > http://profusion.mobi embedded systems
> > --
> > MSN: [EMAIL PROTECTED]
> > Skype: gsbarbieri
> > Mobile: +55 (19) 9225-2202
> >
> > -
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] FOSDEM 2009

[The Rasterman]

On Mon, 3 Nov 2008 22:58:17 +0100 "Sevcsik András" <[EMAIL PROTECTED]> babbled:

> Hi guys!
> 
> fosdem.org says:
> 
> FOSDEM will *NOT take place on 21st and 22nd February 2009*.
> 
> Do you know anything about this? It would be bad if they modified the date
> since I've already bought my plane tickets...

looks like you are in trouble and may need to look to refund your tickets or
possibly reschedule. looks like fosdem is having trouble getting off the ground
for 2009.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Evas fill-transform patch

[Vincent Torri]

On Tue, 4 Nov 2008, Carsten Haitzler (The Rasterman) wrote:

> On Tue, 07 Oct 2008 19:05:16 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
>
> ok. in svn. just a summer (as in my svn log):
>
>  1. nearest scaling is now broken - it's always linear interpolation. this
>  will lead to slowdowns. i need to fix this - a must.
>  2. i think it's time i put in a transformed image cache that can cache an
>  image object at a transform (and share it) automatically.
>  3. transforms in non-software-engines will not work - broken. need to at
>  least do xrender and gl engines.
>
>  any volunteers to help?

I'll try to make my student wrk on the direct3d engine, if he can fix it. 
Otherwise, I think i will have to do it.

Vincent

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Evas fill-transform patch

[The Rasterman]

On Tue, 4 Nov 2008 01:24:43 +0100 (CET) Vincent Torri <[EMAIL PROTECTED]>
babbled:

> 
> 
> On Tue, 4 Nov 2008, Carsten Haitzler (The Rasterman) wrote:
> 
> > On Tue, 07 Oct 2008 19:05:16 -0400 Jose Gonzalez <[EMAIL PROTECTED]>
> > babbled:
> >
> > ok. in svn. just a summer (as in my svn log):
> >
> >  1. nearest scaling is now broken - it's always linear interpolation. this
> >  will lead to slowdowns. i need to fix this - a must.
> >  2. i think it's time i put in a transformed image cache that can cache an
> >  image object at a transform (and share it) automatically.
> >  3. transforms in non-software-engines will not work - broken. need to at
> >  least do xrender and gl engines.
> >
> >  any volunteers to help?
> 
> I'll try to make my student wrk on the direct3d engine, if he can fix it. 
> Otherwise, I think i will have to do it.

cool. first i'm going to fix nearest (non-smooth) scaling in software so its
back to "fast" then look at xrender and gl - not in that order - not sure which
to do first. maybe xrender :)


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efreet mime default application patch

[Nick Hughart]

On Tue, 4 Nov 2008 11:01:10 +1100
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote:

> On Mon, 3 Nov 2008 14:39:05 +0100 (CET) Dave Andreoli
> <[EMAIL PROTECTED]> babbled:
> 
> > > 1. config everyone cal look at
> > > OR
> > > 2. "opening service". e.g. a dbus call- u send an array (list) of
> > > file paths
> > > and say "open them please" - e will open them for you. this way
> > > you also
> > > recycle the exec method and child process tracking etc. if the
> > > target file is a
> > > directory - it opens a directory window, etc.
> > > 
> > > is #2 perhaps not better?
> > 
> > The #2 is powerfull but will work only if E is running, and this is
> > bad for applications, that should work also outside E. 
> > 
> > I prefer the #1, put the config where everyone can look...what about
> > the defaults.list file ? ;) (it's not yet a fdo standard, but it's
> > a simple and clear way to store the info)
> 
> technically - any app/desktop/wm could provide the same dbus
> service... a stand-alone app could too. the problem with #1 is that
> if e decides to change config, format, versioning, keys, break it
> etc. every app is stuck catching up. putting it into a lib and
> formalising it sets the config in stone as u cant go change it as u
> are going to break format/api. a very limited config is possible, but
> i think it's a bit premature to go formalising this - for e it is i
> think. also this means the config now can't use e's normal config
> schemes.
> 

I agree here, thus why I didn't bother applying this patch yet.  I want
to make sure there is a specification set before we do anything.  They
may end up using dbus or they may keep it simple.  I really think dbus
is complete overkill for matching mimetypes to applications though.  No
need to have a daemon running that is going to sit idle 99.9% of
the time.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Gadcon V3 *BREAK*

[Dave Andreoli]

Ok, I have committed the gadcon_client_class V3.
ALL THE MODULES around need to be patched (just add 
the new params). 
I have updated all the internal modules and I will do
all the EXTRA modules shortly. All the modules outside
need to be fixed.

Sorry for the inconvenience.
Dave

This is the new class:

#define GADCON_CLIENT_CLASS_VERSION 3
/* Version 3 add the *client_class param to icon(),label(),id_new(), id_del() */
/*   and the *orient param to orient() */
struct _E_Gadcon_Client_Class
{
   int   version;
   /* All members below are part of version 1 */
   const char *name;
   struct 
 {
E_Gadcon_Client *(*init) (E_Gadcon *gc, const char *name, const 
char *id, const char *style);
void (*shutdown) (E_Gadcon_Client *gcc);
void (*orient)   (E_Gadcon_Client *gcc, E_Gadcon_Orient 
orient);
char*(*label)(E_Gadcon_Client_Class *client_class);
Evas_Object *(*icon) (E_Gadcon_Client_Class *client_class, Evas 
*evas);
/* All members below are part of version 2 */
/* Create new id, so that the gadcon client can refer to a config set 
inside the module */
const char  *(*id_new)   (E_Gadcon_Client_Class *client_class);
/* Del an id when a gadcon client is removed from the system */
void (*id_del)   (E_Gadcon_Client_Class *client_class, 
const char *id);
/* All members below are part of version 3 */
 } func;
   char *default_style;
};

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Fw: Re: Copyleft-style

[Nathan Ingersoll]

Was this exception ever decided?

On Thu, Oct 16, 2008 at 5:46 PM, The Rasterman Carsten Haitzler
<[EMAIL PROTECTED]> wrote:
> (forgot AUTHORS in cc list)
>
> PLEASE REPLY (authors on CC list). yes or no to adding static linking 
> exception
> below?
>
> On Fri, 17 Oct 2008 00:53:29 +0200 Michael Feiri <[EMAIL PROTECTED]> babbled:
>
> this got debated to hell. the alternative was going to be watching developers
> leave - ones wanting to add in better code but only wanting to do so if they
> know their code will be free and improvements to it given back.
>
> if we added the static linking exception - which imho would not violate the
> spirit of the LGPL, would this be good enough?
>
> (nb - if apple decide to place all these nasty nasty nasty restrictions on
> developers and applications - all the best to them, but i know i have zero
> interest in becoming part of that world as long as apple basically say "you do
> just what we say, what we want, and if we don't like you we'll just ban your
> app from the platform because you may possibly compete with us or be the wrong
> shade of pink for steve jobs").
>
> i definitely buy the ecos (static linking) argument.
>
> i've explicitly cc'd all the AUTHORS for eina. do you guys agree to adding an
> ecos-style static linking exception (here it is for you guys):
>
> "...As a special exception, if other files instantiate templates or use macros
> or inline functions from this file, or you compile this file and link it with
> other works to produce a work based on this file, this file does not by itself
> cause the resulting work to be covered by the GNU General Public License.
> However the source code for this file must still be made available in
> accordance with section (3) of the GNU General Public License.
>
> This exception does not invalidate any other reasons why a work based on this
> file might be covered by the GNU General Public License"
>
>> On monday, starting with revision 36622, all vital EFL components have
>> been configured to depend on copylefted code (eina is licensed under
>> LGPLv2.1). This is unfortunate, as it renders the existing BSD-style
>> license agreement essentially worthless. It is especially unfortunate as
>> the EFL seems to be unique as the only successful GUI environment under
>> a BSD-style license.
>>
>> I have used Evas as a component in a proof-of-concept for an embedded
>> project using the eCos operating system. No patches or other information
>> have been published yet, because the project is not yet released. But I
>> do expect to have patches for EFL ready upon release in order to avoid
>> the advertisement clause.
>>
>> Now, eCos is owned by the FSF and is licensed under the GPLv2 with a
>> linking exception that makes it completely non-viral. This exception is
>> more powerful than the LGPL, because the LGPL does require dynamic
>> linking or the distribution of linkable object files and additional
>> modification and reverse engineering rights. These obligations would
>> "infect" a project that would otherwise just use a non-viral GPLv2 with
>> linker exception.
>>
>> So I want to ask you to please consider keeping the core EFL components
>> and non-optional dependencies under the existing BSD-style license or
>> consider a non-viral copyleft like the GPLv2 with a linking exception in
>> oder to keep the EFL usable with eCos and similar free embedded
>> operating systems (FreeRTOS and RTEMS both use GPLv2 with linking
>> exceptions too). Dynamic linking is not an option for deeply embedded
>> operating systems. Often we dont even have a filesystem.
>>
>> Additionally I might mention that the BSD-style license of the EFL could
>> mean that the EFL might technically be the only serious option for a
>> free 3rd party GUI library on things like the iPhone. Dynamic linking
>> does seem to exist on this platform but things like forced codesigning,
>> bans on externally loadable code, and restrictions on reverse
>> engineering and modification rights make the use of copylefted code
>> "questionable" at best.
>>
>> MfG, Michael
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux ba

Re: [E-devel] Fw: Re: Copyleft-style

[The Rasterman]

On Mon, 3 Nov 2008 22:36:06 -0600 "Nathan Ingersoll" <[EMAIL PROTECTED]>
babbled:

i'm still waiting on any replies/comments. imho it makes sense. it doesnt
violate the "spirit". it simple defines an exception where building a
statically compiled os image for things like ecos, the same rules as dynamic
linking apply.

> Was this exception ever decided?
> 
> On Thu, Oct 16, 2008 at 5:46 PM, The Rasterman Carsten Haitzler
> <[EMAIL PROTECTED]> wrote:
> > (forgot AUTHORS in cc list)
> >
> > PLEASE REPLY (authors on CC list). yes or no to adding static linking
> > exception below?
> >
> > On Fri, 17 Oct 2008 00:53:29 +0200 Michael Feiri <[EMAIL PROTECTED]>
> > babbled:
> >
> > this got debated to hell. the alternative was going to be watching
> > developers leave - ones wanting to add in better code but only wanting to
> > do so if they know their code will be free and improvements to it given
> > back.
> >
> > if we added the static linking exception - which imho would not violate the
> > spirit of the LGPL, would this be good enough?
> >
> > (nb - if apple decide to place all these nasty nasty nasty restrictions on
> > developers and applications - all the best to them, but i know i have zero
> > interest in becoming part of that world as long as apple basically say "you
> > do just what we say, what we want, and if we don't like you we'll just ban
> > your app from the platform because you may possibly compete with us or be
> > the wrong shade of pink for steve jobs").
> >
> > i definitely buy the ecos (static linking) argument.
> >
> > i've explicitly cc'd all the AUTHORS for eina. do you guys agree to adding
> > an ecos-style static linking exception (here it is for you guys):
> >
> > "...As a special exception, if other files instantiate templates or use
> > macros or inline functions from this file, or you compile this file and
> > link it with other works to produce a work based on this file, this file
> > does not by itself cause the resulting work to be covered by the GNU
> > General Public License. However the source code for this file must still be
> > made available in accordance with section (3) of the GNU General Public
> > License.
> >
> > This exception does not invalidate any other reasons why a work based on
> > this file might be covered by the GNU General Public License"
> >
> >> On monday, starting with revision 36622, all vital EFL components have
> >> been configured to depend on copylefted code (eina is licensed under
> >> LGPLv2.1). This is unfortunate, as it renders the existing BSD-style
> >> license agreement essentially worthless. It is especially unfortunate as
> >> the EFL seems to be unique as the only successful GUI environment under
> >> a BSD-style license.
> >>
> >> I have used Evas as a component in a proof-of-concept for an embedded
> >> project using the eCos operating system. No patches or other information
> >> have been published yet, because the project is not yet released. But I
> >> do expect to have patches for EFL ready upon release in order to avoid
> >> the advertisement clause.
> >>
> >> Now, eCos is owned by the FSF and is licensed under the GPLv2 with a
> >> linking exception that makes it completely non-viral. This exception is
> >> more powerful than the LGPL, because the LGPL does require dynamic
> >> linking or the distribution of linkable object files and additional
> >> modification and reverse engineering rights. These obligations would
> >> "infect" a project that would otherwise just use a non-viral GPLv2 with
> >> linker exception.
> >>
> >> So I want to ask you to please consider keeping the core EFL components
> >> and non-optional dependencies under the existing BSD-style license or
> >> consider a non-viral copyleft like the GPLv2 with a linking exception in
> >> oder to keep the EFL usable with eCos and similar free embedded
> >> operating systems (FreeRTOS and RTEMS both use GPLv2 with linking
> >> exceptions too). Dynamic linking is not an option for deeply embedded
> >> operating systems. Often we dont even have a filesystem.
> >>
> >> Additionally I might mention that the BSD-style license of the EFL could
> >> mean that the EFL might technically be the only serious option for a
> >> free 3rd party GUI library on things like the iPhone. Dynamic linking
> >> does seem to exist on this platform but things like forced codesigning,
> >> bans on externally loadable code, and restrictions on reverse
> >> engineering and modification rights make the use of copylefted code
> >> "questionable" at best.
> >>
> >> MfG, Michael
> >>
> >> -
> >> This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> challenge Build the coolest Linux based applications with Moblin SDK & win
> >> great prizes Grand prize is a trip for two to an Open Source event
> >> anywhere in the world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> ___

Re: [E-devel] Evas fill-transform patch

[The Rasterman]

On Tue, 04 Nov 2008 01:42:30 -0500 Jose Gonzalez <[EMAIL PROTECTED]> babbled:

> Carsten Haitzler (The Rasterman) wrote:
> > On Tue, 07 Oct 2008 19:05:16 -0400 Jose Gonzalez <[EMAIL PROTECTED]>
> > babbled:
> >
> > ok. in svn. just a summer (as in my svn log):
> >
> >   1. nearest scaling is now broken - it's always linear interpolation. this
> >   will lead to slowdowns. i need to fix this - a must.
> >   
> 
>Yes, and as I mentioned in the original email, I have a subsequent patch
> to add the 'nearest' case. However, there (at least) two ways you could enable
> this.

yup. i know. that's just a sore point for the software engines and
performance. :)

>Given that you have the possibility to do:

oh gee. i was just looking into making it work :) if you have a patch.. that
saves me the effort :)

> 1. Nearest scaling/transforming,
> 2. Simple box filter sampling (with lin interp for both the scaling and
> transf).
> 3. Full src pixel sampling when fill scaling down, and box filter sampling for
>the transfs and up-scaling.
> 
>This means that you could keep the current 'smooth-scaling' flag to enable
> 3, and default to 2, and further enable 1 via the genral object no-aa state.

well as it was before u have only #1 or #3 to choose from. now we also have a
#2.

>But you could also extend 'smooth-scaling' so it's not just a bool, and
> instead have it take three states, say: NONE, GOOD, and BEST.

i'd rather extend smooth to be an enum with 0 == #1, 1 == #3 and 2 == #2, so
EVAS_SMOOTH_NONE = 0
EVAS_SMOOTH_BEST = 1
EVAS_SMOOTH_GOOD = 2

this would remain compatible with everything we already have and just add the
#2 as "GOOD" :)

>The former option would be fairly intuitive and leave the api as is, but
> would break the semantics (since no smooth-scaling means box-filter sampling
> not simple nearest sampling).
>The latter option breaks the api since you have to change smooth-scaling
> to no longer be a bool.

this should be a trivial break - abi will break, api won't though really (a
recompile will fix it) :). doing it the aa flag way means semantics break and
someoen has to go adding code to get back "nearest" as it was - so it's going
to be more work and really seems a bit evil to me as it splits the scaling
algorithm used into 2 separate flags and the combination thereof defines the
algorithm.

>Either way you prefer it'd be solved in evas, in things like edje you have
> a further option on ho to proceed, since there for example you could do the
> latter approach regardless of what's done in evas.

i'd also take the latter approach. it's compatible and i can just make it an
enum that accepts these:
0 (NEAREST)
1 (BEST)
NEAREST (NEAREST)
OFF (NEAREST)
BEST (BEST)
GOOD (GOOD)
LINEAR (GOOD)
etc.
:)

>Your choice - I've already added the core stuff to evas, just decide how
> you prefer to control things... and note that it does give an extra degree of
> freedom for controlling things which can be useful in some cases.

sure. i'd go using the smooth flag myself :)

> >   2. i think it's time i put in a transformed image cache that can cache an
> >   image object at a transform (and share it) automatically.
> 
>Something like that could be useful in various ways.. good luck.

this also obviates the need for forcing scale on load to be the exact size as
its taken care of generically :)

> >   3. transforms in non-software-engines will not work - broken. need to at
> >   least do xrender and gl engines.
> >   
> >   any volunteers to help?
> 
>That's right... It's trivial though to get things to just ignore transforms
> and do what they used to do. But to get the most of this, for both images and

that'd be the first thing - just to make them work again - with no transforms.
just for now. that's an immediate need.

> gradient2 - and mind you this is basically a start to what can fairly easily
> be added to allow for stroke/fill texturing of shapes, and for general
> object-level transforms -- to get the most of this, people would have to
> invest in supporting the various engines, xrender in particular is fairly
> easy, gl will likely need rtt (unless you're clever enough to find a way to
> use meshes for border related stuff).

yeah. that'd be the next step - full support.

>The semantics is simple enough, as I mentioned in the original email.
> 
> 
> > thanks jose! :)
> 
>You're quite welcome, and I hope it will be useful to this project..
> HOWEVER, you may want to REVERT this patch, and in fact all the earlier grad2
> and transforms stuff.
> 
>Regrettably, due to persistent issues that I find with this project, things
> like license issues, issues on the aims and progress of the project, and
> others, I no longer feel committed to continuing with this or even supporting
> it in the future, or other future work for this project in its current form.
>Again, I will send you that 'nearest' patch if you like, and I hope you can
> find the work useful to th

Re: [E-devel] Evas fill-transform patch

[Jose Gonzalez]

Carsten Haitzler (The Rasterman) wrote:
> On Tue, 07 Oct 2008 19:05:16 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
>
> ok. in svn. just a summer (as in my svn log):
>
>   1. nearest scaling is now broken - it's always linear interpolation. this
>   will lead to slowdowns. i need to fix this - a must.
>   

   Yes, and as I mentioned in the original email, I have a subsequent patch
to add the 'nearest' case. However, there (at least) two ways you could enable
this.
   Given that you have the possibility to do:

1. Nearest scaling/transforming,
2. Simple box filter sampling (with lin interp for both the scaling and transf).
3. Full src pixel sampling when fill scaling down, and box filter sampling for
   the transfs and up-scaling.

   This means that you could keep the current 'smooth-scaling' flag to enable
3, and default to 2, and further enable 1 via the genral object no-aa state.

   But you could also extend 'smooth-scaling' so it's not just a bool, and
instead have it take three states, say: NONE, GOOD, and BEST.
 
   The former option would be fairly intuitive and leave the api as is, but
would break the semantics (since no smooth-scaling means box-filter sampling
not simple nearest sampling).
   The latter option breaks the api since you have to change smooth-scaling
to no longer be a bool.

   Either way you prefer it'd be solved in evas, in things like edje you have
a further option on ho to proceed, since there for example you could do the
latter approach regardless of what's done in evas.
   Your choice - I've already added the core stuff to evas, just decide how
you prefer to control things... and note that it does give an extra degree of
freedom for controlling things which can be useful in some cases.


>   2. i think it's time i put in a transformed image cache that can cache an
>   image object at a transform (and share it) automatically.
>   

   Something like that could be useful in various ways.. good luck.


>   3. transforms in non-software-engines will not work - broken. need to at
>   least do xrender and gl engines.
>   
>   any volunteers to help?
>
>   

   That's right... It's trivial though to get things to just ignore transforms
and do what they used to do. But to get the most of this, for both images and
gradient2 - and mind you this is basically a start to what can fairly easily
be added to allow for stroke/fill texturing of shapes, and for general 
object-level
transforms -- to get the most of this, people would have to invest in supporting
the various engines, xrender in particular is fairly easy, gl will likely need 
rtt
(unless you're clever enough to find a way to use meshes for border related 
stuff).

   The semantics is simple enough, as I mentioned in the original email.


> thanks jose! :)
>
>   

   You're quite welcome, and I hope it will be useful to this project.. HOWEVER,
you may want to REVERT this patch, and in fact all the earlier grad2 and 
transforms
stuff.

   Regrettably, due to persistent issues that I find with this project, things
like license issues, issues on the aims and progress of the project, and others,
I no longer feel committed to continuing with this or even supporting it in
the future, or other future work for this project in its current form.
   Again, I will send you that 'nearest' patch if you like, and I hope you can
find the work useful to the project.. maybe Jorge, Cedric, Gustavo, and you and
others will continue with it.. but otherwise, I'd sincerely advise you to let 
it go.



>>Attached is a patch to add support for "fill transforms" to evas 
>> image objects
>> (plus new modifications to grad2s and some other minor things).
>>
>>Let me note a few aspects of this, since it it a rather 'big' change 
>> in some
>> ways for evas internals.
>>
>>First of all, ALL engines but the software based ones are broken by 
>> this patch.
>> It should be very easy to bring them all to doing what they did before, 
>> but it
>> would be much better for the various engineers to take this opportunity 
>> (as with
>> grda2) to enable this new capability for their engine of choice (I've 
>> only mofified
>> the relevant engine funcs for the gl-x11 and xrender-x11 engines to 
>> build correctly,
>> but they don't draw anything).
>>
>>The semantics of the fill-transform for images is simple: It should 
>> be equivalent
>> to first scaling the image to the given fill size (preserving borders as 
>> need be),
>> and then apply the (inverse) transform to that, with the fill x,y being 
>> an initial translation.
>> Note that only affine transforms need be supported, and that the origin 
>> is to be taken
>> relative to the image object's top-left.
>>
>>See raster, cedric, jorge, and gustavo for examples on how to use 
>> this.. :)
>>
>>The performance will vary somewhat here and there, but should be 
>> roughly the same
>> as before when restricted to un-transformed images.. The one exception 
>> to that being
>> the case of w