help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] Iliad localization: managing layouts, #render: some


From: Stefan Schmiedl
Subject: Re: [Help-smalltalk] Iliad localization: managing layouts, #render: someText on: aWidget message
Date: Fri, 31 Jul 2009 19:38:05 +0200

On Fri, 31 Jul 2009 19:41:57 +0300
Bèrto ëd Sèra <address@hidden> wrote:

> > rl-tb looks to be the same with "text-align: right", but this
> > can't be right... I'd expect rl-tb to render "hello world" as
> >  |          dlrow olleh |
> > and not
> >  |          hello world |
> It's not so simple. Font rendering implies a hidden rendering layer
> that we do not control as it depends on unicode and it's managed
> directly by CSS standards (at least as long as you use UTF-8, not sure
> of what happens if you resort to other codings).

ah ... so if the example had used arabic glyphs it would have
appeared correctly. Learned something, thanks.

> The unaddressed problems are not with fonts (unless you deal with
> choosing different typefaces, sizes, etc), but rather with what
> #content does. For example,
> 
> a TopBottom layout needs
> 1) to exchange colums with rows (and I guess we can hack this in
> pretty much a user transparent way)
> 2) to make sure that we can read an horizontal scroll, rather than a
> vertical one. (pretty an headache, as I'm currently not aware of a way
> to have a fixed 100% height for an HTML table)
> 
> a rightToLeft horizontal layout needs to
> 1) invert the float attributes of the inline images

That's what the different TextLayout subclasses should handle.

While I was thinking about a good example, where css/js are
not enough to handle the requirements for different types
of writing directions, I suddenly recognized what we're
dealing with her: PluggableLayout

So each subclass of PluggableLayout adds the necessary
js/css statements to the page header and then implements one
polymorphic message, say layout:on: (no render:on: anymore).

Keep "inner, moving" widgets in a dictionary accessible to the outer
widget, so that you can tell it to place it's content in the
correct way.

  OuterWidget [
    | innerWidgets |
    contents [
      ^ [ :e | self textLayout layout: innerWidgets on: e ]
    ]
  ]

where "self textLayout" answers e.g. one of the following:

  TwoColLayout [
    layout: widgets on: parent [ |d|
      d := parent div class: 'twocollayout'.
      d build: ( widgets at: #search ).
      d div 
        class: 'twocolumns';
        build: ( widgets at: #results );
        build: ( widgets at: #history )
    ]
  ]

  WeirdThreeColLayout [ 
    layout: widgets on: parent [
      parent div
        class: 'threecolumns';
        build: ( widgets at: #history );
        build: ( widgets at: #results );
        build: ( widgets at: #search )
    ]
  ]

If necessary, the "inner" widgets themselves could use the same
approach and implement contents like OuterWidget above does.

> Many other such things will popup in time. The target is to make all
> the "obvious moves" in a transparent way, so that they need not being
> hardcoded into the #content messages. In an ideal package you wouldn't
> have to change a line of code to port your web-design design to RTL.

As long as you provide a generic method to assign the correct layouter
to a widget, that would be the case.

s.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]