Re: [E-devel] Things you consider broken or old in current repository
On Sun, Aug 17, 2008 at 6:20 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Hi people, As now we're using SVN and it's easy to move things around I suggest we moving things out of the main project if they're broken for some time. Some projects like KDE, for example, move things into their experimental/playground (our proto) and then into main project, if things were in main project but are getting outdated, they are moved into extra-gears, etc.. it's easy and cheap to do that. So far I know some things are broken and could be moved to BROKEN, they are: - edje_viewer: usage of etk_canvas is broken, I can hackish patch it to work, but IMHO it's ugly. And edje_editor is far superior now. - express - most of MISC/ Since I don't have time to maintain edje_viewer (work + university + new country), I'd appreciate it if someone (codewarrior) would fix it for the etk_canvas change. I'd rather keep it (biased++), since it's just a viewer, and it used to do that job just fine :) These probably could be moved into OLD: - eclair - e_utils - epeg (evas does that) - eterm (i know it is maintained, but does not use any of current efl, much like e16) - imlib2* (now epsilon uses evas, this can be moved) - examine BTW, we could move these to main: - edje_editor Unknown to me: - emprint - emphasis - elicit - empower - enhance - enity - enscribe - etk_extra - evfs - evolve what do you think? I'm not sure, but I think elicit is currently broken (the screen recording thing doesn't seem to work). It is also unmaintained right now (the author stated that a few months ago on the ml). But it is a great tool, and if it had a ruler, it'd be a designer's best friend :) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Things you consider broken or old in current repository
2008/8/17 Gustavo Sverzut Barbieri [EMAIL PROTECTED] Hi people, As now we're using SVN and it's easy to move things around I suggest we moving things out of the main project if they're broken for some time. Some projects like KDE, for example, move things into their experimental/playground (our proto) and then into main project, if things were in main project but are getting outdated, they are moved into extra-gears, etc.. it's easy and cheap to do that. So far I know some things are broken and could be moved to BROKEN, they are: - edje_viewer: usage of etk_canvas is broken, I can hackish patch it to work, but IMHO it's ugly. And edje_editor is far superior now. - express - most of MISC/ Actually enna, that is present in MISC/ should compiled fine. I use another SVN repo in sourceforge for enna and I planned (this week) to sync this two repository and in near future use only E SVN. It could be nice, if you are agree, you don't put enna in OLD or BROKEN. Thanks. Nico - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Things you consider broken or old in current repository
On Monday, 18 August 2008, at 08:40:01 (+0200), Nicolas Aguirre wrote: Actually enna, that is present in MISC/ should compiled fine. I use another SVN repo in sourceforge for enna and I planned (this week) to sync this two repository and in near future use only E SVN. It could be nice, if you are agree, you don't put enna in OLD or BROKEN. I was actually going to check with you about enna before anything was done. No worries; we'll leave it as is. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- Your best? Losers always whine about [doing] their best. Winners go home and f*** the prom queen.-- Sean Connery, The Rock - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: evas smart pre_render
On Sat, Aug 16, 2008 at 3:15 AM, Jose Gonzalez [EMAIL PROTECTED] wrote:
Just to make it clear what I think about this: This kind of thing is
something that really needs to be done, one way or another. :)
Some time back, I thought about having the edje recalc function called
by smart class render-pre/post funcs, and these funcs I wanted to be called
by the obj's internal render-pre/post ones as this would be useful for
creating
semi-custom, stateful, objs that rendered to image buffers (possibly native
surfaces). But I saw that there were problems with that due to the very kinds
of things you mention, the events system and possibly other things, as I
mentioned to Cedric once here.
You could have an additional smart class func, say a calculate one and
then do as you suggest.. but the main issue here is whether this kind of smart
class specific approach is the best way to deal with this kind of general
issue.
I've mentioned two other possible ways to deal with this in a more generic
manner - for example an ecore_evas based one akin to what's done with
sub-canvases
(which is useful for those), or a more 'evas only' one akin to what you have
here
but using user supplied callbacks. There are other possibilities.. evas could
expose an EVAS_RENDER_EVENT and have callbacks one can add for such, called
prior
to the internal evas-render loop... and other possibilities.
I don't know what might be best.. just that this is something needed but
that needs more thought, some experimenting, etc. Maybe raster, nathan,
hisham,
and others can give more feedback on this - maybe your proposal *is* the best
way to deal with this general issue, but it won't hurt to consider other
possible
ways if they have potentially wider applicability. :)
Ok, here is a patch that improve the speed for evas part of Gustavo
work. I did rename the callback to calculate. Regarding if it's the
best way, that I don't know, but it's easy to implement on both side
and fast.
Between the edje patch is currently not correct as many getter expect
the underlying object to be calculated. If you apply the attached
patch (not really a smart patch) you will see that many user of edje
expect it to be calculated at some point.
--
Cedric BAIL
diff --git a/src/lib/Evas.h b/src/lib/Evas.h
index 1c45061..e001ac5 100644
--- a/src/lib/Evas.h
+++ b/src/lib/Evas.h
@@ -129,7 +129,7 @@ typedef enum _Evas_Aspect_Control
} Evas_Aspect_Control;
-#define EVAS_SMART_CLASS_VERSION 1 /** the version you have to put into the version field in the smart class struct */
+#define EVAS_SMART_CLASS_VERSION 2 /** the version you have to put into the version field in the smart class struct */
struct _Evas_Smart_Class /** a smart object class */
{
const char *name; /** the string name of the class */
@@ -145,6 +145,7 @@ struct _Evas_Smart_Class /** a smart object class */
void (*color_set) (Evas_Object *o, int r, int g, int b, int a); // FIXME: DELETE ME
void (*clip_set)(Evas_Object *o, Evas_Object *clip); // FIXME: DELETE ME
void (*clip_unset) (Evas_Object *o); // FIXME: DELETE ME
+ void (*calculate) (Evas_Object *o);
const void *data;
};
@@ -738,6 +739,7 @@ extern C {
EAPI void evas_object_smart_callback_add(Evas_Object *obj, const char *event, void (*func) (void *data, Evas_Object *obj, void *event_info), const void *data);
EAPI void *evas_object_smart_callback_del(Evas_Object *obj, const char *event, void (*func) (void *data, Evas_Object *obj, void *event_info));
EAPI void evas_object_smart_callback_call (Evas_Object *obj, const char *event, void *event_info);
+ EAPI void evas_object_smart_changed (Evas_Object *obj);
/* events */
EAPI void evas_event_freeze (Evas *e);
diff --git a/src/lib/canvas/evas_main.c b/src/lib/canvas/evas_main.c
index 27b3ce6..1a9b34c 100644
--- a/src/lib/canvas/evas_main.c
+++ b/src/lib/canvas/evas_main.c
@@ -70,6 +70,7 @@ evas_new(void)
evas_array_setup(e-pending_objects, 16);
evas_array_setup(e-obscuring_objects, 16);
evas_array_setup(e-temporary_objects, 16);
+ evas_array_setup(e-calculate_objects, 16);
return e;
}
diff --git a/src/lib/canvas/evas_object_smart.c b/src/lib/canvas/evas_object_smart.c
index aaffd3e..ec42e10 100644
--- a/src/lib/canvas/evas_object_smart.c
+++ b/src/lib/canvas/evas_object_smart.c
@@ -429,6 +429,21 @@ evas_object_smart_callback_call(Evas_Object *obj, const char *event, void *event
evas_object_smart_callbacks_clear(obj);
}
+/**
+ * Mark smart object as changed, dirty.
+ *
+ * This will inform the scene that it changed and needs to be redraw.
+ */
+EAPI void
+evas_object_smart_changed(Evas_Object *obj)
+{
+ MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
+ return;
+ MAGIC_CHECK_END();
+ evas_object_change(obj);
+ evas_render_object_calc(obj);
+}
+
/* internal calls */
static
Re: [E-devel] [RFC] EET signature support
On Wed, Jul 30, 2008 at 4:21 PM, Cedric BAIL [EMAIL PROTECTED] wrote:
So here is a little patch that signature support to eet. It append
at the end of a classic eet file a signature and the public x509
certificate in der format. This change doesn't break file
compatibility as the signature is automatically detected based on the
file content against it's size. But this means, that eet_open first
make an attempt to load the file structure (directory and dictionnary)
before checking the signature. It use openssl library and the test
provided in eet_suite.c work well with openssl version 0.9.8e.
Ok, here is an updated patch. It provide a way to set a callback for
entering password for private key. A way to retrieve the public
certificate so if you want to check it against a CA you can. It also
provide some helper to output the certificate content in human
readable form to any FILE* and use it for the new command -c (check
and display the signature of a file) and -s for signing a file.
As always have fun with this patch.
--
Cedric BAIL
diff --git a/configure.in b/configure.in
index ebf301e..78e49f2 100644
--- a/configure.in
+++ b/configure.in
@@ -117,6 +117,22 @@ int main (int argc, char **argv) {
], AC_MSG_WARN([Cannot check when cross-compiling -- assuming null is okay])
)
+dnl Disable support for old eet file format.
+old_eet_file_format=yes
+AC_ARG_ENABLE(old-eet-file-format,
+ AC_HELP_STRING(
+[--disable-old-eet-file-format],
+[disable old eet file format support. [[default=enabled]]]
+ ),
+ [ old_eet_file_format=$enableval ]
+)
+AM_CONDITIONAL(EET_OLD_EET_FILE_FORMAT, test x$old_eet_file_format = xyes)
+if test x$old_eet_file_format = xyes; then
+ AC_DEFINE(EET_OLD_EET_FILE_FORMAT, 1, [support old eet file format])
+else
+ AC_DEFINE(EET_OLD_EET_FILE_FORMAT, 0, [support old eet file format])
+fi
+
dnl Unit Tests
AC_ARG_ENABLE(tests,
@@ -143,6 +159,54 @@ fi
AM_CONDITIONAL(EET_ENABLE_TESTS, test x${enable_tests} = xyes)
+dnl Openssl support
+want_openssl=auto
+have_openssl=no
+AC_ARG_ENABLE(openssl,
+ [AC_HELP_STRING([--disable-openssl], [disable openssl eet support])],
+ [ want_openssl=$enableval ]
+)
+if test x$want_openssl = xyes -o x$want_openssl = xauto; then
+ PKG_CHECK_MODULES(OPENSSL, openssl,
+[
+ have_openssl=yes
+ AC_DEFINE(HAVE_OPENSSL, 1, [Have Openssl support])
+],
+[
+ if test x$use_strict = xyes; then
+AC_MSG_ERROR([Openssl not found (strict dependencies checking)])
+ fi
+])
+fi
+
+dnl Crypto option
+want_cypher=yes
+have_cypher=yes
+want_signature=yes
+have_signature=yes
+
+AC_MSG_CHECKING(whether to activate cypher support in eet)
+AC_ARG_ENABLE(cypher,
+ [AC_HELP_STRING([--disable-cypher], [disable cypher support for eet API])],
+ [ want_cypher=$enableval ]
+)
+if test x$have_openssl = xyes -a x$want_cypher = xyes; then
+ have_cypher=yes
+ AC_DEFINE(HAVE_CYPHER, 1, [Have cypher support built in eet])
+fi
+AC_MSG_RESULT($have_cypher)
+
+AC_MSG_CHECKING(whether to activate signature support in eet)
+AC_ARG_ENABLE(signature,
+ [AC_HELP_STRING([--disable-signature], [disable signature file support for eet])],
+ [ want_signature=$enableval ]
+)
+if test x$have_openssl = xyes -a test x$have_signature = xyes -a x$want_signature = xyes; then
+ have_signature=yes
+ AC_DEFINE(HAVE_SIGNATURE, 1, [Have signature support for eet file])
+fi
+AC_MSG_RESULT($have_signature)
+
dnl Coverage
AC_ARG_ENABLE(coverage,
@@ -241,6 +305,12 @@ echo
echo
echo Configuration Options Summary:
echo
+echo Openssl..: ${have_openssl}
+echo Cypher support.: ${have_cypher}
+echo Signature..: ${have_signature}
+
+echo Old eet file format..: ${old_eet_file_format}
+echo
echo Tests: ${enable_tests}
echo Coverage.: ${enable_coverage}
echo
diff --git a/src/bin/eet_main.c b/src/bin/eet_main.c
index d352a0f..f5762dd 100644
--- a/src/bin/eet_main.c
+++ b/src/bin/eet_main.c
@@ -200,6 +200,50 @@ do_eet_remove(const char *file, const char *key)
eet_close(ef);
}
+static void
+do_eet_check(const char *file)
+{
+ Eet_File *ef;
+ const void *der;
+ int der_length;
+
+ ef = eet_open(file, EET_FILE_MODE_READ);
+ if (!ef)
+ {
+ fprintf(stdout, checking signature of `%s` failed\n, file);
+ exit(-1);
+ }
+
+ der = eet_identity_x509(ef, der_length);
+
+ eet_identity_certificate_print(der, der_length, stdout);
+
+ eet_close(ef);
+}
+
+static void
+do_eet_sign(const char *file, const char *private_key, const char *public_key)
+{
+ Eet_File *ef;
+ Eet_Key *key;
+
+ ef = eet_open(file, EET_FILE_MODE_READ_WRITE);
+ if (!ef)
+ {
+ fprintf(stdout, cannot open for read+write: %s.\n, file);
+ exit(-1);
+ }
+
+ key = eet_identity_open(public_key, private_key, NULL);
+
+ fprintf(stdout, Using the following key to sign `%s`.\n, file);
+ eet_identity_print(key,
Re: [E-devel] Efreet bin ef_icon theme bug
Dmitriy Mazovka wrote:
Hello!
Seems there is a problem in
ef_icon_theme.c:590
if (!strcmp(p, .png) || !strcmp(p, .xpm))
{
*p = '\0';
p = strrchr(file, '/');
if (p) p++;
if (p) ecore_hash_set(icons, strdup(p), strdup(p));
}
I suppose there is a bug here, and the code should be like follows:
if (!strcmp(p, .png) || !strcmp(p, .xpm))
{
*p = '\0';
p = strrchr(file, '/');
if (p) p++;
else p = file;
if (p) ecore_hash_set(icons, strdup(p), strdup(p));
}
It is a small notice however and we (me and Vincent Torri) cannot decide
whether this is a feature or bug. So just a warning for you:). Tests pass
good and without it actually, but icons list stays empty while it should be
definitely filled.
Shouldn't it be just to add the file? ecore_file_ls will only give file
names without path, and such never contain '/'.
Sebastian
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: IN trunk/E16/e: sample-scripts scripts
2 things: 1 - reply-all to enlightenment-svn lacks enlightenment-devel 2 - bit pointless to keep .cvsignore, let's remove them altogether? On Mon, Aug 18, 2008 at 3:04 PM, [EMAIL PROTECTED] wrote: Author: kwo Date: 2008-08-18 11:04:11 -0700 (Mon, 18 Aug 2008) New Revision: 35557 Removed: trunk/E16/e/sample-scripts/.cvsignore Modified: trunk/E16/e/scripts/.cvsignore Log: Cleanups (.cvsignore). Deleted: trunk/E16/e/sample-scripts/.cvsignore Modified: trunk/E16/e/scripts/.cvsignore === --- trunk/E16/e/scripts/.cvsignore 2008-08-18 17:18:47 UTC (rev 35556) +++ trunk/E16/e/scripts/.cvsignore 2008-08-18 18:04:11 UTC (rev 35557) @@ -1,4 +1,2 @@ -.icons Makefile.in Makefile -enlightenment.install - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-svn mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: IN trunk/E16/e: sample-scripts scripts
On Monday, 18 August 2008, at 15:20:35 (-0300), Gustavo Sverzut Barbieri wrote: 1 - reply-all to enlightenment-svn lacks enlightenment-devel Fixed. 2 - bit pointless to keep .cvsignore, let's remove them altogether? Subversion supports both. Personally I like the files way better than the propset way, so I'd vote to keep it. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- The trouble with doing something right the first time is that nobody appreciates how difficult it was. -- Walt West - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] fixing docs: cvs-svn, bugzilla-trac
Hi guys, I did some work on wiki to move CVS to SVN and bugzilla to trac, it's far from complete, so if you want to help... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: IN trunk/E16/e: sample-scripts scripts
On Mon, 18 Aug 2008 20:42:19 +0200, Michael Jennings [EMAIL PROTECTED] wrote: On Monday, 18 August 2008, at 15:20:35 (-0300), Gustavo Sverzut Barbieri wrote: ... 2 - bit pointless to keep .cvsignore, let's remove them altogether? Subversion supports both. Personally I like the files way better than the propset way, so I'd vote to keep it. I have about 5 minutes of experience with svn so I might got it wrong but it looks to me like svn does not support .cvsignore and that the .cvsignore files have been converted to props in the cvs-svn conversion process. If that is correct we might as well remove the .cvsignore's. If not I'd like to know how to configure svn to use the .cvsignore files. /Kim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: IN trunk/E16/e: sample-scripts scripts
On Tue, 19 Aug 2008 00:32:16 +0200 Kim Woelders [EMAIL PROTECTED] babbled: On Mon, 18 Aug 2008 20:42:19 +0200, Michael Jennings [EMAIL PROTECTED] wrote: On Monday, 18 August 2008, at 15:20:35 (-0300), Gustavo Sverzut Barbieri wrote: ... 2 - bit pointless to keep .cvsignore, let's remove them altogether? Subversion supports both. Personally I like the files way better than the propset way, so I'd vote to keep it. I have about 5 minutes of experience with svn so I might got it wrong but it looks to me like svn does not support .cvsignore and that the .cvsignore files have been converted to props in the cvs-svn conversion process. If that is correct we might as well remove the .cvsignore's. If not I'd like to know how to configure svn to use the .cvsignore files. it supports both - on IMPORT svn also set the properties for ignore based on .cvsignore files... it kept the .cvsignore files (as i told it to) :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
