[E-devel] Edje translations - Why they shouldn't be inside .edj's
Hey all, I found out today that there's a plan to put translations for strings inside edj's inside the edj's themselves - this is *BAD*. Here are my two main issues with this solution: 1. There are at least 80 common languages around the world this means that each edj will now include 79 useless translations per user, this is very bloated. There's a reason why gettext translations are in separate files, it's so people will be able to download only the translations they care about. 2. There's a very nice almost standard way of doing translations, gettext, it's a well thought of, tested and widely used translation mechanism, I don't see why not to use it. I know you'll be using it internally, but why not to store the gettext files in the standard locations? why shove them in one big edj? I really don't get it. In other words, I think we should think of a nice way to load standard gettext translations from standard locations when loading edj's and not ship all of the translations in the world in the same edj file (not even generating a different edj per language, no reason why to duplicate the images/whatever is stored inside the edj's). Hoping to see what you guys think, Tom. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's
Hi Tom, I'm not an expert on this, so please correct me if I understood stuff wrong. I think the reason for this is that with different languages often a different culture comes along with different user interface expectations. This might lead to the point where you'd like to have a complete different UI, since simple text translation and rtl - ltr and ud - du just doesn't do the job satisfyingly. 2010/8/26 Tom Hacohen tom.haco...@partner.samsung.com: Hey all, I found out today that there's a plan to put translations for strings inside edj's inside the edj's themselves - this is *BAD*. Here are my two main issues with this solution: 1. There are at least 80 common languages around the world this means that each edj will now include 79 useless translations per user, this is very bloated. There's a reason why gettext translations are in separate files, it's so people will be able to download only the translations they care about. I guess there'll be an easy way to strip translations you don't need so packagers can provide per language edje packages if they like. Maybe cedric can provide more information as e.g. an example of his idea. 2. There's a very nice almost standard way of doing translations, gettext, it's a well thought of, tested and widely used translation mechanism, I don't see why not to use it. I know you'll be using it internally, but why not to store the gettext files in the standard locations? why shove them in one big edj? I really don't get it. In other words, I think we should think of a nice way to load standard gettext translations from standard locations when loading edj's and not ship all of the translations in the world in the same edj file (not even generating a different edj per language, no reason why to duplicate the images/whatever is stored inside the edj's). Why should images be duplicated? If same are used in two translations they should use the same id thus be stored once. Hoping to see what you guys think, Tom. Hope you're not disappointed ;-) Leif -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's
On Thu, 2010-08-26 at 16:20 +0200, Leif Middelschulte wrote: Hi Tom, I'm not an expert on this, so please correct me if I understood stuff wrong. I think the reason for this is that with different languages often a different culture comes along with different user interface expectations. This might lead to the point where you'd like to have a complete different UI, since simple text translation and rtl - ltr and ud - du just doesn't do the job satisfyingly. Hi Leif, We are talking about translations, not about a different interface layout per language (although my points apply to that case as wel). If you want a different UI per language, you'll need to create a different edj per language. The solution currently being implemented (which I'm against) suggests handling only text translations by embedding all of the gettext translations in the .edj. Tell me if you need any more clarifications. -- Tom. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's
On Thu, Aug 26, 2010 at 4:06 PM, Tom Hacohen tom.haco...@partner.samsung.com wrote: I found out today that there's a plan to put translations for strings inside edj's inside the edj's themselves - this is *BAD*. Here are my two main issues with this solution: 1. There are at least 80 common languages around the world this means that each edj will now include 79 useless translations per user, this is very bloated. There's a reason why gettext translations are in separate files, it's so people will be able to download only the translations they care about. Nothing prevent you to ship Edje file with a limited set of translations. They will be in separated eet section. So you can remove/add/modify them at your convenience. The problem of shipping Edje file with separate translation, cause issue with such concept like Exchange. It complexify the work of user as they need to download the theme they like and the translation they want. They also need to install them at different place (something that could be handled with a direct interface in each application or with a packaging script). So yes, it's a trade off, but you have the choice. Nothing prevent you to put the infra on the server to automatically ship edje file with just the translation the user want by just removing the eet section that are not requested. It will always remain easier to distribute one file than many. 2. There's a very nice almost standard way of doing translations, gettext, it's a well thought of, tested and widely used translation mechanism, I don't see why not to use it. I know you'll be using it internally, but why not to store the gettext files in the standard locations? why shove them in one big edj? I really don't get it. Putting translation inside edje file just make it easier to user. I don't expect people to get all the possible theme from there distrib, but more from online source. So we will use the same gettext file format, that could be extracted from any edj file (anyone can contribute with normal gettext tool to the translation of the edje file they are using). And last point, I believe that interface should be localized too, some theme just doesn't make sense for some culture. So by shipping edje file targeting one culture and the translation related to it, I think it make sense. And maybe I am wrong, but gettext expect to see translation in /usr/share/local a place that users are not allowed to write to. Edje is designed to be a package that include all the needed ressource to correctly display a theme for any app, including translation inside is just one more step on this road. In other words, I think we should think of a nice way to load standard gettext translations from standard locations when loading edj's and not ship all of the translations in the world in the same edj file (not even generating a different edj per language, no reason why to duplicate the images/whatever is stored inside the edj's). No need to duplicate, just remove before sending if you are really short on bandwidth. -- Cedric BAIL -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's
On Thu, 2010-08-26 at 16:32 +0200, Cedric BAIL wrote: Nothing prevent you to ship Edje file with a limited set of translations. They will be in separated eet section. So you can remove/add/modify them at your convenience. The problem of shipping Edje file with separate translation, cause issue with such concept like Exchange. It complexify the work of user as they need to download the theme they like and the translation they want. They also need to install them at different place (something that could be handled with a direct interface in each application or with a packaging script). So yes, it's a trade off, but you have the choice. Nothing prevent you to put the infra on the server to automatically ship edje file with just the translation the user want by just removing the eet section that are not requested. It will always remain easier to distribute one file than many. There's a pretty automatic way of separating translations to different packages in many build systems, this will have to be adjusted to support extracting the pot's from the edj's, removing them, and packaging them differently, this is a hassle no one will bother doing. So no, I can't remove them at my convenience. You can easily create a ~/.e/translations directory and put your gettext files there. It's easier and cleaner to adjust exchange to support that than adjusting all of the other pieces of software in the world. Plus, you get the added advantage of easily manipulating gettext files. Putting translation inside edje file just make it easier to user. I don't expect people to get all the possible theme from there distrib, but more from online source. So we will use the same gettext file format, that could be extracted from any edj file (anyone can contribute with normal gettext tool to the translation of the edje file they are using). And last point, I believe that interface should be localized too, some theme just doesn't make sense for some culture. So by shipping edje file targeting one culture and the translation related to it, I think it make sense. That's cool (although I believe completely unnecessary, but really no idea as I don't speak all the languages in the world), but completely not related to the issue at hand. Actually, since themes may make sense in one culture but not in another, you can't expect a themer, from culture x, to understand the culture y, so if the guys from culture y think that x does not understand them, they should create their own fork of the theme, and not merge it into a big binary blob that contains two interfaces which only one of will be used per system. The only real adjustment I can think of (which can and will be done automatically) is UI mirroring, but that does not require a change in the theme, only in edje. And maybe I am wrong, but gettext expect to see translation in /usr/share/local a place that users are not allowed to write to. man bindtextdomain Edje is designed to be a package that include all the needed ressource to correctly display a theme for any app, including translation inside is just one more step on this road. Translation outside is also one more step on this road, the difference between those two steps that the former is working on reinventing the wheel, and the latter is driving a car. Really no need to invent something already so widely used. No need to duplicate, just remove before sending if you are really short on bandwidth. Back to my first comment: No distribution maintainer will bother to rip your edjs apart and distribute them separately, and even if someone will, they'll have a lot of big (because he has to duplicate the whole edj, including pictures) packages in there server. And installing two different locales on a machine using a package manager will become impossible, you are really just making the maintainers life a living hell, and no one anywhere in the world in any situation what so ever will be willing to ship all of the locales in one package (edj). I'm thinking as a package maintainer and a developer, I have strong objections when wearing either hat. -- Tom. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's
I for one wont be supporting any languages other than english in my
themes, as to include more languages would mean me having to write
them myself, or get people to send me patches which would add to more
work for a themer to do... That work would then get duplicated across
themers and every single theme would have a different set of
translations... right?
Its also a huge 'Help' issue too... if you provide support with menu
items, the theme might change the name just to be different and then
whatever docs you write will be different to that too. (I assume
anyway)
I think I missed the thread where this was all suggested anyway. Am I
wrong in assuming the translation would be in text { text: Hello; }
format?
Toma
On 26 August 2010 22:32, Cedric BAIL cedric.b...@free.fr wrote:
On Thu, Aug 26, 2010 at 4:06 PM, Tom Hacohen
tom.haco...@partner.samsung.com wrote:
I found out today that there's a plan to put translations for strings
inside edj's inside the edj's themselves - this is *BAD*.
Here are my two main issues with this solution:
1. There are at least 80 common languages around the world this means
that each edj will now include 79 useless translations per user, this is
very bloated. There's a reason why gettext translations are in separate
files, it's so people will be able to download only the translations
they care about.
Nothing prevent you to ship Edje file with a limited set of
translations. They will be in separated eet section. So you can
remove/add/modify them at your convenience. The problem of shipping
Edje file with separate translation, cause issue with such concept
like Exchange. It complexify the work of user as they need to download
the theme they like and the translation they want. They also need to
install them at different place (something that could be handled with
a direct interface in each application or with a packaging script). So
yes, it's a trade off, but you have the choice. Nothing prevent you to
put the infra on the server to automatically ship edje file with just
the translation the user want by just removing the eet section that
are not requested. It will always remain easier to distribute one file
than many.
2. There's a very nice almost standard way of doing translations,
gettext, it's a well thought of, tested and widely used translation
mechanism, I don't see why not to use it. I know you'll be using it
internally, but why not to store the gettext files in the standard
locations? why shove them in one big edj? I really don't get it.
Putting translation inside edje file just make it easier to user. I
don't expect people to get all the possible theme from there distrib,
but more from online source. So we will use the same gettext file
format, that could be extracted from any edj file (anyone can
contribute with normal gettext tool to the translation of the edje
file they are using). And last point, I believe that interface should
be localized too, some theme just doesn't make sense for some culture.
So by shipping edje file targeting one culture and the translation
related to it, I think it make sense.
And maybe I am wrong, but gettext expect to see translation in
/usr/share/local a place that users are not allowed to write to.
Edje is designed to be a package that include all the needed ressource
to correctly display a theme for any app, including translation inside
is just one more step on this road.
In other words, I think we should think of a nice way to load standard
gettext translations from standard locations when loading edj's and not
ship all of the translations in the world in the same edj file (not even
generating a different edj per language, no reason why to duplicate the
images/whatever is stored inside the edj's).
No need to duplicate, just remove before sending if you are really
short on bandwidth.
--
Cedric BAIL
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
enlightenment-devel mailing list
Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's
On Thu, Aug 26, 2010 at 5:01 PM, Tom Haste tomha...@gmail.com wrote:
I for one wont be supporting any languages other than english in my
themes, as to include more languages would mean me having to write
them myself, or get people to send me patches which would add to more
work for a themer to do... That work would then get duplicated across
themers and every single theme would have a different set of
translations... right?
Patch would be only on the translation on a specific locale, nothing
related to main edc. On insertion it will do some check to prevent
loss of translation and handle conflict.
Its also a huge 'Help' issue too... if you provide support with menu
items, the theme might change the name just to be different and then
whatever docs you write will be different to that too. (I assume
anyway)
When you are planning to provide a theme for more than one langage,
you must accept the fact that some item will be translated. To ease
with that issue, we really plan to reuse the same text file format as
gettext so all tool that with gettext text source file will work with
edje translation too.
I think I missed the thread where this was all suggested anyway. Am I
wrong in assuming the translation would be in text { text: Hello; }
format?
Translation should be provided and injected has .po file in edje file.
So in your edc source you have : text: _(someid); This will be added
to the .pot description that could be extracted from the edj file by
people that want to do translation. When generating the edje file, you
could reuse translation from an existing edje file or just inject all
the po people submitted to you.
--
Cedric BAIL
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's
On Thu, Aug 26, 2010 at 5:00 PM, Tom Hacohen tom.haco...@partner.samsung.com wrote: On Thu, 2010-08-26 at 16:32 +0200, Cedric BAIL wrote: Nothing prevent you to ship Edje file with a limited set of translations. They will be in separated eet section. So you can remove/add/modify them at your convenience. The problem of shipping Edje file with separate translation, cause issue with such concept like Exchange. It complexify the work of user as they need to download the theme they like and the translation they want. They also need to install them at different place (something that could be handled with a direct interface in each application or with a packaging script). So yes, it's a trade off, but you have the choice. Nothing prevent you to put the infra on the server to automatically ship edje file with just the translation the user want by just removing the eet section that are not requested. It will always remain easier to distribute one file than many. There's a pretty automatic way of separating translations to different packages in many build systems, this will have to be adjusted to support extracting the pot's from the edj's, removing them, and packaging them differently, this is a hassle no one will bother doing. So no, I can't remove them at my convenience. You can easily create a ~/.e/translations directory and put your gettext files there. It's easier and cleaner to adjust exchange to support that than adjusting all of the other pieces of software in the world. Plus, you get the added advantage of easily manipulating gettext files. Do you really expect user downloading theme from website to move the file in ~/.e/translations ? Right now, when you import a theme in edje, you just need to select an edje file and you get your theme. You have nice preview too. If you want to include translation your way, please explain how user will handle that ? Adjusting exchange doesn't change anything at all, you still have to move your file around on your own disk. Nothing like, one file to download and try. Putting translation inside edje file just make it easier to user. I don't expect people to get all the possible theme from there distrib, but more from online source. So we will use the same gettext file format, that could be extracted from any edj file (anyone can contribute with normal gettext tool to the translation of the edje file they are using). And last point, I believe that interface should be localized too, some theme just doesn't make sense for some culture. So by shipping edje file targeting one culture and the translation related to it, I think it make sense. That's cool (although I believe completely unnecessary, but really no idea as I don't speak all the languages in the world), but completely not related to the issue at hand. Actually, since themes may make sense in one culture but not in another, you can't expect a themer, from culture x, to understand the culture y, so if the guys from culture y think that x does not understand them, they should create their own fork of the theme, and not merge it into a big binary blob that contains two interfaces which only one of will be used per system. The only real adjustment I can think of (which can and will be done automatically) is UI mirroring, but that does not require a change in the theme, only in edje. And maybe I am wrong, but gettext expect to see translation in /usr/share/local a place that users are not allowed to write to. man bindtextdomain Maybe I am wrong, but does it handle multiple path for the same domain. From what I read, I don't think so. So how do you handle translation for system theme and user theme, where translation are obviously not installed in the same directory ? Edje is designed to be a package that include all the needed ressource to correctly display a theme for any app, including translation inside is just one more step on this road. Translation outside is also one more step on this road, the difference between those two steps that the former is working on reinventing the wheel, and the latter is driving a car. Really no need to invent something already so widely used. I don't want to start a troll here, but it's not because a lot of people are using a tool, that it is a good solution that fit our need. In our case, using gettext does trigger a lot of issue for user. And it's not reinventing a wheel as gettext is not designed to handle this our use case. No need to duplicate, just remove before sending if you are really short on bandwidth. Back to my first comment: No distribution maintainer will bother to rip your edjs apart and distribute them separately, and even if someone will, they'll have a lot of big (because he has to duplicate the whole edj, including pictures) packages in there server. And installing two different locales on a machine using a package manager will become impossible, you are really just making the maintainers life a
Re: [E-devel] E SVN: lucas IN trunk: E16/e/src PROTO/eon/src/lib/layout ecore/src/lib/ecore_win32 ecore/src/lib/ecore_wince edje/src/lib evas/src/lib/cache exalt/src/lib
On Thu, 26 Aug 2010, Enlightenment SVN wrote:
Log:
Apply double_condition_check.cocci
I do not agree at all with that patch. It is hiding potential problems.
The double condition check is in most case a copy/paste error that needs
fixing instead of removal.
Please revert it.
Vincent
The offending projects were:
E16/e/src/backgrounds.c | 10 --
PROTO/eon/src/lib/layout/eon_stack.c|4 +---
ecore/src/lib/ecore_win32/ecore_win32.c |3 +--
ecore/src/lib/ecore_wince/ecore_wince.c |3 +--
edje/src/lib/edje_edit.c|3 +--
evas/src/lib/cache/evas_cache_image.c |2 +-
exalt/src/lib/libexalt_private.c|2 +-
This patch assumes code in these places were insane and the fix is to remove
one condition check. Most likely this is not true, but there's no automatic
fix
for that.
Looking at the patch, it seems that some places should use x and y vars
but
used just one of them and therefore they were caught by coccinelle.
Author: lucas
Date: 2010-08-26 13:45:09 -0700 (Thu, 26 Aug 2010)
New Revision: 51666
Modified:
trunk/E16/e/src/backgrounds.c trunk/PROTO/eon/src/lib/layout/eon_stack.c
trunk/ecore/src/lib/ecore_win32/ecore_win32.c
trunk/ecore/src/lib/ecore_wince/ecore_wince.c trunk/edje/src/lib/edje_edit.c
trunk/evas/src/lib/cache/evas_cache_image.c
trunk/exalt/src/lib/libexalt_private.c
Modified: trunk/E16/e/src/backgrounds.c
===
--- trunk/E16/e/src/backgrounds.c 2010-08-26 20:38:37 UTC (rev 51665)
+++ trunk/E16/e/src/backgrounds.c 2010-08-26 20:45:09 UTC (rev 51666)
@@ -350,8 +350,8 @@
{
if ((strcmp(bg-bg.file, bgx-bg.file)) ||
(bg-bg.keep_aspect != bgx-bg.keep_aspect) ||
- (bg-bg.xjust != bgx-bg.xjust || bg-bg.xjust != bgx-bg.xjust) ||
- (bg-bg.xperc != bgx-bg.xperc || bg-bg.xperc != bgx-bg.xperc))
+ (bg-bg.xjust != bgx-bg.xjust) ||
+ (bg-bg.xperc != bgx-bg.xperc))
return 1;
}
else if (bg-bg.file || bgx-bg.file)
@@ -361,10 +361,8 @@
{
if ((strcmp(bg-top.file, bgx-top.file)) ||
(bg-top.keep_aspect != bgx-top.keep_aspect) ||
- (bg-top.xjust != bgx-top.xjust ||
- bg-top.xjust != bgx-top.xjust) ||
- (bg-top.xperc != bgx-top.xperc ||
- bg-top.xperc != bgx-top.xperc))
+ (bg-top.xjust != bgx-top.xjust) ||
+ (bg-top.xperc != bgx-top.xperc))
return 1;
}
else if (bg-top.file || bgx-top.file)
Modified: trunk/PROTO/eon/src/lib/layout/eon_stack.c
===
--- trunk/PROTO/eon/src/lib/layout/eon_stack.c2010-08-26 20:38:37 UTC
(rev 51665)
+++ trunk/PROTO/eon/src/lib/layout/eon_stack.c2010-08-26 20:45:09 UTC
(rev 51666)
@@ -201,9 +201,7 @@
Eon_Paint *prev;
int final;
- if ((!ekeko_type_instance_is_of(em-related, EON_TYPE_PAINT_SQUARE))
- (!ekeko_type_instance_is_of(em-related,
- EON_TYPE_PAINT_SQUARE)))
+ if ((!ekeko_type_instance_is_of(em-related, EON_TYPE_PAINT_SQUARE)))
return;
prv = PRIVATE(o);
Modified: trunk/ecore/src/lib/ecore_win32/ecore_win32.c
===
--- trunk/ecore/src/lib/ecore_win32/ecore_win32.c 2010-08-26 20:38:37 UTC
(rev 51665)
+++ trunk/ecore/src/lib/ecore_win32/ecore_win32.c 2010-08-26 20:45:09 UTC
(rev 51666)
@@ -362,8 +362,7 @@
_ecore_win32_event_handle_destroy_notify(data);
return 0;
case WM_SHOWWINDOW:
- if ((data-data_param == SW_OTHERUNZOOM) ||
- (data-data_param == SW_OTHERUNZOOM))
+ if ((data-data_param == SW_OTHERUNZOOM))
return 0;
if (data-window_param)
Modified: trunk/ecore/src/lib/ecore_wince/ecore_wince.c
===
--- trunk/ecore/src/lib/ecore_wince/ecore_wince.c 2010-08-26 20:38:37 UTC
(rev 51665)
+++ trunk/ecore/src/lib/ecore_wince/ecore_wince.c 2010-08-26 20:45:09 UTC
(rev 51666)
@@ -311,8 +311,7 @@
_ecore_wince_event_handle_destroy_notify(data);
break;
case WM_SHOWWINDOW:
- if ((data-data_param == SW_OTHERUNZOOM) ||
- (data-data_param == SW_OTHERUNZOOM))
+ if ((data-data_param == SW_OTHERUNZOOM))
break;
if (data-window_param)
Modified: trunk/edje/src/lib/edje_edit.c
===
--- trunk/edje/src/lib/edje_edit.c2010-08-26 20:38:37 UTC (rev 51665)
+++ trunk/edje/src/lib/edje_edit.c2010-08-26 20:45:09 UTC (rev 51666)
@@ -5889,8 +5889,7 @@
effects[edje_edit_part_effect_get(obj, part)]);
//Dragable
- if (edje_edit_part_drag_x_get(obj, part) ||
-
Re: [E-devel] E SVN: lucas IN trunk: E16/e/src PROTO/eon/src/lib/layout ecore/src/lib/ecore_win32 ecore/src/lib/ecore_wince edje/src/lib evas/src/lib/cache exalt/src/lib
On Thursday, 26 August 2010, at 23:14:23 (+0200), Vincent Torri wrote: I do not agree at all with that patch. It is hiding potential problems. The double condition check is in most case a copy/paste error that needs fixing instead of removal. Please revert it. No, that's the whole point. Every instance that was patched needs to be examined and probably fixed. Reverting it doesn't accomplish anything either. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- The Road I have travelled on is paved with good intentions. It's littered with broken dreams that never quite came true. -- Restless Heart, When She Cries -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: lucas IN trunk: E16/e/src PROTO/eon/src/lib/layout ecore/src/lib/ecore_win32 ecore/src/lib/ecore_wince edje/src/lib evas/src/lib/cache exalt/src/lib
On Thu, 26 Aug 2010, Michael Jennings wrote: On Thursday, 26 August 2010, at 23:14:23 (+0200), Vincent Torri wrote: I do not agree at all with that patch. It is hiding potential problems. The double condition check is in most case a copy/paste error that needs fixing instead of removal. Please revert it. No, that's the whole point. Every instance that was patched needs to be examined and probably fixed. Reverting it doesn't accomplish anything either. that patch is NOT good, hence it should not be in. A mail showing where the problems are, without modifying the code in svn is far way better than committing something wrong. Vincent -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: lucas IN trunk: E16/e/src PROTO/eon/src/lib/layout ecore/src/lib/ecore_win32 ecore/src/lib/ecore_wince edje/src/lib evas/src/lib/cache exalt/src/lib
On Fri, 27 Aug 2010 00:08 +0200, Vincent Torri wrote : On Thu, 26 Aug 2010, Michael Jennings wrote: No, that's the whole point. Every instance that was patched needs to be examined and probably fixed. Reverting it doesn't accomplish anything either. that patch is NOT good, hence it should not be in. A mail showing where the problems are, without modifying the code in svn is far way better than committing something wrong. I don't have any strong opinion as to whether this should be reverted or not, but I do agree with Vincent that sending the patch to the ML saying hey, those places probably need fixing would have been a far nicer approach. Cheers, -- Albin Tonnerre -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: lucas IN trunk: E16/e/src PROTO/eon/src/lib/layout ecore/src/lib/ecore_win32 ecore/src/lib/ecore_wince edje/src/lib evas/src/lib/cache exalt/src/lib
On Thu, Aug 26, 2010 at 7:16 PM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Fri, 27 Aug 2010 00:08 +0200, Vincent Torri wrote : On Thu, 26 Aug 2010, Michael Jennings wrote: No, that's the whole point. Every instance that was patched needs to be examined and probably fixed. Reverting it doesn't accomplish anything either. that patch is NOT good, hence it should not be in. A mail showing where the problems are, without modifying the code in svn is far way better than committing something wrong. I don't have any strong opinion as to whether this should be reverted or not, but I do agree with Vincent that sending the patch to the ML saying hey, those places probably need fixing would have been a far nicer approach. It doesn't matter. I'm sure someone would come and say: why don't you just apply this patch and send a mail saying what you did? No way to have everybody happy. I did the way I did because if nobody replies, it means it's right and the current code is better than before. I was even planning to go and investigate these cases. Lucas De Marchi -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's
Guys, just one request: If you change the format of .edj again, please add a version number to the binary format so that you can still parse the old format, and build backwards compatibility into the code. The previous change of format screwed everything up royally, from me personally restarting Enlightenment and having it misbehave, to the new EditJE tool not being able to edit old EDJ format, to themes that are written for a device here not working on new EFL. Really, you have to start thinking about this kind of stuff if you're at ALPHA. thanks, Mike -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's
On 08/27/2010 11:07 AM, Carsten Haitzler (The Rasterman) wrote: already did that. :) as such though... you used pre-alpha software... you were warned. your edj files were built from PRE alpha software. don't forget that. we didn't not advertise, maintain or pretend to support any form of compatibility during pre-alpha. we made a point of it. I know what the policy is, but I think with a small bit of work (which you will have do get used to doing very soon now), these kinds of BC breaks can be avoided. EFL developers to learn about BC, and the best way to learn is to start keeping BC. I'll be impressed if you can announce EFL 1.0 and start keeping BC the next day without having the policies and practices in place well before that time. The pre-alpha excuse won't last for much longer. thanks, Mike -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's
On Fri, 27 Aug 2010 12:21:53 +0900 Mike McCormack mj.mccorm...@samsung.com said: On 08/27/2010 11:07 AM, Carsten Haitzler (The Rasterman) wrote: already did that. :) as such though... you used pre-alpha software... you were warned. your edj files were built from PRE alpha software. don't forget that. we didn't not advertise, maintain or pretend to support any form of compatibility during pre-alpha. we made a point of it. I know what the policy is, but I think with a small bit of work (which you will have do get used to doing very soon now), these kinds of BC breaks can be avoided. EFL developers to learn about BC, and the best way to learn is to start keeping BC. I'll be impressed if you can announce EFL 1.0 and start keeping BC the next day without having the policies and practices in place well before that time. i think we know about binary compatibility better than let's say... most of the people you say were inconvenienced by the break :) we have version numbers now in edje - as above. eet itself has has several file format versions it supports and has now supported since eet 1.0.0 for over 2 years now (since april 2008). with no policies and practices in place as well. it simply has managed to do it because we do actually know what an abi/api and binary compat break is. as of at least 1.0.0 on we made sure we keep compatibility back to 1.0.0 and make sure the data is there to do that. we just choose to do breaks at-will prior to 1.0.0 because we can, and it means minimal overhead for doing necessary changes. we very much knew the edje format changed - if you didn't see cedric provided an edje_convert utility that builds along with edje for EXACTLY that reason - so the old format can be ditched asap and we don't have to support it going froward from 1.0.0 AND you get a helping hand moving over. that utility will go away as soon as we go to 1.0.0. e17's config files have had versions in them for YEARS now. they actually have managed to forward-port and upgrade many versions over the years. there is even a major and minor version segment of the version (major versions make e throw out your old config and replace it with defaults from your chosen profile or from standard as we had to break something - and it nicely tells you that it did this, and for minor-versions it quietly upgrades your configs for you by merging in new config data from the system configs that it knows your version is missing based on the delta between your version and the e's own compiled-in version). this edje format break just wasn't done with a nice long-range smooth transition process to your liking. it was an abrupt break BECAUSE we are going to 1.0.0 - if it was a smooth long-term process guess what... i'd be saying sorry guys - no efl 1.0.0 for you for 6-12 months as we need to support every possible api/abi/file format we ever used for long periods so people don't get a shock. have fun. you'll just have to wait!. we definitely know about compat. probably better than most as we eat our own dogfood every single day around the clock around the world. you just didn't like the fact that we used our get-out-of-jail card in the way we did (we could have not provided a conversion util and still been fine), but we did. we widely advertise that we have one. that's nothing new. it just created pain for you that we used our get out of jail free card. :) we know full well as of 1.0.0 release that card expires and we no longer have that luxury, so ... make hay while the sun shines. :) The pre-alpha excuse won't last for much longer. we're not pre-alpha anymore. we WERE and your issue is that your pre-alpha build edje files didn't work with alpha. :) perfectly reasonable for that to happen as the DEFINITELY would not have worked with the 1.0.0 release. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's
On 08/27/2010 01:37 PM, Carsten Haitzler (The Rasterman) wrote: The pre-alpha excuse won't last for much longer. we're not pre-alpha anymore. we WERE and your issue is that your pre-alpha build edje files didn't work with alpha. :) perfectly reasonable for that to happen as the DEFINITELY would not have worked with the 1.0.0 release. I'm glad to hear that there will be no more BC breaks after ALPHA ... :-) thanks, Mike -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
