Re: [E-devel] [RFC] SDL Engine
Cedric wrote: I finally got a SDL Engine running and starting to look correct. I did split it in 3 patch. - evas_cache_image.diff: Add a global cache for image mechanism. I hope it could be shared with other engine and reduce their code complexity. This cache works more like the one from FreeType, you request image/operation from the cache, and the cache forwards it if needed to the right callback function. This need to be carefully reviewed, even if it seems correct. raster will be the one to bless or damn this :) but I took a quick look at it and thought I'd give you some of my impressions. I like the cache stuff. I actually had to do something similar recently (though I didn't bother abstracting it as much as you did here). A couple of things quickly came to mind though: You're using the image struct's extended_info pointer, in the sdl engine, to hold an engine-specific surface (namely, an sdl surface), I added an extra void *engine_surface for this (I did it for the xrender and gl engines), since the 'extended_info' pointer was likely intended to hold 'meta data' that an image file format may have..? There are some things I think could be cleaned up... maybe the various assert calls could be replaced by a more 'silent' means of checking for invalid inputs? Also, why the need to keep a hash of 'inactive' images when there's the (last used precedence) list of such? - evas_sdl_engine.diff: This patch really provides the SDL engine. You must not expect other colorspace than EVAS_COLORSPACE_ ARGB to work. I have no plan to fix this now as I think it will be easier to test that with emotion. So I first need an Ecore_SDL to fix this. It doesn't use evas_pipe (and never will) as it need to use SDL thread to do that same task, and I am really not planing to do it soon. Ummm... I'll have to preface what follows here by saying that I know nothing about sdl, and haven't really looked at the engine too much... But from what I can gather: It seems to be what I'd call a 'generic' implementation -- ie. uses the software routines for things and puts the result argb on the dst surface. If so, I think it might then be best to call it software_sdl? Also, if so, why do you seem to keep an sdl surface for src images, when it doesn't seem to be used for any copying or compositing to a dst surface? (for the yuv color space why not then use software conversion routines?) Or maybe I'm reading that wrong? I did visit the sdl website, and there seems to be mention of using OpenGL with SDL... Is it possible to maybe also have a gl_sdl version of the engine.. ie. one which would presumably use some gl rendering? Now, this is not perfect and I think some more work is needed. It's a lot, even as is :) Sure it could be better... What can't? Anyway that's just my limited feedback for now, based on a quick look. I'm sure raster will disect and digest it all far better, when he gets a chance. :) Keep the spam coming. jose. BTW: You never did tell me 'what is sdl' or 'why is it interesting' from your own point of view :) -- not the sdl website's views!. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] easy_e17.sh
Or else, you might wanna discover the magic -e arg : #easy_e17.sh -i -e --clean --clean is my default way to build e. Or else the developer might remove entrance_edit_gui from the script, because it is pretty much broken. It uses a year old API definiton, while these stuff are changing day-by-day (or at least they used to). It never actually worked, btw, so there's no point including it in the script. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] shelf authohide patch
В чт, 2007-04-05 в 21:09 +0200, Hannes Janetzek написа: Hi, I made a patch so that hiding of the shelf is done by the shelf and not by the theme. I think this will make it easier to have a consistent and configurable shelf-hiding behaviour. I added one theme-data item to the shelf group: hidden_state_size which sets the height or width for the shelf when it is in hidden state. The only problem with this patch that i can see is, that it should work regardless of whether the theme has a hidden_state_size set. Currently, if a theme does not have that, things will mess up, bad. And it might be useful to increase the default hidden_state_size from 2 to 6, so as to minimize the chance of rolling over to another virtual desktop. Other than that, the patch is dandy, and if no one objects, I'll commit it. Regards, Hannes - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Виктор Кожухаров /Viktor Kojouharov/ signature.asc Description: Това е цифрово подписана част от писмото - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore englebass
Enlightenment CVS wrote:
Enlightenment CVS committal
Author : englebass
Project : e17
Module : libs/ecore
Dir : e17/libs/ecore/src/lib/ecore_evas
Modified Files:
ecore_evas.c ecore_evas_private.h ecore_evas_x.c
Log Message:
Don't use an idler to delete the evas. This wont work during ecore main
loop shutdown.
===
RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore_evas/ecore_evas.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -3 -r1.29 -r1.30
--- ecore_evas.c27 Jul 2006 16:14:33 - 1.29
+++ ecore_evas.c5 Apr 2007 06:53:41 - 1.30
@@ -6,8 +6,6 @@
static int _ecore_evas_init_count = 0;
-static int _ecore_evas_idle_enter_delete(void *data);
-
/**
* Query if a particular renginering engine target has support
* @param engine The engine to check support for
@@ -139,9 +137,7 @@
ecore_evas_free);
return;
}
- if (ee-delete_idle_enterer) return;
- ee-delete_idle_enterer =
- ecore_idle_enterer_add(_ecore_evas_idle_enter_delete, ee);
+ _ecore_evas_free(ee);
return;
}
@@ -1764,11 +1760,6 @@
_ecore_evas_free(Ecore_Evas *ee)
{
ECORE_MAGIC_SET(ee, ECORE_MAGIC_NONE);
- if (ee-delete_idle_enterer)
- {
- ecore_idle_enterer_del(ee-delete_idle_enterer);
- ee-delete_idle_enterer = NULL;
- }
while (ee-sub_ecore_evas)
{
_ecore_evas_free(ee-sub_ecore_evas-data);
@@ -1792,14 +1783,4 @@
ee-evas = NULL;
if (ee-engine.func-fn_free) ee-engine.func-fn_free(ee);
free(ee);
-}
-
-static int
-_ecore_evas_idle_enter_delete(void *data)
-{
- Ecore_Evas *ee;
-
- ee = (Ecore_Evas *)data;
- _ecore_evas_free(ee);
- return 0;
}
===
RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore_evas/ecore_evas_private.h,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -3 -r1.25 -r1.26
--- ecore_evas_private.h20 Oct 2006 01:46:41 - 1.25
+++ ecore_evas_private.h5 Apr 2007 06:53:41 - 1.26
@@ -164,8 +164,6 @@
charshould_be_visible : 1;
charalpha : 1;
- Ecore_Idle_Enterer *delete_idle_enterer;
-
Evas_Hash *data;
struct {
===
RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore_evas/ecore_evas_x.c,v
retrieving revision 1.93
retrieving revision 1.94
diff -u -3 -r1.93 -r1.94
--- ecore_evas_x.c 16 Jan 2007 10:17:46 - 1.93
+++ ecore_evas_x.c 5 Apr 2007 06:53:41 - 1.94
@@ -110,14 +110,12 @@
Evas_List *ll;
#endif
- if (ee-delete_idle_enterer) return;
#ifdef BUILD_ECORE_EVAS_BUFFER
for (ll = ee-sub_ecore_evas; ll; ll = ll-next)
{
Ecore_Evas *ee2;
ee2 = ll-data;
- if (ee2-delete_idle_enterer) continue;
if (ee2-func.fn_pre_render) ee2-func.fn_pre_render(ee2);
_ecore_evas_buffer_render(ee2);
if (ee2-func.fn_post_render) ee2-func.fn_post_render(ee2);
@@ -360,7 +358,6 @@
Ecore_Evas *ee;
ee = evas_hash_find(ecore_evases_hash, _ecore_evas_x_winid_str_get(win));
- if ((ee) (ee-delete_idle_enterer)) return NULL;
return ee;
}
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
enlightenment-cvs mailing list
enlightenment-cvs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
Hi! I have fixed the directfb to compile with englebass changes..
Please see attached makefile.
Danke!
cvs diff: Diffing .
cvs diff: Diffing debian
cvs diff: Diffing doc
cvs diff: Diffing doc/img
cvs diff: Diffing m4
cvs diff: Diffing src
cvs diff: Diffing src/bin
cvs diff: Diffing src/lib
cvs diff: Diffing src/lib/ecore
cvs diff: Diffing src/lib/ecore_con
cvs diff: Diffing src/lib/ecore_config
cvs diff: Diffing src/lib/ecore_dbus
cvs diff: Diffing src/lib/ecore_desktop
cvs diff: Diffing src/lib/ecore_directfb
cvs diff: Diffing src/lib/ecore_evas
Index: src/lib/ecore_evas/ecore_evas_directfb.c
===
RCS file: /var/cvs/e/e17/libs/ecore/src/lib/ecore_evas/ecore_evas_directfb.c,v
retrieving revision 1.8
diff -u -r1.8 ecore_evas_directfb.c
--- src/lib/ecore_evas/ecore_evas_directfb.c5 Nov 2006 15:22:47 -
1.8
+++ src/lib/ecore_evas/ecore_evas_directfb.c6 Apr 2007 11:58:03 -
@@ -16,8 +16,6 @@
static Ecore_Evas *ecore_evases = NULL;
static Evas_Hash *ecore_evases_hash = NULL;
-static Ecore_Idle_Enterer *ecore_evas_directfb_idle_enterer = NULL;
-
static void
Re: [E-devel] [RFC] SDL Engine
On Friday 06 April 2007 09:58:26 [EMAIL PROTECTED] wrote: Cedric wrote: - evas_cache_image.diff: Add a global cache for image mechanism. I hope it could be shared with other engine and reduce their code complexity. This cache works more like the one from FreeType, you request image/operation from the cache, and the cache forwards it if needed to the right callback function. This need to be carefully reviewed, even if it seems correct. raster will be the one to bless or damn this :) but I took a quick look at it and thought I'd give you some of my impressions. Nice you take the time also. I like the cache stuff. I actually had to do something similar recently (though I didn't bother abstracting it as much as you did here). A couple of things quickly came to mind though: You're using the image struct's extended_info pointer, in the sdl engine, to hold an engine-specific surface (namely, an sdl surface), I added an extra void *engine_surface for this (I did it for the xrender and gl engines), since the 'extended_info' pointer was likely intended to hold 'meta data' that an image file format may have..? I didn't see it, it would perhaps be a good idea to have this engine_surface directly as a part of the RGBA_Image (I did use extended_info, because I didn't see any use of it). There are some things I think could be cleaned up... maybe the various assert calls could be replaced by a more 'silent' means of checking for invalid inputs? I like assert when developping, they stop the apps as soon as needed. But after debugging, they must be useless and never trigerred. I could remove them completely I think. Also, why the need to keep a hash of 'inactive' images when there's the (last used precedence) list of such? It's faster, easier (one line of code :-) ), to look into a hash to find the right image to use. The LRU is only used when we need to drop some content due to cache presure. - evas_sdl_engine.diff: This patch really provides the SDL engine. You must not expect other colorspace than EVAS_COLORSPACE_ ARGB to work. I have no plan to fix this now as I think it will be easier to test that with emotion. So I first need an Ecore_SDL to fix this. It doesn't use evas_pipe (and never will) as it need to use SDL thread to do that same task, and I am really not planing to do it soon. Ummm... I'll have to preface what follows here by saying that I know nothing about sdl, and haven't really looked at the engine too much... But from what I can gather: It seems to be what I'd call a 'generic' implementation -- ie. uses the software routines for things and puts the result argb on the dst surface. If so, I think it might then be best to call it software_sdl? Yes, it's mainly a software_sdl. I wanted to use more SDL function, but most of them are useless due to the strange way they handle the alpha case. The only case that really use SDL is when doing the update of a surface with SDL_UpdateRects. Also, if so, why do you seem to keep an sdl surface for src images, when it doesn't seem to be used for any copying or compositing to a dst surface? Mainly for SDL_UpdateRects as it could be of some use, and also because direct access to the SDL_Surface is the same as an access to the RGBA_Surface software surface. (for the yuv color space why not then use software conversion routines?) Or maybe I'm reading that wrong? I think I could use the software conversion routines, I just want to be sure that the SDL YUV function are also useless before doing it. I did visit the sdl website, and there seems to be mention of using OpenGL with SDL... Is it possible to maybe also have a gl_sdl version of the engine.. ie. one which would presumably use some gl rendering? I did think about that also, but I must have some priority. So first I want to have an Ecore with all others EFL running cleany with the software_sdl. So it's definitively possible in my opinion, but not really on top of my TODO list :) Now, this is not perfect and I think some more work is needed. It's a lot, even as is :) Sure it could be better... What can't? :) Anyway that's just my limited feedback for now, based on a quick look. I'm sure raster will disect and digest it all far better, when he gets a chance. :) Thanks, for the feedback ! Keep the spam coming. Of course ! BTW: You never did tell me 'what is sdl' or 'why is it interesting' from your own point of view :) -- not the sdl website's views!. Well for some crazy idea. I did notice that many little 2D game on Linux are using SDL, but they always need to re develop their own EFL like functionnality because SDL is really limited. The drawback of the EFL is that they need a specific engine each time we want to make it run on a new device/OS. The SDL provide an easy solution to
Re: [E-devel] Fwd: Re: [collab4] eclair improvements
Hi Peter, All the changes you are describing are actually the reasons why I started coding Etk: I needed a toolkit library to add a filechooser and a collection manager to Eclair. Etk was just more work than I first thought it would be, and I've never been able to work on Eclair again. So, if you want to add those features, feel free to do it :) The library support is even started, all the songs are already stored in a database with sqlite. If you even think eclair should be rewritten, go ahead, I'll probably never work on it again. I thought, the collection manager would be implemented in evas smarts, and edje, but to be honest, i don't know much about them. First, I'll have to read through the code of eclair, and then if I'll have time, I'll start working on it. Unfortunately, I don't have time to code till the end of May, so don't expect very much till June. ;) If I find some edje/evas smarts how-to, then I'll be able to start working on the UI, and extending the theme. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] E17 + X screensaver + DPMS = Xorg.segv
Hello,
While investigating a different DPMS issue I've run across what I
believe is an Xorg/xscreensaver/DPMS issue. Running Xorg 6.9.0 (maybe
others for all I know) if I enable the xscreensaver, and setup DPMS to
*not* enter standby, but *do* enter suspend... I get a segv shortly
after the screen suspends.
I use the following commands specifically.
1) xset s noblank
2) xset s 60 5
3) xset dpms 0 0 120
The commands above are important. The screensaver must be set to no
blank, it should alternate at a short period (or you'll have to wait for
the segv). And on two different machines I have had to setup DPMS
differently... but what seems significant is I am *not* entering standby
or suspend before entering off.
The following is the backtrace I get with gdb attached to Xorg.
Program received signal SIGSEGV, Segmentation fault.
0x080d9121 in SaveScreens ()
(gdb) bt
#0 0x080d9121 in SaveScreens ()
#1 0x080deb5d in ScreenSaverTimeoutExpire ()
#2 0x080de8db in DoTimer ()/gallery/main.
#3 0x080de3f9 in WaitForSomething ()
#4 0x080ba564 in Dispatch ()
#5 0x080cce94 in main ()
Now... all this is interesting. And I *think* it is an Xorg issue
entirely. I say think because I *can not* reproduce this running other
window managers (fvwm). However, given the above bt, and the fact that
E17 does not segv when it occurs, it just looks like Xorg
However, my question to the ml here is... Do we ignore the bug and code
to spec until Xorg fixes it? Meaning the DPMSSetTimeouts() man page
says you may disable any one of the modes. Or do we prevent the user
from shooting themselves in the foot by altering our config panel?
Presently the E17 DPMS config panel allows us to put ourselves in this
particular position. So if we do nothing, we are coding to what the
manpage says is perfectly legitimate, and the user can apparently
configure their machine to segv on timed intervals.
Or we can apply the attached patch. The attached patch will fix the
problem behavior and make no (noticeable?) change in functionality. It
does so by quietly setting any disabled lesser mode to the same timeout
as the next greater mode's timeout. I did this without modifying the
gui intentionally. Ideally I would be able to report this upstream, and
once its fixed we could quietly revert this patch and be on our way.
I'm hoping for comments on if anyone else can reproduce this, whether
this is in fact a bug with Xorg, if this is a suitable way to fix it,
or if we should just carry on without the patch.
Questions, comments, and complaints welcome.
--
Regards,
Ravenlock
Index: e17/apps/e/src/bin/e_dpms.c
===
RCS file: /var/cvs/e/e17/apps/e/src/bin/e_dpms.c,v
retrieving revision 1.1
diff -u -r1.1 e_dpms.c
--- e17/apps/e/src/bin/e_dpms.c 13 Feb 2007 16:33:35 - 1.1
+++ e17/apps/e/src/bin/e_dpms.c 6 Apr 2007 16:15:23 -
@@ -14,10 +14,22 @@
standby = e_config-dpms_standby_timeout;
if (e_config-dpms_suspend_enable)
- suspend = e_config-dpms_suspend_timeout;
+ {
+ suspend = e_config-dpms_suspend_timeout;
+
+ if (!e_config-dpms_standby_enable)
+ standby = e_config-dpms_suspend_timeout;
+ }
- if (e_config-dpms_off_enable)
- off = e_config-dpms_off_timeout;
+ if (e_config-dpms_off_enable)
+ {
+ off = e_config-dpms_off_timeout;
+
+ if (!e_config-dpms_standby_enable !e_config-dpms_suspend_enable)
+ standby = e_config-dpms_off_timeout;
+ if (!e_config-dpms_suspend_enable)
+ suspend = e_config-dpms_off_timeout;
+ }
ecore_x_dpms_timeouts_set(standby, suspend, off);
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] shelf authohide patch
В чт, 2007-04-05 в 21:09 +0200, Hannes Janetzek написа: Hi, I made a patch so that hiding of the shelf is done by the shelf and not by the theme. I think this will make it easier to have a consistent and configurable shelf-hiding behaviour. I added one theme-data item to the shelf group: hidden_state_size which sets the height or width for the shelf when it is in hidden state. Regards, Hannes I've committed a modified version of the patch. The things that were changed were, among other things: - the hidden_state_size fallback is 4 instead of 2. - _e_shelf_cb_hide_animator is actually a callback for an animator now, instead of a timer. that way it will be affected by e's fps settings - the logic inside _e_shelf_cb_hide_animator has been changed. it now takes the same amount of time to hide any shelf, regardless of it's size settings. (which is currently 1 second, and should be made configurable in the future) - reintroduced the e,state,visible edje signal, so that themers can go crazy if they want to - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Виктор Кожухаров /Viktor Kojouharov/ signature.asc Description: Това е цифрово подписана част от писмото - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
You're using the image struct's extended_info pointer, in the sdl engine, to hold an engine-specific surface (namely, an sdl surface), I added an extra void *engine_surface for this (I did it for the xrender and gl engines), since the 'extended_info' pointer was likely intended to hold 'meta data' that an image file format may have..? I didn't see it, it would perhaps be a good idea to have this engine_surface directly as a part of the RGBA_Image (I did use extended_info, because I didn't see any use of it). Oh there's no void *engine_surface pointer right now, it's something I added to my local copy since I wanted a single 'image' structure for all engines (in fact, I had to introduce engine level 'objects' in order to have things like texturing and clipping). The 'extended_info' pointer isn't used anywhere at the moment, but it could be.. if indeed it was meant to hold additional file format related 'meta data' of some sort. Also, why the need to keep a hash of 'inactive' images when there's the (last used precedence) list of such? It's faster, easier (one line of code :-) ), to look into a hash to find the right image to use. The LRU is only used when we need to drop some content due to cache presure. Yes, but it's only faster when it *fails* to find a cached (ie. inactive) image. If it suceeds (which is the whole point of having the cache), then it could actually be slower.. because not only will you have to remove the image from the inactive hash, but also from the lru list and remove it. You also need to add images to both the hash and the list when they are to be cached, and when flushing the cache you again need to go thru both. Also, if so, why do you seem to keep an sdl surface for src images, when it doesn't seem to be used for any copying or compositing to a dst surface? Mainly for SDL_UpdateRects as it could be of some use, and also because direct access to the SDL_Surface is the same as an access to the RGBA_Surface software surface. I'm not sure I follow you here.. Why do you need to keep an sdl surface for api created images (eg. loaded, etc), when those surfaces never seem to be used by any sdl functions (as far as a dst sdl surface is concerned)? There are cases where it could be useful to keep such, even if you're not using any sdl based compositing funcs (assuming there are such) -- you could use 'copy' ones in certain cases. Using sdl copy funcs would also be useful in things like rect drawing, with eg. rgb colors. One thing you may want to look into, assuming sdl does have some built-in compositing capabilities, is wether they can allow for using premul color data (there's plenty of time to get into that kind of thing a bit later). I did visit the sdl website, and there seems to be mention of using OpenGL with SDL... Is it possible to maybe also have a gl_sdl version of the engine.. ie. one which would presumably use some gl rendering? I did think about that also, but I must have some priority. So first I want to have an Ecore with all others EFL running cleany with the software_sdl. So it's definitively possible in my opinion, but not really on top of my TODO list :) Ahhh, good. :) I just wondered if it could be done at all. There's plenty of time to get to such an engine, and/or tweak the software based one, etc. It's a lot just to get something working in place. :) BTW: You never did tell me 'what is sdl' or 'why is it interesting' from your own point of view :) -- not the sdl website's views!. Well Now that was informative, and interesting! Thanks. :) jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] bug in evas
On Wed, 4 Apr 2007 10:39:13 -0500 Brian Mattern [EMAIL PROTECTED] babbled: On Wed, Apr 04, 2007 at 01:39:51PM +0900, Carsten Haitzler wrote: all in all this isnt a simple solution. the only way i see to handle both methods is to have 2 calls. 1 to add a point relative to origin and one to specify it absolutely. Two calls makes sense, but I think internally the point list should be relative to the object origin, and then convert to absolute coords at render time. This would allow us to do some sore of scaling based on object size (although some error would be introduced if the points were specified in abs coords). well the points need to be recorded when defined in some sort of given scaling space. when scaled to a new size they need to be scaled on the fly using the original scaling space. that way you won't get cumulative error either way - of course all scaling does introduce error - you are transforming co-ords given a discrete co-ordinate space :) but this would solve it - and same with line objects too. Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Events
On Wed, 21 Mar 2007 17:45:43 +0100 Cedric BAIL [EMAIL PROTECTED] babbled:
i'll do this one first - it's less work than the sdl engine + cache + one :)
Another discussion, this time about events. During my test of SDL engine, I
did like the key repeat functionnality of SDL, but it wasn't possible to
easily expose it to evas. So I just added a EVAS_CALLBACK_KEY_REPEAT with the
corresponding 'evas_event_feed_key_repeat'. It seems quite logic and work.
See evas_key_repeat.diff.
hmmm- is the point of this to send a key repeat event diferently to a normal
keydown/up - the reason i never had this is basically from the hardware or x
point of view - it's just more key down/up events. key repeat is done by the
keyboard controller - or if not inside x itself. x apps dont know it's a repeat
event.
I don't know what is the policy for adding new events, but SDL could
also expose some Joystick events:
SDL_JoyAxisEvent -- Joystick axis motion event structure
SDL_JoyButtonEvent -- Joystick button event structure
SDL_JoyHatEvent -- Joystick hat position change event structure
SDL_JoyBallEvent -- Joystick trackball motion event structure
Would people object if I come up with some evas event for this also ? This
would be nice, if an Ecore SDL was able to directly feed them to evas. But I
will understand that it's not the primary usage/goal of evas.
i wouldn't object at all. the evas events are intended to be extended and
become a superset of whatever input devices exist. if it makes sens to re-use
existing systems (key events or mouse) then use them (eg remote controls imho
should be key events). one thing i think i do need to do is exten evas and
ecore etc. events to allow for multiple mice and keyboards so you can tell
which one is which. this of course means an abi break - add members to structs,
but thats why we are still at 0.x :) so summary - yes. adding these is
perfectly fine.
On the same subject, it would also be nice if we could handle
multiple device easily in evas. From what I see, the only thing that is
needed is a 'char* device' in all struct _Evas_Event and breaking all
evas_event_feed functions prototype by adding a device parameter. The device
could be set to NULL, so all existing code will still work with very few
modification (mainly in ecore).
Would people be interested/object to this kind of patch ?
yes - definitely. i think you need to actually do 2 things. you need to add an
typedef enum _Evas_Device_Class {
EVAS_DEVICE_CLASS_MOUSE,
EVAS_DEVICE_CLASS_KEYBOARD,
/* Extend as needed */
} Evas_Device_Class;
typedef struct _Evas_Device Evas_Device;
struct _Evas_Device {
int version; /* starting version 1 */
int num; /* device number - guaranteed to always be there. the default device
is 0, but extra devices may be 1, 2, 3 etc. this is unique with the device class
so the first mouse is device 0, the 2nd is device 1. the first keyboard is
device 0, the second is device 1 etc. */
Evas_Device_Class clas; /* The class of device - EVAS_DEVICE_CLASS_MOUSE,
EVAS_DEVICE_CLASS_KEYBOARD etc. */
const char *name; /* This may not exist - or
may be synthesized. this only lets you get a better idea of the device (eg
Logitech Mouse or Microsoft Keyboard
- Natural Media etc.) */
/* NB: This structure may be extended in the future - version will indicate how
much it has extended */
};
then every event in evas that comes FROM a device add a
const Evas_Device *dev;
to the structure - this way in future we can extend the meaning of a device
without breaking event structs. (same with event feed calls)
of course we will need ways to add and delete devices from evas in general and
modify them, list them etc.
i.e.
Evas_Device *evas_device_add(void);
void evas_device_del(Evas_Device *dev);
const Evas_List *evas_device_list(void);
void evas_device_class_set(Evas_Device *dev, Evas_Device_Class clas);
void evas_device_name_set(Evas_Device *dev, const char *name);
etc.
it would be ecore_evas's job to init evas with at least basic devices (mouse,
keyboard - you can add joystick etc. to this too).
sound useful?
Cedric
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
