Re: [E-devel] [RFC] SDL Engine
ok- started reviewing... and i'll basically cover as much as i had time to review here. 1. shared evas image cache - good idea, BUT... has problems. ... ... ... No it won't work to use his caching code, as is, for some of the other engines. But it can be made to work. One needs to Just to follow up on this a bit.. Again, one could make it work (though it would require a bit of work, some re-structuring of current stuff, etc), but the real question here is wether this would be desirable to have or not. One thing this would allow is for 'localized' image caches, eg. it would allow per-evas canvas caches if desired (and indeed his current sdl engine implementation has that), or per-'engine' (which is better, as far as memory use is concerned), etc. It would also 'simplify' the caching code a bit as it would have a generalized form, and indeed it also depends on a generalized image structure. However, in the interest of expediting a software_sdl engine, I'd suggest that maybe it would be better if that part of it were left for another time, when such an idea can be looked at in more detail. :) Cedric: It seems to me that you don't really this for your engine - you don't really need to use an sdl surface for images that are created via the canvas api.. the only time I see that you really need to hold an sdl surface in images (say in the 'extended_info' pointer as you're now doing), is for images which are obtained from the target (display) surface, and such images don't need to use any cache aspects at all. If this is true, then you can just use the current 'generic' image cache - like the other software based engines do. Of course I could be wrong about this, it just seems that way to me from looking at the engine a bit. :) 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] E17 Bindings
Carsten Haitzler [2007-04-09 08:36]: Hello, I would like to try and write some PLT-Scheme bindings to EWL and E17. Where should I start? Probably from imlib2 and then all my way to ewl and e17? I don't think I can go directly to EWL, right? well actually you don't need to do imlib2 - but start at eet, evas, ecore, embryo, edje. Only do that if you loads of free time. AFAIK Ewl apps don't need to deal with ecore/ecore_evas directly so I believe you can just start with Ewl bindings. If you later decide you would like to have Eet support, too, you can always go back and write bindings for it. e17 itself you will not be able to rite bindings for. You can write a Scheme meta module that loads other modules written in Scheme. Like I did with Ruby some years ago. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpVVFT2UsfP2.pgp Description: PGP signature - 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
On Fri, 6 Apr 2007 15:21:52 +0200 Cedric BAIL [EMAIL PROTECTED] wrote: Well for some crazy idea. I did notice that many little 2D game on Linux are using SDL, And some big ones. Unreal Tournament 2004 at least is written to use SDL for the Linux version. Dunno what they use for the Windows version. signature.asc Description: PGP signature - 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] UNSUBSCRIBE
CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** - 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
On Fri, 6 Apr 2007 15:21:52 +0200, Cedric BAIL [EMAIL PROTECTED] wrote : 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 :) I have some experience with SDL + OpenGL and there is nothing different between using OpenGL with SDL and using OpenGL with an X11 window (OpenGL-wise). The only differences are the calls that depends on the windowing system: the creation of the GL context and the swapping of the front/back buffers. But I don't think it's worth it to create an Evas engine for OpenGL+SDL. It will be exactly the same as the GL-X11 engine (i.e just a wrapper of the GL-common engine). Actually, I don't think there should be a GL-X11 engine in Evas at all. Just the GL-common engine should be enough. Then all the code to create the GL-context and to swap the buffers (that is to say, all the code that is currently in the GL-X11 engine) should be moved to Ecore_Evas imho. This way, if we'd like to use OpenGL+SDL or OpenGL+Win32, there will be no need to create a new Evas engine. We would just have to create the window, the GL-context and to use it with the GL-common engine of Evas (all of these could be done in Ecore_Evas). And it will make it possible to use Evas in your own OpenGL app which already has its own GL context: for example, you could use Evas for the GUI of an OpenGL game, which could be really cool imho :) I've already discussed this with raster and he told me the only reason to bind the GL-Context with the Evas engine is because the context is stateful and if the context were to be shared between the Evas-engine and the application code, the application could change/corrupt the context's state and it could break the Evas engine. That's a good point, but actually, there is a way to save/restore the current state of a GL-context with glPushAttrib(GL_ALL_ATTRIB_BITS)/glPopAttrib(GL_ALL_ATTRIB_BITS). It saves the current viewport, the current matrices, and all the current states. I just don't know if it is efficient and if it's available on all the GL cards. Raster, what do you think about creating a generic GL-engine for Evas (with the glPushAttrib()/glPopAttrib() thing), and to move the existing code of the GL-X11 engine (creation of the context and buffer-swapping) to Ecore_Evas_GL_X11? If this is ok, I'm willing to do it if you want. Regards, Simon TRENY MoOm Cedric - 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 - 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] E17 Bindings
On 4/9/07, Tilman Sauerbeck [EMAIL PROTECTED] wrote: Carsten Haitzler [2007-04-09 08:36]: Hello, I would like to try and write some PLT-Scheme bindings to EWL and E17. Where should I start? Probably from imlib2 and then all my way to ewl and e17? I don't think I can go directly to EWL, right? well actually you don't need to do imlib2 - but start at eet, evas, ecore, embryo, edje. Only do that if you loads of free time. Thank you, I'll remember that! :) -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK - 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] E17 Bindings
On 4/9/07, Tilman Sauerbeck [EMAIL PROTECTED] wrote: Only do that if you loads of free time. AFAIK Ewl apps don't need to deal with ecore/ecore_evas directly so I believe you can just start with Ewl bindings. If you later decide you would like to have Eet support, too, you can always go back and write bindings for it. Right. There are some ruby bindings in proto for it now that do not rely on any of the dependent libraries having bindings. - 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] E17 Bindings
On 4/9/07, Nathan Ingersoll [EMAIL PROTECTED] wrote: On 4/9/07, Tilman Sauerbeck [EMAIL PROTECTED] wrote: Only do that if you loads of free time. AFAIK Ewl apps don't need to deal with ecore/ecore_evas directly so I believe you can just start with Ewl bindings. If you later decide you would like to have Eet support, too, you can always go back and write bindings for it. Right. There are some ruby bindings in proto for it now that do not rely on any of the dependent libraries having bindings. Although I know nothing about ruby, I'll look at them to see if I can make any sense out of the code. Thank you - 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 -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK - 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] Entrance errors
On 4/9/07, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sun, 8 Apr 2007 22:38:59 +0100 Paulo J. Matos [EMAIL PROTECTED] babbled: On 4/8/07, Paulo J. Matos [EMAIL PROTECTED] wrote: Any ideas on what this might be about? Oh well, this probably is about the eet evas module as it says, what I really want to know is if I need to run anything before entrance -T? did evas build with eet support? do you have the eet loader for evas? For some reason... it didn't... :( Wierd. Recompiling... Thank you -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK - 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 (東京 日本) -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK - 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 widgets or GTK+
hi, i need to know which widgets are lighter/ more customisable, and if the e17 gui library can be used in all other projects that qt or gtk are normally used. - 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] E17 widgets or GTK+
To reply accurately to this, I think we'll need some more info about what you want to accomplish. Each toolkit has it's strengths and weaknesses. Thanks, Nathan On 4/9/07, Ahmed MANSOUR [EMAIL PROTECTED] wrote: hi, i need to know which widgets are lighter/ more customisable, and if the e17 gui library can be used in all other projects that qt or gtk are normally used. - 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 - 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] E17 widgets or GTK+
El Lunes 09 Abril 2007 17:04, Ahmed MANSOUR escribió: hi, i need to know which widgets are lighter/ more customisable, and if the e17 gui library can be used in all other projects that qt or gtk are normally used. Check out the wiki (wiki.enlightenment.org) for a performance comparison between ETK, EWL and GTK. http://wiki.enlightenment.org/index.php/EWL_Performance Among other things. - 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 - 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] E17 widgets or GTK+
To be entirely fair, this is a comparison of one particular use case. GTK and ETK may perform better under other circumstances and also provide other methods for handling lists/trees that reduce some of the overhead. This test is to see how each toolkit scales in it's memory and CPU use as the number of widgets grows. It's an exaggerated data set that provides an easy way to measure where the overhead occurs. On 4/9/07, Andres [EMAIL PROTECTED] wrote: El Lunes 09 Abril 2007 17:04, Ahmed MANSOUR escribió: hi, i need to know which widgets are lighter/ more customisable, and if the e17 gui library can be used in all other projects that qt or gtk are normally used. Check out the wiki (wiki.enlightenment.org) for a performance comparison between ETK, EWL and GTK. http://wiki.enlightenment.org/index.php/EWL_Performance Among other things. - 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 - 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 - 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 4/7/07, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote:
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?
Sounds very similar to what i did to ecore_fb a while ago, indeed very
usefull. Just one thing, instead of defining the device classes as
device types (keyboard, joystick, mouse, touchpad, touchscreen, etc)
wouldnt be better to define them as device capabilities
(absolute/relative axes, buttons/keys, etc) so a keyboard has only
capabilities of button/keys, a mouse has relative axes, a touchscreen
absolute axes, and so on ... ? In case of a special device it just
need to or the different capabilities it has.
Cedric
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
