Re: [E-devel] Patch for Evil fopen function
On Tue, 28 Oct 2008, Lionel ORRY wrote: 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__) ) can you try this instead: # define open(path, flag, ...) _open((path), _O_BINARY | (flag), ##args) ? Vincent- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Evas: Abstract the engine calls
Jorge wrote: > Hi all, > > Here i attach a patch that wraps all the calls to > obj->layer->evas->engine.func inside the objects into a function > itself. So instead of doing evas->engine.func->image_border_set you > should call evas_engine_image_border_set. It looks like a cosmetic > patch, but is the base for a larger rewrite of Evas internals. > > As Jose has been saying (and myself) for some time now, Evas *needs* a > refactor on its internals, this is the first step in the path to allow > objects to be built outside Evas which will imply to build a good and > defined interface between objects, engines and the canvas system. > Right now the evas_engine_xxx functions are just on a private header, > later those can be as well exported and let users build their own > objects based on this accelerated primitives. > > I can commit myself this patch (the text objects are still missing > btw), but i prefer to know your impressions before. > > I've argued one side of the coin on this issue of an extensible mechanism for evas objects which can get 'close-in' for better efficiency and flexibility, and suggested a simple initial approach that can be realized now... But let me also argue another side of this coin and reply in part to your proposal here. One reason I've not mentioned this much recently (til now when I saw carsten and gustavo wanting to add new objs and their apis to evas lib proper) is that it does have its 'issues' with current evas. Basically, evas is still too immature in many ways and just not ready to 'export' much of anything - not unless you're willing to constantly keep up with possible changes of various sorts. This is why I suggested an initial approach that does require objs to be built against evas internals (much like e17 modules). I'd leave a more advanced approach which exposes some kind of (stable) abstract immediate-mode gfx api, or whatever, for later when things are well-defined enough. In other words, I'd suggest a two-tier approach for evas object extensibility, object modules say (which do require access to evas internals) and obj plugins say (which can be defined without such access). From a user's point of view though, there's no difference between these two.. one still needs to include the headers for the obj (or lib of objs) that one wants to use. Another 'issue' to keep in mind here is how well the rest of the current efl can adopt/adapt to such a new capability. It can potentially bring a wealth of stuff, but only to those libs/apps which have some ability to incorporate extensible/ pluggable/modular aspects without too much trouble. Take edje for example. There are several ways one can get it to use such evas obj extensibility.. the more direct ways would take quite a bit of work, but one can do it fairly easily if one adopts various indirect ways - eg. have a generic OBJECT part which references its own description, which in turn could either be in a separate file (possibly even using a different format than edc), or in some part of the eet itself. The descriptions would then be loaded/realized by associated edje plugins that know about the type of object being dealt with. etc, etc. In any case, I really don't know exactly what you envision here for later so I can't really say much more about your proposal.. except that I'd be concerned about exporting evas engine functions in any serious way. Maybe you could some more specific details as to what you have in mind for things here? PS. I can give you more details on what I've already suggested, even send you a version if you like, but it's really very simple as I've already described before.. it's simple largely because it demands that the object modules have access to evas internals. It'll give evas extensibility - one way of realizing object modules - but at the price of this dependence, and if the internals change enough then your object may become crap. So, it means such objs always have to keep up with the evas version and be updated, ie. much as is happening now with evas engines from my attempts to extend its gfx capabilities. Free information - Learn about Beauty School. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oLm4N6idRExqGifE53NLvrOcAwe4i3OV0CdvbkdYJloqjLj/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@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=100&url=/
> ___
> 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=100&url=/
___
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 clicked " signal ,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=100&url=/___
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=100&url=/ > >> ___ > >> 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=100&url=/ > >> > > >> > >> ___ > >> 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=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://l
[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=100&url=/___
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
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=100&url=/ ___ 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 primitive
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=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[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=100&url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
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 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 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 header file. */ +#undef HAVE_PWD_H + +/* Define if sigsetjmp is available. */ +#undef HAVE_SIGSETJMP + /* Define to 1 if you have the header file. */ #undef
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
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 clicked " signal ,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=100&url=/
___
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 mec
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 clicked " signal ,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=100&url=/
___
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 t
[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=100&url=/ ___ 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
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=100&url=/ ___ 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? _
