[E-devel] e17 release stuff

[The Rasterman]

ok. i just added some of the things discussed in the efm thoughts thread a few
weeks ago:

http://trac.enlightenment.org/e/wiki/Release

does anyone have anything to add? i'd like focus to pretty much revolve around
what's on that list. there are other things being done that are parallel to
that list (things some of us are paid to do or are on other project timelines),
but otherwise for e17 that list is pretty much the core of what's to be done.
some of them are broad items that can encompass a lot of work (make dialogs
even if big, work on small screens). i may have missed a few things along the
way - again. if you have anything - add it to that page (then mail about it -
we can remove it or modify it).

but this is what needs doing. if you want to see an e17 release - lets get this
stuff done!

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] Show more color classes in the color conf dialog

[The Rasterman]

On Thu, 13 Nov 2008 12:00:44 +0100 Viktor Kojouharov 
babbled:

> This patch makes the color conf dialog show more color classes, than the
> "default" ones. Unfortunately, it doesn't list all available classes,
> since edje_color_class_list() doesn't list all color classes used by a
> theme (I think it lists only the classes that are so far encountered).

in svn :)


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Invalid memory access in Edje script

[The Rasterman]

On Wed, 26 Nov 2008 15:43:10 -0500 digger vermont 
babbled:

i'm baffled. staring at strcmp vs fnmatch bindings in embryo - they are
IDENTICAL - except one calls strcmp with the 2 stgrings, the other fnmatch...
i'm scratching my noggen.

> Help! I give up!
> 
> I'm getting this error with a mouse click using fnmatch in an Edje
> script.
> 
> EDJE:ERROR with embryo script.
> ENTRY POINT: _p0
> ERROR:   Invalid memory access
> 
> I've reduced the Edje file to this and still can't see a problem.  If
> its not error in the code I'll file a ticket.
> 
> Thanks for any help,
> 
> digger
> --
> collections {
> group {
> name: "main";
> script {
> public toggle() {
> set_state(PART:"button", "active", 0.0);
> }
> }
> parts {
> part {
> name: "button";
> type: RECT;
> mouse_events: 1;
> description {
> state: "default" 0.0;
> color: 0 255 0 255;
> }
> description {
> state: "active" 0.0;
> color: 0 0 255 255;
> }
> }
> }
> programs {
> program {
> name: "set";
> signal: "mouse,clicked,1";
> source: "*button*";
> script {
> // If call the function here it works
> // toggle();
> new exp[] = "button";
> // These expressions work okay
> //if ( !strcmp(exp, "button")) {
> //if ( !fnmatch("button", src) ) {
> if ( !fnmatch(exp, src) ) {
> toggle();
> }
> }
> }
> }
> }
> }
> 
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] Merge all ecore event

[The Rasterman]

On Fri, 14 Nov 2008 14:39:34 +0100 "Cedric BAIL"  babbled:

hmm - this is one of those things we should include as early as possible not
delay. so basically your'e trying to merge all device input (be it from X, or
FB (tslib/ps2 etc.) etc. into single events. the reason i didn't do this was a
fundamental difference of things like fb based events (which are always device
global) vs x which are window-relative. window, root_window should be typedefed
to something taking a look at the event structs. :)

> Hi,
> 
>   This another set of patch, this one is a first review, I don't plan
> to see it included soon in the svn. The idea is to merge as much code
> from all event generation in ecore to reduce duplication code and make
> application using them as much as possible independent of the ecore
> events engine. So ecore could feed events to evas transparently
> regarding of the engine.
> 
> ecore_ei.diff: Add a new library Ecore_Input (Didn't found any better
> name) and use it in all events backend and in ecore_evas.
> 
> e_ei.diff: Big patch, that could break any key or mouse handler. I am
> not using E17 as a window manager (I break my efl too often), but from
> some session of test, it seems to work fine.
> 
> e_module_extra_ei.diff: Unbreak some module.
> etk_ei.diff: easy patch for etk as it is using ecore_evas so only a
> few change are needed.
> 
> This serie of patch lack one for ewl, but it was a huge task, so
> before spending time on it, I first want to know your opinion on this.
> Have some review and more tester.
> 
> Have fun breaking your e !
> -- 
> Cedric BAIL
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] Illume keyboard

[The Rasterman]

On Mon, 22 Dec 2008 13:27:12 +0100 Peter van de Werken
 babbled:

> On Mon, Dec 22, 2008 at 11:15:51AM +1100, Carsten Haitzler wrote:
> > added a bug here - used _cb_ not _callback in an flaunch call (frankly
> > i want to see flaunch die or become something else but its there to
> > keep asu happy - for now). :)
> 
> Aah hmm, just found out where I went wrong: the e_flaunch.h has the
> wrong (non-existent) function in it.
> Attached patch fixes the typo and the .h file.

aaah the typoe monster strikes again! thanks! patch in.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje doesn't seem to handle inheritance properly

[The Rasterman]

On Fri, 5 Dec 2008 12:21:13 -0200 andres  babbled:

> El Thursday 04 December 2008 09:46:13 Viktor Kojouharov escribió:
> > Lets say that a part has 3 states. The first defines the rels and a
> > color. The second inherits from the first, and defines a new color. If I
> > want the third part to inherit from the second (to make a smooth
> > transition from a second color to the third), edje will not doo the
> > lookup for the rels properly, meaning that the rels for the 3rd state
> > will be 0, since the 2nd state did not define rels, but inherited them.
> > It should be though that if the 3rd state wants something from the
> > second state, and the second state does not have the needed item, but
> > inherits from the first, the lookup should proceed to search in the
> > first as well.
> >
> yes, that is known as multiple level inheritance and it does not work on Edje 
> as it is.
> 
> Its one of the things I would like to implement down the road but I haven't 
> assessed the requirements for it yet. Since its not implemented I assume its 
> not easy.
> 
> Does anyone know what it would take to implement this?

it's actually pretty easy. just hasnt been done :) it's only done at edje_cc
time - the inherit: "xx" x; simply copes the state description from "xxx" x to
the current one. then any more delcarations just modify the state. so all it
needs to do is make sure it copies to the parent before using it - if the
parent has also done an inherit... :) or maybe move the inherit to parse time
and do it in-line (this means though anything you inherit from must be declared
before the current one in the file).

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] Ecore_Desktop fix

[The Rasterman]

On Sat, 13 Dec 2008 16:08:30 +0100 thomasg  babbled:

> On Sat, Dec 13, 2008 at 3:43 PM, thomasg  wrote:
> 
> > On Sat, Dec 13, 2008 at 4:18 AM, Nick Hughart  wrote:
> >
> >> A better patch would be to remove it completely.  None of the code is
> >> useful anymore and efreet_desktop is far better.
> >>
> >
> > Ok. Patch 1 removes Ecore_Desktop from autoconf/automake, Patch 2 does the
> > same but aditinally removes it completely from SVN - I'm not sure if you
> > want that, so make your choice :)
> >
> > I did a quick grep and found Ecore_Desktop only used in engage and evfs -
> > but both are broken anyway.
> > It also is mentioned in e/doc/cache.txt and e/doc/FDO.txt, but these seem
> > to be obsolte information files, so there should be no problem.
> >
> > I hope patch 2 arrived, it's lzma compressed. Tell me if it didn't.
> 
> 
> pfritz informed me, that my patches did not arrive at all, so I uploaded
> them.
> Here are the links:
> http://gstaedtner.net/remove_ecore_desktop.patch - removes ecore_desktop
> from autofoo
> http://gstaedtner.net/eliminate_ecore_desktop.patch.lzma - removes
> ecore_desktop from autofoo and from svn
> http://gstaedtner.net/ecore_desktop.patch - was the old patch that fixed the
> broken Eina calls.

i finally nixed ecore_desktop from svn - no point having the cruft. if we want
it - it's in svn revision history. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] ecore_fb absolute coordinate support

[The Rasterman]

On Tue, 16 Dec 2008 16:32:59 +0100 l...@segv.dk (Lars Munch) babbled:

ok - if it still uses tslib if there - good. its not much extra code int he
patch - though  a lot of changes - and in many ways the style of the code looks
odd. i.e.:

if (x) {
 something;
}

instead of
if (x)
 something;

or
if (x)
{
 something;
}

can you clear that up?

> On Tue, Dec 16, 2008 at 02:59:59PM +0100, Michael 'Mickey' Lauer wrote:
> > Am Tuesday 16 December 2008 11:23:37 schrieb Lars Munch:
> > > On Mon, Dec 15, 2008 at 08:56:18PM +0100, Michael 'Mickey' Lauer wrote:
> > > > Am Monday 15 December 2008 11:24:07 schrieb Lars Munch:
> > > > > This patch adds absolute coordinate support to ecore_fb, e.g.
> > > > > touchscreen support. There is no calibration support yet, it just uses
> > > > > the values it gets from the kernel.
> > > >
> > > > Why don't you use tslib?
> > >
> > > One less dependency and if the touchscreen driver is already calibrated
> > > then it "just works".
> > 
> > I don't think that justifies adding that code to ecore_fb. Everyone and
> > their brother is using tslib these days. Anyways, if you want that patch to
> > go in, keep the tslib functionality around and only add on top.
> 
> Apparently not everyone :-)
> 
> Yes, we should definitely keep the tslib functionality! my intension was
> not to replace it but apparently I was missing a HAVE_TSLIB guard in
> ecore_evas_fb.c. Now it will use TSLIB lib if you have it installed and
> fallback to ecore_fb_li if not.
> 
> Updated patch below.
> 
> ---
> 
> Index: src/lib/ecore_fb/ecore_fb_private.h
> ===
> --- src/lib/ecore_fb/ecore_fb_private.h   (revision 38149)
> +++ src/lib/ecore_fb/ecore_fb_private.h   (working copy)
> @@ -19,8 +19,8 @@
>   #define kernel_ulong_t unsigned long 
>   #define BITS_PER_LONG 32
>   #include 
> - #undef kernel_ulong_t <-added
> - #undef BITS_PER_LONG <-added
> + #undef kernel_ulong_t
> + #undef BITS_PER_LONG
>  #else
>   #include 
>  #endif
> @@ -52,7 +52,7 @@
>   /* absolute axis */
>   int min_w, min_h;
>   double rel_w, rel_h;
> -
> + int event;
>   } mouse;
>   struct
>   {
> Index: src/lib/ecore_fb/ecore_fb_li.c
> ===
> --- src/lib/ecore_fb/ecore_fb_li.c(revision 38149)
> +++ src/lib/ecore_fb/ecore_fb_li.c(working copy)
> @@ -250,52 +250,110 @@
>  static void
>  _ecore_fb_li_device_event_abs(Ecore_Fb_Input_Device *dev, struct input_event
> *iev) {
> + static int prev_x = 0, prev_y = 0, prev_pressure = 0;
> + int v = 0;
> + int pressure;
> + int num;
> + char *ptr;
> + double t;
> +
>   if(!dev->listen)
>   return;
> +
>   switch(iev->code)
>   {
>   case ABS_X:
> - case ABS_Y:
> - {
> - Ecore_Fb_Event_Mouse_Move *ev;
> - if((iev->code == ABS_X) && (dev->mouse.w != 0))
> + if(dev->mouse.w != 0)
>   {
>   int tmp;
>  
>   tmp = (int)((double)(iev->value -
> dev->mouse.min_w) / dev->mouse.rel_w);
> - if(tmp < 0)
> + if(tmp < 0) {
>   dev->mouse.x = 0;
> - else if(tmp > dev->mouse.w)
> + }
> + else if(tmp > dev->mouse.w) {
>   dev->mouse.x = dev->mouse.w;
> - else
> + }
> + else {
>   dev->mouse.x = tmp;
> + }
> + dev->mouse.event = ECORE_FB_EVENT_MOUSE_MOVE;
>   }
> - else if((iev->code == ABS_Y) && (dev->mouse.h != 0))
> + break;
> +
> + case ABS_Y:
> + if(dev->mouse.h != 0)
>   {
>   int tmp;
>  
>   tmp = (int)((double)(iev->value -
> dev->mouse.min_h) / dev->mouse.rel_h);
> - if(tmp < 0)
> + if(tmp < 0) {
>   dev->mouse.y = 0;
> - else if(tmp > dev->mouse.h)
> + }
> + else if(tmp > dev->mouse.h) {
>   dev->mouse.y = dev->mouse.h;
> - else
> + }
> + else {
>   dev->mouse.y = tmp;
> + }
> + dev->mouse.event = ECORE_FB_EVENT_MOUSE_MOVE;
>   }
> - 

Re: [E-devel] Move binaries reserved for E internal use out of /usr/bin

[The Rasterman]

On Tue, 16 Dec 2008 21:02:11 +0100 Albin Tonnerre 
babbled:

> Hi there,
> I think it might be a good idea to stop putting all the binairies e17 creates
> into /usr/bin, as half of them are actually only for internal use, and have
> nothing to do in $PATH.
> The attached patch moves the following binaries to /usr/lib/enlightenment and
> updates the code accordingly:
>   - enlightenment_fm
>   - enlightenment_fm_op
>   - enlightenment_init
>   - enlightenment_sys
>   - enlightenment_thumb
> 
> Toughts ?

no problem with this - though some people who like to be really nitty might say
we should have a libexec/enlightenment dir... but really - not worth quibbling
over. lib is ok - it's inside e's dir and whatever e puts inside of that is e's
business.

but i'd move these to a subdir ie:

PREFIX/lib/enlightenment/bin/
or
PREFIX/lib/enlightenment/utils/

or something as modules are in modules/ - preload hacks in preload/ etc. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Static Analysis of EFL

[The Rasterman]

On Tue, 23 Dec 2008 16:28:28 -0200 "Luis Felipe Strano Moraes"
 babbled:

> Just ran a test build of EFL with LLVM's static analyser
> (http://clang.llvm.org/StaticAnalysis.html)
> on latest (at the time) svn revision (38291). The output is here :
> http://local.profusion.mobi:8081/~lfelipe/output-efl/
> 
> If you guys want to run it, there are instructions on the first link,
> but it is basically just
> compiling llvm, compiling clang and instead of calling make calling
> 'scan-build make'.

this is good. i scanned through a few of them and yes - some thing are just
harmless cruft - most are actually, but some need fixing for sure. it's a
matter of sitting down and doing it. :)


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: raster trunk/evas/src/lib/file

[The Rasterman]

On Sun, 28 Dec 2008 10:59:21 + Ian Lee  
babbled:

aaah more. yeah - didnt see them (they weren't causing me problems at the
time) :) fixed there too.

>  > Modified: trunk/evas/src/lib/file/evas_module.c
>  > ===
>  > --- trunk/evas/src/lib/file/evas_module.c 2008-12-23 23:15:53 UTC 
> (rev > 38313)
>  > +++ trunk/evas/src/lib/file/evas_module.c 2008-12-23 23:54:51 UTC 
> (rev > 38314)
>  > @@ -174,7 +174,7 @@
>  > em->handle = NULL;
>  > em->data = NULL;
>  > em->loaded = 0;
>  > -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
>  > +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
>  > pthread_spin_init(&em->lock, PTHREAD_PROCESS_PRIVATE);
>  > #endif
>  > if (em->type == EVAS_MODULE_TYPE_ENGINE)
> 
> 
> Dont all the #ifdefs need to change, edje_cc hangs otherwise.
> Quick patch below
> 
> thanks
> Ian
> 
> --- /home/ian/Desktop/evas_module.c   2008-12-28 10:47:43.455093172 +
> +++ evas_module.c 2008-12-28 10:41:46.288093315 +
> @@ -309,7 +309,7 @@
>  em->func.close = NULL;
>  em->api = NULL;
>  em->loaded = 0;
> -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
>  pthread_spin_destroy(&em->lock);
>   #endif
>   }
> @@ -317,12 +317,12 @@
>   void
>   evas_module_ref(Evas_Module *em)
>   {
> -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
>  pthread_spin_lock(&em->lock);
>   #endif
>  em->ref++;
>   /*   printf("M: %s ref++ = %i\n", em->name, em->ref); */
> -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
>  pthread_spin_unlock(&em->lock);
>   #endif
>   }
> @@ -330,12 +330,12 @@
>   void
>   evas_module_unref(Evas_Module *em)
>   {
> -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
>  pthread_spin_lock(&em->lock);
>   #endif
>  em->ref--;
>   /*   printf("M: %s ref-- = %i\n", em->name, em->ref); */
> -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
>  pthread_spin_unlock(&em->lock);
>   #endif
>   }
> 
> 
> 
> 
> --
> ___
> 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)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Epsilon debian package and depends

[The Rasterman]

On Mon, 29 Dec 2008 19:27:19 -0400 "Thiago Marcos P. Santos"
 babbled:

> Epsilon package should depend on libevas-engine-buffer or otherwise
> will crash. Maybe we can add a check on configure.ac. I would like to
> suggest a sanity check if the evas_buffer can be created (patch
> attached).

yes - indeed packages should make sure it depends on the buffer engine module.
a check in configure isnt that useful as engine can be installed or removed
runtime - long after the compile :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] [Patch] for gcc3 (was Re: failing to compile eina)

[The Rasterman]

On Thu, 01 Jan 2009 02:01:27 +0900 Naruto TAKAHASHI  babbled:

> Hi, all.
> 
> I'm creating a tiny patch for eina.
> 
> This patch supports gcc 3.x

すみません　- あなたの添付ファイルがない.：（


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [Patch] for gcc3 (was Re: [e-users] failing to compile eina)

[Naruto TAKAHASHI]

Hi, all.

I'm creating a tiny patch for eina.

This patch supports gcc 3.x

Best Regards.
-=-=-=-=-=-=-=-=-
Naruto TAKAHASHI
tnar...@gmail.com




At Thu, 01 Jan 2009 00:29:01 +0900 (JST),
Yasufumi Haga wrote:
> 
> On Wed, 31 Dec 2008 23:58:08 +0900,
> Naruto TAKAHASHI  wrote:
> 
> Hi Takahashi-san
> Thanks for your advice.
> 
> > Please try to add "-fno-strict-aliasing" option of CFLAGS.
> 
> Yes, this works just fine. This helped me compile eina successfully.
> Thanks a lot.
> Regards.
> --Yasufumi
> 
> >
> > Best Regards.
> >
> > -=-=-=-=-=-=-=-=-
> > Naruto TAKAHASHI
> > tnar...@gmail.com
> >
> >
> > At Fri, 19 Dec 2008 21:40:12 +0900 (JST),
> > Yasufumi Haga wrote:
> >>
> >> Hi all
> >>
> >> I updated the sources of eina to revision 38223 and tried to 
> >> compile
> >> it, but it failed with the following error:
> >>
> >>   gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I../.. 
> >> -I../../src/include
> >> -I../../src/include -DPACKAGE_BIN_DIR=\"/usr/local/e17/bin\"
> >> -DPACKAGE_LIB_DIR=\"/usr/local/e17/lib\"
> >> -DPACKAGE_DATA_DIR=\"/usr/local/e17/share/eina\" -Wall -W -Werror
> >> -I/opt/fumi/dbus/include/dbus-1.0 
> >> -I/opt/fumi/libpng/include/libpng12
> >> -I/opt/fumi/glib/include/glib-2.0
> >> -I/opt/fumi/glib/include/gio-unix-2.0 
> >> -I/opt/fumi/atk/include/atk-1.0
> >> -I/opt/fumi/pixman/include -I/opt/fumi/cairo/include
> >> -I/opt/fumi/pango/include -I/opt/fumi/jasper/include
> >> -I/opt/fumi/gtk+/include -I/opt/fumi/babl/include
> >> -I/opt/fumi/gegl/include -I/opt/fumi/gettext/include
> >> -I/opt/fumi/gimp/include -I/opt/fumi/imagemagick/include/ -g -O2 
> >> -MT
> >> eina_hash.lo -MD -MP -MF .deps/eina_hash.Tpo -c eina_hash.c  -fPIC
> >> -DPIC -o .libs/eina_hash.o
> >> eina_hash.c: In function `_eina_hash_rbtree_each':
> >> eina_hash.c:273: warning: dereferencing type-punned pointer will
> >> break strict-aliasing rules
> >> make[3]: *** [eina_hash.lo] Error 1
> >> make[3]: Leaving directory 
> >> `/home/fumi/src/e17/e/trunk/eina/src/lib'
> >> make[2]: *** [all-recursive] Error 1
> >> make[2]: Leaving directory `/home/fumi/src/e17/e/trunk/eina/src'
> >> make[1]: *** [all-recursive] Error 1
> >> make[1]: Leaving directory `/home/fumi/src/e17/e/trunk/eina'
> >> make: *** [all] Error 2
> >>
> >> Are there any ways to compile eina successfully? Does this error 
> >> has
> >> anything to do with gcc3 which I'm using?
> >>
> >> Thanks in advance.
> >> --Yasufumi
> >>
> >> --
> >> ___
> >> enlightenment-users mailing list
> >> enlightenment-us...@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eflpp

[Andreas Volz]

Am Sun, 21 Dec 2008 18:11:15 +0200 schrieb fusca...@gmail.com:

> Hi Andreas,

Hello Teodor,

I put enlightenment-devel@lists.sourceforge.net on Cc as it may be of
public interest.

> I'm writing you to ask some questions about eflpp:
> 1. Is it possible to install and use only eet++ (if not, is it easy to
> modify the autotools configuration, I know nothig about autotools
> though :() 

In near future I plan to split the big eflpp build to smaller ones as
in the C EFL packages. Then you've a eet build without the rest. If you
like to now you've to modify SUBDIRS variable in src/Makefile.am. Maybe
also AC_OUTPUT in configure.ac. Try it if you like, but don't expect
any more help as this isn't the correct way to do it in the end.

2. Is sigc++ better in something than bind/function which
> will be in the next standart(in tr1 at the moment) and can eflpp be
> switched to them? 

I used sigc++ often in the past and I know it. I don't know anything
about bind/function in tr1. Is this a new C++ standard? When will it be
official? Do you've a link for this topic. But I don't think it would
be smart to base eflpp on something that is so new. I will take a long
time until all compilers support it.

3. Is there any particular reason to prefer
> prefixes than namespaces: efl::EvasFunc1
> than
>   elf::evas::Func1
> or even
>   evas::Func1

I think it was efl:: because currently all stuff is in one big library.
Maybe efl::evas::Func1 could be smart. I'll investigate this after the
library split.

> I'm using c++ and ewl to write a filemanager app and I think I'll use
> eet for the configuration files. I've also done an ewl c++ wrapper
> (not complete at all). And I can contribute the code to eflpp when it
> is more complete.

I just started to wrap ETK as you see with my last commit. In parallel
I liked to start with EWL. But if you yet work on it we may share our
work. But the EWL wrapper you do has to fit the eflpp design. How far
did you proceed? Could you show something?

regards
Andreas 

-- 
Technical Blog 

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17 on Cygwin/X platform?

[Pavel Lipenský]

Hi  ,

good news you are are still working on Cygwin/X port.
I remember your 042 experimental release half a year ago, which really helped 
me.
But then the link became unreachable and/or blocked :(  
When updating Cygwin components, the X libraries were moved and my customized 
E17/043 stopped working :( 
I decided to port 050 snapshot myself from scratch, instead of recompiling the 
old one. 

Regarding the changes in 050 snapshot, I don't thing our patches differ 
semantically so much. 
Generally we are both fixing the same things, trying not to affect exiting 
platforms.  

I would personally prefer the Cygwin/X to be natively supported in SVN 
repository, 
instead of using cygport utilities for every new snapshot.
It is probably not possible to move all the changes at once.
But what about to do it incrementally, step by step, component by component
starting e.g. with updating Makefiles.in and configure.ac by adding your cygwin 
section 
and using AC_LIBTOOL_WIN32_DLL and "-no-undefined" linking flag ??? 

I currently don't know how the EFL-E17 devel processes look like 
(I mean commitments, testing, reviews, knowledge base, etc.), and how to join 
the team. 

However on some places in the code I would suggest to unify platform dependent 
directives 
among the component to improve the portability and to avoid so many directives 
such like
"#if defined _WIN32 || ! defined __CYGWIN__"  :) 

Here are some issues:
1) Including win/linux header files such like 
e.g. #ifdef _WIN32 v.s #ifdef HAVE_WINSOCK2_H

2) Detecting an using shared library suffixes
e.g. SHARED_LIB_SUFFIX (in ecore) v.s.  #ifdef _WIN32 + ".dll" | ".so"

3) Handing OS specific defines such like _POSIX_PATH_MAX 
e.g. embryo_cc_osdefs.h v.s. #ifdef in C files v.s. not defined

4) Unix-like signal handling on windows (siginfo_t supported by cygwin but not 
by mingw)

Regards,
Pavel

>  Původní zpráva 
> Od:  
> Předmět: Re: [E-devel] E17 on Cygwin/X platform?
> Datum: 24.12.2008 16:07:22
> 
> Hello lipens...@email.cz,
> 
> 
> I'm trying to compile e17 for cygwin, too.
> 
> 
> I upload e17 packages of snapshot(2008-09-25).
> 
>  http://fd0.x0.to/cygwin/release/
> 
> *-src.tar.bz2 contains my patches to compile on cygwin.
> (My patches differ from yours.)
> 
> 
> I hope you find them informative.
> 
> 
> 
> 
> Best regards
> 
> 
> 
> 

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eflpp

[Andreas Volz]

Am Sun, 21 Dec 2008 18:11:15 +0200 schrieb fusca...@gmail.com:

> Hi Andreas,

Hello Teodor,

I put enlightenment-devel@lists.sourceforge.net on Cc as it may be of
public interest.

> I'm writing you to ask some questions about eflpp:
> 1. Is it possible to install and use only eet++ (if not, is it easy to
> modify the autotools configuration, I know nothig about autotools
> though :() 

In near future I plan to split the big eflpp build to smaller ones as
in the C EFL packages. Then you've a eet build without the rest. If you
like to now you've to modify SUBDIRS variable in src/Makefile.am. Maybe
also AC_OUTPUT in configure.ac. Try it if you like, but don't expect
any more help as this isn't the correct way to do it in the end.

2. Is sigc++ better in something than bind/function which
> will be in the next standart(in tr1 at the moment) and can eflpp be
> switched to them? 

I used sigc++ often in the past and I know it. I don't know anything
about bind/function in tr1. Is this a new C++ standard? When will it be
official? Do you've a link for this topic. But I don't think it would
be smart to base eflpp on something that is so new. I will take a long
time until all compilers support it.

3. Is there any particular reason to prefer
> prefixes than namespaces: efl::EvasFunc1
> than
>   elf::evas::Func1
> or even
>   evas::Func1

I think it was efl:: because currently all stuff is in one big library.
Maybe efl::evas::Func1 could be smart. I'll investigate this after the
library split.

> I'm using c++ and ewl to write a filemanager app and I think I'll use
> eet for the configuration files. I've also done an ewl c++ wrapper
> (not complete at all). And I can contribute the code to eflpp when it
> is more complete.

I just started to wrap ETK as you see with my last commit. In parallel
I liked to start with EWL. But if you yet work on it we may share our
work. But the EWL wrapper you do has to fit the eflpp design. How far
did you proceed? Could you show something?

regards
Andreas 

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel