[E-devel] Dernier version de edje_match
Hey,
Cedric sent me his last version of his code to replace fn_match in edje
(see attachment).
As fnmatch is used in eet and evas too, and as fnmatch is not avaialble in
some platform, I would like to know if it would be a good idea to ave our
own implementation of the features of fnmatch we use in these 3 libraries.
If so, what about adding it in an existing library ?
Vincentdiff -Nrua -X exclude.cvs e17-clean/libs/edje/src/lib/edje_load.c e17-dev/libs/edje/src/lib/edje_load.c
--- e17-clean/libs/edje/src/lib/edje_load.c 2007-12-18 18:48:06.0 +0100
+++ e17-dev/libs/edje/src/lib/edje_load.c 2007-12-17 17:02:53.0 +0100
@@ -158,15 +158,16 @@
{
if (edf-collection_dir)
{
- Evas_List *l;
+ Edje_Patterns *patterns;
- for (l = edf-collection_dir-entries; l; l = l-next)
- {
- Edje_Part_Collection_Directory_Entry *ce;
-
- ce = l-data;
- if (_edje_glob_match(ce-entry, glob)) return 1;
- }
+ patterns = edje_match_collection_dir_init(edf-collection_dir-entries);
+ if (edje_match_collection_dir_exec(patterns,
+glob))
+ {
+ edje_match_patterns_free(patterns);
+ return 1;
+ }
+ edje_match_patterns_free(patterns);
}
_edje_cache_file_unref(edf);
}
diff -Nrua -X exclude.cvs e17-clean/libs/edje/src/lib/edje_match.c e17-dev/libs/edje/src/lib/edje_match.c
--- e17-clean/libs/edje/src/lib/edje_match.c 1970-01-01 01:00:00.0 +0100
+++ e17-dev/libs/edje/src/lib/edje_match.c 2008-01-04 15:20:08.0 +0100
@@ -0,0 +1,570 @@
+#include stdlib.h
+#include stddef.h
+#include Evas.h
+
+#include Edje.h
+#include edje_private.h
+
+/* States manipulations. */
+
+typedef struct _Edje_State Edje_State;
+struct _Edje_State
+{
+ size_tidx;
+ size_tpos;
+};
+
+typedef struct _Edje_States Edje_States;
+struct _Edje_States
+{
+ size_t size;
+ Edje_State*states;
+ _Bool *has;
+};
+
+static void
+_edje_match_states_free(Edje_States *states,
+size_tstates_size)
+{
+ (void) states_size;
+ free(states);
+}
+
+#define ALIGN(Size) \
+ { \
+ Size--;\
+ Size |= sizeof (void*) - 1;\
+ Size++;\
+ };
+
+static Edje_States*
+_edje_match_states_alloc(size_t n,
+ size_t patterns_size,
+ size_t patterns_max_length)
+{
+ Edje_States *l;
+
+ const size_t array_len = (patterns_max_length + 1) * patterns_size;
+
+ size_t states_size;
+ size_t has_size;
+ size_t states_has_size;
+ size_t struct_size;
+
+ unsigned char*states;
+ unsigned char*has;
+
+ size_ti;
+
+ states_size = sizeof (*l-states) * array_len;
+ ALIGN(states_size);
+
+ has_size = sizeof (*l-has) * array_len;
+ ALIGN(has_size);
+
+ states_has_size = states_size + has_size;
+
+ struct_size = sizeof (*l);
+ ALIGN(struct_size);
+ struct_size += states_has_size;
+
+ l = malloc(n * struct_size);
+ if (!l) return NULL;
+
+ states = (unsigned char *) (l + n);
+ has = states + states_size;
+
+ for (i = 0; i n; ++i)
+ {
+l[i].states = (Edje_State *) states;
+l[i].has = (_Bool *) has;
+states += states_has_size;
+has += states_has_size;
+ }
+
+ return l;
+}
+
+static void
+_edje_match_states_insert(Edje_States*list,
+ size_t patterns_max_length,
+ size_t idx,
+ size_t pos)
+{
+ {
+ const size_t i = idx * (patterns_max_length + 1) + pos;
+
+ if (list-has[i]) return;
+ list-has[i] = 1;
+ }
+
+ const size_t i = list-size;
+
+ list-states[i].idx = idx;
+ list-states[i].pos = pos;
+ ++list-size;
+}
+
+static void
+_edje_match_states_clear(Edje_States *list,
+ size_t patterns_size,
+ size_t patterns_max_length)
+{
+ list-size = 0;
+ memset(list-has, 0, patterns_size * (patterns_max_length + 1) * sizeof (*list-has));
+}
+
+/* Token manipulation. */
+
+enum status
+ {
+patterns_not_found = 0,
+patterns_found = 1,
+patterns_syntax_error = 2
+ };
+
+static size_t
+_edje_match_patterns_exec_class_token(enum status *status,
+ const char *cl_tok,
+ char c)
+{
+ if (! *cl_tok)
+{
+ *status = patterns_syntax_error;
+ return 0;
+}
+ else if (cl_tok[1] == '-' cl_tok[2] != ']')
+{
+ if (*cl_tok = c c = cl_tok[2])
+ *status = patterns_found;
+ return 3;
+}
+ else
+{
+ if (c == *cl_tok)
+
Re: [E-devel] Bang Revival !!
Hi Dave, Hi dave, I found a bug this week end when I try to use bang. Actually it makes e crashing when the composite extension is not enabled. The error comes from the errorhandler section in the debugging part at the line o = e-error_code - compDisplays-damageError which should be replaced by this o = e-error_code; if(compDisplays) o-= compDisplays-damageError; Thanks, fixed... but the real problem is that bang attach the x error handler with: XSetErrorHandler (errorHandler); and never release it (so the function is called also when bang didn't exist anymore)... some know the X function to remove the handler? I didn't found it :( Searching on google gave me one hack to reverse back to the old configuration. Actually it seems that there is no functions reversing back to the old configuration in Xlib so we have to do it ourself. After searching I found this way static XErrorHandler old_handler = (XErrorHandler) 0 ; /* this variable is needed to obtain the address of the actual ErrorHandler function (for instance the one defined in the toolkit) in the function that call XsetErrorHandler put this /* Install our error handler to override Xlib's termination behavior */ old_handler = XSetErrorHandler(ApplicationErrorHandler) ; and put this line before finishing the application /* Restore original X handler */ /* Assumption: the X queue has been temporarily flushed/synchronized */ /* at the end of the application-critical code, otherwise a possible */ /* asynchronously arriving error might arrive further down the stream */ /* after the original handlers are restored. */ /* XFlush(display) */ /* XSync(display, False) ; */ XSetErrorHandler(old_handler); return whatever you want. It seems that it is the only way to restore the initial ErrorHandler function, but confirmation or suggestion from people familiar with xlib are welcome of course :-) ciao Mathieu - 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] Nightly build log for E17 on 2008-01-15 14:42:06 -0800
On Wed, 16 Jan 2008 23:59:07 +0100 Brian 'morlenxus' Miculcy [EMAIL PROTECTED] wrote: The used easy_e17 version is simply not up to date, someone should replace it with the svn version or the latest stable version... Should be taken care of now. I updated the script while it was running, so the next results might be screwed up. signature.asc Description: PGP signature - 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] Edje improvement
On Tue, 18 Dec 2007 19:12:46 +0100 Cedric BAIL [EMAIL PROTECTED] babbled: Hi, I have been working on some little improvement for Edje recently. The first patch, edje_data_file.diff, add support for a data.file entry inside edc file. It give the possibility to put text file inside edje directy. It hmm - ok. sounds ok to me - using that for copyrights and such? note - your patch has bugs. you snprintf the mmaped() data - which is not guaranteed to be 0 byte terminated. snprintf is going a bit far there. just a malloc() of the file size + 1, a read() into the malloced buffer and set the last byte of the buffer as 0 will do the job fine. :) also provide EDJE_FILL_TYPE_TILE_WIDTH and EDJE_FILL_TYPE_TILE_HEIGHT for fill.type, this give the possibility to scale in one direction, and repeat tile in the other direction. This patch is small and will not impact existing edje application. ummm that already is possible. set the fill.size.relative in one dimension to 0.0 and the other 1.0 then use fill.size.offset to define the tile size in pixels for the dimension u set to 0.0 and 0 for the one at 1.0. you should know the dimensions of your image at edje_cc time so getting the image size runtime is only a convenience. so the patch for this needs some fixing - the fill stuff imho is not needed. I also provide a rerun of eet race condition patch. It should apply correctly and it should not break any thing also. can you describe the race condition it fixes? about half the patch as i'm reading it is moving of code around and whitespace changes so i'm not able to really see what it fixes and how? The last patch is a more complex patch and need carefull review. It replace fnmatch by a edje specific match. We did it with a friend, Thomas Claveirole, and it work like fnmatch. We did make it work like edje_glob_match, it recognize [], ? and *. As it replace all fnmatch call inside edje, it could break any existing edje applications, if we didn't handle all case correctly. So if you have time, apply this patch to your CVS and test all edje application you have (with and without the patch ofcourse). This replacement of fnmatch should be more easy to port to other system and it could be faster than the original fnmatch version. problem. you don't match '.' (single character). i.e. blah.blah would match blahXblah blah-blah blahhblah but not blahblah. A last topic I would like to discuss is FPU need by Edje. Right now without hardware floatting point, Edje could loose around 30% of time in soft float when you have many objects on the screen. I don't know what would be the best solution to this problem, doing some fixed point calculation or caching result, updating them when required. If people have idea on this I would like to ear as it is something I want to fix. i think i'd want to see some real performance numbers here. i do know edje has a habit of over-calculating. it really does calculate a LOT. possibly much more than it should. any fp heaviness is probably not a result of fp math itself but just that edje calculates too much. we possibly should focus on reducing calculations in general first. one example would be to queue recalculations per object until you force a calc via edje_object_calc_force() or until idle time. that could remove a lot. min size calcs are also slow. we could cache this value for an object if nothing changed that would affect its size. moving some core of some calcs to be fixed point or pure integer could help too. most of the calcs FIRST promote TO floating point - then do it all in fp, then go back to integer at the end. but i'd do this as a final step in this fix list. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] Edje improvement
I have been working on some little improvement for Edje recently. The first patch, edje_data_file.diff, add support for a data.file entry inside edc file. It give the possibility to put text file inside edje directy. hmm - ok. sounds ok to me - using that for copyrights and such? Sounds potentially useful - one could even use it to embedd other text-based file formats...? One thing that edje/edc may need is a means of 'typing' the various kinds of edjes. Right now, all these .edj files are used to define a very large and disparate number of things How does one know if it's an e17 bg, some clock thing, an etk or ewl theme, an icon, some menu or dialog theme, or who knows what others may use them to define. This kind of thing can become a problem over time. Maybe time for some way of specifying WHAT these edj files are supposed to be - perhaps something akin to what's done with mime- types... maybe some 'type', 'category', 'description' sorts of data in the edj/edc file (maybe with versions as well)? Anyone have any suggestions on this? jose. _ Save hundreds on an Unsecured Loan - Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m3iUASETfimAwEe8X9bUmPtTpfLDeW14o6KQy9FK3cdqdWw/ - 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] Show disabled style of entry
On Jan 17, 2008 3:44 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Sun, 13 Jan 2008 18:57:56 -0300 schrieb Gustavo Sverzut Barbieri: On Jan 13, 2008 6:16 PM, Adriano Rezende [EMAIL PROTECTED] wrote: On Jan 13, 2008 3:03 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Sat, 12 Jan 2008 19:44:40 -0300 schrieb Adriano Rezende: I believe you have to emit the signal to sd-editable_object-text_object Search for the following code in your e_entry.c | sd-editable_object = o; | e_editable_theme_set(o, base/theme/widgets, e/widgets/entry); and follow the method e_editable_theme_set. I just took a fast look at the code, so I recommend to test before. Thanks for that hint. I did a better patch and it works now. I think the visual improvement is really nice. http://tux-style.de/tmp/tclock_deactivated_gray.png Now users could see that a text entry is deactivated. I've created a new bug entry about that topic: http://bugzilla.enlightenment.org/show_bug.cgi?id=357 Please review the patch if possible. Commit it or allow me to commit if the patch looks good. Sorry, I don't work on this project. But probably the owner will see the patch and apply the changes. :-) Andreas, Patch looks really small and yes, maybe applied by raster one he have the time to check. As I'm not used to E code, just found something weird with the existing code: edje_object_signal_emit(entry, e,state,enabled, e); Ok, as you noticed correct it was there before my modifications. since entry is not (at least looks like it's not) an Edje object, this will have no effect due defensive programming, edje_object_signal_emit() will find no Edje * with _edje_fetch(obj) and then will return. I just noticed that because I think the signal should be sent to sd-entry_object, not sd-editable_object, it would allow us even to set a clipper and make it transparent, thus disabled items could be semi-transparent! :-) If I'm right and the above code is bogus, then it's just a matter of using sd-entry_object instead of entry, add the theme part and we're done. I think my patch looks good so far. Not sure about the yet existing code. Please one of the E developers should give me the ok for commit the patch. I'll to create some more theme patches in the future and like to know if it's ok this way. Sorry, but if I'm correct and the existing code is wrong, then your patch is useless. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - 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] Show disabled style of entry
Am Thu, 17 Jan 2008 18:00:28 -0300 schrieb Gustavo Sverzut Barbieri: On Jan 17, 2008 3:44 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Sun, 13 Jan 2008 18:57:56 -0300 schrieb Gustavo Sverzut Barbieri: On Jan 13, 2008 6:16 PM, Adriano Rezende [EMAIL PROTECTED] wrote: On Jan 13, 2008 3:03 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Sat, 12 Jan 2008 19:44:40 -0300 schrieb Adriano Rezende: I believe you have to emit the signal to sd-editable_object-text_object Search for the following code in your e_entry.c | sd-editable_object = o; | e_editable_theme_set(o, base/theme/widgets, e/widgets/entry); and follow the method e_editable_theme_set. I just took a fast look at the code, so I recommend to test before. Thanks for that hint. I did a better patch and it works now. I think the visual improvement is really nice. http://tux-style.de/tmp/tclock_deactivated_gray.png Now users could see that a text entry is deactivated. I've created a new bug entry about that topic: http://bugzilla.enlightenment.org/show_bug.cgi?id=357 Please review the patch if possible. Commit it or allow me to commit if the patch looks good. Sorry, I don't work on this project. But probably the owner will see the patch and apply the changes. :-) Andreas, Patch looks really small and yes, maybe applied by raster one he have the time to check. As I'm not used to E code, just found something weird with the existing code: edje_object_signal_emit(entry, e,state,enabled, e); Ok, as you noticed correct it was there before my modifications. since entry is not (at least looks like it's not) an Edje object, this will have no effect due defensive programming, edje_object_signal_emit() will find no Edje * with _edje_fetch(obj) and then will return. I just noticed that because I think the signal should be sent to sd-entry_object, not sd-editable_object, it would allow us even to set a clipper and make it transparent, thus disabled items could be semi-transparent! :-) If I'm right and the above code is bogus, then it's just a matter of using sd-entry_object instead of entry, add the theme part and we're done. I think my patch looks good so far. Not sure about the yet existing code. Please one of the E developers should give me the ok for commit the patch. I'll to create some more theme patches in the future and like to know if it's ok this way. Sorry, but if I'm correct and the existing code is wrong, then your patch is useless. Perhaps there's a wrong understanding. Do you say it was wrong before? Then my patch does even not take it worse. And the result is as desired if you look at the screenshot that I attached to the bug report. regards Andreas - 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] Show disabled style of entry
On Jan 17, 2008 6:13 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Thu, 17 Jan 2008 18:00:28 -0300 schrieb Gustavo Sverzut Barbieri: On Jan 17, 2008 3:44 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Sun, 13 Jan 2008 18:57:56 -0300 schrieb Gustavo Sverzut Barbieri: On Jan 13, 2008 6:16 PM, Adriano Rezende [EMAIL PROTECTED] wrote: On Jan 13, 2008 3:03 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Sat, 12 Jan 2008 19:44:40 -0300 schrieb Adriano Rezende: I believe you have to emit the signal to sd-editable_object-text_object Search for the following code in your e_entry.c | sd-editable_object = o; | e_editable_theme_set(o, base/theme/widgets, e/widgets/entry); and follow the method e_editable_theme_set. I just took a fast look at the code, so I recommend to test before. Thanks for that hint. I did a better patch and it works now. I think the visual improvement is really nice. http://tux-style.de/tmp/tclock_deactivated_gray.png Now users could see that a text entry is deactivated. I've created a new bug entry about that topic: http://bugzilla.enlightenment.org/show_bug.cgi?id=357 Please review the patch if possible. Commit it or allow me to commit if the patch looks good. Sorry, I don't work on this project. But probably the owner will see the patch and apply the changes. :-) Andreas, Patch looks really small and yes, maybe applied by raster one he have the time to check. As I'm not used to E code, just found something weird with the existing code: edje_object_signal_emit(entry, e,state,enabled, e); Ok, as you noticed correct it was there before my modifications. since entry is not (at least looks like it's not) an Edje object, this will have no effect due defensive programming, edje_object_signal_emit() will find no Edje * with _edje_fetch(obj) and then will return. I just noticed that because I think the signal should be sent to sd-entry_object, not sd-editable_object, it would allow us even to set a clipper and make it transparent, thus disabled items could be semi-transparent! :-) If I'm right and the above code is bogus, then it's just a matter of using sd-entry_object instead of entry, add the theme part and we're done. I think my patch looks good so far. Not sure about the yet existing code. Please one of the E developers should give me the ok for commit the patch. I'll to create some more theme patches in the future and like to know if it's ok this way. Sorry, but if I'm correct and the existing code is wrong, then your patch is useless. Perhaps there's a wrong understanding. Do you say it was wrong before? Then my patch does even not take it worse. And the result is as desired if you look at the screenshot that I attached to the bug report. I'm saying that current code (already commited, in CVS) looks like it was trying to do that, but it is wrong and thus is not working. If the code is fixed and it should work without any patch to _code_ (but we still require the theme patch, modified). I'm talking about e_entry.c line 294: edje_object_signal_emit(entry, e,state,enabled, e); entry is the smart object, not an edje file, so it is doing nothing (due defensive programming in edje_object_signal_emit(), check the code). If this code reads: edje_object_signal_emit(sd-entry_object, e,state,enabled, e); and e/widgets/entry is changed (.edc), then it should work as you want. Notes: 1) I'd use sd-entry_object instead of sd-editable_object because this would free us to do more things, since the editable_object is swallowed inside entry_object, thus we can do things like apply a clipper and change its color, graying it or even making it transparent. 2) I'd not add yet another API call to editable. That's my understanding, what do you think about it? -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - 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] [RFC] get-e.org integration in wallpaper configuration module
Hi, here's the result of my first work on E's internals (and widgets):
i wrote a simple addon that allow to select a wallpaper directly from
get-e.org, actually only from static backgrounds.
Requirements:
ecore_file with libcurl support(updated 14 january)
How it works:
My module get and parse a RSS feed from get-e.org, obtaining a list of
images of static backgrounds that actually are available on get-e.org,
downloading all images and shows it in efm. When you choose an image
and click OK, the module get the real background you've choose,
already in edj format, and copy it into ~/.e/e/backgrounds. Now the
new wallpaper is available in the first window of wallpaper
configuration dialog.
Status:
This is a preview. It works (just tested 5 minutes ago), and it works
fine also without DSL connection (i'm testing it with GPRS/UMTS). I'm
sure that something can be done in a better way, and it miss some cool
features, like caching of results to avoid useless connections, and
proxy support (i'm not sure but i think that it will be done by
libcurl internals).
Todo:
Implement a way to use a image cache to avoid connections
Test in proxy environment
Animated backgrounds support
Other sites support (Flickr,DeviantArt,...)
Thanks:
devilhorns and morlenxus for initial support, exhibit's guys for
example code, raster for enthusiasm, kainx and englebass for support
to make the attached diff :)
If you like this way to get backgrounds from get-e.org, there's two
other things that can be done easily in the same way: 0) animated
backgrounds, 1) themes.
Feel free to send a comment, to hate/love/commit it.
Regards
Massimiliano
Index: Makefile.am
===
RCS file: /var/cvs/e/e17/apps/e/src/modules/conf_wallpaper/Makefile.am,v
retrieving revision 1.1
diff -u -r1.1 Makefile.am
--- Makefile.am 4 Jul 2007 15:09:24 - 1.1
+++ Makefile.am 17 Jan 2008 22:44:43 -
@@ -25,7 +25,9 @@
e_int_config_wallpaper_gradient.h \
e_int_config_wallpaper.h \
e_int_config_wallpaper_import.c \
- e_int_config_wallpaper_import.h
+ e_int_config_wallpaper_import.h \
+ e_int_config_wallpaper_web.c \
+ e_int_config_wallpaper_web.h
module_la_LIBADD = @e_libs@ @dlopen_libs@
module_la_LDFLAGS = -module -avoid-version
Index: e_int_config_wallpaper.c
===
RCS file: /var/cvs/e/e17/apps/e/src/modules/conf_wallpaper/e_int_config_wallpaper.c,v
retrieving revision 1.8
diff -u -r1.8 e_int_config_wallpaper.c
--- e_int_config_wallpaper.c 14 Dec 2007 16:34:47 - 1.8
+++ e_int_config_wallpaper.c 17 Jan 2008 22:44:46 -
@@ -55,6 +55,7 @@
/* dialogs */
E_Win *win_import;
E_Dialog *dia_gradient;
+ E_Dialog *dia_web;
};
EAPI E_Config_Dialog *
@@ -151,6 +152,15 @@
cfdata-dia_gradient = NULL;
}
+EAPI void
+e_int_config_wallpaper_web_done(E_Config_Dialog *dia)
+{
+ E_Config_Dialog_Data *cfdata;
+
+ cfdata = dia-cfdata;
+ cfdata-dia_web = NULL;
+}
+
EAPI void
e_int_config_wallpaper_handler_set(Evas_Object *obj, const char *path, void *data)
{
@@ -381,6 +391,18 @@
}
static void
+_cb_web(void *data1, void *data2)
+{
+ E_Config_Dialog_Data *cfdata;
+
+ cfdata = data1;
+ if (cfdata-dia_web)
+ e_win_raise(cfdata-dia_web-win);
+ else
+ cfdata-dia_web = e_int_config_wallpaper_web(cfdata-cfd);
+}
+
+static void
_fill_data(E_Config_Dialog_Data *cfdata)
{
char path[4096];
@@ -460,6 +482,8 @@
e_int_config_wallpaper_del(cfdata-win_import);
if (cfdata-dia_gradient)
e_int_config_wallpaper_gradient_del(cfdata-dia_gradient);
+ if (cfdata-dia_web)
+ e_int_config_wallpaper_web_del(cfdata-dia_web);
E_FREE(cfdata-bg);
E_FREE(cfd-data);
E_FREE(cfdata);
@@ -558,6 +582,12 @@
ow = e_widget_button_add(evas, _(Gradient...), enlightenment/gradient,
_cb_gradient, cfdata, NULL);
e_widget_table_object_append(ot, ow, 1, 1, 1, 1, 1, 0, 0, 0);
+ if (ecore_file_download_protocol_available(http://;))
+ {
+ ow = e_widget_button_add(evas, _(Website...), enlightenment/website,
+ _cb_web, cfdata, NULL);
+ e_widget_table_object_append(ot, ow, 2, 1, 1, 1, 1, 0, 0, 0);
+ }
mw = 320;
mh = (320 * zone-h) / zone-w;
@@ -704,6 +734,12 @@
ow = e_widget_button_add(evas, _(Gradient...), enlightenment/gradient,
_cb_gradient, cfdata, NULL);
e_widget_table_object_append(ot, ow, 1, 1, 1, 1, 1, 0, 0, 0);
+ if (ecore_file_download_protocol_available(http://;))
+ {
+ ow = e_widget_button_add(evas, _(Website...), enlightenment/website,
+ _cb_web, cfdata, NULL);
+ e_widget_table_object_append(ot, ow, 2, 1, 1, 1, 1, 0, 0, 0);
+ }
mw = 320;
mh = (320 * zone-h) / zone-w;
Index: e_int_config_wallpaper_web.c
===
RCS file: e_int_config_wallpaper_web.c
diff -N e_int_config_wallpaper_web.c
---
Re: [E-devel] Ecore_Fb + libts
On Jan 5, 2008 9:02 PM, Tobias [EMAIL PROTECTED] wrote: Hi all, I've played around with Ecore_Fb on my zaurus and I've run into some problems with events getting through to evas. First, there were some comments about libts support in ecore a couple of weeks ago, this libts implementation (ecore_fb_ts_c) seems to be very ipaq specific, and is not used anywhere and deprecated. Hi Tobias, As you said the tslib code is not building because the linux_input subsystem can handle more input devices, but touchscreen devices aren't full supported, to be able to receive ecore_fb events on evas - edje you need to also modify ecore_evas. I've altered it and attach patches here to enable it again and only support the libts mouse events and remove all the ipaq backlightning,led,brightnes...etc stuff, I've also removed the calibration. Now ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_*...) events works, but I can't get any evas_object_event_callbacks to work (subsequently edje files don't receive any mouse events either). But where do you enable the tslib specific functions? when ecore_fb_init is called you should also initialize the tslib subsystem. I've tried evas_event_feed_mouse in an app but I can't get any more events than mouse_in and mouse_out fed to the evas_object. I'm not sure I grok evas_event_feed*. If you can receive ECORE_FB events on ecore_evas then there should not be any problems, as the ecore_evas just wraps those events and feeds them to evas, so you should see them. If you look on the ecore_evas_fb_init code, the input devices (/dev/input/*) are sent to the linux_input subsystem on ecore_fb and then the ecore_fb events are received, you should do the same. Any hints to solve this would be very appreciated, I've looked at ecore_evas_fb.c but can't find anything wrong with it. /Cheers Tobias - 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 - 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] Call for help: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 )
(Resend) What: Gareth from SCALE has really kindly offered Enlightenment.org (that's use guys) free floor/booth space @ SCALE ( http://www.socallinuxexpo.org/ ) Next February (2008). So it looks like I will be there. Also Nathan of EWL fame and work will likely be there. Is there anyone else in the area (This is southern califronia) who wants to join and help put together/man a booth and at an expo? Hands up now? Suggestions on things to do are welcome. ... So want to come - show off your E desktop or whatever? :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] Call for help: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 )
On Fri, 2008-01-18 at 13:50 +1100, Carsten Haitzler wrote: (Resend) What: Gareth from SCALE has really kindly offered Enlightenment.org (that's use guys) free floor/booth space @ SCALE ( http://www.socallinuxexpo.org/ ) Next February (2008). So it looks like I will be there. Also Nathan of EWL fame and work will likely be there. Is there anyone else in the area (This is southern califronia) who wants to join and help put together/man a booth and at an expo? Hands up now? Suggestions on things to do are welcome. I sort of assumed that maybe folks just sent their suggestions directly to you before thus the low list traffic on the topic :/ I'd go for having demos running on the '73, n8x0 and laptop machine. Maybe pushing the fact that the same edje file is running on all three devices if using emotion that the source code is identical. Though I have no doubt that you are already planning to have those devices demoing I'd be pushing the same easy API, same code angle. Also if emotion works well on the n8x0 I'd have that going as part of a demo loop or available for easy exhibition. Unfortunately its too early to demo gevas on meamo and its integration... maybe in 6 months ;) It would be cool to have+show reimplementations of some older games running purely or very heavily in edje/embryo, maybe one day I'll get around to brewing some off :| ... So want to come - show off your E desktop or whatever? :) * Grumbles about long raft trip and lack of suitable tarp to remain buoyant. signature.asc Description: This is a digitally signed message part - 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] Vertical Align of Edje Textblock
On Wed, 26 Dec 2007 00:29:27 +0100 Thomas Gstädtner [EMAIL PROTECTED] babbled: Hello people, I'm currently working on my first interface in edje and guess I found a bug in the edje-textblock. As I want to do multi-line captions on buttons, I want to have the textblock centered on the button-graphics. I assumed that the valign-property in the style-block was what I wanted, but neither valign=center nor valign=0.5 works. Horizontal align works perfectly. So I also tried to set the align property for the part itself (even if it should be 0.5 0.5 by default) what didn't work, too. As the valign style-property seems to do nothing at all, I assume that's a bug. Can somebody confirm and fix this? :) valign in a textblock is the alignment WITHIN a line of text - so imagine u have a 30point font and a 8point fount on the same line - valign controls where the 8point font is aligned. align SHOULD work if you set the min: 1 1; (ie make the minimum size of the part controlled by the minimum size of the text itself. Greetings, thomasg - 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
