[E-devel] Fix selection in edje entry/evas textblock
Attached patch fixes getting selected text in an edje entry,
both an infinite loop that caused a massive alloc and getting
the right range of selected text.
Index: src/lib/canvas/evas_object_textblock.c
===
--- src/lib/canvas/evas_object_textblock.c (revision 37263)
+++ src/lib/canvas/evas_object_textblock.c (working copy)
@@ -4345,7 +4345,7 @@
if ((n == n1) (n == n2))
{
ps = n-text + cur1-pos;
- pe = ps + index - cur1-pos + 1;
+ pe = ps + index - cur1-pos;
}
else if (n == n1)
{
@@ -4355,7 +4355,7 @@
else if (n == n2)
{
ps = n-text;
- pe = ps + cur1-pos + 1;
+ pe = ps + cur2-pos + 1;
}
else
{
-
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=100url=/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/evas/src/lib: . canvas
Gustavo wrote: This code is part of our effort to unify common code into base libs, where its worth to avoid duplicating code over and over again. With that in Evas, we can now expose it in Edje and use it in Guarana and Elementary and possible any other toolkit. It uses Evas_Object's size hints infrastructure, but can be extended to have its own properties if one wish. Attached is a test case and example. You can try to hack your own fancy layout function, it's it's generic and useful to others, add it to evas as well (Like layout using a Bezier or any other path). People implementing Ecore Evas can now use layout stack and ecore_evas_object_associate() to provide the main window concept, just add your background and then your object to the evas_object_box and associate this box to the window. If you want your background to scale in both directions, just set it's aligns to -1.0 and -1.0. This is the kind of thing that I hoped evas would avoid tending to, and yet both raster and gustavo seem prone to want to get into. :( I know it's tempting to add more and more specialized layout/widgetry 'objects' to the core evas lib/api, but I think it's a big mistake for evas in the long run. It's not hard to start extending evas *and* edje to allow for custom objects, even if at first all such object modules need to access evas internals. Adding these kinds of things, whether text-grid objs, or box objs, or table objs, etc.. directly into the evas lib api is likely to become 'not a good idea'. this requires no access to internals, it's just a helper to avoid spreading this code everywhere (e_box, guarana, elementary, etk...). the point is, raster always planned to have dynamic layout options in Edje, so it's possible to specify in Edje if you want a stack, vertical or horizontal layout and in code you add the objects. To add this we need this kind of code. We could create yet another library (like split esmart into edje independent and dependent code) and add this there, make edje dependent on it, but it will be lot of work to get a simple and useful code in. Since evas already have internal libs in it, at some point we can create a libevas_utils and users can optionally link to it. That way we keep things in a common place and avoid extra overhead. Our point is to do now what others should have done already: unify stuff. Size hints, box, editable text block and these stuff should go in Evas and make it easy to share stuff and easier to use EFL. I always hear, at least from ETK, that some things were re-done in ETK just to work around some problems in Evas or Edje, I consider that wrong, these stuff should be fixed there, and that's what we're doing. Ok, let me pose this this from a different view.. let's not worry about whether or not such 'layout' or 'widgetry' or 'special-purpose' or whatever kinds of objects should be added to the evas lib *api* -- I don't think they should in some cases, but that's partly incidental here. There will be a need for such kinds of objects, and others... things like custom self-rendered objs (possibly relying on other libs and apsects that those libs allow) that are best implemented at the 'evas level' for efficiency reasons and whatnot. It's just a matter of where their implementation should be, how to realize them.. and how to expose their apis. So, let's discuss the underlying issue that I think is what should be addressed here - namely, that of evas' extensibility at least as far as object types goes. Would one want things like object modules, or libs of them, for giving evas that kind of of flexibility and extensibility at a low enough level? Well, one could certainly obtain the kinds of objs you want here, quite trivially really, and have them implemented by some lib.. even by edje itself say. And you could have things like a 'cairo' or an 'svg' object (which for certain engines could be done more 'directly' then via having these render to an argb buffer), and you could have say an 'ogre3d' object, or maybe a 'gstreamer' obj, or a video obj, or many, many things... and not have to worry about these being 'added' to the evas lib's api, or imposing a hard dependence on them by evas.. and yet, they can be implemented at the 'evas' level (possibly having them need access to evas internals at first, as I quickly outlined in an erlier email, and maybe further refined into a more abstract mechanism later if desired). So, as a question: Would this kind of extensibility for evas be something desired? What concrete things could you do with this? Is it a 'better' way to 'add' special/custom objs to evas then always worrying about whether or not to extend the evas lib's api with this or that 'one' useful obj? Click for online loan, fast no lender fee, approval today
Re: [E-devel] E SVN: barbieri IN trunk/evas/src/lib: . canvas
I wrote: Ok, let me pose this this from a different view.. let's not worry about whether or not such 'layout' or 'widgetry' or 'special-purpose' or whatever kinds of objects should be added to the evas lib *api* -- I don't think they should in some cases, but that's partly incidental here. There will be a need for such kinds of objects, and others... things like custom self-rendered objs (possibly relying on other libs and apsects that those libs allow) that are best implemented at the 'evas level' for efficiency reasons and whatnot. It's just a matter of where their implementation should be, how to realize them.. and how to expose their apis. So, let's discuss the underlying issue that I think is what should be addressed here - namely, that of evas' extensibility at least as far as object types goes. Would one want things like object modules, or libs of them, for giving evas that kind of of flexibility and extensibility at a low enough level? Well, one could certainly obtain the kinds of objs you want here, quite trivially really, and have them implemented by some lib.. even by edje itself say. And you could have things like a 'cairo' or an 'svg' object (which for certain engines could be done more 'directly' then via having these render to an argb buffer), and you could have say an 'ogre3d' object, or maybe a 'gstreamer' obj, or a video obj, or many, many things... and not have to worry about these being 'added' to the evas lib's api, or imposing a hard dependence on them by evas.. and yet, they can be implemented at the 'evas' level (possibly having them need access to evas internals at first, as I quickly outlined in an erlier email, and maybe further refined into a more abstract mechanism later if desired). So, as a question: Would this kind of extensibility for evas be something desired? What concrete things could you do with this? Is it a 'better' way to 'add' special/custom objs to evas then always worrying about whether or not to extend the evas lib's api with this or that 'one' useful obj? Just to throw in a couple of other interesting aspects that one may want to ponder on this stuff... Given such an 'object modules' extension mechanism for evas, how would one go about extending something like edje/edc to allow for using some given set of such object modules (ie. how to make edje/edc aware of and represent any given custom object types - beyond simple swallowing of external objs that is). Once one has that, it could possible to have things like edje_editor have a plugin system that would allow for people to extend it to allow for building edjes which take advantage of some given set of object modules. Click here to find the right business program for you and take your career to the next level. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l7gNDxaZWwC1nLTZIjec1l0ZxYEzvoVXqTacJE7hHc7q6PO/ - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] EFL xembed implementation
Hey guys, Is it possible to create an Xembed implementation in EFL? Would ecore hide some of the nasty X code in the process? Where should one start? My purpose is to embed Flash Player 10 into and E application. -- Veli Ogla Sungutay http://gui-rd.org - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/evas/src/lib: . canvas
On Tue, Oct 28, 2008 at 6:05 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Gustavo wrote: This code is part of our effort to unify common code into base libs, where its worth to avoid duplicating code over and over again. With that in Evas, we can now expose it in Edje and use it in Guarana and Elementary and possible any other toolkit. It uses Evas_Object's size hints infrastructure, but can be extended to have its own properties if one wish. Attached is a test case and example. You can try to hack your own fancy layout function, it's it's generic and useful to others, add it to evas as well (Like layout using a Bezier or any other path). People implementing Ecore Evas can now use layout stack and ecore_evas_object_associate() to provide the main window concept, just add your background and then your object to the evas_object_box and associate this box to the window. If you want your background to scale in both directions, just set it's aligns to -1.0 and -1.0. This is the kind of thing that I hoped evas would avoid tending to, and yet both raster and gustavo seem prone to want to get into. :( I know it's tempting to add more and more specialized layout/widgetry 'objects' to the core evas lib/api, but I think it's a big mistake for evas in the long run. It's not hard to start extending evas *and* edje to allow for custom objects, even if at first all such object modules need to access evas internals. Adding these kinds of things, whether text-grid objs, or box objs, or table objs, etc.. directly into the evas lib api is likely to become 'not a good idea'. this requires no access to internals, it's just a helper to avoid spreading this code everywhere (e_box, guarana, elementary, etk...). the point is, raster always planned to have dynamic layout options in Edje, so it's possible to specify in Edje if you want a stack, vertical or horizontal layout and in code you add the objects. To add this we need this kind of code. We could create yet another library (like split esmart into edje independent and dependent code) and add this there, make edje dependent on it, but it will be lot of work to get a simple and useful code in. Since evas already have internal libs in it, at some point we can create a libevas_utils and users can optionally link to it. That way we keep things in a common place and avoid extra overhead. Our point is to do now what others should have done already: unify stuff. Size hints, box, editable text block and these stuff should go in Evas and make it easy to share stuff and easier to use EFL. I always hear, at least from ETK, that some things were re-done in ETK just to work around some problems in Evas or Edje, I consider that wrong, these stuff should be fixed there, and that's what we're doing. Ok, let me pose this this from a different view.. let's not worry about whether or not such 'layout' or 'widgetry' or 'special-purpose' or whatever kinds of objects should be added to the evas lib *api* -- I don't think they should in some cases, but that's partly incidental here. There will be a need for such kinds of objects, and others... things like custom self-rendered objs (possibly relying on other libs and apsects that those libs allow) that are best implemented at the 'evas level' for efficiency reasons and whatnot. It's just a matter of where their implementation should be, how to realize them.. and how to expose their apis. So, let's discuss the underlying issue that I think is what should be addressed here - namely, that of evas' extensibility at least as far as object types goes. Would one want things like object modules, or libs of them, for giving evas that kind of of flexibility and extensibility at a low enough level? Well, one could certainly obtain the kinds of objs you want here, quite trivially really, and have them implemented by some lib.. even by edje itself say. And you could have things like a 'cairo' or an 'svg' object (which for certain engines could be done more 'directly' then via having these render to an argb buffer), and you could have say an 'ogre3d' object, or maybe a 'gstreamer' obj, or a video obj, or many, many things... and not have to worry about these being 'added' to the evas lib's api, or imposing a hard dependence on them by evas.. and yet, they can be implemented at the 'evas' level (possibly having them need access to evas internals at first, as I quickly outlined in an erlier email, and maybe further refined into a more abstract mechanism later if desired). So, as a question: Would this kind of extensibility for evas be something desired? of course yes What concrete things could you do with this? with your approach, that you're trying to push for some time now, you can do anything you want, so lots of stuff. Is it a 'better' way to 'add' special/custom objs to evas then always worrying about whether or not to extend the
Re: [E-devel] can't focus on swallowed part (Gustavo Sverzut Barbieri) (Gustavo Sverzut Barbieri)
hi, I just want to when I clicked the swallowed part It can handle the event according to the special icon part. a simple code : self.restaurant_icon=edje.Edje(self.ee.evas, file=self.edje_file, group=restaurant_menu) self.restaurant.part_swallow(contents,self.restaurant_icon) self.main_group.part_swallow(sub_menu_contents,self.restaurant) #self.main_group.member_add(self.restaurant) (this line code not work well ) self.restaurant.signal_emit(transition,in,source) self.main_group.part_object_get(sub_menu_contents).focus =True self.main_group.focus =False self.main_group.show() so when I clicked the restaurant icon , I can get the sub_menu_contents clicked signal , then I can SIGNAL_EMIT the xx restaurant icon clickedsignal ,but I don't know how to recognize which icon is clicked , I want to try the mouse_grab : self.restaurant.mouse_grab_set( ) but It can't work thanks! I fail to understand what you have and what you're trying to do. Just attach a simple edje and a simple code so I can fix and send the patch to you. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/evas/src/lib: . canvas
Gustavo wrote: On Tue, Oct 28, 2008 at 6:05 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Gustavo wrote: This code is part of our effort to unify common code into base libs, where its worth to avoid duplicating code over and over again. With that in Evas, we can now expose it in Edje and use it in Guarana and Elementary and possible any other toolkit. It uses Evas_Object's size hints infrastructure, but can be extended to have its own properties if one wish. Attached is a test case and example. You can try to hack your own fancy layout function, it's it's generic and useful to others, add it to evas as well (Like layout using a Bezier or any other path). People implementing Ecore Evas can now use layout stack and ecore_evas_object_associate() to provide the main window concept, just add your background and then your object to the evas_object_box and associate this box to the window. If you want your background to scale in both directions, just set it's aligns to -1.0 and -1.0. This is the kind of thing that I hoped evas would avoid tending to, and yet both raster and gustavo seem prone to want to get into. :( I know it's tempting to add more and more specialized layout/widgetry 'objects' to the core evas lib/api, but I think it's a big mistake for evas in the long run. It's not hard to start extending evas *and* edje to allow for custom objects, even if at first all such object modules need to access evas internals. Adding these kinds of things, whether text-grid objs, or box objs, or table objs, etc.. directly into the evas lib api is likely to become 'not a good idea'. this requires no access to internals, it's just a helper to avoid spreading this code everywhere (e_box, guarana, elementary, etk...). the point is, raster always planned to have dynamic layout options in Edje, so it's possible to specify in Edje if you want a stack, vertical or horizontal layout and in code you add the objects. To add this we need this kind of code. We could create yet another library (like split esmart into edje independent and dependent code) and add this there, make edje dependent on it, but it will be lot of work to get a simple and useful code in. Since evas already have internal libs in it, at some point we can create a libevas_utils and users can optionally link to it. That way we keep things in a common place and avoid extra overhead. Our point is to do now what others should have done already: unify stuff. Size hints, box, editable text block and these stuff should go in Evas and make it easy to share stuff and easier to use EFL. I always hear, at least from ETK, that some things were re-done in ETK just to work around some problems in Evas or Edje, I consider that wrong, these stuff should be fixed there, and that's what we're doing. Ok, let me pose this this from a different view.. let's not worry about whether or not such 'layout' or 'widgetry' or 'special-purpose' or whatever kinds of objects should be added to the evas lib *api* -- I don't think they should in some cases, but that's partly incidental here. There will be a need for such kinds of objects, and others... things like custom self-rendered objs (possibly relying on other libs and apsects that those libs allow) that are best implemented at the 'evas level' for efficiency reasons and whatnot. It's just a matter of where their implementation should be, how to realize them.. and how to expose their apis. So, let's discuss the underlying issue that I think is what should be addressed here - namely, that of evas' extensibility at least as far as object types goes. Would one want things like object modules, or libs of them, for giving evas that kind of of flexibility and extensibility at a low enough level? Well, one could certainly obtain the kinds of objs you want here, quite trivially really, and have them implemented by some lib.. even by edje itself say. And you could have things like a 'cairo' or an 'svg' object (which for certain engines could be done more 'directly' then via having these render to an argb buffer), and you could have say an 'ogre3d' object, or maybe a 'gstreamer' obj, or a video obj, or many, many things... and not have to worry about these being 'added' to the evas lib's api, or imposing a hard dependence on them by evas.. and yet, they can be implemented at the 'evas' level (possibly having them need access to evas internals at first, as I quickly outlined in an erlier email, and maybe further refined into a more abstract mechanism later if desired). So, as a question: Would this kind of extensibility for evas be something desired? of course yes What concrete things could you do with this? with your approach, that you're trying to push for some time now, you can do anything you want, so lots of stuff. I haven't been trying to 'push' any
Re: [E-devel] can't focus on swallowed part (Gustavo Sverzut Barbieri) (Gustavo Sverzut Barbieri)
First, try to send plain text mails, doing html/rich text is hard to use. On Tue, Oct 28, 2008 at 9:51 AM, dongmei zhou [EMAIL PROTECTED] wrote: hi, I just want to when I clicked the swallowed part It can handle the event according to the special icon part. a simple code : self.restaurant_icon=edje.Edje(self.ee.evas, file=self.edje_file, group=restaurant_menu) self.restaurant.part_swallow(contents,self.restaurant_icon) self.main_group.part_swallow(sub_menu_contents,self.restaurant) #self.main_group.member_add(self.restaurant) (this line code not work well ) This is because it's wrong. When you swallow, edje automatically member_add that object, if you member_add it to main_group it will be reparented and screw. self.restaurant.signal_emit(transition,in,source) what's this good for? self.main_group.part_object_get(sub_menu_contents).focus =True self.main_group.focus =False again, mouse actions have nothing to do with focus. focus is just for keyboard actions and you need to use event_callback_add(EVAS_CALLBACK_KEY_DOWN, ...) so when I clicked the restaurant icon , I can get the sub_menu_contents clicked signal , then I can SIGNAL_EMIT the xx restaurant icon clickedsignal ,but I don't know how to recognize which icon is clicked , I want to try the mouse_grab : without your edje it's hard to figure out what your doing wrong. Your code is also not enough, since nowhere you connect signals, so maybe you are connecting to the wrong object. Please post a working test (.py + .edc) somewhere. I'm not asking you to publish your real code, but a working example of the problem. write it as simple as possible, use rectangles to avoid sending pictures. self.restaurant.mouse_grab_set( ) but It can't work it have nothing to do with that work. It's hard to help without information, sorry. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/evas/src/lib: . canvas
On Tue, Oct 28, 2008 at 11:11 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Gustavo wrote: On Tue, Oct 28, 2008 at 6:05 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Gustavo wrote: This code is part of our effort to unify common code into base libs, where its worth to avoid duplicating code over and over again. With that in Evas, we can now expose it in Edje and use it in Guarana and Elementary and possible any other toolkit. It uses Evas_Object's size hints infrastructure, but can be extended to have its own properties if one wish. Attached is a test case and example. You can try to hack your own fancy layout function, it's it's generic and useful to others, add it to evas as well (Like layout using a Bezier or any other path). People implementing Ecore Evas can now use layout stack and ecore_evas_object_associate() to provide the main window concept, just add your background and then your object to the evas_object_box and associate this box to the window. If you want your background to scale in both directions, just set it's aligns to -1.0 and -1.0. This is the kind of thing that I hoped evas would avoid tending to, and yet both raster and gustavo seem prone to want to get into. :( I know it's tempting to add more and more specialized layout/widgetry 'objects' to the core evas lib/api, but I think it's a big mistake for evas in the long run. It's not hard to start extending evas *and* edje to allow for custom objects, even if at first all such object modules need to access evas internals. Adding these kinds of things, whether text-grid objs, or box objs, or table objs, etc.. directly into the evas lib api is likely to become 'not a good idea'. this requires no access to internals, it's just a helper to avoid spreading this code everywhere (e_box, guarana, elementary, etk...). the point is, raster always planned to have dynamic layout options in Edje, so it's possible to specify in Edje if you want a stack, vertical or horizontal layout and in code you add the objects. To add this we need this kind of code. We could create yet another library (like split esmart into edje independent and dependent code) and add this there, make edje dependent on it, but it will be lot of work to get a simple and useful code in. Since evas already have internal libs in it, at some point we can create a libevas_utils and users can optionally link to it. That way we keep things in a common place and avoid extra overhead. Our point is to do now what others should have done already: unify stuff. Size hints, box, editable text block and these stuff should go in Evas and make it easy to share stuff and easier to use EFL. I always hear, at least from ETK, that some things were re-done in ETK just to work around some problems in Evas or Edje, I consider that wrong, these stuff should be fixed there, and that's what we're doing. Ok, let me pose this this from a different view.. let's not worry about whether or not such 'layout' or 'widgetry' or 'special-purpose' or whatever kinds of objects should be added to the evas lib *api* -- I don't think they should in some cases, but that's partly incidental here. There will be a need for such kinds of objects, and others... things like custom self-rendered objs (possibly relying on other libs and apsects that those libs allow) that are best implemented at the 'evas level' for efficiency reasons and whatnot. It's just a matter of where their implementation should be, how to realize them.. and how to expose their apis. So, let's discuss the underlying issue that I think is what should be addressed here - namely, that of evas' extensibility at least as far as object types goes. Would one want things like object modules, or libs of them, for giving evas that kind of of flexibility and extensibility at a low enough level? Well, one could certainly obtain the kinds of objs you want here, quite trivially really, and have them implemented by some lib.. even by edje itself say. And you could have things like a 'cairo' or an 'svg' object (which for certain engines could be done more 'directly' then via having these render to an argb buffer), and you could have say an 'ogre3d' object, or maybe a 'gstreamer' obj, or a video obj, or many, many things... and not have to worry about these being 'added' to the evas lib's api, or imposing a hard dependence on them by evas.. and yet, they can be implemented at the 'evas' level (possibly having them need access to evas internals at first, as I quickly outlined in an erlier email, and maybe further refined into a more abstract mechanism later if desired). So, as a question: Would this kind of extensibility for evas be something desired? of course yes What concrete things could you do with this? with your approach, that you're trying to push for some time now, you can do anything you want, so lots of stuff.
Re: [E-devel] IMLIB2 ported to mingw+msys
Hello, I got the sources of your newly released Imlib2 1.4.2 and I did again the fixes for Mingw+Msys. I think I also fixed my bugs with: 1) bad mmap() detection 2) wrong use of HAVE_SIGJMP_BUF instead of HAVE_SIGSETJMP. 3) all my files are in unix format. I tested Imlib2 with: - Mingw+Msys - Cygwin - Linux Debian 4.0r3 and everything seems to be working. Attached patch includes all those fixes. Sincerely, Carlo Bramini. -- Initial Header --- From : Kim Woelders [EMAIL PROTECTED] To : Vincent Torri [EMAIL PROTECTED],carlo\.bramix [EMAIL PROTECTED] Cc : enlightenment-devel enlightenment-devel@lists.sourceforge.net Date : Thu, 16 Oct 2008 17:38:41 +0200 Subject : Re: [E-devel] IMLIB2 ported to mingw+msys On Wed, 15 Oct 2008 13:29:10 +0200, Vincent Torri [EMAIL PROTECTED] wrote: On Wed, 15 Oct 2008, carlo\.bramix wrote: Hello, I have already implemented some of the functions you need in a lib called 'Evil' (mmap, dlfcn, pwd.h, mkstemp,...). I use it for the EFL Windows (XP or Ce) port. Maybe you could look at my code, improve it if you think it's needed, and make imlib2 Windows port depending on Evil If all that's needed is included in the patch I think it's a bit much to have to depend on another (unreleased) library. Otherwise, i would say that you need to add AC_LIBTOOL_WIN32_DLL in configure.ac too so that libtool is aware that you have a Windows port. Sorry, my fault, I forgot to tell you that I also upgraded to a newer version these files: config.guess config.sub depcomp install-sh ltmain.sh missing These should all be generated when running ./autogen.sh. AC_LIBTOOL_WIN32_DLL seems deprecated and I think this could be the reason because it works fine here on my PC. It's not a problem to add it anyways. it's deprecated but the new way to do it requires a recent version of libtool (= 1.9b, more precisely). You can say that that version was released in 2004 and we are in 2008. I have absolutely no problem in using the new way to do that, but as it is Kim who uses really imlib2 in e16, I would wait for his opinion about using or not a recent version of libtool. I don't think imlib2 should depend on a libtool version 1.5.x. I also forgot to add $LT_LDFLAGS into src/modules/filters/Makefile.am (my mistake): it is not possible to create shared libs without that flag, I discovered it only when I checked the content of /lib directory after I did the make install, if I must provide a new patch with this little fix, just let me know. Yes, please. that should be the new way of doing things with libtool. Please also excuse my ignorance, but I have not found a package called EFL into download page at sourceforge... EFL means Enlightenment fundation libraries. It is a set of libraries that e17 uses (eet, evas, ...). actually I was just trying to build IMLIB2 because libcaca checked if it was available. I tried to do it in the simplest manner (especially because I'm a developer for Windows and not very expert with unix stuff) You interest me ! I am searching some help for the Windows port of the EFL, especially because I'm not a Windows developper. If you want to join the task force (and if you have time, of course), I would be glad to have someone more on that port :) Anyway, I think that this port should be done in the same way than the other EFL. Using Evil means that the Windows code it located at one place only. Less things to fix. And I would be happy if you have time to review the code in Evil :) regards Vincent Basically I'm fine with these changes. However: - We should make a 1.4.2 release of current svn before doing this. - tga support wasn't built when I tested (no configure arguments), I think the HAVE_MMAP test is wrong. - In configure.in (which has been renamed to configure.ac) you set HAVE_SIGSETJMP but in loader_jpeg.c you use HAVE_SIGJMP_BUF. - Some dos style CRLF line endings have crept in (e.g. loader_gif.c). /Kim diff -r -u imlib2-1.4.2-old/config.h.in imlib2-1.4.2-new/config.h.in --- imlib2-1.4.2-old/config.h.in2008-10-21 03:02:04 + +++ imlib2-1.4.2-new/config.h.in2008-10-27 21:03:34 + @@ -18,6 +18,18 @@ /* Define to 1 if you have the memory.h header file. */ #undef HAVE_MEMORY_H +/* Define to 1 if you have the `mkstemp' function. */ +#undef HAVE_MKSTEMP + +/* Define to 1 if you have a working `mmap' system call. */ +#undef HAVE_MMAP + +/* Define to 1 if you have the pwd.h header file. */ +#undef HAVE_PWD_H + +/* Define if sigsetjmp is available. */ +#undef HAVE_SIGSETJMP + /* Define to 1 if you have the stdint.h header file. */ #undef HAVE_STDINT_H @@ -39,6 +51,12 @@ /* Define to 1 if you have the unistd.h header file. */ #undef HAVE_UNISTD_H +/* Define to 1 if you have the windows.h header file. */ +#undef HAVE_WINDOWS_H + +/* Always
[E-devel] Patch for Evil fopen function
Hello, here is a tiny patch to make the open() function from Evil.h closer to the real posix open() function. Without the _O_BINARY flag, the opened filestream is postprocessed under Windows, which leads to unexpected carriage returns in binary files, such as in eet files for example. Thanks for reviewing and applying if possible. regards, Lionel - 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=100url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Patch for Evil fopen function
Hey, here is a tiny patch to make the open() function from Evil.h closer to the real posix open() function. Without the _O_BINARY flag, the opened filestream is postprocessed under Windows, which leads to unexpected carriage returns in binary files, such as in eet files for example. Thanks for reviewing and applying if possible. I think that SF removed the attached file. If the patch is tiny, just put it in the body of the mail, it will be sufficient thank you 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/evas/src/lib: . canvas
Gustavo wrote: Ok, let me pose this this from a different view.. let's not worry about whether or not such 'layout' or 'widgetry' or 'special-purpose' or whatever kinds of objects should be added to the evas lib *api* -- I don't think they should in some cases, but that's partly incidental here. There will be a need for such kinds of objects, and others... things like custom self-rendered objs (possibly relying on other libs and apsects that those libs allow) that are best implemented at the 'evas level' for efficiency reasons and whatnot. It's just a matter of where their implementation should be, how to realize them.. and how to expose their apis. So, let's discuss the underlying issue that I think is what should be addressed here - namely, that of evas' extensibility at least as far as object types goes. Would one want things like object modules, or libs of them, for giving evas that kind of of flexibility and extensibility at a low enough level? Well, one could certainly obtain the kinds of objs you want here, quite trivially really, and have them implemented by some lib.. even by edje itself say. And you could have things like a 'cairo' or an 'svg' object (which for certain engines could be done more 'directly' then via having these render to an argb buffer), and you could have say an 'ogre3d' object, or maybe a 'gstreamer' obj, or a video obj, or many, many things... and not have to worry about these being 'added' to the evas lib's api, or imposing a hard dependence on them by evas.. and yet, they can be implemented at the 'evas' level (possibly having them need access to evas internals at first, as I quickly outlined in an erlier email, and maybe further refined into a more abstract mechanism later if desired). So, as a question: Would this kind of extensibility for evas be something desired? of course yes What concrete things could you do with this? with your approach, that you're trying to push for some time now, you can do anything you want, so lots of stuff. I haven't been trying to 'push' any particular approach.. just pointing out a simple one that can be realized now if desired. And frankly, I'm not sure I'd bother to work it out given your attitude on it. I sure as hell don't need it for anything. Hey Jose, don't take this personally. Everybody tries to push their own point of view everywhere, it's not something bad. You were trying to push transforms that way you said, I liked the idea but thought it would never happened, you proved me wrong and showed your code. Again, I like this idea but don't see it happening, prove me wrong again! :-) I'm not trying to 'push' anything into evas.. never have. I've never even wanted cvs/svn access. I do have my views as to what I think is a 'good idea' and conversely, but I prefer to make the reasons for those views open for discussion and let people see if they want it, and leave it up to Carsten to make the choice - for evas' better or worse, that's what I've decide is best for *my* interaction with this project. You see Gustavo, if I really personally *want* something in evas or whatever else, I can just do it myself, my system - I don't need someone to do it for me.. and very rarely do I suggest stuff here that I haven't already done in some form or another. Is it a 'better' way to 'add' special/custom objs to evas then always worrying about whether or not to extend the evas lib's api with this or that 'one' useful obj? yes, seems that we all know about that. BUT, nothing done. Enesim was the way to go for that and is halted. All in all, we need manpower to provide this extensible and very optimized immediate rendering api so we can allow other things to render to Canvas, and we also need to change the rendering pipeline, because we need more hints in the case objects can render to outside their bounding box. No. This has nothing to do with enesim or any other immediate-mode rendering lib. It's about evas providing an extension mechanism of some sort - and here in particular it's about a simple mechanism that imposes no policy on the implementations. As we already have an extension mechanism called smart, I'm sure you're talking about objects that draw new primitives. If so, don't play the fool, we know that for that we need to expose somehow the drawing primitives and in that case a 'immediate rendering api. You don't *need* to expose any drawing primitives - that's a fairly advanced way that would be useful, ie. expose an abstract api, but it's not needed. You could draw via whatever methods you feel like using as best suits you and/or the object in question. For example, a cairo object would use (guess)... an svg obj could use librsvg (via cairo say), an ogre3d obj would use etc. They may or may not be supported by all
Re: [E-devel] Patch for Evil fopen function
sorry for that. Here it is: Index: src/lib/Evil.h === --- src/lib/Evil.h (révision 37267) +++ src/lib/Evil.h (copie de travail) @@ -134,7 +134,7 @@ # define S_IXGRP S_IXUSR # define S_IXOTH S_IXUSR -# define open(path,...) _open((path),__VA_ARGS__) +# define open(path,...) _open((path), _O_BINARY | (__VA_ARGS__) ) # define close(fd) _close(fd) # define read(fd,buffer,count) _read((fd),(buffer),(count)) # define write(fd,buffer,count) _write((fd),(buffer),(count)) Thanks regards, Lionel 2008/10/28 Vincent Torri [EMAIL PROTECTED]: Hey, here is a tiny patch to make the open() function from Evil.h closer to the real posix open() function. Without the _O_BINARY flag, the opened filestream is postprocessed under Windows, which leads to unexpected carriage returns in binary files, such as in eet files for example. Thanks for reviewing and applying if possible. I think that SF removed the attached file. If the patch is tiny, just put it in the body of the mail, it will be sufficient thank you 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] e_fm: fix single-click on folders
Hi,
the attached patch fixes the single-click feature of e_fm, so you can use
single-click on folders, not just on files.
It also removes the strdup in the affected functions that seems useless
here.
Would be nice if someone could check/review and commit it.
Greetings,
thomasg
Index: e_fm.c
===
--- e_fm.c (Revision 37249)
+++ e_fm.c (Arbeitskopie)
@@ -5136,18 +5136,17 @@
{
/* if its a directory open dirs in-place is set then change the dir
* to be the dir + file */
- if ((S_ISDIR(ic-info.statinfo.st_mode))
+ if (
+ (S_ISDIR(ic-info.statinfo.st_mode))
(ic-sd-config-view.open_dirs_in_place)
(!ic-sd-config-view.no_subdir_jump)
(!ic-sd-config-view.single_click)
)
{
-char buf[4096], *dev = NULL;
+char buf[4096];
-if (ic-sd-dev) dev = strdup(ic-sd-dev);
snprintf(buf, sizeof(buf), %s/%s, ic-sd-path, ic-info.file);
-e_fm2_path_set(ic-sd-obj, dev, buf);
-E_FREE(dev);
+e_fm2_path_set(ic-sd-obj, ic-sd-dev, buf);
}
else
evas_object_smart_callback_call(ic-sd-obj, selected, NULL);
@@ -5170,7 +5169,7 @@
ic-drag.dnd = 0;
ic-drag.src = 1;
}
- _e_fm2_mouse_1_handler(ic, 0, ev-modifiers);
+ _e_fm2_mouse_1_handler(ic, 0, ev-modifiers);
}
else if (ev-button == 3)
{
@@ -5195,6 +5194,24 @@
ic-drag.start = 0;
ic-drag.dnd = 0;
ic-drag.src = 0;
+
+if (
+ (S_ISDIR(ic-info.statinfo.st_mode))
+(ic-sd-config-view.open_dirs_in_place)
+(!ic-sd-config-view.no_subdir_jump)
+(ic-sd-config-view.single_click)
+)
+ {
+ char buf[4096];
+
+ snprintf(buf, sizeof(buf), %s/%s, ic-sd-path, ic-info.file);
+ e_fm2_path_set(ic-sd-obj, ic-sd-dev, buf);
+ }
+else if ((S_ISDIR(ic-info.statinfo.st_mode))
(ic-sd-config-view.single_click))
+ evas_object_smart_callback_call(ic-sd-obj, selected, NULL);
+
+
+
}
ic-down_sel = 0;
}
-
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=100url=/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
- Nick Hughart [EMAIL PROTECTED] ha scritto: This is not yet an fdo specification so I'm not going to put it in just yet. It seems to have promise and is a fairly simple format, but for now we have our own methods of choosing default applications and it is similar to how they choose as well (given the user is not making this file on their own). When opening a file in EFM, if that mimetype has not been opened previously you will be given a list of apps that support that mimetype and a list of all apps as well just in case. Once you have chosen an app, EFM remembers this and will use that app until you pick a different app by using Open With. So for now we have our own methods of doing this, but if it does become a specification it may be good to adopt this as it would help with those doing packaging and distribution. Where EFM store the user preference, is it possible to others to access this data? I think we need a centralised way to keep this information, or the user need to choose a preferred application for every apps/module that need to open a filemanager or a browser. I know this is not a standard yet. But this doesn't mean we can't have our method to storing this user preference. I have also done a module that add a configuration dialog to set your preferred apps. Its very simple, but it make no sense if there are not a shared place to store the informations. Don't you think this is a must have module?? So IMHO we need to define witch is the E way to store the mime/application associations, and have the code in some lib (maybe not efreet for now). In this way we can have all the apps/module work the same way and we can also change the lib to fit a final freedesktop standard without touching modules. If we don't do this now all the apps/modules will do the associations in a different way and when the fdo standard will become a reality we need to redo everything. Regards Dave Dave Andreoli wrote: ...and the attachment ;) the patch is to be applied in the main efreet directory. Dave - Dave Andreoli [EMAIL PROTECTED] ha scritto: Hi all This is a relly small patch that add 2 functions to Efreet_Mime. EAPI const char* efreet_mime_default_application_get(const char *mime) EAPI void efreet_mime_default_application_set(const char *mime, const char *desktop) The _get function take a mime-type (as 'text/html') and return the name of the desktop file (as 'Firefox.desktop') that should be used to open the given mime-type. The information is readed from the $XDG_DATA_DIRS/applications/defaults.list file, first the user preference file is checked than the system wide. The second one set the preference in the user defaults.list file. With this functions all the applications that use efreet can know witch is the default program to use to open a given mime-type. Hope you like it Dave - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] can't focus on swallowed part (Gustavo Sverzut Barbieri) (Gustavo Sverzut Barbieri)
hi, I post the working example , when I clicked the restaurant icon , it will entry the sub menu interface , then when I clicked all the sub menu icon (today , history , future) it will all receive the signal in sub_menu_contents part, so I can't deal with the special sub menu icon. what can do it ? 2008/10/28 Gustavo Sverzut Barbieri [EMAIL PROTECTED] First, try to send plain text mails, doing html/rich text is hard to use. On Tue, Oct 28, 2008 at 9:51 AM, dongmei zhou [EMAIL PROTECTED] wrote: hi, I just want to when I clicked the swallowed part It can handle the event according to the special icon part. a simple code : self.restaurant_icon=edje.Edje(self.ee.evas, file=self.edje_file, group=restaurant_menu) self.restaurant.part_swallow(contents,self.restaurant_icon) self.main_group.part_swallow(sub_menu_contents,self.restaurant) #self.main_group.member_add(self.restaurant) (this line code not work well ) This is because it's wrong. When you swallow, edje automatically member_add that object, if you member_add it to main_group it will be reparented and screw. self.restaurant.signal_emit(transition,in,source) what's this good for? self.main_group.part_object_get(sub_menu_contents).focus =True self.main_group.focus =False again, mouse actions have nothing to do with focus. focus is just for keyboard actions and you need to use event_callback_add(EVAS_CALLBACK_KEY_DOWN, ...) so when I clicked the restaurant icon , I can get the sub_menu_contents clicked signal , then I can SIGNAL_EMIT the xx restaurant icon clickedsignal ,but I don't know how to recognize which icon is clicked , I want to try the mouse_grab : without your edje it's hard to figure out what your doing wrong. Your code is also not enough, since nowhere you connect signals, so maybe you are connecting to the wrong object. Please post a working test (.py + .edc) somewhere. I'm not asking you to publish your real code, but a working example of the problem. write it as simple as possible, use rectangles to avoid sending pictures. self.restaurant.mouse_grab_set( ) but It can't work it have nothing to do with that work. It's hard to help without information, sorry. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/___ 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/canvas
Go Sachiel :)
dh
Enlightenment SVN wrote:
Log:
another sachiel fix! :)
Author: raster
Date: 2008-10-28 20:29:10 -0700 (Tue, 28 Oct 2008)
New Revision: 37292
Modified:
trunk/evas/src/lib/canvas/evas_object_textblock.c
Modified: trunk/evas/src/lib/canvas/evas_object_textblock.c
===
--- trunk/evas/src/lib/canvas/evas_object_textblock.c 2008-10-29 01:51:45 UTC
(rev 37291)
+++ trunk/evas/src/lib/canvas/evas_object_textblock.c 2008-10-29 03:29:10 UTC
(rev 37292)
@@ -1788,12 +1788,16 @@
if ((repch) (n-text))
{
- int i, len = strlen(n-text), chlen;
+ int i = 0, len = 0, chlen;
+ char *ptr;
+ while (evas_common_font_utf8_get_next(n-text, i))
+ len++;
chlen = strlen(repch);
str = alloca((len * chlen) + 1);
- for (i = 0; i len; i += chlen)
- strcpy((str[i]), repch);
+ for (i = 0, ptr = str; i len; ptr += chlen, i++)
+ memcpy(ptr, repch, chlen);
+ *ptr = 0;
}
else
str = n-text;
-
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=100url=/
___
enlightenment-svn mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
