hi,

   the minimum working sample of the problem and  the backtrace :

               self.meeting =  edje.Edje(self.ee.evas,
                                      file=self.edje_file,
                                      group="sub_menu")

                self.meeting_icon=edje.Edje(self.ee.evas,
                                         file=self.edje_file,

group="meeting_icon")
                self.meeting.part_swallow("contents",self.meeting_icon)


self.main_group.part_swallow("sub_menu_contents",self.meeting)
                self.meeting.signal_emit("transition,in",source)

                self.main_group.focus =False
                self.main_group.part_object_get("sub_menu_contents").focus
=True

                 self.main_group.show()

       when I clicked the  "meeting_icon"  it still output :
                "   Mouse Clicked: sub_menu_contents  "
       not  the  corresponding   icon clicked .       I don't know what  the
proble  is ?

  thanks !




2008/10/27 <[EMAIL PROTECTED]>

> Send enlightenment-devel mailing list submissions to
>        [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> or, via email, send a message with subject or body 'help' to
>        [EMAIL PROTECTED]
>
> You can reach the person managing the list at
>        [EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of enlightenment-devel digest..."
>
>
> Today's Topics:
>
>   1. Re: [PATCH] tiny patch eina for FreeBSD (Joerg Sonnenberger)
>   2. Re: evil trouble (Joerg Sonnenberger)
>   3. Re: evil trouble (Lars Munch)
>   4. Re: evil trouble (Vincent Torri)
>   5. Re: evil trouble (Vincent Torri)
>   6. Re: can't focus on swallowed part (Gustavo Sverzut Barbieri)
>   7. Re: evil trouble (Vincent Torri)
>   8. Re: E SVN: englebass trunk/ecore/src/lib/ecore_evas
>      (Gustavo Sverzut Barbieri)
>   9. Re: evil trouble (Lars Munch)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 26 Oct 2008 13:56:43 +0100
> From: Joerg Sonnenberger <[EMAIL PROTECTED]>
> Subject: Re: [E-devel] [PATCH] tiny patch eina for FreeBSD
> To: [email protected]
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=us-ascii
>
> On Sat, Oct 25, 2008 at 01:18:25PM -0500, Ravenlock wrote:
> > > eina build failed on FreeBSD, so I made FreeBSD patch.
> >
> > In SVN! :)
>
> Please invert that patch. CLOCK_PROF is mostly present, the alternative
> not. E.g. linux clock if present, otherwise CLOCK_PROF or CLOCK_REALTIME
> as last line of fallback.
>
> Joerg
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 26 Oct 2008 14:00:06 +0100
> From: Joerg Sonnenberger <[EMAIL PROTECTED]>
> Subject: Re: [E-devel] evil trouble
> To: [email protected]
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Oct 26, 2008 at 06:26:01PM +1030, Samuel Nicholas wrote:
> > libuuid.a exists at c:/msys/1.0/mingw/lib/
>
> Only the static archive or also a shared library? The reason libtool is
> complaining is it only finds the former.
>
> Joerg
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 26 Oct 2008 14:08:29 +0100
> From: [EMAIL PROTECTED] (Lars Munch)
> Subject: Re: [E-devel] evil trouble
> To: Samuel Nicholas <[EMAIL PROTECTED]>
> Cc: [email protected]
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="us-ascii"
>
> On Sun, Oct 26, 2008 at 06:26:01PM +1030, Samuel Nicholas wrote:
> > hay guise
> >
> > cause eina has recently been added as a dependancy i was updating my
> > libs and ran into trouble... so i decided to start from scratch again.
> > now i have a problem I didn't have before
> >
> > when compiling evil:
> > ...
> > /bin/sh ../../libtool --tag=CC   --mode=link gcc  -g -O2 -no-undefined
> > -Wl,--enable-auto-import -version-info 0:1:0 -L/usr/local/lib -o
> > libevil.la -rpath /usr/local/lib libevil_la-evil_errno.lo
> > libevil_la-evil_fcntl.lo libevil_la-evil_fnmatch.lo
> > libevil_la-evil_fnmatch_list_of_states.lo libevil_la-evil_langinfo.lo
> > libevil_la-evil_mman.lo libevil_la-evil_pwd.lo libevil_la-evil_stdlib.lo
> > libevil_la-evil_stdio.lo libevil_la-evil_string.lo
> > libevil_la-evil_time.lo libevil_la-evil_unistd.lo
> > libevil_la-evil_util.lo -lole32 -luuid -lws2_32 -lsecur32
> > libtool: link: rm -fr  .libs/libevil.a .libs/libevil.la.libs/libevil.lai
> >
> > *** Warning: linker path does not have real file for library -luuid.
> > *** I have the capability to make that library automatically link in when
> > *** you link to this library.  But I can only do this if you have a
> > *** shared version of the library, which you do not appear to have
> > *** because I did check the linker path looking for a file starting
> > *** with libuuid and none of the candidates passed a file format test
> > *** using a file magic. Last file checked: /mingw/lib//libuuid.a
> > *** The inter-library dependencies that have been dropped here will be
> > *** automatically added whenever a program is linked with this library
> > *** or is declared to -dlopen it.
> >
> > *** Since this library must not contain undefined symbols,
> > *** because either the platform does not support them or
> > *** it was explicitly requested with -no-undefined,
> > *** libtool will only create a static version of it.
> > ...
> >
> > which then, later on, fails completely when it goes to make the shared
> lib.
> >
> > libuuid.a exists at c:/msys/1.0/mingw/lib/
>
> Do you have the "file" utility installed in mingw? Having this utility
> will make libtool fail in this manor, because it will detect libraries
> differently, since "file" can tell the difference between a static
> library and a dll. The above also happens if you try to cross compile
> evil linux->mingw.
>
> IMHO it is not a libtool problem, but the problem is that evil.dll tries
> to link to at static library (uuid in this case), which is generally
> considered bad.
>
> I currently use the attached patch to get around this problem.
>
> Regards
> Lars Munch
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: evil_uuid_build_fix.patch
> Type: text/x-diff
> Size: 1252 bytes
> Desc: not available
>
> ------------------------------
>
> Message: 4
> Date: Sun, 26 Oct 2008 16:42:18 +0100 (CET)
> From: Vincent Torri <[EMAIL PROTECTED]>
> Subject: Re: [E-devel] evil trouble
> To: Joerg Sonnenberger <[EMAIL PROTECTED]>
> Cc: [email protected]
> Message-ID:
>        <[EMAIL PROTECTED]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
>
> On Sun, 26 Oct 2008, Joerg Sonnenberger wrote:
>
> > On Sun, Oct 26, 2008 at 06:26:01PM +1030, Samuel Nicholas wrote:
> >> libuuid.a exists at c:/msys/1.0/mingw/lib/
> >
> > Only the static archive or also a shared library? The reason libtool is
> > complaining is it only finds the former.
>
> the problem is that libtool is not detecting that libuuid.a is an import
> library
>
> Vincent
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 26 Oct 2008 16:59:19 +0100 (CET)
> From: Vincent Torri <[EMAIL PROTECTED]>
> Subject: Re: [E-devel] evil trouble
> To: Lars Munch <[EMAIL PROTECTED]>
> Cc: [email protected]
> Message-ID:
>        <[EMAIL PROTECTED]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
>
> On Sun, 26 Oct 2008, Lars Munch wrote:
>
> > IMHO it is not a libtool problem, but the problem is that evil.dll tries
> > to link to at static library (uuid in this case), which is generally
> > considered bad.
>
> it is a libtool problem, in a manner or another. Your remark:
>
> + * This file defines all the windows UUID used in evil. This is here
> + * since uuid.lib is a static only library and libtool does not allow
> + * you to link a DLL against a static library.
>
> is wrong. We can link a lib against a static lib to produce a dll. Check
> when I link against libm.a, libws2_32.a, etc... in evil or other efl lib.
> There is no dll for those lib. But libtool detects that it is an import
> lib (look at the function func_win32_libid() in ltmain.sh or libtool
> scripts) and accepts to create the dll.
>
> about the 'file' program, i didn't know.
>
> Vincent
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 26 Oct 2008 14:07:15 -0200
> From: "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]>
> Subject: Re: [E-devel] can't focus on swallowed part
> To: "dongmei zhou" <[EMAIL PROTECTED]>
> Cc: [email protected]
> Message-ID:
>        <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=UTF-8
>
> On Sun, Oct 26, 2008 at 5:22 AM, dongmei zhou <[EMAIL PROTECTED]>
> wrote:
> > hi all,
> >
> >  I use the following code  to give focus on the swallowed  part,but  it
> > can't   work .
> >  It still focus on the main_group , why?
> >
> > code:
> >                       self.main_group.focus =False
> >
> > self.main_group.part_object_get("menu_contents").focus =True
>
> try to provide an minimum working sample of the problem and, if
> possible, the backtrace. This code should be correct, but it's hard to
> say if it's really what you want, possible you're misusing something.
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: [EMAIL PROTECTED]
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 26 Oct 2008 19:44:36 +0100 (CET)
> From: Vincent Torri <[EMAIL PROTECTED]>
> Subject: Re: [E-devel] evil trouble
> To: Samuel Nicholas <[EMAIL PROTECTED]>
> Cc: [email protected]
> Message-ID:
>        <[EMAIL PROTECTED]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
>
> On Sun, 26 Oct 2008, Samuel Nicholas wrote:
>
> > hay guise
> >
> > cause eina has recently been added as a dependancy i was updating my libs
> and
> > ran into trouble... so i decided to start from scratch again.
> > now i have a problem I didn't have before
> >
> > when compiling evil:
> >
> > *** Warning: linker path does not have real file for library -luuid.
> > *** I have the capability to make that library automatically link in when
> > *** you link to this library.  But I can only do this if you have a
> > *** shared version of the library, which you do not appear to have
> > *** because I did check the linker path looking for a file starting
> > *** with libuuid and none of the candidates passed a file format test
> > *** using a file magic. Last file checked: /mingw/lib//libuuid.a
> > *** The inter-library dependencies that have been dropped here will be
> > *** automatically added whenever a program is linked with this library
> > *** or is declared to -dlopen it.
> >
> > *** Since this library must not contain undefined symbols,
> > *** because either the platform does not support them or
> > *** it was explicitly requested with -no-undefined,
> > *** libtool will only create a static version of it.
> > ...
>
> i think that you will hate me: i don't have the problem... I don't know
> what to say. May as Lars said, a program that makes libtool crazy.
>
> Vincent
>
>
>
> ------------------------------
>
> Message: 8
> Date: Sun, 26 Oct 2008 17:59:12 -0200
> From: "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]>
> Subject: Re: [E-devel] E SVN: englebass trunk/ecore/src/lib/ecore_evas
> To: [email protected]
> Cc: [EMAIL PROTECTED]
> Message-ID:
>        <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=UTF-8
>
> On Sun, Oct 26, 2008 at 5:46 PM, Enlightenment SVN
> <[EMAIL PROTECTED]> wrote:
> > Log:
> >  This function returns void
> > Author:       englebass
> > Date:         2008-10-26 12:45:59 -0700 (Sun, 26 Oct 2008)
> > New Revision: 37163
> >
> > Modified:
> >  trunk/ecore/src/lib/ecore_evas/ecore_evas.c
> >
> > Modified: trunk/ecore/src/lib/ecore_evas/ecore_evas.c
> > ===================================================================
> > --- trunk/ecore/src/lib/ecore_evas/ecore_evas.c 2008-10-26 17:31:14 UTC
> (rev 37162)
> > +++ trunk/ecore/src/lib/ecore_evas/ecore_evas.c 2008-10-26 19:45:59 UTC
> (rev 37163)
> > @@ -232,7 +232,7 @@
> >  }
> >
> >  /* inline is just to avoid need to ifdef around it */
> > -static inline const char *
> > +static inline void
> >  _ecore_evas_parse_extra_options_uint(const char *extra_options, const
> char *key, unsigned int *value)
> >  {
> >    int len = strlen(key);
>
>
> Actually it's missing the return of extra_options, please revert the
> patch and fix it correctly.
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: [EMAIL PROTECTED]
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
>
>
> ------------------------------
>
> Message: 9
> Date: Sun, 26 Oct 2008 23:10:41 +0100
> From: [EMAIL PROTECTED] (Lars Munch)
> Subject: Re: [E-devel] evil trouble
> To: Vincent Torri <[EMAIL PROTECTED]>
> Cc: [email protected]
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Oct 26, 2008 at 04:59:19PM +0100, Vincent Torri wrote:
> >
> >
> > On Sun, 26 Oct 2008, Lars Munch wrote:
> >
> > >IMHO it is not a libtool problem, but the problem is that evil.dll tries
> > >to link to at static library (uuid in this case), which is generally
> > >considered bad.
> >
> > it is a libtool problem, in a manner or another. Your remark:
> >
> > + * This file defines all the windows UUID used in evil. This is here
> > + * since uuid.lib is a static only library and libtool does not allow
> > + * you to link a DLL against a static library.
> >
> > is wrong. We can link a lib against a static lib to produce a dll. Check
> > when I link against libm.a, libws2_32.a, etc... in evil or other efl lib.
> > There is no dll for those lib. But libtool detects that it is an import
> > lib (look at the function func_win32_libid() in ltmain.sh or libtool
> > scripts) and accepts to create the dll.
>
> But there are dll's for those libs:
>
> libws2_32.a is an import library for windows\system32\ws2_32.dll.
> libole32.a is an import library for windows\system32\ole32.dll.
> libsecur32.a is an import library for windows\system32\secur32.dll.
>
> libuuid.a on the other hand is not an import library but a real static
> library, hence the error when not detected as an import library.
>
> > about the 'file' program, i didn't know.
>
> The func_win32_libid function is different if you got the file utility
> on your system (as most people do on linux). This version is actually
> better at identifying a static library vs. import library.
>
> See for instance:
> http://www.cygwin.com/ml/cygwin/2003-02/msg01464.html
>
> I went for a modified version of point 1) in my patch.
>
> -- Lars Munch
>
>
>
> ------------------------------
>
> -------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> End of enlightenment-devel Digest, Vol 30, Issue 48
> ***************************************************
>
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to