John Lee | 1 Dec 11:15 2008

[E-devel] [PATCH] etk_scrolled_view.c: make scrolled_view + viewport draggable again


	... by adding 3 callbacks to viewport->event and connecting
	them back to the original callbacks.

Signed-off-by: John Lee <john_lee <at> openmoko.com>
---
 etk/src/lib/etk_scrolled_view.c |   38 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/etk/src/lib/etk_scrolled_view.c b/etk/src/lib/etk_scrolled_view.c
index 5ae9e07..613dda3 100644
--- a/etk/src/lib/etk_scrolled_view.c
+++ b/etk/src/lib/etk_scrolled_view.c
 <at>  <at>  -71,6 +71,9  <at>  <at>  static Etk_Bool _etk_scrolled_view_mouse_up(Etk_Object *object, Etk_Event_Mouse_
 static Etk_Bool _etk_scrolled_view_mouse_click(Etk_Object *object, Etk_Event_Mouse_Up *event,
void *data);
 static Etk_Bool _etk_scrolled_view_mouse_move(Etk_Object *object, Etk_Event_Mouse_Move *event,
void *data); 
 static Etk_Bool _etk_scrolled_view_bar_mouse_down(Etk_Object *object, Etk_Event_Mouse_Down
*event, void *data); 
+static void _etk_evas_scrolled_view_mouse_down(void *object, Evas *e, Evas_Object *evas_obj, void *evas_event);
+static void _etk_evas_scrolled_view_mouse_up(void *object, Evas *e, Evas_Object *evas_obj, void *evas_event);
+static void _etk_evas_scrolled_view_mouse_move(void *object, Evas *e, Evas_Object *evas_obj, void *evas_event);
 /**************************
  *
  * Implementation
 <at>  <at>  -165,6 +168,7  <at>  <at>  Etk_Range *etk_scrolled_view_vscrollbar_get(Etk_Scrolled_View *scrolled_view)
 void etk_scrolled_view_add_with_viewport(Etk_Scrolled_View *scrolled_view, Etk_Widget *child)
 {
    Etk_Widget *viewport;
(Continue reading)

John Lee | 1 Dec 11:16 2008

Re: [E-devel] ETK scrolled_view isn't draggable anymore

I enclosed the patch in another mail.  Please review.

On Fri, Nov 28, 2008 at 06:14:34PM +0800, John Lee wrote:
> Hi list,
> 
> In the HEAD version of ETK, scrolled_view is not draggable anymore.
> You can verify this by executing etk_test -> scrolled_view.  However,
> the mouse event can be caught by viewport.event, which is an evas obj
> on the top level.  raster added it in #34948 to add on_hold.
> 
> viewport.event is set to repeat events, but these events will
> eventually be caught by something below it, maybe buttons or the
> viewport itself.  So callbacks like _etk_scrolled_view_mouse_move, etc
> will never be called, hence the drag function won't work.  This
> behavior seems correct to me, so I wonder why the drag works in the
> first place?
> 
> This could easily be worked around by set repeat mouse events to every
> widgets in the scrolled_view, but there must be a better way to fix
> it.  I think it might make sense to move the viewport.event to
> scrolled_view, so the drag function and the on_hold function can both
> work by the same top layer evas object.
> 
> I can do a patch, but I just started to learn about ETK, so I want to
> ask first if I missed anything.
> 
> 
> Regards,
> John
> 
(Continue reading)

Klaus Rechert | 1 Dec 12:25 2008
Picon

[E-devel] WinCE Evas crash

Hi,

I've tried to get your EFL example working on several WinCE devices. No 
success with the precompiled binaries. So I compiled the libs with 
debugging symbols and stumbled upon few issues:

1. Evas needs ddraw.h to compile evas_wince_ddraw_buffer.cpp. It is not 
catched by configure.

2. Evas engine modules aren't named properly by default. (e.g. 
module.dll instead of software_16_wince.dll)

The major issue where I'm stuck is a crash:

warning: search software_16_wince
warning: module software_16_wince
warning: search module 00125510
warning: method 1
warning: ecore_wince : instance + class bon
warning:  *** ecore message : create 320 240
Error while mapping shared library sections:
oleaut32.dll: No such file or directory.
Error while mapping shared library sections:
compime.dll: No such file or directory.
Error while mapping shared library sections:
shellres.dll: No such file or directory.
warning:  * ecore message : focus in
warning: LOAD software_16_wince
warning:  * ee window show
warning:  ** ecore_wince_window_show  00124010
(Continue reading)

Klaus Rechert | 1 Dec 15:25 2008
Picon

Re: [E-devel] WinCE Evas crash

The trace below was made with wince_gapi. With wince_fb the trace looks 
different but it seems to crash on a similar issue.

warning: ecore_wince : instance + class bon
warning:  *** ecore message : create 240 320
Error while mapping shared library sections:
oleaut32.dll: No such file or directory.
Error while mapping shared library sections:
compime.dll: No such file or directory.
Error while mapping shared library sections:
shellres.dll: No such file or directory.
warning:  * ecore message : focus in
warning: LOAD software_16_wince
warning:  * ee window show
warning:  ** ecore_wince_window_show  00124010
warning:  * ecore message : paint
warning:  * ecore message : painting...
warning:  * ecore : event expose 240 320
warning:  *** ecore message : show 240 320
warning: evas 0012A270
warning:  * ee window event damage
warning:  * ee window event show
warning:  * ecore message : lbuttondown
warning:  * ecore event button press
warning:  * ecore message : mouse move
warning: GetClientRect !!
warning: dans rect... 0
warning: w->pointer_is_in a 0
warning:  * ecore event enter notify 0
warning:  * ecore event enter notify 1
(Continue reading)

pwerken-e | 1 Dec 16:48 2008
Picon

[E-devel] [PATCH] Illume keyboard

Hi all,

Attached are two patches related to the illume keyboard:
 - When the ctrl and/or alt key are pressed they can't be deselected
   again by pressing them, illume.ctrlalt.diff fixes this.
 - it is possible to open both the layout and dict/matches ilists
   over each other.
   With illume.lists.diff the other open lists are closed when a new
   list is show.  It also closes the matcheslist when a char is
   entered/removed (though it probably would be beter to update the
   matcheslist with the new matches).

Regards,
Peter van de Werken
--

-- 
Everything fears time, but time fears the pyramids
    -- ancient Egyptian proverb
Attachment (illume.ctrlalt.diff): text/x-diff, 671 bytes
Attachment (illume.lists.diff): text/x-diff, 1363 bytes
-------------------------------------------------------------------------
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 <at> lists.sourceforge.net
(Continue reading)

Vincent Torri | 1 Dec 17:13 2008
Picon

Re: [E-devel] WinCE Evas crash


On Mon, 1 Dec 2008, Klaus Rechert wrote:

> Hi,
>
> I've tried to get your EFL example working on several WinCE devices. No 
> success with the precompiled binaries.

what are the problems ?

> So I compiled the libs with debugging 
> symbols and stumbled upon few issues:
>
> 1. Evas needs ddraw.h to compile evas_wince_ddraw_buffer.cpp. It is not 
> catched by configure.

that's right, you need ddraw.h from the microsoft Direct X SDK

> 2. Evas engine modules aren't named properly by default. (e.g. module.dll 
> instead of software_16_wince.dll)

indeed, but I've put a script in the wiki that creaates for you a zip 
files and which renames the names of the modules

> The major issue where I'm stuck is a crash:
>
> warning: search software_16_wince
> warning: module software_16_wince
> warning: search module 00125510
> warning: method 1
(Continue reading)

Vincent Torri | 1 Dec 17:17 2008
Picon

Re: [E-devel] E SVN: turran IN trunk/PROTO/enesim: . examples src/include src/include/private src/lib src/lib/drawer


On Mon, 1 Dec 2008, Enlightenment SVN wrote:

> Modified: trunk/PROTO/enesim/enesim.pc.in
> ===================================================================
> --- trunk/PROTO/enesim/enesim.pc.in	2008-12-01 15:08:30 UTC (rev 37883)
> +++ trunk/PROTO/enesim/enesim.pc.in	2008-12-01 15:34:34 UTC (rev 37884)
>  <at>  <at>  -5,7 +5,7  <at>  <at> 
>
> Name: enesim
> Description: Enesim
> -Requires:
> +Requires: eina

i think that it's eina-0 and not eina

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=/
utopic | 1 Dec 21:00 2008

Re: [E-devel] ecore_ipc ref and ref_to use

En/na Gustavo Sverzut Barbieri ha escrit:
> On Sun, Nov 30, 2008 at 9:19 AM, utopic <utopic <at> ono.com> wrote:
>>        Hi all,
>>
>>        I'm coding a program that uses ecore_ipc, and I used "ref" and "ref_to"
>> values to know wich function should process the recived message. I was
>> able to pass the values I need in both "ref" and "ref_to", but since
>> last svn actualization I can't.
>>        How I should use this two values?
> 
> why are you using ecore_ipc? I'd use dbus (more standard and has more
> features, easier to use)  or direct pipes/sockets for simple and fast
> communication.
> 
> AFAIK you can use private bus if you want to.
> 

	I'm programming a client-server application, I thought that IPC
functions are for it, they aren't? What's the problem with IPC?

	Thanks,

--
Utopic

-------------------------------------------------------------------------
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=/
(Continue reading)

Nick Hughart | 1 Dec 21:18 2008
Picon

Re: [E-devel] ecore_ipc ref and ref_to use

On Mon, 01 Dec 2008 21:00:20 +0100
utopic <utopic <at> ono.com> wrote:

> En/na Gustavo Sverzut Barbieri ha escrit:
> > On Sun, Nov 30, 2008 at 9:19 AM, utopic <utopic <at> ono.com> wrote:
> >>        Hi all,
> >>
> >>        I'm coding a program that uses ecore_ipc, and I used "ref"
> >> and "ref_to" values to know wich function should process the
> >> recived message. I was able to pass the values I need in both
> >> "ref" and "ref_to", but since last svn actualization I can't.
> >>        How I should use this two values?
> > 
> > why are you using ecore_ipc? I'd use dbus (more standard and has
> > more features, easier to use)  or direct pipes/sockets for simple
> > and fast communication.
> > 
> > AFAIK you can use private bus if you want to.
> > 
> 
> 	I'm programming a client-server application, I thought that
> IPC functions are for it, they aren't? What's the problem with IPC?
> 

There is nothing wrong with it, he just suggested dbus, which is an IPC
mechanism, because it is popular and well distributed.

> 	Thanks,
> 
> --
(Continue reading)

Vincent Pomageot | 1 Dec 22:53 2008
Picon

Re: [E-devel] EFM: thoughts, current work et al.

>
> no. "windows" reversed the convention. before windows existed in the mac
> and
> amiga etc. worlds shift was multi-select, control was range select. i am
> following the original convention by default. efm can switch to do it the
> "windows way". but nothng is exposed in the gui to do that - the code is
> there
> though.
>

Ok ! I didn't know that. Anyway that's not an habit that couldn't be lost -
particularly if it comes from windows ;)

> you could do this with multiple fm views... but this is going too far. efm
> is
> intended as a basic SIMPLE fm that you get "for free" because the majority
> of
> the infra for a fm is already lurking inside e - and this just exposes it.
> we
> need to get e17 released and so i want efm to remain simple - we can worry
> about more features after release - unless those features are really core
> to
> the thing working properly at all. as such the old fm that brought up a new
> window per dir worked wonders on macos and amigaos and a dozen others for
> many
> years. its very simple and flexible. thats all i wanted for e17 - fore e18
> etc.
> we can look at doing more.
>

(Continue reading)


Gmane