Re: [E-devel] Shared Strings
Cedric BAIL schrieb: Putting eina now into cvs doesn't help anyone at the moment. There are two ways we can go: 1. First we start with a little lib, where we put step by step code into it, we agree with that it belongs into the common lib. That's what I tried with edt. 2. We first discuss how the common lib needs to be en bloc and in detail and then change eina to match the result of the discussion. And move it then into cvs. It looks like most people here prefer the second way. I will say we have a third option. Put a common lib in cvs now. Then slowly move stuff around to the new system. With current work from caro with Evas_Data.h we should be able to provide a set of macro that will help do the move quickly. This move should not impact performance at all (and looking at eina current code, I don't see how it could change something regarding that). With focus on evas this is right, but you would be going to make facts without discussing them before. For example in eina the evas_hash implementation is called eina_hash. I think it'd be better to reserve this name for the ecore_hash implementation, because it is much more general. For the evas_hash implementation another name like eina_strhash would imho then be better. And I'm still not convinced if there is a general need to have a fixed-point implementation in the base data types lib, just to mention my concerns. Maybe someone else, with more authority then me :), will join this discussion. I'm sure turran took care in doing eina, but you'll get more agreement if things are discussed before. Regards, Peter - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Hisham Mardam Bey schrieb: On Mon, Jul 7, 2008 at 6:45 PM, Peter Wehrfritz [EMAIL PROTECTED] wrote: I've put now the evas stringshare code into a standalone lib. I know that Nathan is working on improving ecore_hash, so that ecore_string becomes faster. We can still change the code later, since the API and ABI remains the same. I called that lib edt for enlighten data types. At this point, I'm going to point you to Jorge's edata. Stuff should go in there if anything. I actually took edata's infrastructure as a starting point. And what is that special with edata? It is more or less the same code like the ecore code, only the formating was changed and the headers are split. There is even still the ecore_list2 in, although it isn't used anywhere. Only thing that is new to it, is the array implementation. Besides that it doesn't contain what we are talking about, a string pool. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Vincent Torri schrieb: I think that Hisham wants you to put your code in edata, and not create another lib. Unfortunately, it isn't that easy. We have two (or with other counting 3 or 4) list implementations and two hash implementations. Since their API is totally different, especially for the lists, we cannot simply choose one of them and port the rest to that API without an incredibly huge amount of work. So the only way we can handle it is to have both implementations parallel in the data lib. But how are we going to name them? Maybe we name the evas_list edt_nodes or we name the ecore_list edt_slist and the ecore_dlist edt_dlist, so we can use edt_list for the evas_list. For the hashs the situation is a bit better. After Nathan has his ecore_hash improvements in. We can make the evas_hash a wrapper around it. But we still need to think about a name for it, maybe edt_strhash. Where we can really unify stuff is for ecore_list2 and evas_object_list, i think we can take there turran's eina_inlist. And edata has also an edata_array, what are we going to use evas_array or edata_array, or do we also need both? Besides that I wouldn't put ecore_tree into the new lib before it is fixed, it is currently in an unusable state. As you can see there are many open questions, that needs to be answered first. That's why raster had the idea to first put the string pool into the new lib, because - as mentioned before - the API is the same. Of course we still need to discuss what is going into that lib and how. If people prefer to discuss it yet and do the whole stuff later at once, we can do this as well, but just taking edata doesn't work. I hope that clarify things Peter - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Cedric BAIL schrieb: On Tue, Jul 8, 2008 at 10:47 AM, Peter Wehrfritz [EMAIL PROTECTED] wrote: Vincent Torri schrieb: I think that Hisham wants you to put your code in edata, and not create another lib. Unfortunately, it isn't that easy. We have two (or with other counting 3 or 4) list implementations and two hash implementations. Since their API is totally different, especially for the lists, we cannot simply choose one of them and port the rest to that API without an incredibly huge amount of work. So the only way we can handle it is to have both implementations parallel in the data lib. But how are we going to name them? Maybe we name the evas_list edt_nodes or we name the ecore_list edt_slist and the ecore_dlist edt_dlist, so we can use edt_list for the evas_list. For the hashs the situation is a bit better. After Nathan has his ecore_hash improvements in. We can make the evas_hash a wrapper around it. But we still need to think about a name for it, maybe edt_strhash. Where we can really unify stuff is for ecore_list2 and evas_object_list, i think we can take there turran's eina_inlist. And edata has also an edata_array, what are we going to use evas_array or edata_array, or do we also need both? Besides that I wouldn't put ecore_tree into the new lib before it is fixed, it is currently in an unusable state. We also have some inthash and we need hash indexed by two int for the font subsytem. Maybe, we can use there ecore_hash, but i don't know if it fits the needs. And you forgot the simple hash and list implementation of eet :-) Yes, the situation is a bit complex... Yup, i know that it is very complex :), especially if we want to unify things. As you can see there are many open questions, that needs to be answered first. That's why raster had the idea to first put the string pool into the new lib, because - as mentioned before - the API is the same. Of course we still need to discuss what is going into that lib and how. If people prefer to discuss it yet and do the whole stuff later at once, we can do this as well, but just taking edata doesn't work. But why didn't we just put eina inside the libs cvs directory (svn checkout http://efl-research.googlecode.com/svn/trunk/eina eina). And start hacking from here. We can then slowly switch evas , ecore and eet to the data type eina provide or the one we add to eina. It should be easier to start from something with code and hack than agree on what we should put in. But if you are going to do the work, I will agree and help on this project as it's something we need to do. Iirc, there are some things in eina that raster didn't want to have in the data type. I haven't looked into eina lately, but last time i did he started to use evas_list instead of ecore_list, the problem is that i don't think we can choose one of them and then port the rest to that, it isn't only a different way of API, it also results in a different code structure and some things aren't possible with the one implementation, which aren't possible with the other. So i think we have to go with boths, if we don't want to move the release date into the fare future. Using both reduce the porting to the new API to a simple sed script. I don't think, that it is much work to put things together, the code is already here, no matter if we take it from evas, ecore, edata or eina. Some lines of sed, maybe a reindent and then adding it to the Makefile.am and the header to the Edt.h (or how name it). I hope that clarify things I just don't like edt as a name, but that's really not something important :-) So as long as we have a plan to merge all data type into one lib, I will be happy. I'd prefer eina, as well :). But that would break then turran's code, if we don't take all of its code. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Jorge Luis Zapata Muga schrieb: Having a common agreement isnt easy but we should make one. Cedric ideas of providing a common API and just do some macros is useful, i agree that the structure of the code using might have to change, but either way a list API of any kind, is more or less common, you iterate over it with the next and prev and you get data, the rest is an extended API. A big effort has to be made from us to port everything on cvs to it, but one time or another this has to be done. I don't think that an unification of the list APIs is possible. And even if, we'd end up to change thousands of lines of stable code, which was tested over many years. And that without any reasonable benefit. Iirc, there are some things in eina that raster didn't want to have in the data type. I haven't looked into eina lately, but last time i did he Well, having some subsystems of eina not desirable isnt an excuse to have 5 implementations of the same ;) We have two string pools and the lib I proposed would reduce it to one implementation. If stringshare pool already has a common API between ecore an evas ones, why not put that on the current effort of a common data type? I'm not sure if I understand you correct, but that's exactly what edt was meant for. eina should be included into cvs, im ok with that, im kind of restrictive to indentation changes, but that's another matter :) In my opinion the first thing that should be done is add the svn code into cvs, then add your stringshare there and slowly port the rest, eet is a special case because it already has a release, so it should depend on another releasable code (eina) which isnt complete, so eet might have to be last one to be ported. Putting eina now into cvs doesn't help anyone at the moment. There are two ways we can go: 1. First we start with a little lib, where we put step by step code into it, we agree with that it belongs into the common lib. That's what I tried with edt. 2. We first discuss how the common lib needs to be en bloc and in detail and then change eina to match the result of the discussion. And move it then into cvs. It looks like most people here prefer the second way. I think that a good thing to do is to actually compare both API's and try (if possible) to merge them, any volunteer? for the simplest use cases of course, get a data from the list and iterate over it. I don't like the two very much, but I believe we have to keep both implementations. As I said above, I don't think it is worth the effort. And about merging them, you haven't much space for that, because eet expects a evas_list-like API. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Peter Wehrfritz schrieb: Yesterday we had a discussion on irc, if we should put abstract data types of ecore and of evas into a single standalone lib. The whole discussion came up because of the two implementations of the shared strings. And in fact if we really want to share strings efficient, we have to share them over the borders of the different libraries. Raster's idea was to first put the shared string stuff in this new library because both implementation have the same api (of course the names are different) and the same functionality. Remains the question which implementation we use. I've put now the evas stringshare code into a standalone lib. I know that Nathan is working on improving ecore_hash, so that ecore_string becomes faster. We can still change the code later, since the API and ABI remains the same. I called that lib edt for enlighten data types. If you prefer another name I can change it easily. It isn't much work at that point. I also can change the function names they are now: edt_stringshare_init edt_stringshare_shutdown edt_stringshare_add edt_stringshare_del If you like it, i can commit it. Next step would be to make ecore and evas depend on edt. And make their functions to be only wrappers around edt's one. And then we can replace step by step the names in the libs and apps. You can find the lib here: www.mowem.de/e/edt.tar.gz Kind Regards Peter - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore ravenlock
Enlightenment CVS schrieb: === RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore_con/ecore_con_url.c,v retrieving revision 1.23 retrieving revision 1.24 diff -u -3 -r1.23 -r1.24 --- ecore_con_url.c 20 Jun 2008 07:48:33 - 1.23 +++ ecore_con_url.c 27 Jun 2008 16:00:55 - 1.24 @@ -545,11 +545,15 @@ } #else return 0; + /* +* DEAD CODE? +* url_con = NULL; filename = NULL; user = NULL; pass = NULL; upload_dir = NULL; +*/ #endif } That's to avoid compile warnings about unused parameters, when you compile with -Wextra. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/elitaire kaethorn
Enlightenment CVS schrieb: Enlightenment CVS committal Author : kaethorn Project : e17 Module : apps/elitaire Dir : e17/apps/elitaire/debian Modified Files: control Log Message: correct Debian dependencies. === RCS file: /cvs/e/e17/apps/elitaire/debian/control,v retrieving revision 1.2 retrieving revision 1.3 diff -u -3 -r1.2 -r1.3 --- control 29 May 2008 08:36:53 - 1.2 +++ control 30 May 2008 09:16:25 - 1.3 @@ -2,7 +2,7 @@ Section: games Priority: optional Maintainer: Falko Schmidt [EMAIL PROTECTED] -Build-Depends: cdbs, debhelper (= 6), libewl-dev, libedje-dev, libefreet-dev, libimlib-dev +Build-Depends: cdbs, debhelper (= 6), libewl-dev, libedje-dev, libefreet-dev, libesmart-dev I don't know how you came to this list, but you don't need efreet to build elitaire. It is an indirect dep, because you need it for ewl. Therefor you need ecore to build it. Here a list of libs you need to build it: eet, evas, ecore, ecore-config, ecore-evas, ecore-file, edje, esmart_container, esmart_draggies, esmart_resize, ewl Regards Peter - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/edje raster
Enlightenment CVS schrieb:
Enlightenment CVS committal
Author : raster
Project : e17
Module : libs/edje
Dir : e17/libs/edje/src/lib
Modified Files:
edje_script_only.c
Log Message:
doing some work on a test script object and actually making it work.
===
RCS file: /cvs/e/e17/libs/edje/src/lib/edje_script_only.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- edje_script_only.c30 May 2008 11:20:49 - 1.1
+++ edje_script_only.c30 May 2008 15:29:39 - 1.2
@@ -92,29 +92,58 @@
#define IFNJ(type) if (!si-job.type)
#define EXPF(func) embryo_program_native_call_add(ed-collection-script,
#func, _exp_##func)
-/* FIXME: need an oid - ptr translation here. this is a hack. id # is
linear\
- * and runs out after 2billion uses or so. the hash is fat if all u have is
- * a few objects... doesn't know how to do anything but evas_object as it
- * will evas_object_del at the end... so for now this is a testing stub. */
+typedef struct _Oid Oid;
+
+struct _Oid
+{
+ Edje *ed;
+ Evas_Object *obj;
+ Evas_Coord x, y, w, h;
+ int oid;
+};
+
+/* FIXME: using evas_hash and strings is just nasty! make a custom int hash
*/
Since edje depends on ecore, can't you then use ecore_hash instead?
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] name for a postscript lib
Vincent Torri schrieb: Hey, I've written a small rendering lib that is based on libspectre, this latter being based on ghostscript. For the name, I've thought about eps (it's already an extension), egs (E ghostscript), epscript, epostcript. But I've also found 'ectoplasm', which is related to ghost or spectre. Since you already have epdf and edvi, eps would be consequent. Sure it is already an extension and might be used by other libs. So egs is maybe better. But since you chose purely technical names for the other libs (epdf and edvi) I'd do the same for the 3rd lib, too. Peter - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Missing mouse up event, when opening a pointer grabbing window
Carsten Haitzler (The Rasterman) schrieb: On Fri, 25 Apr 2008 20:26:37 +0200 Peter Wehrfritz [EMAIL PROTECTED] babbled: it should work now in cvs :) Yup, it works for me, too. Thanks :) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Carsten Haitzler (The Rasterman) schrieb: after. i've run the tests myself now. i'll add some stats. e17 maintains about 3000-4000 unique strings in evas_stringshare. in my tests. i also checked on number of adds, dels and lookups in evas_stringshare usage. about 6.48% of calls are for adds of a unique string. 5.12% are for deletes of a string. 88.41% are accesses (an add or a del of an existing string where the operation does not free or allocate any memory but just refcounts up or down). now based on this, the existing stringshare vs. string_instance means, that if you account for the relative usage of add, del and access paths, string_instance gets overall faster once you have about 3200 or so strings. so e17 is about at the cusp point. it's also one of the heavier users i imagine. i simply changed hash bucket size to be 1024 items instead of 256 and that makes the crossover point at about 7200 strings items - well beyond normal usage of e17 anyway. adds and delets are still significantly faster (string instance takes 1.8 and 1.4 times the time respectively compared to stringshare) even at 10,000 strings. with the 1024 buckets for stringshare of course. but string_instance takes 0.8 times the time for lookups. overall it's a close race. i'll try improve stringshare a little and see what i get, but beyond making it have dynamic bucket sizes (like ecore_hash) it isn't likely to go far. a dynamic bucket size will mean it will scale very high (question: do we need it to go that high?) but the idea of having to re-do the bucket array at certain points is a little uncomfortable (so u go from 3000 to 3001 and the system has to spend extra cycles re-packing all hash items in a new bucket set thats bigger). yes - this is nicer in terms of base mem usage of course. so the thing here is to figure out how to get the best thing we can for the least cost. i do know stringshare has a 1 alloc per unique string overhead. thats about as small as it gets (also either 8 or 12 bytes (32 or 64bit) per unique string for refcount and pointer). The (only) one alloc is most probably the reason why has better results for adds and removes then the ecore counter-parts. It's probably possible somehow to improve the situation for ecore_hash, but it'd make the code more of ecore_hash to alloc only one piece of memory per item. I think it isn't worth it, because i don't see a general usage for such a feature. now... more interestingly - i now started looking at the test. it is very artificial. Yes, i know. I start to read the two implementations and saw the difference. And i wondered if how they affect the performance. How much is the overhead of the two allocations? Where will evas start to suck, because of the static bucket count. So i've written the test case to get a feeling for it. I know it is artificial, but I think it is still interesting, even if it doesn't represent a normal usage. at most 2 copies of a string, so n repeated adds, and all short strings. not very representative of common usage. in common usage i have seen some strings with refcounts of 200. in fact the del wont work with stringshare. on del u need to supply the actual string pointer - not the snprintf'd buffer. so nothing gets found and deleted. ie its meant to work with: char *s; s = evas_stringshare_add(string); ... evas_stringshare_del(s); ie - the same return from stringshare. evas_stringshare_del(string) will not work. ... so as such you need a test that is more representative of actual usage. so that's just what i did. i literally logged all stringshare add's, dels etc. in such a way it'd produce correct code from a session of e17 i fiddled with for about 5 minutes doing stuff. you'll forgive me for not including the code as the .c file generated is 11m (239,000 lines of c) that i included into the compare.c infra to test both ecore and evas code and just time it doing exactly what e does. i also included nops where functions are called, but do nothing so we can remove the simple test harness and function call overhead and compare just core. as it was a little too fast i make it run 1000 loops of what e actually does one after the other (yes it'll be bad as it doesn't start with a clean slate but better than nothing). result for 1000 iterations one after the other: evas: 20.691495 ecore: 30.510302 nops: 3.444793 real factor: 1.57 so really 20.69 - 3.44 vs 30.51 - 3.44 - i.e 17.25 vs 27.07 (evas being the lower). yes - this means a lot of things will get high refcounts as things get re-added a lot and then not removed, so the raw results of only 1 iteration: evas: 0.031672 ecore: 0.045482 nops: 0.004831 real factor: 1.51 not as accurate as the times are so small, but the same order of magnitude as above. so as such... if we are doing benchmarks to know which implementation to use to find the one with best results - at least for the
Re: [E-devel] Shared Strings
Nathan Ingersoll schrieb: Were these numbers from ecore before or after cedric's changes this morning? I updated ecore_data just before. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Shared Strings
Yesterday we had a discussion on irc, if we should put abstract data types of ecore and of evas into a single standalone lib. The whole discussion came up because of the two implementations of the shared strings. And in fact if we really want to share strings efficient, we have to share them over the borders of the different libraries. Raster's idea was to first put the shared string stuff in this new library because both implementation have the same api (of course the names are different) and the same functionality. Remains the question which implementation we use. Therefor I've written a small test application, to measure the time it takes to create new strings, access new strings and to delete them. You can find the program here: mowem.de/ecore/compare.c And here a here the plot of the result mowem.de/ecore/result_direct.ps In short words, since evas uses a static bucket count it has a very good performance for few strings, for many ecore has a good access time, but still pays the price for the reordering of the increased or decreased bucket count. Peter - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] patch: Evas fill policies
andres schrieb: Hello, in order to implement the layout objects for my SoC project I need to know if it would be possible to add size hints to Evas Objects. I attached a patch file with the required changes. I tried following the implementation of size hints since its a similar concept but I can't compile the code. I don't think I it is a good idea to put fill policies into evas. Unlike to the various size hints, a fill policy is not an intrinsic property of an evas_object. If you put the fill policy into evas, your next wish is probably to add alignment hints, maybe padding, etc. And at the end you turned evas from a canvas lib into a widget set. BTW, you are missing some combinations of fill policies in your enumeration. Peter - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] patch: Evas fill policies
Gustavo Sverzut Barbieri schrieb: Just to make clear: what goes into Evas_Object is the hints. They could be represented as allocated structs managed with evas_object_data_*(), but since they're so common we could 1) make it more standard, helping integration and I don't see where they are so common. Sure every widget set use this or a similar concept for fill policies, but for widgets and not for evas objects. 2) minor optimizations by not walking the linked list doing strcmp() in order to find these values. You can use a hash or a tree instead. The integration idea came out after the layout stuff appeared and it would duplicate lots of stuff into edje, thus having this would help. What I have read is that raster wants this layout stuff anyway in edje, so you can reuse it there. All this layout stuff will not go inside evas, but some other library, either a new one or esmart. Right and that is the weak point of the whole thing. Why putting all the getters and setters into evas, if evas has no concept to deal with the values? If you need the callback infrastructure you can probably extend evas_object to support custom callbacks. And as you said you can already attach data to evas_objects. Also, layout is not widgets, but they can be used to provide widgets. They're regular smart objects that will be provided to avoid code duplication and help integration. Also, by making it like that and using standard properties (size hints) we can expose it from Edje without much trouble. The big picture is to have this and enable toolkit integration one day, like be able to mix in the same vertical list a rectangle, an etk button and a ewl list, this would be really easy since these (in THEORY!) should expose Evas_Object with all the properties set. You can already mix them if you want this. Just put your widget(s) into an ewl_embed or in an etk_embed (or however the etk counter-part is called) and put them into a esmart_container. In general, i think, you make the assumption that a widget is an evas (smart) object plus some other values that are needed to manage them. But this is not true, at least for ewl. An ewl widget that is off-screen or hidden will not have an evas object at all. So even if we would want to, we cannot re-use this flags. Peter - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] patch: Evas fill policies
Gustavo Sverzut Barbieri schrieb: On Fri, May 2, 2008 at 11:23 AM, Peter Wehrfritz [EMAIL PROTECTED] wrote: You can use a hash or a tree instead. sure, but then you waste almost a kb on the bucket allocation. it's a trade off, no free lunch. (btw, yes, evas speed up this by keeping the hot elements at the beginning) A tree shouldn't add much over head. All this layout stuff will not go inside evas, but some other library, either a new one or esmart. Right and that is the weak point of the whole thing. Why putting all the getters and setters into evas, if evas has no concept to deal with the values? If you need the callback infrastructure you can probably extend evas_object to support custom callbacks. And as you said you can already attach data to evas_objects. the point is a common interface to set these hints so others can interact the same way. imagine one day ewl and etk supports that, you can use the layout machinery to place elements from both tk without trouble. or you can mix them if needed. Again, a widget is not an evas_object. And a evas_object shouldn't become a widget. the whole point is: this should be in Evas (or official E libs) way before, if both hints and layouts were there before these libs would be already using it, maybe built with that in mind, making it easier to integrate. Also, layout is not widgets, but they can be used to provide widgets. They're regular smart objects that will be provided to avoid code duplication and help integration. Also, by making it like that and using standard properties (size hints) we can expose it from Edje without much trouble. The big picture is to have this and enable toolkit integration one day, like be able to mix in the same vertical list a rectangle, an etk button and a ewl list, this would be really easy since these (in THEORY!) should expose Evas_Object with all the properties set. You can already mix them if you want this. Just put your widget(s) into an ewl_embed or in an etk_embed (or however the etk counter-part is called) and put them into a esmart_container. why this requirement? given the way evas and edje work, this should be transparent at least. Also, by having ewl_embeded or etk_embeded, how did you get the hints communicated? you don't. Because a widget is not a top level widget in general. In general, i think, you make the assumption that a widget is an evas (smart) object plus some other values that are needed to manage them. But this is not true, at least for ewl. An ewl widget that is off-screen or hidden will not have an evas object at all. that's ewl design, you have to live with that, not me. You can be sure, I'm living good with that. But you want to tell me that ewl would use evas fill flags if they would already exist. And I can only say, it wouldn't. So even if we would want to, we cannot re-use this flags. You can, for example, copy ewl hints/policies to evas_object when you return it from ewl_embeded, you can check these properties on evas_object and copy them to ewl when you add some object to canvas. You'd not use _JUST_ that, but you can benefit from that. Yes, I have no problems with the size hints, they are a good thing and I'm sure ewl will set them for the embed smart object in future. But I don't see the point to have the fill flags set by ewl. The user has to set them anyway. So it makes no different if he set them with ewl_object_fill_policy_set(w, EWL_FLAG_FILL_FILL); or with esmart_object_fill_policy_set(embed, ESMART_FILL_FILL); - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Missing mouse up event, when opening a pointer grabbing window
When you open a pointer grabbing window during the evas mouse down
callback, evas doesn't get the mouse up event feeded and turns to be
unusable, because every mouse actions are blocked because the evas
believes that the mouse is still dragged.
If found a work-around for it, but it would be nice to fix it in evas or
ecore_evas.
Attached you find a program that shows this behavior.
Start it.
Click on the white area, nothing is printed because there is no callback
registered for it.
Right click on the red rectangle, a green window will be opened in the
left top corner.
Click on it to close it.
Click on the white area, and a message is printed from the callback of
the red rectangle.
I hope there is a way to fix that in general.
Peter
/* vim: set sw=8 ts=8 sts=8 noexpandtab: */
#include Evas.h
#include Ecore.h
#include Ecore_X.h
#include Ecore_Evas.h
#include stdio.h
Evas_Object *bg;
static void
destroy_main_window(Ecore_Evas *ee)
{
ecore_main_loop_quit();
}
static void
destroy_second_window(void * data, Evas * e, Evas_Object * obj,
void * event_info)
{
Ecore_Evas *ee = data;
ecore_evas_free(ee);
}
static void
resize_window(Ecore_Evas *ee)
{
Evas_Coord w, h;
ecore_evas_geometry_get(ee, NULL, NULL, w, h);
evas_object_resize(bg, w, h);
}
static void
open_window(void * data, Evas * e, Evas_Object * obj, void * event_info)
{
Evas_Event_Mouse_Down * ev;
Ecore_Evas *ee;
Evas *evas;
Evas_Object *o;
ev = (Evas_Event_Mouse_Down *) event_info;
printf(mouse down: %d\n, ev-button);
if (ev-button != 3)
return;
/*
* setup ecore evas
*/
ee = ecore_evas_software_x11_new(NULL, 0, 0, 0, 100, 20);
ecore_evas_override_set(ee, 1);
ecore_evas_title_set(ee, Second);
ecore_evas_raise(ee);
ecore_evas_show(ee);
ecore_x_pointer_grab(ecore_evas_software_x11_window_get(ee));
evas = ecore_evas_get(ee);
o = evas_object_rectangle_add(evas);
evas_object_move(o, 0, 0);
evas_object_resize(o, 300, 300);
evas_object_color_set(o, 0, 255, 0, 255);
evas_object_show(o);
evas_object_event_callback_add(o, EVAS_CALLBACK_MOUSE_DOWN,
destroy_second_window, ee);
//evas_event_feed_mouse_up(e, ev-button, 0, ev-timestamp, NULL);
}
int
main(int argc, char **argv)
{
Evas_Object *rect;
Ecore_Evas *ee;
Evas *evas;
/*
* initialize
*/
evas_init();
ecore_evas_init();
/*
* setup ecore evas
*/
ee = ecore_evas_software_x11_new(NULL, 0, 0, 0, 300, 300);
ecore_evas_title_set(ee, Test Case);
ecore_evas_callback_delete_request_set(ee, destroy_main_window);
ecore_evas_callback_resize_set(ee, resize_window);
ecore_evas_size_min_set(ee, 300, 300);
ecore_evas_show(ee);
evas = ecore_evas_get(ee);
/* the background */
bg = evas_object_rectangle_add(evas);
evas_object_move(bg, 0, 0);
evas_object_resize(bg, 300, 300);
evas_object_show(bg);
/* the rectangle */
rect = evas_object_rectangle_add(evas);
evas_object_color_set(rect, 255, 0, 0, 255);
evas_object_move(rect, 100, 100);
evas_object_resize(rect, 100, 100);
evas_object_show(rect);
evas_object_event_callback_add(rect, EVAS_CALLBACK_MOUSE_DOWN,
open_window, NULL);
ecore_main_loop_begin();
return 0;
}
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] updated: three new edje embryo functions
Gustavo Sverzut Barbieri schrieb:
Maybe it will not impact things. The problem with these calls is that
they would collide with Edje internal states, getting these
inconsistent. But since Edje does not handle any layer/stack-related
information in their states, maybe this is no problem, in this case
just add the call to edje C api (edje_object_part_{raise,lower}()) and
expose it from embryo.
I don't think it is a good idea to have those functions in the edje c
api. The application should change directly the theme. That's why there
isn't a edje_object_part_state_set() function.
Peter
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EWL theming
[EMAIL PROTECTED] schrieb: Just adding a +1 to this. I have had similar difficulties theming Gtk+ in the past. I admire the old Athena (Xaw) and Motif widget sets because they grant the 'themer' the ability to pick out a widget based on it's parents names and classes as well as it's own. It was somewhat possible to do this with Gtk+ 1.x, but it was a very obscure technique that never quite worked perfectly and failed completely in some apps. What you describe here is already possible in ewl. An icon (actually the icon widget theme i.e. the background) can look different if it is in a toolbar or in a filepicker. Since the themes are more then simple pics, it is not possible to tell a children or a deeper offsprings that the parent state has changed. For example a menu item turns from white into black after a mouse,in then the label and other elements may want to know about that, so they can turn their color in to white, therefor they are still readable. Peter - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] EWL theming
We had already some discussion in the bugtracker (bug #381) about this issue, but I want to give it a wider audience. To give you a short overview about the discussion, here the it is in a nutshell. It started with the question, if the checkbutton needs to be be split into several widget (as it is now: a container that holds the checkbox and the label) or if it wouldn't be better to have it in a single widget. The main reason for this question is/was that if the state of the parent container (the checkbutton) will change, for example a mouse,in event or a focus,in, there is no way to change the label or the checkbox. Although putting it in a single widget would solve this, and we might/will go that way, it showed a more basically problem, that needs another - more general - solution. To describe the problem more general, if the parent or grandfather or even higher ancestor will change it look it might to want that some offsprings will look different, too. For example this is solved in e menu that the label get a signal e,state,selected when the parent is selected. Although this solution works fine for this case, imagine a tree where a row is selected (or highlight, why ever) and any label that has this widget as parent needs to adjust it fg color to be readable, no matter how many ancestors are between it and the row itself, makes it much more complicated. And when you concern that any theme action might do that, like mouse,in/out, focus,in/out, disable/enable or even random changes or parent related signals like to have a lighter or no background, it becomes a very difficult job. So here comes my idea, how this could be solved. Any theme part (actually any edje group) can send a signal to its children. Maybe with the source set to this, or some general string. And ewl will pipe them into the offspring widget theme objects. To reduce some of the upcoming noise, the theme groups could define if they want to receive/emit signals, if they want to pipe them directly to their children or if they want to stop those signals because they have solid bg, so they aren't affected to those changes. Pros: - theme groups can control the look of the offspring widget - it is very general solution because the theme isn't constricted to the signal the library (here ewl) is aware of Cons: - we need to have a way to distinguish between transient signals and states, because a new created or a revealed widget child needs to know of the state too, but don't need to know about the whole event history Any suggestions are welcome! Peter - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eet - proposing doing an alpha release. 0.9.99900
I think it'd be nice to have a @since 1.0.0 entry in the doxy before realsing eet (and its api documentation). That'd make it easier to keep track of API extensions in later releases. If you like it can add it. Peter ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eet - proposing doing an alpha release. 0.9.99900
Carsten Haitzler (The Rasterman) schrieb: (floating point numbers may lose accuracy as they are decoded as decimal and thus when encoded again may not be exactly the same). Afaik, there is no accuracy loss if you convert a hexadecimal (or binary) number into a decimal number since 10 has 2 as a prime factor. I don't know, however, how many digits you will need. Bigger problem could be that eet use %f instead of %e. So really big or really small numbers are not covered. Peter - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eet - proposing doing an alpha release. 0.9.99900
Carsten Haitzler (The Rasterman) schrieb: On Fri, 28 Mar 2008 19:42:38 +0100 Peter Wehrfritz [EMAIL PROTECTED] babbled: Carsten Haitzler (The Rasterman) schrieb: (floating point numbers may lose accuracy as they are decoded as decimal and thus when encoded again may not be exactly the same). Afaik, there is no accuracy loss if you convert a hexadecimal (or binary) number into a decimal number since 10 has 2 as a prime factor. I don't know, however, how many digits you will need. Bigger problem could be that eet use %f instead of %e. So really big or really small numbers are not covered. sure - so when you are editing your text representation - you really want to edit floats in hex... right? :) point is the text is to make it human readable/editable as people seem to bitch a lot. there is no other use for it as the files are portable as-is in binary. Well, I don't want it to have hex output. My point was that if you convert 2-adic numbers to 10-adic numbers you don't have a loss of accuracy. Of course the revers doesn't work if someone will edit the file later and change it to a 10-adic number that is not representable as a 2-adic number. Peter - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl widget positioning
dan sinclair schrieb: Currently Ewl positions widgets based on absolute coordinates. This works but isn't unnecessarily optional. Thoughts on changing the internals of Ewl to use parent relative placement of widgets? This would, hopefully, simplify some of the container code and allow for more code re-use internally. We would need to convert all containers to a relative layout and modify the theme system to map the coordinates properly. This would cause issues if we do need to place a widget absolutely, as we'd need to walk the parent tree to figure out where we were, but, how often we need to do this I'm not sure. I don't know if we need to place a widget absolutely, but we need at the end to place the edje and evas objects the absolute coordinates. That was my main concern. Peter - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ewl pfritz
Sebastian Dransfeld schrieb: Enlightenment CVS wrote: Enlightenment CVS committal Author : pfritz Project : e17 Module : libs/ewl Dir : e17/libs/ewl/src/lib Modified Files: ewl_tree.c Log Message: i wonder why the compiler didn't cried Because some of the dlist functions are cast? # define ecore_dlist_count(list) ecore_list_count(ECORE_LIST(list)) Yes, I realized that and I have removed the dangerous and unnecessary casts. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] i18n for the configure title
Hi,
attached is a small patch to make the string Enlightenment Configure
translatable for translator.
Index: data/themes/default_configure.edc
===
RCS file: /cvs/e/e17/apps/e/data/themes/default_configure.edc,v
retrieving revision 1.23
diff -u -r1.23 default_configure.edc
--- data/themes/default_configure.edc 17 Sep 2007 12:03:47 - 1.23
+++ data/themes/default_configure.edc 5 Mar 2008 01:21:49 -
@@ -66,7 +66,7 @@
}
}
part {
- name: title;
+ name: e.text.title;
type: TEXT;
effect:SOFT_SHADOW;
mouse_events: 0;
@@ -88,7 +88,7 @@
color3: 0 0 0 32;
color_class: configure_title;
text {
- text: Enlightenment Configuration;
+ text: EC;
font: Sans:style=Bold,Edje-Vera-Bold;
size: 16;
min: 1 1;
Index: src/modules/conf/e_conf.c
===
RCS file: /cvs/e/e17/apps/e/src/modules/conf/e_conf.c,v
retrieving revision 1.11
diff -u -r1.11 e_conf.c
--- src/modules/conf/e_conf.c 23 Jan 2008 09:04:55 - 1.11
+++ src/modules/conf/e_conf.c 5 Mar 2008 01:21:49 -
@@ -129,6 +129,8 @@
eco-edje = edje_object_add(eco-evas);
e_theme_edje_object_set(eco-edje, base/theme/configure,
e/widgets/configure/main);
+ edje_object_part_text_set(eco-edje, e.text.title,
+ _(Enlightenment Configuration));
eco-o_list = e_widget_list_add(eco-evas, 1, 1);
edje_object_part_swallow(eco-edje, e.swallow.content, eco-o_list);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/efreet raster
Enlightenment CVS schrieb:
Enlightenment CVS committal
Author : raster
Project : e17
Module : libs/efreet
Dir : e17/libs/efreet/src/lib
Modified Files:
efreet_desktop.c efreet_desktop.h
Log Message:
return the void pointer return val from the run cb - not just 1 or 0 :) a
superset here...
===
RCS file: /cvs/e/e17/libs/efreet/src/lib/efreet_desktop.c,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -3 -r1.33 -r1.34
--- efreet_desktop.c 11 Jan 2008 07:33:57 - 1.33
+++ efreet_desktop.c 20 Feb 2008 04:10:02 - 1.34
@@ -102,7 +102,7 @@
static void efreet_desktop_type_info_free(Efreet_Desktop_Type_Info *info);
static int efreet_desktop_command_flags_get(Efreet_Desktop *desktop);
-static void efreet_desktop_command_execs_process(Efreet_Desktop_Command
*command, Ecore_List *execs);
+static void *efreet_desktop_command_execs_process(Efreet_Desktop_Command
*command, Ecore_List *execs);
/**
* @internal
@@ -1097,7 +1097,7 @@
* @return Returns 1 on success or 0 on failure
someone should fix the doxy. I can't since i have no idea what this
function does.
* @brief Get a command to use to execute a desktop entry.
*/
-EAPI int
+EAPI void *
efreet_desktop_command_get(Efreet_Desktop *desktop, Ecore_List *files,
Efreet_Desktop_Command_Cb func, void *data)
{
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Image loader for Portable Maps
I've written an image loader for evas that can load pbm, pgm, ppm. It
supports P1, P2, P3, P4, P5, P6. For P5 and P6 it also supports the
2-byte format. Unfortunately I haven't seen that there is a pnm loader
for imlib2, when I started to write it. And when I saw the imlib2
loader, I've already written the most parts of my loader. Compared to
the imlib2 loader my loader is very lenient, supports 2-byte binary
format and imho is easier to understand. Therefor the imlib2 code might
be a bit faster. I haven't measured it tho. And the felt load time is
almost equal.
I named the loader pmaps, but if you prefer I can rename it to pnm.
The attached diff only adds the loader to evas. The pmaps directory can
be found here:
http://mowem.de/evas/pmaps.tar.gz
or if you just want to scroll through the c file:
http://phpfi.com/296415
If you like it, I'll commit it.
Peter
? pmaps.diff
? src/modules/loaders/pmaps
? src/modules/loaders/pmaps.tar.gz
Index: configure.in
===
RCS file: /cvs/e/e17/libs/evas/configure.in,v
retrieving revision 1.248
diff -u -u -r1.248 configure.in
--- configure.in 25 Jan 2008 03:35:49 - 1.248
+++ configure.in 14 Feb 2008 11:24:05 -
@@ -1055,6 +1055,22 @@
AM_CONDITIONAL(BUILD_LOADER_SVG, test x$have_svg = xyes)
+###
+## PMAPS
+have_pmaps=yes;
+AC_MSG_CHECKING(whether to enable pmaps image loader)
+AC_ARG_ENABLE(image-loader-pmaps,
+ AC_HELP_STRING([--disable-image-loader-pmaps], [disable PMAPS image loader]),
+ [ have_pmaps=$enableval ]
+)
+AC_MSG_RESULT($have_pmaps)
+
+pmaps_cflags=
+pmaps_libs=
+
+AM_CONDITIONAL(BUILD_LOADER_PMAPS, test x$have_pmaps = xyes)
+
+
#
## Cpu based optimizations
@@ -1520,6 +1536,8 @@
AC_SUBST(xpm_libs)
AC_SUBST(svg_cflags)
AC_SUBST(svg_libs)
+AC_SUBST(pmaps_cflags)
+AC_SUBST(pmaps_libs)
AC_SUBST(altivec_cflags)
AC_SUBST(pthread_cflags)
AC_SUBST(pthread_libs)
@@ -1595,6 +1613,7 @@
src/modules/loaders/tiff/Makefile
src/modules/loaders/xpm/Makefile
src/modules/loaders/svg/Makefile
+src/modules/loaders/pmaps/Makefile
src/modules/savers/Makefile
src/modules/savers/edb/Makefile
src/modules/savers/eet/Makefile
@@ -1648,6 +1667,7 @@
echo TIFF: $have_tiff
echo XPM.: $have_xpm
echo SVG.: $have_svg
+echo PMAPS...: $have_pmaps
# FIXME: need to add modular image loader system
# FIXME: add more image loader modules
echo
Index: src/lib/engines/common/evas_image_load.c
===
RCS file: /cvs/e/e17/libs/evas/src/lib/engines/common/evas_image_load.c,v
retrieving revision 1.44
diff -u -u -r1.44 evas_image_load.c
--- src/lib/engines/common/evas_image_load.c 2 Dec 2007 19:44:27 - 1.44
+++ src/lib/engines/common/evas_image_load.c 14 Feb 2008 11:24:05 -
@@ -22,7 +22,11 @@
{ tif, tiff },
{ svg, svg },
{ svgz, svg },
- { gif, gif }
+ { gif, gif },
+ { pbm, pmaps },
+ { pgm, pmaps },
+ { ppm, pmaps },
+ { pnm, pmaps }
};
EAPI int
Index: src/modules/loaders/Makefile.am
===
RCS file: /cvs/e/e17/libs/evas/src/modules/loaders/Makefile.am,v
retrieving revision 1.6
diff -u -u -r1.6 Makefile.am
--- src/modules/loaders/Makefile.am 17 Aug 2006 15:39:24 - 1.6
+++ src/modules/loaders/Makefile.am 14 Feb 2008 11:24:05 -
@@ -32,4 +32,9 @@
svg_subdir = svg
endif
-SUBDIRS = $(edb_subdir) $(eet_subdir) $(gif_subdir) $(jpeg_subdir) $(png_subdir) $(tiff_subdir) $(xpm_subdir) $(svg_subdir)
+if BUILD_LOADER_PMAPS
+pmaps_subdir = pmaps
+endif
+
+
+SUBDIRS = $(edb_subdir) $(eet_subdir) $(gif_subdir) $(jpeg_subdir) $(png_subdir) $(tiff_subdir) $(xpm_subdir) $(svg_subdir) $(pmaps_subdir)
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH]: entrance/configure.in: fat finger bug
Thanatermesis schrieb: Seem like somebody has a dirty 'N' key on his keyboard This patch fixes a important bug that elements on entrance uses 'entrace' instead of 'entrance' (like the dir /usr/share/entrance is renamed /usr/share/entrace ), it also includes less-important 'entrace' fixups Thanks. It is in cvs. Peter - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
nash schrieb:
On Fri, 2008-01-25 at 13:28 -0500, Enlightenment CVS wrote:
Enlightenment CVS committal
Author : pfritz
Project : e17
Module : libs/ecore
===
RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore/Ecore.h,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -3 -r1.57 -r1.58
--- Ecore.h 11 Jan 2008 07:33:56 - 1.57
+++ Ecore.h 25 Jan 2008 18:28:16 - 1.58
@@ -61,6 +61,9 @@
extern C {
#endif
+#define ECORE_CALLBACK_CANCEL 0; /** Return value to remove a callback */
+#define ECORE_CALLBACK_RENEW 1; /** Return value to keep a callback */
+
I'm guessing you don't mean for those two semi-colons to be there...
Yes, you are right. That was a mistake.
Thanks,
Peter
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Ecore] pipe wrapper
Vincent Torri schrieb: Hey, as i have succedded in integrating the gstreamer thread in the ecore main loop on Windows, and as some of you talked about a pipe wrapper, I've quickly written a wrapper around pipe(), read() and write(). I have attached the source file to put in ecore/src/lib/ecore/ and a diff. There is a complete example that uses that wrapper with gstreamer (the test I used on Windows, btw) and the documentation is here too. That can, maybe, help people to integrate other threads or loops (like the threaded glib loop) in the ecore main loop. feel free to comment :) I cannot comment it technically, but I think the names ecore_pipe_add() and ecore_pipe_del() would fit better into the ecore naming scheme. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: enna captainigloo
Nicolas Aguirre schrieb:
Le mardi 22 janvier 2008 à 19:48 +0100, Peter Wehrfritz a écrit :
Wouldn't it be better, if ecore_str_has_suffix() were case-insensitive,
because it is most time used to check for extensions? Or maybe to have
another function that does the same job, but that use strcasecmp instead
strcmp?
Peter
Agree with you, but maybe have another function would be better.
You'll find a patch attached, that adds ecore_str_has_extentsion() which
uses strcasecmp() instead of strcmp(). If there are no objections, I'm
going to commit it in some days
Peter
Index: Ecore_Str.h
===
RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore/Ecore_Str.h,v
retrieving revision 1.9
diff -u -r1.9 Ecore_Str.h
--- Ecore_Str.h 15 Mar 2007 22:21:26 - 1.9
+++ Ecore_Str.h 23 Jan 2008 09:29:42 -
@@ -46,6 +46,8 @@
EAPI int ecore_str_has_prefix(const char *str, const char *prefix);
EAPI int ecore_str_has_suffix(const char *str, const char *suffix);
+EAPI int ecore_str_has_extension(const char *str, const char *ext);
+
EAPI char **ecore_str_split(const char *string, const char *delimiter,
int max_tokens);
Index: ecore_str.c
===
RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore/ecore_str.c,v
retrieving revision 1.9
diff -u -r1.9 ecore_str.c
--- ecore_str.c 22 Aug 2007 17:44:04 - 1.9
+++ ecore_str.c 23 Jan 2008 09:29:42 -
@@ -23,6 +23,8 @@
#include ecore_private.h
#include Ecore_Str.h
+static int ecore_str_has_suffix_helper(const char *str, const char *suffix,
+ int (*cmp)(const char *, const char *));
/**
* @param dst the destination
* @param src the source
@@ -140,18 +142,47 @@
int
ecore_str_has_suffix(const char *str, const char *suffix)
{
- size_t str_len;
- size_t suffix_len;
-
CHECK_PARAM_POINTER_RETURN(str, str, 0);
CHECK_PARAM_POINTER_RETURN(suffix, suffix, 0);
+
+ return ecore_str_has_suffix_helper(str, suffix, strcmp);
+}
+
+/**
+ * This function does the same like ecore_str_has_suffix(), but with a
+ * case insensitive compare.
+ *
+ * @param str the string to work with
+ * @param ext the extension to check for
+ * @return true if str has the given extension
+ * @brief checks if the string has the given extension
+ */
+int
+ecore_str_has_extension(const char *str, const char *ext)
+{
+ CHECK_PARAM_POINTER_RETURN(str, str, 0);
+ CHECK_PARAM_POINTER_RETURN(ext, ext, 0);
+
+ return ecore_str_has_suffix_helper(str, ext, strcasecmp);
+}
+
+/*
+ * Internal helper function used by ecore_str_has_suffix() and
+ * ecore_str_has_extension()
+ */
+static int
+ecore_str_has_suffix_helper(const char *str, const char *suffix,
+ int (*cmp)(const char *, const char *))
+{
+ size_t str_len;
+ size_t suffix_len;
str_len = strlen(str);
suffix_len = strlen(suffix);
if (suffix_len str_len)
return 0;
- return (strncmp(str + str_len - suffix_len, suffix, suffix_len) == 0);
+ return cmp(str + str_len - suffix_len, suffix) == 0;
}
/**
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: enna captainigloo
Wouldn't it be better, if ecore_str_has_suffix() were case-insensitive,
because it is most time used to check for extensions? Or maybe to have
another function that does the same job, but that use strcasecmp instead
strcmp?
Peter
Enlightenment CVS schrieb:
Enlightenment CVS committal
Author : captainigloo
Project : misc
Module : enna
Dir : misc/enna/src/bin
Modified Files:
enna_util.c
Log Message:
tests against file extensions are now case insensitive
===
RCS file: /cvs/e/misc/enna/src/bin/enna_util.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- enna_util.c 14 Jan 2008 22:16:05 - 1.1
+++ enna_util.c 22 Jan 2008 18:25:57 - 1.2
@@ -33,6 +33,7 @@
#include stdlib.h
#include stdio.h
#include math.h
+#include ctype.h
EAPI char *
enna_util_user_home_get()
@@ -54,12 +55,19 @@
Evas_List *l;
int result = 0;
+ int i;
+ char *tmp;
+
if (!patterns || !str || !str[0])
- return 0;
+ return 0;
+
for (l = patterns; l; l = evas_list_next(l))
{
- //dbg(pattern : %s\n, (char*)l-data);
- result |= ecore_str_has_suffix(str, (char *)l-data);
+ tmp = strdup(str);
+ for (i = 0; i strlen(str); i++)
+ tmp[i] = tolower(str[i]);
+ result |= ecore_str_has_suffix(tmp, (char *)l-data);
+ free(tmp);
}
return result;
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-cvs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
Dave schrieb: Enlightenment CVS ha scritto: Enlightenment CVS committal Author : pfritz Project : e17 Module : libs/ecore Dir : e17/libs/ecore/src/lib/ecore_file Modified Files: Ecore_File.h Log Message: remove old api macros === RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore_file/Ecore_File.h,v retrieving revision 1.34 retrieving revision 1.35 diff -u -3 -r1.34 -r1.35 --- Ecore_File.h 6 Aug 2007 20:00:28 - 1.34 +++ Ecore_File.h 6 Jan 2008 15:21:00 - 1.35 @@ -71,9 +71,6 @@ EAPI int ecore_file_symlink (const char *src, const char *dest); EAPI char *ecore_file_realpath (const char *file); EAPI int ecore_file_unlink (const char *file); -/* NOTE: these aliases will be removed! DO NOT USE THEM */ -#define ecore_file_get_file(path) ecore_file_file_get(path) -#define ecore_file_get_dir(path) ecore_file_dir_get(path) EAPI const char *ecore_file_file_get (const char *path); EAPI char *ecore_file_dir_get (const char *path); Why ecore_file_file_get is declared static? All the apps/libs that use this function is BROKEN on my system! Sorry, I don't understand your problem. ecore_file_file_get() isn't declared static. It isn't static in the header - as you can see in the diff above - and it isn't static in the c-file either. Peter - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
Kim Woelders schrieb: Michael Jennings wrote: On Monday, 07 January 2008, at 21:06:04 (+0100), Kim Woelders wrote: (and the line length is set to 80 of course :) ). I got into the habit of using 132 instead of 80 because 80 columns is all too often not enough for readability, particularly when using lengthier OO-style function naming (namespace_object_action(OBJECT_CAST(object), ...) -- See how ugly that wrapped? Ick!), and the vast majority of terminals (including xterm and Eterm) have 80/132 column toggles built-in, even key-bindable. To me, sticking with an 80-column limit for coding is like using gcc 2.7.2.3 to compile all your software: it was great 10 years ago, but we live in a different world now. Even the Linux console itself can do well beyond 80 columns. :) But tabs vs. spaces is far more likely to result in spaghetti code then setting the column limit. Michael Yeah, I was just trolling (although the 80 is about the only thing I do care about). We are talking personal preferences here and are most likely never going to agree. You say when I write code like this I really need very long lines and to that I will say then don't write code like that. Somebody(?) should just lay down the rules so it's clear what they are. Full ack. Peter - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ECORE_CALLBACK_KEEP and ECORE_CALLBACK_REMOVE
Peter Wehrfritz schrieb: Hi all, I want to add two aliases (ECORE_CALLBACK_KEEP and ECORE_CALLBACK_REMOVE) to Ecore.h. They can be used as return values for the ecore callbacks like timer, idler etc. Imho that improves code-readability and helps (at least me) to write code, because you don't have to remember if 0 stops the timer or keeps it. I've talked with Nathan about it and he prefers ECORE_CALLBACK_STOP/REPEAT. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] ECORE_CALLBACK_KEEP and ECORE_CALLBACK_REMOVE
Hi all, I want to add two aliases (ECORE_CALLBACK_KEEP and ECORE_CALLBACK_REMOVE) to Ecore.h. They can be used as return values for the ecore callbacks like timer, idler etc. Imho that improves code-readability and helps (at least me) to write code, because you don't have to remember if 0 stops the timer or keeps it. If you like, it'll commit it. Peter Index: Ecore.h === RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore/Ecore.h,v retrieving revision 1.56 diff -u -r1.56 Ecore.h --- Ecore.h 25 Oct 2007 05:55:07 - 1.56 +++ Ecore.h 5 Jan 2008 21:20:18 - @@ -69,6 +69,9 @@ #define ECORE_EVENT_SIGNAL_REALTIME 5 /** Realtime signal event */ #define ECORE_EVENT_COUNT 6 +#define ECORE_CALLBACK_REMOVE 0; /** Return value to remove a callback */ +#define ECORE_CALLBACK_KEEP 1; /** Return value to keep a callback */ + EAPI extern int ECORE_EXE_EVENT_ADD; /** A child process has been added */ EAPI extern int ECORE_EXE_EVENT_DEL; /** A child process has been deleted (it exited, naming consistant with the rest of ecore). */ EAPI extern int ECORE_EXE_EVENT_DATA; /** Data from a child process. */ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: pfritz
Vincent Torri schrieb: On Wed, 12 Dec 2007, Enlightenment CVS wrote: Enlightenment CVS committal Author : pfritz Module : Dir : Added Files: .cvsignore Makefile.am ewl_config_test.c Log Message: add config unit test It seems that the fileswere not added correctly Yes, sorry, something went wrong yesterday night. I've added them now in the right place. Does anyone know how to remove the other files in the wrong place? Peter - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: pfritz
Michael Jennings schrieb: On Thursday, 13 December 2007, at 14:10:49 (+0100), Peter Wehrfritz wrote: Yes, sorry, something went wrong yesterday night. I've added them now in the right place. Does anyone know how to remove the other files in the wrong place? Already done. Michael Thanks - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje_editor / engrave problem
[EMAIL PROTECTED] schrieb: Dave ha scritto: The same problem appear also in the loading of the edc files. Here's the second patch (not including the first) None seems contrary so I will commit the change to cvs. we can always keep back ;) And a stupid question, why isn't parsing a problem with edje_cc? Sebastian Because edje_cc sets the (numeric) locale explicitly to C (it is the default anyway so without this line the results would be the same). And in C a point is used for the decimal point. Peter - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje_editor / engrave problem
Gustavo Sverzut Barbieri schrieb:
On Nov 23, 2007 3:45 AM, Dave [EMAIL PROTECTED] wrote:
Hi all,
I recently have a strange bug in the editor that prevent from saving all
the file.
The problem is that engrave write out an edc with all the floating numbers
having the wrong separator-char ( 0,0 instead of 0.0 ).
The strange think is that engrave_test seems to work well
Someone else have this error?
To try simply create a new group,a new rectangle and save the file.
I have this error:
Executing: edje_cc -v /tmp/edje_editor_tmp.edc-pQu69c /home/dave/as
edje_cc: Error. parse error :22. , marker before ; marker
Error in edje_cc, exit code: 25
and in fact the tmp file have ( , ) instead of ( . ) in numbers
The tmp file is generated by engrave_edc_output() that write the value
with this function:
static void
engrave_out_data(FILE *out, char *name, char *fmt, ...)
{
va_list ap;
char *fmt_new = (char *)calloc(strlen(fmt) + strlen(name) + level +
5, sizeof(char));
char *buf = engrave_output_mk_tabs();
sprintf(fmt_new, %s%s: %s;\n, buf, name, fmt);
va_start(ap, fmt);
vfprintf(out, fmt_new, ap);
va_end(ap);
FREE(fmt_new);
FREE(buf);
}
So seems that vfprintf() write the %.2f param wrong. Is this possible?
is vfprintf() l18n?
yes, it is. I'm not sure how to disable it just for some functions
tough. A quick look at its man page says that every format would use
the locale to format, but maybe there is some that I missed.
Don't think there is a really nice way to do this. The only way I know
is this:
char prev[128];
strncpy(prev, setlocale(LC_NUMERIC, NULL), sizeof(prev));
setlocale(LC_NUMERIC, C);
printf(%f\n, 123.3);
setlocale(LC_NUMERIC, prev);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore Split
Виктор Кожухаров schrieb: В пн, 2007-11-19 в 21:19 +0100, Simon TRENY написа: Is there actually any project that is still using ecore_config? Maybe it could be removed. Ecore_Desktop should be removed too since it's deprecated now. elicit and edje_viewer still use ecore_config entrance and elitaire, too. I don't understand the word still here. Is there something wrong with ecore_config? Or are there plans for an substitute? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore englebass
jochen schroeder schrieb: On Mon, 2007-11-05 at 19:04 -0300, Gustavo Sverzut Barbieri wrote: On Nov 5, 2007 6:54 PM, Luchezar Petkov [EMAIL PROTECTED] wrote: Enlightenment CVS wrote: Enlightenment CVS committal Author : englebass Project : e17 Module : libs/ecore Dir : e17/libs/ecore/src/lib/ecore_file Modified Files: Makefile.am ecore_file_monitor.c ecore_file_private.h Removed Files: ecore_file_monitor_fam.c Log Message: remove fam support, will never be fixed and inotify is the shit. There's still a @fam_libs@ in ecore-file.pc.in should that not be removed as well? Jochen Fixed, thanks. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_path questions
Vincent Torri schrieb:
Hey
I have 2 qestions about ecore_path:
1) about ecore_path_group_new, the documentation says that if an error
occured, then 0 is returned. But I see a return -1; Shouldn't the
function return 0 instead ? Also, if ecore_list_new return NULL, shouldn't
we also return an error (0 or -1, according to the convention used...) ?
2) in __ecore_path_group_find_id, there is no check to see if id is
positive or not (or non negative, if the error is -1). Is it normal ?
thank you
Vincent
Talking about ecore_path, it seems to me that it isn't actually
finished, which raises some questions.
3) What is the purpose of the group name? Currently it is only used
during the creation to check if the group name is an unique string,
otherwise it fails. We could simply remove it, without any feature loss.
It'd save memory and the author doesn't need to worry about an unique
name. Or was the idea to avoid the use of static vars like the following
little example could look like:
group = ecore_path_group_find(my paths);
if (!group) {
/* group doesn't exist, create it now */
group = ecore_path_group_new(my paths);
...
}
Then we need to expose the __ecore_path_group_find() function.
4) Why is it using the group id to identify the group and not a pointer
to Ecore_Path_Group. Using the group id implies a linear search. Sure,
probably not a notable waste of time, but i don't see any benefit.
Peter
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New projects under proto
Jorge Luis Zapata Muga schrieb: In order to compile them you need edata, it's just a split of Ecore_Data from Ecore, but before adding it into CVS i would like your opinions about it, a while ago there was a discussion about splitting ecore in libraries by themselves, this should be step forward it, what do you think? What about to name it ewd? ;-) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas smart-objects future plans?
Simon TRENY schrieb: Hi, I've seen in Evas.h that most of the methods of Evas_Smart_Class are marked as to-be-deleted in the future (FIXME: DELETE ME). This concerns show(), hide(), color_set(), clip_set() and clip_unset(). I think it will be indeed a really great thing to do since when we implement these methods for a new smart-object, we basically always do the same thing (i.e clipping member-objects against the parent's clipper in clip_set(), hiding the member-objects in hide_set()...). It will also simplify a lot the code of Etk_Widget as I tried to make these things done automatically but since Etk doesn't have access to Evas internals, it is quite a mess. I'm totally against the idea to clip all smart members to the smart object geometry. I can understand that this is the common case in the view of a toolkit author. But in fact there are many exception I can think of. For example an animation that overlaps the geometry of the smart object, a shadow that overhangs the area of an swallow part, etc.. In elitaire I use this for the cards. The logical card has always the same size, but when you switch on shadows, the card image has an offset outside of this area and only the shadow has the same geometry (position and size) like the smart object. That make it very handy to handle movements of the card and animations like lifting the card at the same time. I don't think we should sacrifice the power of evas smart objects because of a common case that 90% of the smart object use. Think of the remaining 10% percent. This cases need to be handled, too. You could write an convenience object, maybe called evas_object_group, where you only have to set the resize callback and the rest is done internally. But please let the the smart objects as they are. There are many cases where you need the versatility of them. Peter - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas smart-objects future plans?
Chady Kassouf schrieb: On 8/21/07, Peter Wehrfritz [EMAIL PROTECTED] wrote: Simon TRENY schrieb: Hi, I've seen in Evas.h that most of the methods of Evas_Smart_Class are marked as to-be-deleted in the future (FIXME: DELETE ME). This concerns show(), hide(), color_set(), clip_set() and clip_unset(). I think it will be indeed a really great thing to do since when we implement these methods for a new smart-object, we basically always do the same thing (i.e clipping member-objects against the parent's clipper in clip_set(), hiding the member-objects in hide_set()...). It will also simplify a lot the code of Etk_Widget as I tried to make these things done automatically but since Etk doesn't have access to Evas internals, it is quite a mess. I'm totally against the idea to clip all smart members to the smart object geometry. I can understand that this is the common case in the view of a toolkit author. But in fact there are many exception I can think of. For example an animation that overlaps the geometry of the smart object, a shadow that overhangs the area of an swallow part, etc.. In elitaire I use this for the cards. The logical card has always the same size, but when you switch on shadows, the card image has an offset outside of this area and only the shadow has the same geometry (position and size) like the smart object. That make it very handy to handle movements of the card and animations like lifting the card at the same time. I don't think we should sacrifice the power of evas smart objects because of a common case that 90% of the smart object use. Think of the remaining 10% percent. This cases need to be handled, too. You could write an convenience object, maybe called evas_object_group, where you only have to set the resize callback and the rest is done internally. But please let the the smart objects as they are. There are many cases where you need the versatility of them. The proposal is NOT for clipping to the parent object's geometry, but to the parent object's clipper. Yes, your case if very valid, but if you're going that route, you probably will have your parent clipper account for the shadows by making it that much bigger to not clip the shadows. Ah, then I misunderstood Simon. So you have a function evas_object_smart_clipper_set() to set the clipper and control the clipper on your own? That could work for me, but I still would prefer to have this in an evas object group or something similar. I don't know, however, if that makes the implementation too complicated. Peter - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas smart-objects future plans?
Simon TRENY schrieb: On Tue, 21 Aug 2007 10:26:16 +0200, Peter Wehrfritz [EMAIL PROTECTED] wrote : Chady Kassouf schrieb: On 8/21/07, Peter Wehrfritz [EMAIL PROTECTED] wrote: Simon TRENY schrieb: Hi, I've seen in Evas.h that most of the methods of Evas_Smart_Class are marked as to-be-deleted in the future (FIXME: DELETE ME). This concerns show(), hide(), color_set(), clip_set() and clip_unset(). I think it will be indeed a really great thing to do since when we implement these methods for a new smart-object, we basically always do the same thing (i.e clipping member-objects against the parent's clipper in clip_set(), hiding the member-objects in hide_set()...). It will also simplify a lot the code of Etk_Widget as I tried to make these things done automatically but since Etk doesn't have access to Evas internals, it is quite a mess. I'm totally against the idea to clip all smart members to the smart object geometry. I can understand that this is the common case in the view of a toolkit author. But in fact there are many exception I can think of. For example an animation that overlaps the geometry of the smart object, a shadow that overhangs the area of an swallow part, etc.. In elitaire I use this for the cards. The logical card has always the same size, but when you switch on shadows, the card image has an offset outside of this area and only the shadow has the same geometry (position and size) like the smart object. That make it very handy to handle movements of the card and animations like lifting the card at the same time. I don't think we should sacrifice the power of evas smart objects because of a common case that 90% of the smart object use. Think of the remaining 10% percent. This cases need to be handled, too. You could write an convenience object, maybe called evas_object_group, where you only have to set the resize callback and the rest is done internally. But please let the the smart objects as they are. There are many cases where you need the versatility of them. The proposal is NOT for clipping to the parent object's geometry, but to the parent object's clipper. Yes, your case if very valid, but if you're going that route, you probably will have your parent clipper account for the shadows by making it that much bigger to not clip the shadows. Ah, then I misunderstood Simon. So you have a function evas_object_smart_clipper_set() to set the clipper and control the clipper on your own? That could work for me, but I still would prefer to have this in an evas object group or something similar. I don't know, however, if that makes the implementation too complicated. No, you'll still use evas_object_clip_set() to clip the smart-object. And in that case, the member-objects will be clipped automatically against the same clip object. Oh, sorry for the noise. I thought you are going to implement this (show, hide, color, etc.) via a rectangle clip. When I finally (hopefully :) ) understand you correct, this asumption was wrong. Then I'm fine with it. Peter - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Update e_dbus NetworkManager functions to current API
Ross Vandegrift schrieb: Hello everyone, As I mentioned earlier, I've been playing a bit with getting NetworkManager support to do good stuff in E. This patch updates e_dbus to use the most accurate NM interface that I could find. The patch adds all the functionality required, but I am too dumb to figure out how to get cvs diff -N to work like diff -N and actually include the new file. Instead, I've attached the missing file which will need to go into src/lib/nm/ for e_dbus. Next email will have a simple sample app that gets information about network devices from NetworkManager. Can you send the patch again with cvs diff -uN and as a separated file (not inline)? Thanks Peter - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_Data API change
Carsten Haitzler (The Rasterman) schrieb: On Tue, 24 Jul 2007 20:08:29 +0200 Peter Wehrfritz [EMAIL PROTECTED] babbled: ecore_file has a few bad crufty ones too. Sure, I can change those in the same run, but can you be more precise, please? Do you prefer ecore_file_dir_make over ecore_file_mkdir? ecore_list_append_list ecore_list_prepend_list ecore_list_remove_first ecore_list_remove_last ecore_list_goto_first ecore_list_goto_last ecore_list_goto_index ecore_dlist_prepend_list ecore_dlist_remove_first ecore_dlist_remove_last ecore_dlist_goto_first ecore_dlist_goto_last ecore_dlist_goto_index After positive response per mail and irc, I think most people are content with the changes. Actually I haven't heard anything negative about them. Still remains the question, what to do with the functions above. ecore_list_list_append sounds ok to me, but ecore_list_first_goto sounds a bit clumsy. Or am I just used to the old function names? Peter - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri
Enlightenment CVS schrieb: Enlightenment CVS committal Author : barbieri Project : e17 Module : libs/etk Dir : e17/libs/etk/src/bin Modified Files: etk_combobox_test.c etk_tree_test.c Log Message: Fix compiler warnings === RCS file: /cvs/e/e17/libs/etk/src/bin/etk_combobox_test.c,v retrieving revision 1.16 retrieving revision 1.17 diff -u -3 -r1.16 -r1.17 --- etk_combobox_test.c 29 Jun 2007 09:14:01 - 1.16 +++ etk_combobox_test.c 24 Jul 2007 21:40:16 - 1.17 @@ -1,3 +1,4 @@ +#define _GNU_SOURCE #include etk_test.h #include stdlib.h #include unistd.h @@ -202,7 +203,7 @@ cur_dir = strdup(dir_stripped); files = ecore_file_ls(dir_stripped); - ecore_list_sort(files, strcasecmp, 'a'); + ecore_list_sort(files, (Ecore_Compare_Cb)strcasecmp, 'a'); I'm not sure what your intention is behind the 'a', but the third argument of ecore_list_sort() should be ECORE_SORT_MIN or ECORE_SORT_MAX. I updated the doxy to be more precise about the possible values. Besides that, the return list of ecore_file_ls() should already be sorted. Peter - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri
Hisham Mardam Bey schrieb: On 7/25/07, Peter Wehrfritz [EMAIL PROTECTED] wrote: I'm not sure what your intention is behind the 'a', but the third argument of ecore_list_sort() should be ECORE_SORT_MIN or ECORE_SORT_MAX. I updated the doxy to be more precise about the possible values. Besides that, the return list of ecore_file_ls() should already be sorted. Fixed, thanks. ecore_file_ls seems to use strcol l() which is case sensitive. strcoll is in general case insensitive , only if you haven't set the user's locale (via setlocale(LC_COLLATE, ); or setlocale(LC_ALL, );) and hence the locale is set to C, it will fallback, for whatever reasons, to use strcmp. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_Data API change
Ok the changes are commit to cvs. If you have some code that is not in cvs you can use the little script I wrote. usage: ./replace.sh ../ecore_data.rpl ../ecore_data.grep Note don't save the .rpl and the .grep file in the directory that you want to change, else the script will replace the strings in those files, too. Peter replace.sh Description: application/shellscript ecore_list_nodes ecore_list_is_empty ecore_list_set_free_cb ecore_dlist_nodes ecore_dlist_is_empty ecore_dlist_set_free_cb ecore_hash_set_free_key ecore_hash_set_free_value ecore_hash_set_hash ecore_plugin_get_available ecore_sheap_set_free_cb ecore_sheap_set_compare ecore_sheap_set_order ecore_tree_is_empty ecore_tree_get_closest_larger ecore_tree_get_closest_smaller ecore_tree_add_node ecore_tree_remove_node ecore_tree_set_free_value ecore_tree_set_free_key ecore_list_remove_first ecore_list_remove_last ecore_list_goto_first ecore_list_goto_last ecore_list_goto_index ecore_dlist_remove_first ecore_dlist_remove_last ecore_dlist_goto_first ecore_dlist_goto_last ecore_dlist_goto_index ecore_file_get_file ecore_file_get_dir s/ecore_list_nodes/ecore_list_count/g; s/ecore_list_is_empty/ecore_list_empty_is/g; s/ecore_list_set_free_cb/ecore_list_free_cb_set/g; s/ecore_dlist_nodes/ecore_dlist_count/g; s/ecore_dlist_is_empty/ecore_dlist_empty_is/g; s/ecore_dlist_set_free_cb/ecore_dlist_free_cb_set/g; s/ecore_hash_set_free_key/ecore_hash_free_key_cb_set/g; s/ecore_hash_set_free_value/ecore_hash_free_value_cb_set/g; s/ecore_hash_set_hash/ecore_hash_hash_set/g; s/ecore_plugin_get_available/ecore_plugin_available_get/g; s/ecore_sheap_set_free_cb/ecore_sheap_free_cb_set/g; s/ecore_sheap_set_compare/ecore_sheap_compare_set/g; s/ecore_sheap_set_order/ecore_sheap_order_set/g; s/ecore_tree_is_empty/ecore_tree_empty_is/g; s/ecore_tree_get_closest_larger/ecore_tree_closest_larger_get/g; s/ecore_tree_get_closest_smaller/ecore_tree_closest_smaller_get/g; s/ecore_tree_add_node/ecore_tree_node_add/g; s/ecore_tree_remove_node/ecore_tree_node_remove/g; s/ecore_tree_set_free_value/ecore_tree_free_value_cb_set/g; s/ecore_tree_set_free_key/ecore_tree_free_key_cb_set/g; s/ecore_list_remove_first/ecore_list_first_remove/g; s/ecore_list_remove_last/ecore_list_last_remove/g; s/ecore_list_goto_first/ecore_list_first_goto/g; s/ecore_list_goto_last/ecore_list_last_goto/g; s/ecore_list_goto_index/ecore_list_index_goto/g; s/ecore_dlist_remove_first/ecore_dlist_first_remove/g; s/ecore_dlist_remove_last/ecore_dlist_last_remove/g; s/ecore_dlist_goto_first/ecore_dlist_first_goto/g; s/ecore_dlist_goto_last/ecore_dlist_last_goto/g; s/ecore_dlist_goto_index/ecore_dlist_index_goto/g; s/ecore_file_get_file/ecore_file_file_get/g; s/ecore_file_get_dir/ecore_file_dir_get/g; - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore_Data API change
The current functions names of many Ecore_Data functions don't fit into the common efl-naming schema. For example ecore_list_set_free_cb should be ecore_list_free_cb_set. Hence I would propose to change the API of those functions to follow the common-naming schema. Also I like to rename ecore_list_nodes to ecore_list_count to be more conform with other similar functions like ecore_hash_count. Since only the function names will be changed, it can be easily done by a script and wouldn't break any app in cvs. We could add aliases for apps outside of the cvs tree, so they can move smoothly to the new names. The only downside would be the massive commit mails :). Here a list of the functions, which I would rename: ecore_list_nodesecore_list_count ecore_list_is_emptyecore_list_empty_is ecore_list_set_free_cbecore_list_free_cb_set ecore_dlist_nodesecore_dlist_count ecore_dlist_is_emptyecore_dlist_empty_is ecore_dlist_set_free_cbecore_dlist_free_cb_set ecore_hash_set_free_keyecore_hash_free_key_cb_set ecore_hash_set_free_valueecore_hash_free_value_cb_set ecore_hash_set_hashecore_hash_hash_set ecore_plugin_get_availableecore_plugin_available_get ecore_sheap_set_free_cbecore_sheap_free_cb_set ecore_sheap_set_compareecore_sheap_compare_set ecore_sheap_set_orderecore_sheap_order_set ecore_tree_is_emptyecore_tree_empty_is ecore_tree_get_closest_largerecore_tree_closest_larger_get ecore_tree_get_closest_smallerecore_tree_closest_smaller_get ecore_tree_add_nodeecore_tree_node_add ecore_tree_remove_nodeecore_tree_node_remove ecore_tree_set_free_valueecore_tree_free_value_cb_set ecore_tree_set_free_keyecore_tree_free_key_cb_set and here a list of functions about I'm unsure if they should be renamed or not: ecore_list_append_list ecore_list_prepend_list ecore_list_remove_first ecore_list_remove_last ecore_list_goto_first ecore_list_goto_last ecore_list_goto_index ecore_dlist_prepend_list ecore_dlist_remove_first ecore_dlist_remove_last ecore_dlist_goto_first ecore_dlist_goto_last ecore_dlist_goto_index I've you'll like the idea, I'll do the changes. Peter - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Update e_dbus NetworkManager functions to current API
Ross Vandegrift schrieb: The patch adds all the functionality required, but I am too dumb to figure out how to get cvs diff -N to work like diff -N and actually include the new file. Instead, I've attached the missing file which will need to go into src/lib/nm/ for e_dbus. To include a new file into a diff, you have to add it first with cvs add. Then cvs diff -uN will include it to the patch. Peter - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/edje pfritz
Vincent Torri schrieb: On Fri, 6 Jul 2007, Enlightenment CVS wrote: style = EVAS_TEXT_STYLE_OUTLINE_SHADOW; else if (ep-part-effect == EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW) style = EVAS_TEXT_STYLE_OUTLINE_SOFT_SHADOW; + else if (ep-part-effect == EDJE_TEXT_EFFECT_FAR_SHADOW) + style = EVAS_TEXT_STYLE_FAR_SHADOW; + else if (ep-part-effect == EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW) + style = EVAS_TEXT_STYLE_FAR_SOFT_SHADOW; + else if (ep-part-effect == EDJE_TEXT_EFFECT_GLOW) + style = EVAS_TEXT_STYLE_GLOW; #define EDJE_TEXT_EFFECT_SOFT_SHADOW 5 #define EDJE_TEXT_EFFECT_OUTLINE_SHADOW 6 #define EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW 7 -#define EDJE_TEXT_EFFECT_LAST8 +#define EDJE_TEXT_EFFECT_FAR_SHADOW 8 +#define EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW 9 +#define EDJE_TEXT_EFFECT_GLOW 10 +#define EDJE_TEXT_EFFECT_LAST 11 Isn't it better to use an enum + a switch, instead of defines + if/else ? I only extended, what already was there, but I can change it to use a switch, if people prefer this. Peter - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] glow effect for edje text parts
nvm, I already committed it. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Esmart fixed placing?
Andreas Volz schrieb: Hello, I use Esmart_Container in my project to create a list widget. This works really nice. But now I like some sort of container that is able to place objects on fixed coordinates inside the container. It seems that Esmart_Container places objects only in vertical or horizontal direction. You may ask why I need a container with fixed coordinates. Why not placing it direct in the viewport? - I like to show/hide/move/... a complete group of widgets. I found the esmart_container_layout_plugin_set() function. It's not much documented and I'm not sure if a layout plugin is what I need. What do you think? Another idea may be that I create a EdjeGroup class (here: C++) that holds an array of Edje objects and applies the show/hide/move function to all Edje objects it holds. But this sounds exact like a Esmart_Container. So I hope this is possible with Esmart_Container. I think what you are looking for, are evas smart objects. Take a look into the efl cookbook. There you'll find a nice howto about this. Note that the behavior has changed a little, so you don't need any longer the layer, raise, lower, above and below callbacks, but have to add the child objects as a smart member to the smart object. pfritz - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Elitaire now save statistics and hiscores
Massimiliano Calamelli schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nice game! See attached file. Massimiliano Thanks, committed. Peter - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Esmart_Resize
Hi all,
Sometime ago I've written a smart object, that is very similiar to
Esmart_Draggies, actually I started to modify a copy of draggies. The
purpose of this object is to resize a borderless window. You can set, in
which directions it will resize the window. I named it Esmart_Resize.
Find a patch attached and a test app here: mowem.de/esmart/esr.tar.bz2.
Please let me know if you find it useful and I will commit it.
pfritz
P.S. Sorry that I already commit the subdir. I wonder if it is possible
to add a dir with out committing it.
Index: configure.in
===
RCS file: /cvs/e/e17/libs/esmart/configure.in,v
retrieving revision 1.19
diff -u -r1.19 configure.in
--- configure.in 5 May 2007 15:14:17 - 1.19
+++ configure.in 24 Jun 2007 09:38:39 -
@@ -57,6 +57,15 @@
]
)
+PKG_CHECK_MODULES(RESIZE, [
+evas = 0.9.9
+ecore-evas = 0.9.9
+ ], [
+have_esmart_resize=yes
+requirements=$requirements ecore-evas
+ ]
+)
+
PKG_CHECK_MODULES(TRANSX11, [
evas = 0.9.9
ecore-x = 0.9.9
@@ -107,6 +116,7 @@
AM_CONDITIONAL(BUILD_ESMART_CONTAINER, test $have_esmart_container = yes)
AM_CONDITIONAL(BUILD_ESMART_DRAGGIES, test $have_esmart_draggies = yes)
+AM_CONDITIONAL(BUILD_ESMART_RESIZE, test $have_esmart_draggies = yes)
AM_CONDITIONAL(BUILD_ESMART_FILE_DIALOG, test $have_esmart_file_dialog = yes)
AM_CONDITIONAL(BUILD_ESMART_TEXT_ENTRY, test $have_esmart_text_entry = yes)
AM_CONDITIONAL(BUILD_ESMART_TEXTAREA, test $have_esmart_textarea = yes)
@@ -137,6 +147,7 @@
src/lib/esmart_thumb/Makefile
src/lib/esmart_trans_x11/Makefile
src/lib/esmart_draggies/Makefile
+src/lib/esmart_resize/Makefile
src/bin/Makefile
data/Makefile
data/images/Makefile
@@ -158,6 +169,7 @@
echo Components:
echo Container...: $have_esmart_container
echo Draggies: $have_esmart_draggies
+echo Resize..: $have_esmart_draggies
echo File Dialog.: $have_esmart_file_dialog
echo Text Entry..: $have_esmart_text_entry
echo Text Area...: $have_esmart_textarea
Index: src/lib/Makefile.am
===
RCS file: /cvs/e/e17/libs/esmart/src/lib/Makefile.am,v
retrieving revision 1.4
diff -u -r1.4 Makefile.am
--- src/lib/Makefile.am 21 Mar 2007 13:22:42 - 1.4
+++ src/lib/Makefile.am 24 Jun 2007 09:38:39 -
@@ -6,6 +6,10 @@
draggies_subdir = esmart_draggies
endif
+if BUILD_ESMART_RESIZE
+resize_subdir = esmart_resize
+endif
+
if BUILD_ESMART_FILE_DIALOG
file_dialog_subdir = esmart_file_dialog
endif
@@ -28,7 +32,7 @@
SUBDIRS = \
$(container_subdir) $(draggies_subdir) $(text_entry_subdir) \
- $(file_dialog_subdir) $(thumb_subdir) $(trans_subdir)
+ $(file_dialog_subdir) $(thumb_subdir) $(trans_subdir) $(resize_subdir)
# adding textarea_subdir breaks distcheck
# $(textarea_subdir)
Index: src/lib/esmart_resize/Esmart_Resize.h
===
RCS file: src/lib/esmart_resize/Esmart_Resize.h
diff -N src/lib/esmart_resize/Esmart_Resize.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ src/lib/esmart_resize/Esmart_Resize.h 24 Jun 2007 09:38:39 -
@@ -0,0 +1,74 @@
+#ifndef ESMART_RESIZE_H
+#define ESMART_RESIZE_H
+
+#ifdef EAPI
+#undef EAPI
+#endif
+#ifdef WIN32
+# ifdef BUILDING_DLL
+# define EAPI __declspec(dllexport)
+# else
+# define EAPI __declspec(dllimport)
+# endif
+#else
+# ifdef __GNUC__
+# if __GNUC__ = 4
+# define EAPI __attribute__ ((visibility(default)))
+# else
+# define EAPI
+# endif
+# else
+# define EAPI
+# endif
+#endif
+
+#includeEvas.h
+#includeEcore_Evas.h
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+/**
+ * How to use Esmart Resize.
+ */
+typedef struct _Esmart_Resize Esmart_Resize;
+
+struct _Esmart_Resize
+{
+ Ecore_Evas *ee; /* The ecore_evas that should resize */
+ int dx, dy; /* offset from 0,0 of the window */
+ int w, h; /* The size of the window at the begining*/
+ int x, y; /* The position of the window at the
+ beginning */
+ int resize_x, resize_y; /* the resize direction */
+ int clicked; /* Whether the mouse is down now or not */
+ int button; /* the button that handles dragging */
+ Evas_Object *obj; /* the rectangle that gets events */
+};
+
+typedef enum {
+ ESMART_RESIZE_LEFT = 0,
+ ESMART_RESIZE_RIGHT,
+ ESMART_RESIZE_TOP,
+ ESMART_RESIZE_BOTTOM,
+ ESMART_RESIZE_LEFT_TOP,
+ ESMART_RESIZE_RIGHT_TOP,
+ ESMART_RESIZE_LEFT_BOTTOM,
+ ESMART_RESIZE_RIGHT_BOTTOM
+} Esmart_Resize_Type;
+
+EAPI Evas_Object *esmart_resize_new (Ecore_Evas * evas);
+EAPI void esmart_resize_button_set (Evas_Object * o, int button);
+EAPI void esmart_resize_event_callback_add (Evas_Object * o,
+ Evas_Callback_Type type,
+ void (*func) (void *data, Evas * e,
+ Evas_Object * o,
+ void *ev),
+ const void *data);
+EAPI void esmart_resize_type_set(Evas_Object *
[E-devel] glow effect for edje text parts
Hi all,
attached you'll find a patch, that adds support for glow, far shadow and
far soft shadow to edje text parts. Let me know if I can commit it or if
I have to change something.
pfritz
Index: src/bin/edje_cc_handlers.c
===
RCS file: /cvs/e/e17/libs/edje/src/bin/edje_cc_handlers.c,v
retrieving revision 1.73
diff -u -r1.73 edje_cc_handlers.c
--- src/bin/edje_cc_handlers.c 27 May 2007 05:28:07 - 1.73
+++ src/bin/edje_cc_handlers.c 23 Jun 2007 11:32:01 -
@@ -2148,6 +2148,9 @@
SOFT_SHADOW, EDJE_TEXT_EFFECT_SOFT_SHADOW,
OUTLINE_SHADOW, EDJE_TEXT_EFFECT_OUTLINE_SHADOW,
OUTLINE_SOFT_SHADOW, EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW,
+ FAR_SHADOW, EDJE_TEXT_EFFECT_FAR_SHADOW,
+ FAR_SOFT_SHADOW, EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW,
+ GLOW, EDJE_TEXT_EFFECT_GLOW,
NULL);
}
Index: src/lib/edje_calc.c
===
RCS file: /cvs/e/e17/libs/edje/src/lib/edje_calc.c,v
retrieving revision 1.102
diff -u -r1.102 edje_calc.c
--- src/lib/edje_calc.c 27 May 2007 05:28:07 - 1.102
+++ src/lib/edje_calc.c 23 Jun 2007 11:32:01 -
@@ -735,6 +735,12 @@
style = EVAS_TEXT_STYLE_OUTLINE_SHADOW;
else if (ep-part-effect == EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW)
style = EVAS_TEXT_STYLE_OUTLINE_SOFT_SHADOW;
+ else if (ep-part-effect == EDJE_TEXT_EFFECT_FAR_SHADOW)
+ style = EVAS_TEXT_STYLE_FAR_SHADOW;
+ else if (ep-part-effect == EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW)
+ style = EVAS_TEXT_STYLE_FAR_SOFT_SHADOW;
+ else if (ep-part-effect == EDJE_TEXT_EFFECT_GLOW)
+ style = EVAS_TEXT_STYLE_GLOW;
evas_object_text_style_set(ep-object, style);
evas_object_text_text_set(ep-object, text);
evas_object_geometry_get(ep-object, NULL, NULL, tw, th);
Index: src/lib/edje_private.h
===
RCS file: /cvs/e/e17/libs/edje/src/lib/edje_private.h,v
retrieving revision 1.125
diff -u -r1.125 edje_private.h
--- src/lib/edje_private.h 27 May 2007 05:28:07 - 1.125
+++ src/lib/edje_private.h 23 Jun 2007 11:32:01 -
@@ -143,7 +143,10 @@
#define EDJE_TEXT_EFFECT_SOFT_SHADOW 5
#define EDJE_TEXT_EFFECT_OUTLINE_SHADOW 6
#define EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW 7
-#define EDJE_TEXT_EFFECT_LAST8
+#define EDJE_TEXT_EFFECT_FAR_SHADOW 8
+#define EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW 9
+#define EDJE_TEXT_EFFECT_GLOW 10
+#define EDJE_TEXT_EFFECT_LAST 11
#define EDJE_ACTION_TYPE_NONE 0
#define EDJE_ACTION_TYPE_STATE_SET 1
Index: src/lib/edje_text.c
===
RCS file: /cvs/e/e17/libs/edje/src/lib/edje_text.c,v
retrieving revision 1.63
diff -u -r1.63 edje_text.c
--- src/lib/edje_text.c 18 Jun 2007 16:49:11 - 1.63
+++ src/lib/edje_text.c 23 Jun 2007 11:32:01 -
@@ -579,6 +579,38 @@
(params-color3.b * params-color3.a) / 255,
params-color3.a);
}
+ else if (ep-part-effect == EDJE_TEXT_EFFECT_FAR_SHADOW)
+ {
+ style = EVAS_TEXT_STYLE_FAR_SHADOW;
+ evas_object_text_shadow_color_set(ep-object,
+ (params-color3.r * params-color3.a) / 255,
+ (params-color3.g * params-color3.a) / 255,
+ (params-color3.b * params-color3.a) / 255,
+ params-color3.a);
+ }
+ else if (ep-part-effect == EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW)
+ {
+ style = EVAS_TEXT_STYLE_FAR_SOFT_SHADOW;
+ evas_object_text_shadow_color_set(ep-object,
+ (params-color3.r * params-color3.a) / 255,
+ (params-color3.g * params-color3.a) / 255,
+ (params-color3.b * params-color3.a) / 255,
+ params-color3.a);
+ }
+ else if (ep-part-effect == EDJE_TEXT_EFFECT_GLOW)
+ {
+ style = EVAS_TEXT_STYLE_GLOW;
+ evas_object_text_glow_color_set(ep-object,
+ (params-color2.r * params-color2.a) / 255,
+ (params-color2.g * params-color2.a) / 255,
+ (params-color2.b * params-color2.a) / 255,
+ params-color2.a);
+ evas_object_text_glow2_color_set(ep-object,
+ (params-color3.r * params-color3.a) / 255,
+ (params-color3.g * params-color3.a) / 255,
+ (params-color3.b * params-color3.a) / 255,
+ params-color3.a);
+ }
evas_object_text_style_set(ep-object, style);
}
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] glow effect for edje text parts
Gustavo Sverzut Barbieri schrieb: On 6/23/07, Peter Wehrfritz [EMAIL PROTECTED] wrote: Hi all, attached you'll find a patch, that adds support for glow, far shadow and far soft shadow to edje text parts. Let me know if I can commit it or if I have to change something. IMHO those should go into text styles/effects, not in Edje, but maybe adding those to core will take huge amount of work? Those effects are already in evas. The patch makes them just accessible in edje. Peter - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] equate patch
João Vale schrieb: Equate got broken in a recent EWL update. Attached patch fixes it. Cheers, Vale thanks, it's in CVS now. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
Christopher Michael schrieb: Hi Guys :) I've been reading through the efreet code and it's not too shabby, so big (insert your favorite type) cookie to the authors there :) but before I jump head first into this porting nightmare I have a few remaining questions 1) Is it really worth the effort to port all this efreet code into ecore_desktop, just to be pulling it out at a later date when ecore gets broken apart ?? 2) Am I correct in assuming that we still want to keep the ecore_desktop_some_function calls and just replace the code inside with efreet code ?? (with #ifdef NEW_CODE blocking of course..ie: we still would have ecore_desktop_some_func, just that it would run efreet code) If you want to have efreet to be a part of ecore and raster seems to want this, why don't you move it simply to ecore/src/lib/efreet and keep the efreet name-space. So efreet and ecore_desktop can coexist for sometime and it is much easier to do the transition (not only e17 uses ecore_desktop). And when sometime ecore gets split into several package, you can still use the efreet namespace and you don't have to rename all the function in your applications and libraries. just my 2 cents Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
Stéphane Bauland schrieb:
Vincent Torri wrote:
On Tue, 13 Mar 2007, Stéphane Bauland wrote:
Hi!
1) Why ecore_str_vector_free was removed ?
now, you only need to free the returned pointer. There's no need for a
function to do that :)
I let the others comment the 2nd question :)
Vincent
Hehe ! I got a memory leak here :
Don't believe caro, read the doxy :).
i. e. if (vec) {free(*vec); free(vec);}
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_Str new feature...
Vincent Torri schrieb: On Mon, 12 Mar 2007, Brian Mattern wrote: On Mon, Mar 12, 2007 at 12:41:41PM +0100, Stéphane Bauland wrote: Hi people. I needed a function to split a string into a list. My first func used Ecore_List * as return value, and dourse said me that's not really good. He said me to return a char ** so i did it. And i put it under ecore_str. Since you're using an ecore list internally, I don't see why you shouldn't just return that? What was the reasoning behind why that's not really good? In his library, the use of that function is big. Then, the number of allocation is really high (several tens of thousands of allocations for just a test program). I would not have used ecore_list internally. I would have just parsed 2 times the string in order to build the array of strings. That would lead to allocate only the mem necessary for the storage of the strings. you are right, that's much faster. In my little tests the list approach took twice of the time. And this measurement was without freeing them. I told rookmoot to begin with a list, because it's simpler. Only one parsing of the string. Vincent PS: I've not looked at the code yet. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
Long and messy. Find better version attached. And as a bonus, you only have to free the array pointer and its first element. Quickie test program supplied also. Michael Thanks committed. It is indeed much faster. I changed it slightly, because your version had some problems with empty strings. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] ecore_strbuf_replace
This mail is mainly addressed to rephorm, but every suggestion or
criticism is welcome. Here is a patch to add ecore_strbuf_replace() and
ecore_strbuf_replace_all(). I doesn't reduce the size of the buffer if
that is possible. Cause the current calculation of the maximum step size
is bijective. So it would probably be better to determine the max step
depending on the buffer size and not on the previous step size.
If you like the patch I'll commit it.
Peter
Index: Ecore_Data.h
===
RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore/Ecore_Data.h,v
retrieving revision 1.36
diff -u -r1.36 Ecore_Data.h
--- Ecore_Data.h21 Feb 2007 06:08:22 - 1.36
+++ Ecore_Data.h4 Mar 2007 05:32:09 -
@@ -483,14 +483,21 @@
EAPI int ecore_tree_set_free_cb(Ecore_Tree * tree, Ecore_Free_Cb free_func);
-Ecore_Strbuf * ecore_strbuf_new(void);
-void ecore_strbuf_free(Ecore_Strbuf *buf);
-void ecore_strbuf_append(Ecore_Strbuf *buf, const char *str);
-void ecore_strbuf_append_char(Ecore_Strbuf *buf, char c);
-void ecore_strbuf_insert(Ecore_Strbuf *buf, const char *str, size_t pos);
-#define ecore_strbuf_prepend(buf, str) ecore_strbuf_insert(buf, str, 0)
-const char * ecore_strbuf_string_get(Ecore_Strbuf *buf);
-size_t ecore_strbuf_length_get(Ecore_Strbuf *buf);
+ EAPI Ecore_Strbuf * ecore_strbuf_new(void);
+ EAPI void ecore_strbuf_free(Ecore_Strbuf *buf);
+ EAPI void ecore_strbuf_append(Ecore_Strbuf *buf, const char *str);
+ EAPI void ecore_strbuf_append_char(Ecore_Strbuf *buf, char c);
+ EAPI void ecore_strbuf_insert(Ecore_Strbuf *buf, const char *str,
+ size_t pos);
+# define ecore_strbuf_prepend(buf, str) ecore_strbuf_insert(buf, str, 0)
+ EAPI const char * ecore_strbuf_string_get(Ecore_Strbuf *buf);
+ EAPI size_t ecore_strbuf_length_get(Ecore_Strbuf *buf);
+ EAPI int ecore_strbuf_replace(Ecore_Strbuf *buf, const char *str,
+ const char *with, unsigned int n);
+# define ecore_strbuf_replace_first(buf, str, with) \
+ ecore_strbuf_replace(buf, str, with, 1)
+ EAPI int ecore_strbuf_replace_all(Ecore_Strbuf *buf, const char *str,
+ const char *with);
#ifdef __cplusplus
}
Index: ecore_strbuf.c
===
RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore/ecore_strbuf.c,v
retrieving revision 1.2
diff -u -r1.2 ecore_strbuf.c
--- ecore_strbuf.c 21 Feb 2007 04:31:50 - 1.2
+++ ecore_strbuf.c 4 Mar 2007 05:32:09 -
@@ -15,10 +15,12 @@
size_t step;
};
+static int _ecore_strbuf_resize(Ecore_Strbuf *buf, size_t size);
+
/**
* Create a new string buffer
*/
-Ecore_Strbuf *
+EAPI Ecore_Strbuf *
ecore_strbuf_new(void)
{
Ecore_Strbuf *buf;
@@ -40,7 +42,7 @@
* Free a string buffer
* @param buf the buffer to free
*/
-void
+EAPI void
ecore_strbuf_free(Ecore_Strbuf *buf)
{
CHECK_PARAM_POINTER(buf, buf);
@@ -53,7 +55,7 @@
* @param buf the Ecore_Strbuf to append to
* @param str the string to append
*/
-void
+EAPI void
ecore_strbuf_append(Ecore_Strbuf *buf, const char *str)
{
size_t l;
@@ -80,18 +82,16 @@
buf-len += l;
}
-
/**
* Insert a string to a buffer, reallocating as necessary.
* @param buf the Ecore_Strbuf to insert
* @param str the string to insert
* @param pos the position to insert the string
*/
-void
+EAPI void
ecore_strbuf_insert(Ecore_Strbuf *buf, const char *str, size_t pos)
{
size_t len;
- size_t new_size;
CHECK_PARAM_POINTER(buf, buf);
CHECK_PARAM_POINTER(str, str);
@@ -106,23 +106,12 @@
* resize the buffer if necessary
*/
len = strlen(str);
- new_size = buf-size;
- while (len + buf-len new_size)
-{
-new_size += buf-step;
-if (buf-step ECORE_STRBUF_MAX_STEP)
- buf-step *= 2;
-}
-
- if (new_size != buf-size)
-{
- buf-size = new_size;
-buf-buf = realloc(buf-buf, buf-size);
-}
+ if (!_ecore_strbuf_resize(buf, buf-len + len))
+return;
/* move the existing text */
memmove(buf-buf + len + pos, buf-buf + pos, buf-len - pos);
/* and now insert the given string */
- strncpy(buf-buf + pos, str, len);
+ memcpy(buf-buf + pos, str, len);
buf-len += len;
buf-buf[buf-len] = 0;
}
@@ -132,7 +121,7 @@
* @param buf the Ecore_Strbuf to append to
* @param c the char to append
*/
-void
+EAPI void
ecore_strbuf_append_char(Ecore_Strbuf *buf, char c)
{
CHECK_PARAM_POINTER(buf, buf);
@@ -155,7 +144,7 @@
* This pointer must not be modified, and will no longer be valid if
* the Ecore_Strbuf is modified.
*/
-const char *
+EAPI const char *
ecore_strbuf_string_get(Ecore_Strbuf *buf)
{
CHECK_PARAM_POINTER_RETURN(buf, buf, NULL);
@@ -166,10 +155,206 @@
* Retrieve the length of the string buffer content
* @param buf the buffer
*/
-size_t
+EAPI size_t
Re: [E-devel] transient for the root window
Carsten Haitzler (The Rasterman) schrieb: On Mon, 12 Feb 2007 02:15:52 +0100 Peter Wehrfritz [EMAIL PROTECTED] babbled: Hi, currently e17 ignores the WM_TRANSIENT_FOR property, if the property is set to the root window or to none. The EWMH proposes to treat the application window as a transient for all other windows in the same group. I'm not quit sure what that does mean, but I've tested it in other WMs. xfce places the window in the middle of the screen (as I've actually expected it). Metacity places the window only centered, if the window is also a dialog. So my question is, is this just a yet not implemented feature or are there reasons to ignore it? Personally, I'd like to see e17 to place the window in the middle of the screen. this hasn't bee don e because: 1. our todo list is not complete - icccm and netwm are NOT complete. 2. i have yet to see/use an app that needs this handled in a specific way. :) e17 is NOT complete. thus... not everything imaginable under the sun works :) No problem, I know that e17 isn't complete :) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] transient for the root window
Hi, currently e17 ignores the WM_TRANSIENT_FOR property, if the property is set to the root window or to none. The EWMH proposes to treat the application window as a transient for all other windows in the same group. I'm not quit sure what that does mean, but I've tested it in other WMs. xfce places the window in the middle of the screen (as I've actually expected it). Metacity places the window only centered, if the window is also a dialog. So my question is, is this just a yet not implemented feature or are there reasons to ignore it? Personally, I'd like to see e17 to place the window in the middle of the screen. Peter - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eet crashes in a directory without write permission
Carsten Haitzler (The Rasterman) schrieb: On Mon, 28 Aug 2006 16:17:41 +0200 Peter Wehrfritz [EMAIL PROTECTED] babbled: Hi all, I'm using eet for the highscore support in elitaire, but eet crashes while writing into a file that is in a directory, for that the user hasn't got write permission, altough he has write permission for the file itself. To reproduce this: - first compile the attached test app and then make a directory called tmp - execute the the test app once or twice (or oftener) - chmod 555 tmp - then execute it again and it will crash Attached you will find the test app and the backtrace fixed :) subtle mmap and close() of the fd to the mmaped region bug :) thanks a lot. It works now. peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ewl dj2
Enlightenment CVS schrieb: Enlightenment CVS committal Author : dj2 Project : e17 Module : libs/ewl Dir : e17/libs/ewl/src/lib Modified Files: ewl_text.c Log Message: - fixup some issues with the positioning in ewl_text. - this fixes eap_edit so it dosen't segv on a new eap being created Hi dan, I don't know what the issue was with eap_edit, but your patch breaks utf support. I add a small function to the text_editor test, so you can now test utf support with hitting CTRL-a. You should see then an 'ä' (a 'a' with two dots). peter Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] taskbar 0.1.3
Morten Nilsen schrieb: Morten Nilsen wrote: Morten Nilsen wrote: http://home.4th-age.com/taskbar-0.1.3.tar.bz2 fixes: - Reworded config - Made initial preparations for i18n - Now remembers config - config should now work per taskbar client, but I haven't tested it This patch fixes the callbacks working on all the instances rather than the first found. some improvements over the last (applies against the tar), also removes two _taskbar_icon_remove() calls that should never have been there.. why don't you send diffs against the current cvs version, instead against your own fork version? peter ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] bug in entrance default theme revisited
Morten Nilsen schrieb: I just now started getting into how edje works, and thought I might have an idea as to why this bug occurs, but I didn't.. to me, it seems like items in a swallow don't get clipped by the swallows opened area, because the edc seems to place the buttons at the appropriate location for stacking to be correct.. so, I think one of these two things are happening.. - swallows don't clip their contents Yes, that's right, but AFAIK not the problem. - the dynamically generated session buttons get stacked at the top level anyone able to shed some light on this matter? I haven't take a look into the code of entrance, so perhaps I'm totally wrong. It seems to me that the container itself is swallowed in the part, so it lies in the right layer stack position, but the container elements aren't smart member of the container then they aren't layered with the container and fly over it. I think the problem would be solved when the elements would be smart member of the container. Either you do an evas_object_smart_member_add(element, container) after you have add them to the container or you change directly the esmart_container functions. I hope I could help you peter --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ewl layer handling
Nathan Ingersoll schrieb: On 4/15/06, Peter Wehrfritz [EMAIL PROTECTED] wrote: Hi all, While I'm playing around with ewl_embed to replace my old context menu in elitaire, I recognize that this is nearly impossible, because ewl spreads its objects over the whole layer range, starting with -1000 upto 1000 (I'm not sure if the number are really correct). And swallow it in a edje is indeed impossible. Actually, it can start at any layer, as long as it's set on the smart object for the embed. The default is -1000. So the the current layer system may work well for stand alone ewl apps, but it is useless when you want overlap an ewl_embed and some evas_objects. I think it would make sense to switch to the new (perhaps six month old) evas_smart_object layer system, so that every ewl widget is a smart member of the ewl_embed smart object and all ewl's magic happens in only one layer. This is certainly a possibility. It might solve some problems we've also seen with using shaped windows and ewl_embed. The object cache introduces a few key points that we could use to hook into adding to the smart object. I have avoided this in the past because of the way clipping was done in Evas, and the additional memory allocations used to add an object to a smart object. With the new layering and clipping, this should be negligible now. I know this is not an easy step or an one-day-job, I've already done this in elitaire. On the other hand the most code I've seen in ewl concerning to layering was put this object over another or put this object to the top and that is easily done with stack_above() and raise(). You're mostly correct in how layering is used, but there is a circumstance where this is not so trivial. The most basic example is a tooltip, if a window contains a tooltip above some widgets, then a widget is added that should be stacked above the existing widgets, we need to maintain the layering of the tooltip above other widgets. The same situation applies to imenu's. Right now we use a large layer offset for these types of widgets to make it extremely unlikely that any new widget will get stacked above them. I don't think this issue is a show-stopper to your proposed change, but it does need to be considered and addressed. I see what you mean. I see two ways to do this: 1. Trying to stay as nearly as possible to the current system. E.g. just replacing the evas_object_layer_set(o, 1000) with evas_object_raise(o). This should be possible but might become tricky in the detail. IIRC, this is not a hard coded layer setting, except that the default layer is -1000 or so. It should presently use whatever layer that is set on the smart object as the starting layer and spread the range of widgets upward from that point. Sorry, yes it is relative to the embed. Using the ewl function ewl_widget_layer_set() 2. Every widget get a dummy smart object, with no callbacks. So this smart object holds in a normal widget the clip and the edje theme and in the case of a container also the smart object of the children. This approach would be cleaner and easier, but I don't know if it cause extra overhead. Unfortunately, this could be a lot of overhead. You can potentially have thousands (millions?) or widgets, so performing extra allocations like this really adds up. Right now we scale pretty well, and a lot of the scalability improvements came from the fact that we limit the number of evas objects to what is presently on screen at any given time. So the only way I see this being feasible is if we can create the smart objects at the time of a reveal callback (like we do for the clip and theme object). That may work, but not if we rely on object persistence to get layering right. So I will start with option number 1 and hope it works that way. Would do you think about it ? Have I missed anythink or should I try a start (without guaranty of success)? If we can figure out how the issues I mentioned earlier can be addressed, I would be quite happy to accept a patch for this. It might be worthwhile to test if adding all of the evas objects to the embed's smart object solves the issue completely. If the layering within a smart object is relative to that smart object only and not the global layering, then there may not be any additional work required. I can't claim strong knowledge of how the layering works now, but maybe raster can shed some insight. When I understand you right this won't work, because a smart object afaik has only one layer stack. So function calls like evas_object_layer_set() are just ignored by evas when the object is a smart member. Thanks, Nathan Thanks for your fast response peter --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group
[E-devel] ewl layer handling
Hi all, While I'm playing around with ewl_embed to replace my old context menu in elitaire, I recognize that this is nearly impossible, because ewl spreads its objects over the whole layer range, starting with -1000 upto 1000 (I'm not sure if the number are really correct). And swallow it in a edje is indeed impossible. So the the current layer system may work well for stand alone ewl apps, but it is useless when you want overlap an ewl_embed and some evas_objects. I think it would make sense to switch to the new (perhaps six month old) evas_smart_object layer system, so that every ewl widget is a smart member of the ewl_embed smart object and all ewl's magic happens in only one layer. I know this is not an easy step or an one-day-job, I've already done this in elitaire. On the other hand the most code I've seen in ewl concerning to layering was put this object over another or put this object to the top and that is easily done with stack_above() and raise(). I see two ways to do this: 1. Trying to stay as nearly as possible to the current system. E.g. just replacing the evas_object_layer_set(o, 1000) with evas_object_raise(o). This should be possible but might become tricky in the detail. 2. Every widget get a dummy smart object, with no callbacks. So this smart object holds in a normal widget the clip and the edje theme and in the case of a container also the smart object of the children. This approach would be cleaner and easier, but I don't know if it cause extra overhead. Would do you think about it ? Have I missed anythink or should I try a start (without guaranty of success)? Thanks for your attention and sorry for my linguistic mistakes peter --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Re: E CVS: libs/ewl dj2
Enlightenment CVS schrieb:
Enlightenment CVS committal
Author : dj2
Project : e17
Module : libs/ewl
Dir : e17/libs/ewl/src/lib
Modified Files:
ewl_menu.c
Log Message:
- fix the menu corruption when you open and close the same menu multiple
times.
- needed to actually call ewl_widget_configure instead of just calling
the CONFIGURE callback
Yes, this fixed it for the menu, but the real problem lies a bit deeper.
When you hide and show a override window again the output is corrupted,
but when you call ewl_widget_configure it works. Attached is a little
prog demonstrating this. I cannot imagine why, because this only happens
with override set to true. Anyway it doesn't bother me, I only want to
mention it.
Also attached you will find a patch for the context menu placment in the
iconbox.
peter
#include Ewl.h
void _win_show(Ewl_Widget * w, void * e, void * data)
{
ewl_widget_show(EWL_WIDGET(data));
}
void _win_hide(Ewl_Widget * w, void * e, void * data)
{
ewl_widget_hide(EWL_WIDGET(data));
}
void _win_conf(Ewl_Widget * w, void * e, void * data)
{
ewl_widget_configure(EWL_WIDGET(data));
}
void _destroy_main_window(Ewl_Widget * main_win, void * ev_data, void *
user_data)
{
ewl_main_quit();
return;
}
int main(int argc, char ** argv)
{
Ewl_Widget * win, * win2, * w, * c;
ewl_init(argc, argv);
win = ewl_window_new();
ewl_object_size_request(EWL_OBJECT(win), 300, 100);
ewl_callback_append(win, EWL_CALLBACK_DELETE_WINDOW,
_destroy_main_window, NULL);
ewl_widget_show(win);
win2 = ewl_window_new();
ewl_window_transient_for(EWL_WINDOW(win2), EWL_WINDOW(win));
ewl_window_override_set(EWL_WINDOW(win2), TRUE);
ewl_window_borderless_set(EWL_WINDOW(win2));
ewl_object_size_request(EWL_OBJECT(win2), 100, 200);
c = ewl_hbox_new();
ewl_widget_show(c);
ewl_container_child_append(EWL_CONTAINER(win), c);
w = ewl_button_new();
ewl_button_label_set(EWL_BUTTON(w), show);
ewl_widget_show(w);
ewl_container_child_append(EWL_CONTAINER(c), w);
ewl_callback_append(w, EWL_CALLBACK_CLICKED, _win_show, win2);
w = ewl_button_new();
ewl_button_label_set(EWL_BUTTON(w), configure);
ewl_widget_show(w);
ewl_container_child_append(EWL_CONTAINER(c), w);
ewl_callback_append(w, EWL_CALLBACK_CLICKED, _win_conf, win2);
w = ewl_button_new();
ewl_button_label_set(EWL_BUTTON(w), hide);
ewl_widget_show(w);
ewl_container_child_append(EWL_CONTAINER(c), w);
ewl_callback_append(w, EWL_CALLBACK_CLICKED, _win_hide, win2);
ewl_main();
}
Index: ewl_iconbox.c
===
RCS file: /var/cvs/e/e17/libs/ewl/src/lib/ewl_iconbox.c,v
retrieving revision 1.112
diff -u -r1.112 ewl_iconbox.c
--- ewl_iconbox.c 2 Apr 2006 01:45:45 - 1.112
+++ ewl_iconbox.c 13 Apr 2006 20:30:31 -
@@ -1367,10 +1367,13 @@
(ib-xdown != ev-x
ib-ydown != ev-y))
{
+ int h;
+
+ h =
ewl_object_current_h_get(EWL_OBJECT(ib-ewl_iconbox_context_menu));
ewl_widget_show(ib-ewl_iconbox_menu_floater);
ewl_floater_position_set(EWL_FLOATER(ib-ewl_iconbox_menu_floater),
- ev-x-ibx +
abs(px-ibx),
- ev-y-iby +abs(py-iby));
+ ev-x - px,
+ ev-y - py - h);
ewl_callback_call(EWL_WIDGET(ib-ewl_iconbox_context_menu),
EWL_CALLBACK_FOCUS_IN);
@@ -1424,9 +1427,12 @@
iby = ewl_object_current_y_get(EWL_OBJECT(ib-icon_box_parent));
if (ev-button == 3) {
+ int h;
+
+ h =
ewl_object_current_h_get(EWL_OBJECT(ib-icon_box_parent-icon_menu));
ewl_floater_position_set(EWL_FLOATER(ib-icon_box_parent-icon_menu_floater),
- ev-x-ibx + abs(sx-ibx),
- ev-y-iby +abs(sy-iby));
+ ev-x - sx,
+ ev-y - sy - h);
ewl_callback_call(EWL_WIDGET(ib-icon_box_parent-icon_menu),
EWL_CALLBACK_FOCUS_IN);
} else {
Re: [E-devel] ewl_spectrum
dan sinclair schrieb:
I noticed one thing as I was playing with it. It seems like the
initial click on the spectrum (the square one) before you move your
mouse at all the cross hairs end up in the wrong spot. As soon as you
move your mouse they correct to be under the mouse as expected.
Yes, that's wright. Also the crosshairs don't move on resize or when a
value is changed. The r, b and g vertical view dont do their jobs
correct (or at least on an other way then gimp ;-)).
Here is a patch to fix these issues and some minor things.
peter
Index: ewl_spectrum.c
===
RCS file: /var/cvs/e/e17/libs/ewl/src/lib/ewl_spectrum.c,v
retrieving revision 1.21
diff -u -r1.21 ewl_spectrum.c
--- ewl_spectrum.c 9 Apr 2006 15:59:33 - 1.21
+++ ewl_spectrum.c 10 Apr 2006 10:27:08 -
@@ -13,20 +13,30 @@
static void ewl_spectrum_hsv_from_rgb(Ewl_Spectrum *sp);
static void ewl_spectrum_rgb_from_hsv(Ewl_Spectrum *sp);
static void ewl_spectrum_draw(Ewl_Spectrum *sp);
-static void ewl_spectrum_mouse_process(Ewl_Spectrum *sp, unsigned int x,
- unsigned int y);
-
+static void ewl_spectrum_cross_hairs_draw(Ewl_Spectrum *sp);
+static void ewl_spectrum_mouse_process(Ewl_Spectrum *sp, int x, int y);
static void ewl_spectrum_hsv_to_rgb(double h, double s, double v,
- int *r, int *g, int *b);
+ int *r, int *g, int *b);
+static void ewl_spectrum_rgb_to_hsv(int r, int g, int b,
+ double *h, double *s, double *v);
static void ewl_spectrum_color_coord_map(Ewl_Spectrum *sp, int x, int y,
int w, int h, unsigned int *r,
unsigned int *g, unsigned int *b);
+static void ewl_spectrum_color_coord_xy_get(Ewl_Spectrum *sp, int *x, int *y,
+ int w, int h, unsigned int r,
+ unsigned int g, unsigned int b);
static void ewl_spectrum_color_coord_map_vertical(Ewl_Spectrum *sp, int y,
int img_h, unsigned int *r,
unsigned int *g, unsigned int *b);
static void ewl_spectrum_color_coord_map_square(Ewl_Spectrum *sp, int x,
int y, int img_w, int img_h, unsigned int *r,
unsigned int *g, unsigned int *b);
+static void ewl_spectrum_color_coord_vertical_y_get(Ewl_Spectrum *sp,
+ int *y, int img_h,
+ unsigned int r, unsigned int g, unsigned int b);
+static void ewl_spectrum_color_coord_square_xy_get(Ewl_Spectrum *sp,
+ int *x, int *y, int img_w, int img_h,
+ unsigned int r, unsigned int g, unsigned int b);
/**
* @return Returns a new Ewl_Spectrum widget or NULL on failure
@@ -56,7 +66,7 @@
/**
* @param sp: The Ewl_Spectrum to init
- * @return Returns TRUEE on success or FALSE on failure
+ * @return Returns TRUE on success or FALSE on failure
* @brief Initializes an Ewl_Specturm widget to default values
*/
int
@@ -309,6 +319,7 @@
CURRENT_W(sp), CURRENT_H(sp));
ewl_spectrum_draw(sp);
+ ewl_spectrum_cross_hairs_draw(sp);
DLEAVE_FUNCTION(DLEVEL_STABLE);
}
@@ -370,50 +381,31 @@
}
static void
-ewl_spectrum_mouse_process(Ewl_Spectrum *sp, unsigned int x, unsigned int y)
+ewl_spectrum_mouse_process(Ewl_Spectrum *sp, int x, int y)
{
Evas_Coord img_w, img_h;
unsigned int r, g, b;
- unsigned int mx, my;
DENTER_FUNCTION(DLEVEL_STABLE);
DCHECK_PARAM_PTR(sp, sp);
DCHECK_TYPE(sp, sp, EWL_SPECTRUM_TYPE);
+
+ x -= CURRENT_X(sp-canvas);
+ y -= CURRENT_Y(sp-canvas);
+
+ if (x 0)
+ x = 0;
+ if (y 0)
+ y = 0;
+ if (x CURRENT_W(sp-canvas))
+ x = CURRENT_W(sp-canvas);
+ if (y CURRENT_H(sp-canvas))
+ y = CURRENT_H(sp-canvas);
- if (x (CURRENT_X(sp-canvas) + CURRENT_W(sp-canvas)))
- x = CURRENT_X(sp-canvas) + CURRENT_W(sp-canvas);
- if (y (CURRENT_Y(sp-canvas) + CURRENT_H(sp-canvas)))
- y = CURRENT_Y(sp-canvas) + CURRENT_H(sp-canvas);
-
- mx = x - CURRENT_X(sp-canvas);
- my = y - CURRENT_Y(sp-canvas);
evas_object_image_size_get(EWL_IMAGE(sp-canvas)-image, img_w,
img_h);
- ewl_spectrum_color_coord_map(sp, mx, my, img_w, img_h, r, g, b);
+ ewl_spectrum_color_coord_map(sp, x, y, img_w, img_h, r, g, b);
ewl_spectrum_rgb_set(sp, r, g, b);
- /* place the horizontal cross hair */
- y -= CURRENT_H(sp-cross_hairs.horizontal) / 2;
-
[E-devel] ewl_spectrum
Hi all,
here is a patch for ewl_spectrum to set the cross hair on the right
position.
regards
peter
Index: ewl_spectrum.c
===
RCS file: /var/cvs/e/e17/libs/ewl/src/lib/ewl_spectrum.c,v
retrieving revision 1.20
diff -u -r1.20 ewl_spectrum.c
--- ewl_spectrum.c 22 Feb 2006 03:51:01 - 1.20
+++ ewl_spectrum.c 7 Apr 2006 20:10:55 -
@@ -318,7 +318,6 @@
{
Ewl_Spectrum *sp;
Ewl_Event_Mouse_Down *e;
- unsigned int x, y;
DENTER_FUNCTION(DLEVEL_STABLE);
DCHECK_PARAM_PTR(w, w);
@@ -330,15 +329,7 @@
ewl_callback_append(w, EWL_CALLBACK_MOUSE_MOVE,
ewl_spectrum_cb_mouse_move, NULL);
- x = e-x - CURRENT_X(w);
- y = e-y - CURRENT_Y(w);
-
- if (x (unsigned int)(CURRENT_X(sp-canvas) + CURRENT_W(sp-canvas)))
- x = (CURRENT_W(sp-canvas) - CURRENT_X(sp-canvas));
- if (y (unsigned int)(CURRENT_Y(sp-canvas) + CURRENT_H(sp-canvas)))
- y = (CURRENT_H(sp-canvas) - CURRENT_Y(sp-canvas));
-
- ewl_spectrum_mouse_process(sp, x, y);
+ ewl_spectrum_mouse_process(sp, e-x, e-y);
DLEAVE_FUNCTION(DLEVEL_STABLE);
}
@@ -348,7 +339,6 @@
{
Ewl_Spectrum *sp;
Ewl_Event_Mouse_Move *e;
- int x, y;
DENTER_FUNCTION(DLEVEL_STABLE);
DCHECK_PARAM_PTR(w, w);
@@ -357,15 +347,7 @@
sp = EWL_SPECTRUM(w);
e = ev;
- x = e-x - CURRENT_X(sp);
- y = e-y - CURRENT_Y(sp);
-
- if (x (CURRENT_X(sp-canvas) + CURRENT_W(sp-canvas)))
- x = (CURRENT_W(sp-canvas) - CURRENT_X(sp-canvas));
- if (y (CURRENT_Y(sp-canvas) + CURRENT_H(sp-canvas)))
- y = (CURRENT_H(sp-canvas) - CURRENT_Y(sp-canvas));
-
- ewl_spectrum_mouse_process(sp, x, y);
+ ewl_spectrum_mouse_process(sp, e-x, e-y);
DLEAVE_FUNCTION(DLEVEL_STABLE);
}
@@ -392,16 +374,25 @@
{
Evas_Coord img_w, img_h;
unsigned int r, g, b;
+ unsigned int mx, my;
DENTER_FUNCTION(DLEVEL_STABLE);
DCHECK_PARAM_PTR(sp, sp);
DCHECK_TYPE(sp, sp, EWL_SPECTRUM_TYPE);
+ if (x (CURRENT_X(sp-canvas) + CURRENT_W(sp-canvas)))
+ x = CURRENT_X(sp-canvas) + CURRENT_W(sp-canvas);
+ if (y (CURRENT_Y(sp-canvas) + CURRENT_H(sp-canvas)))
+ y = CURRENT_Y(sp-canvas) + CURRENT_H(sp-canvas);
+
+ mx = x - CURRENT_X(sp-canvas);
+ my = y - CURRENT_Y(sp-canvas);
evas_object_image_size_get(EWL_IMAGE(sp-canvas)-image, img_w,
img_h);
- ewl_spectrum_color_coord_map(sp, x, y, img_w, img_h, r, g, b);
+ ewl_spectrum_color_coord_map(sp, mx, my, img_w, img_h, r, g, b);
ewl_spectrum_rgb_set(sp, r, g, b);
/* place the horizontal cross hair */
+ y -= CURRENT_H(sp-cross_hairs.horizontal) / 2;
ewl_object_position_request(EWL_OBJECT(sp-cross_hairs.horizontal),
CURRENT_X(sp), y);
ewl_object_w_request(EWL_OBJECT(sp-cross_hairs.horizontal),
@@ -413,6 +404,7 @@
/* place the vertical cross hair if needed */
if (sp-type == EWL_SPECTRUM_TYPE_SQUARE)
{
+ x -= CURRENT_W(sp-cross_hairs.vertical) / 2;
ewl_object_position_request(EWL_OBJECT(sp-cross_hairs.vertical),
x, CURRENT_Y(sp));
ewl_object_h_request(EWL_OBJECT(sp-cross_hairs.vertical),
Re: [E-devel] Ewl_Menu in Ewl_Embed
Nathan Ingersoll schrieb:
Thanks for the information Peter. That line would definitely cause
that warning to be printed. Looks like we need to register an ecore_x
callback for the configure event on the embed and store the window
position information.
Here is a patch to solve the problem. It moves ewl_window_postion_get()
to ewl_embed_window_position_get() and adds ewl_embed_position_get(). I
don't know if the last one is really needed, so you can also remove it.
Actually the menu doesn't need it.
ciao
peter
? .cvsignore
Index: ewl_datepicker.c
===
RCS file: /var/cvs/e/e17/libs/ewl/src/lib/ewl_datepicker.c,v
retrieving revision 1.10
diff -u -r1.10 ewl_datepicker.c
--- ewl_datepicker.c17 Feb 2006 06:43:33 - 1.10
+++ ewl_datepicker.c6 Apr 2006 20:09:06 -
@@ -157,7 +157,7 @@
/* Get the position of the parent */
emb = ewl_embed_widget_find(EWL_WIDGET(dp));
if (emb) {
- ewl_window_position_get(EWL_WINDOW(emb), x, y);
+ ewl_embed_window_position_get(emb, x, y);
ewl_object_current_size_get(EWL_OBJECT(dp), sx, sy);
ewl_window_move(EWL_WINDOW(dp-calendar_window), x + (sx / 4),
y + sy + 3);
Index: ewl_embed.c
===
RCS file: /var/cvs/e/e17/libs/ewl/src/lib/ewl_embed.c,v
retrieving revision 1.54
diff -u -r1.54 ewl_embed.c
--- ewl_embed.c 31 Mar 2006 06:31:42 - 1.54
+++ ewl_embed.c 6 Apr 2006 20:09:20 -
@@ -1502,6 +1502,53 @@
DLEAVE_FUNCTION(DLEVEL_STABLE);
}
+/**
+ * @param e: the embed to query for position
+ * @param x: a pointer to the integer that should receive the x coordinate
+ * @param y: a pointer to the integer that should receive the y coordinate
+ * @return Returns no value.
+ * @brief Retrieve the position of the embed
+ *
+ * Stores the embed position into the parameters @a x and @a y.
+ */
+void
+ewl_embed_position_get(Ewl_Embed *e, int *x, int *y)
+{
+ int sx, sy;
+
+ DENTER_FUNCTION(DLEVEL_STABLE);
+ DCHECK_PARAM_PTR(e, e);
+ DCHECK_TYPE(e, e, EWL_EMBED_TYPE);
+
+ evas_object_geometry_get(e-smart, sx, sy, NULL, NULL);
+ if (x) *x = e-x + sx;
+ if (y) *y = e-y + sy;
+
+ DLEAVE_FUNCTION(DLEVEL_STABLE);
+}
+
+/**
+ * @param e: the embed to query for window-position
+ * @param x: a pointer to the integer that should receive the x coordinate
+ * @param y: a pointer to the integer that should receive the y coordinate
+ * @return Returns no value.
+ * @brief Retrieve the position of the window
+ *
+ * Stores the window position into the parameters @a x and @a y.
+ */
+void
+ewl_embed_window_position_get(Ewl_Embed *e, int *x, int *y)
+{
+ DENTER_FUNCTION(DLEVEL_STABLE);
+ DCHECK_PARAM_PTR(e, e);
+ DCHECK_TYPE(e, e, EWL_EMBED_TYPE);
+
+ if (x) *x = e-x;
+ if (y) *y = e-y;
+
+ DLEAVE_FUNCTION(DLEVEL_STABLE);
+}
+
void
ewl_embed_realize_cb(Ewl_Widget *w, void *ev_data __UNUSED__,
void *user_data __UNUSED__)
Index: ewl_embed.h
===
RCS file: /var/cvs/e/e17/libs/ewl/src/lib/ewl_embed.h,v
retrieving revision 1.16
diff -u -r1.16 ewl_embed.h
--- ewl_embed.h 15 Mar 2006 04:03:48 - 1.16
+++ ewl_embed.h 6 Apr 2006 20:09:21 -
@@ -70,6 +70,9 @@
Ewl_Widget *mouse_in; /** Last widget to receive a mouse_in */
} last; /** Collection of widgets to last receive
events */
+ int x; /** Screen relative horizontal position of window */
+ int y; /** Screen relative vertical position of window */
+
Ewl_Widget *dnd_widget; /** The current DND widget */
};
@@ -132,6 +135,8 @@
int *x, int *y);
void ewl_embed_mouse_cursor_set(Ewl_Widget *w);
+void ewl_embed_position_get(Ewl_Embed *e, int *x, int *y);
+void ewl_embed_window_position_get(Ewl_Embed *e, int *x, int *y);
/*
* Internally used callbacks, override at your own risk.
Index: ewl_events.c
===
RCS file: /var/cvs/e/e17/libs/ewl/src/lib/ewl_events.c,v
retrieving revision 1.25
diff -u -r1.25 ewl_events.c
--- ewl_events.c28 Mar 2006 12:25:38 - 1.25
+++ ewl_events.c6 Apr 2006 20:09:25 -
@@ -217,26 +217,33 @@
*/
Ecore_X_Event_Window_Configure *ev;
Ewl_Window *window;
+ Ewl_Embed *embed;
DENTER_FUNCTION(DLEVEL_STABLE);
ev = e;
- window = ewl_window_window_find((void *)ev-win);
- if (!window)
+ embed = ewl_embed_evas_window_find((void *)ev-win);
+ if (!embed)
DRETURN_INT(TRUE, DLEVEL_STABLE);
[E-devel] Ewl_Menu in Ewl_Embed
Hi ewl-devs,
Some days ago I started with the rewrite of the elitaire context menu. I
use a smilar approach like the Ewl_Iconbox - a floater holding the
Ewl_Menu. This works well in an Ewl_Window, but when I use it in an
Ewl_Embed as I was planing it, because the main elitaire window isn't a
Ewl_Window, it causes error messages and doesn't work correctly:
* Ewl Developer Warning * :
To find where this is occurring set a breakpoint
for the function ewl_print_warning.
This program is calling:
ewl_window_position_get();
With the paramter:
win
as the wrong type. (:widget::container::overlay::embed:) instead
of (window).
Please fix your program.
IMO the problem lies in this function:
void
ewl_menu_configure_cb(Ewl_Widget *w, void *ev_data __UNUSED__,
void *user_data __UNUSED__)
{
int x, y;
Ewl_Menu *menu;
Ewl_Embed *emb;
DENTER_FUNCTION(DLEVEL_STABLE);
DCHECK_PARAM_PTR(w, w);
DCHECK_TYPE(w, w, EWL_WIDGET_TYPE);
menu = EWL_MENU(w);
emb = ewl_embed_widget_find(w);
ewl_window_position_get(EWL_WINDOW(emb), x, y); // HERE
menu-popup_x = x + CURRENT_X(w);
menu-popup_y = y + CURRENT_Y(w);
ewl_menu_popup_move_cb(menu-base.popup, NULL, w);
DLEAVE_FUNCTION(DLEVEL_STABLE);
}
So in my case the emb isn't also an Ewl_Window, but just an Ewl_Embed.
Perhaps it is possible to move the ewl_window_position_get() to
ewl_embed_position_get()
and return the evas position plus the evas_object position (this should
be 0 , 0 in case of Ewl_Window). But I havent looked deep enough into
the code to see if this would work or not.
thanks
peter
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] elitaire 0.0.6
Hi all, I'm back from Italy, where I've studied the last semester. There is now a new version of elitaire available. For those never heard of elitaire, elitaire is a solitaire card game using the efl. There are some new features like highscore, statistics, restart, e17ish theme etc. and some new variants like spider, baker's dozen, vegas etc. Get it here: http://www.mowem.de/elitaire/elitaire-0.0.6.tar.bz2 Have a lot of fun peter P.S. Yes I know the context menu doesn't work properly. I hope I can fix it in the next version. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[Fwd: Re: [E-devel] elitaire 0.0.6]
I forgot the list. ---BeginMessage--- Hawkwind schrieb: After doing ./configure make sudo make install I get no errors. However, how does one run the application ? There seems to be no elitaire executable, and if you try to load it as a module it errors and doesn't load. The default installation prefix is /usr/local/games. So probably you haven't got /usr/local/games/bin in your $PATH-variable. There are two ways you can go: 1. execute /usr/local/games/bin/elitaire 2. or reinstall it with ./configure --prefix=/usr/local or --prefix=/usr It was a stupid idea of mine to set the default prefix to /usr/local/games. I will change it in the next version. Sorry peter ---End Message---
Re: [E-devel] elitaire-0.0.4 make error
Laurence Vanek schrieb: while attempting to make elitaire I get the following: == playingCard.h:33: error: ISO C++ forbids declaration of ‘cardDeck’ with no t ype playingCard.h:33: error: expected ‘;’ before ‘*’ token playingCard.h:42: error: ‘cardDeck’ has not been declared playingCard.h: In constructor ‘playingCard::playingCard(short int, bool, int*) ’: playingCard.h:46: error: ‘myDeck’ was not declared in this scope playingCard.h: In constructor ‘cardDeck::cardDeck(char, char, bool)’: playingCard.h:77: error: no matching function for call to ‘playingCard::playin gCard(short int, bool, cardDeck* const)’ playingCard.h:42: note: candidates are: playingCard::playingCard(short int, bool , int*) playingCard.h:28: note: playingCard::playingCard(const playingCa rd) make[2]: *** [gui.o] Error 1 make[2]: Leaving directory `/root/elitaire-0.0.4/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/elitaire-0.0.4' make: *** [all] Error 2 I am running updated Fedora Core 4, with gcc: gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) Yes it seems to be a gcc 4 problem. Unfortunatelly I don't use gcc4 so I didn't recognize it. There is now a new version (0.0.5) available, which should work now, thanks to Nick's patch. Also I applyed the patches from Justin. So I hope building works now for all (most). Thanks to all peat --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] elitaire 0.0.4
Hi, elitaire-0.0.4 is now available. Here is short list of what is changed: * add native language support * add configure and about windows = ewl deps * remember configuration * add thoughtful solitaire variante * only borderless if the theme is supporting this * new theme, namely simple * removed hardcoded paths * add undo So if you are interessed, here you get it: www.mowem.de/elitaire Have a lot of fun peat P.S. Sorry, I've used the asprintf() function, before I read that it isn't very portable. I hope it is removed in the next version. But I think on the most systems (GNU, *BSD, OSX) it should work. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elitaire - an efl based solitaire
Daniel Kozlowski schrieb: Well i said this before but i don't think it made it out there is a small compile error on my computer when i attempted to make the program it was fixed by changing line 912 from this m = eli_card-eli-velocity * 0.02 / sqrt( pow( to_x - from_x, 2) + pow( to_y - from_y ,2)); to this m = eli_card-eli-velocity * 0.02 / sqrt( pow( to_x - from_x, 2.0) + pow( to_y - from_y ,2.0)); thanks, I now found a very simple way to avoid this. A x * x do the same job like a pow( (double) x, 2.0). By the way, I've got now a very little home page, where you can find the latest version (0.0.2). It's now with autoconf and automake and a theme selector. Here's the page: http://www.mowem.de/elitaire/ peat --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] elitaire - an efl based solitaire
elitaire is an efl based solitaire card game. It's written in C / C++. At the moment there are only freecell and klondike. Resizing works for now only in the right bottom border. So if you are interested in. You'll find it here: www.mowem.de/elitaire/elitaire-2005-05-12.tar.bz2 So have a lot of fun! peat P.S. I have used the sources of Esmart_Draggies. Where should I mention this. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
