Almost forgot, wanted to emphasize why it's important to have the direction in the translation file: Not only that only parts of a specific application can be different, but having complete applications different is very common. For example, many people would hate running e17 itself in rtl mode (including myself), but would like running the image editing applications in rtl mode. He also would like running the word processor in rtl mode, but because there's no Hebrew translation available, or the current one is very poor (hence you won't get the special translated string translated, either by lack of translation or a decision by the translator that the interface is not translated enough to mirror) it should not mirror, because an rtl interface in English is just weird. :)
I hope this clarifies the use cases a bit more. -- Tom. On Wed, 2010-10-20 at 09:41 +0200, Tom Hacohen wrote: > On Wed, 2010-10-20 at 10:12 +0900, Carsten Haitzler wrote: > > > I also considered this, but Tasn enlightened me that this is context > > > specific and just parts of the interface should be like that. Thus no > > > canvas/global event. > > > > eh? hrrrmfmw he? hummm fmmm? eh? do enlighten me... (i am assuming for now > > that > > ui mirroring doesn't just dumbly go change x coords of all edje parts to be > > "w > > - x" as opposed to "x"). ie that parts have left and right modes and the > > designer has to handle it properly etc. (so some parts go left, some go > > right > > and so on). > > Let me explain, generally it is a per application decision (actually > taken from the translation file, by translating a special string), but, > even so, parts of the interface can be manually set to rtl/ltr (hence > the need for per object control). The most basic example is images. Some > of the images need to mirror, for example image used for elm_menu's > arrow (remember, it will be moved automatically to the left, and a right > facing arrow there will look weird), while others should not mirror, for > example the image in an elm_icon object. Therefore, I came up with the > following scheme: Each object has two flags, one that signifies the > current state (whether it's CURRENTLY rtl/ltr), and one that signifies > the behavior (AUTO/MANUAL) in MANUAL mode, the object's direction is > exactly what set by the programmer/designer, either by a direct call to > evas, or just by marking the flag in the edc. This will be use > automatically for images, ui-designers will have to explicitly set (in > the edje/code) that a specific image (like the one in elm_menu) is not > really a normal image, but it's use used for indication and should be > mirrored*. So generally you'll have a full interface in one direction, > and some objects in another direction. > > So yeah, mostly what you said raster, you just flip (inside each evas > object, for example inside an edje layout) the UI i.e x1 becomes w - x2 > x2 = w - x1 (because you want to also keep x1 to be the upper left > corner) and in some cases like described above you also mirror images, > and yes, the designer can control whether one item should mirror or not, > but he does not need to write the layout twice, everything just works, > like magic :P (and since the feature is already implemented here, and > just the toggling is not yet implemented, I can testify from experience, > it's awesome.) > > > * - in the future I intend on supporting replacement layouts and > replacement images in edje just if someone wants to more fine-tune the > change, although, looking at how GTK+ are doing UI-mirroring, it's not > really needed. > > > Regarding: > "imho all you need is the same as scale. you want a single global RTL or > LTR (default is LTR) and then per object an api call to set this > explicitly. the rest would be the job of something like elementary to > just set it on everything (like it does with scale etc.)." > > What if I want to change an object and all of it's children? The idea > was: each children with AUTO mode registers to his father's rtl changes > so this way when you change this property, it goes down the chain, you > don't think that's a good idea? > > Thanks again, > Tom. ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
