headers
Gaetan de Menten | 7 Oct 16:45

Decoration inheritance

Hi again,

I see there is a lot of repetition in decorations. For example, the
"input-focused" and "input-disabled" decorations only differ from the
"input" decoration for a few keys each. It would certainly make
decorations declarations shorter to have some kind of inheritance
system in place.

Does something like this already exist for decorations? If so, why
isn't it used? Is it a run-time lookup (which would slow things down
obviously but make the JS files shorter to download), or is it a
compile-time expansion? Is such a system planned?

--

-- 
Gaëtan de Menten
http://openhex.org

-------------------------------------------------------------------------
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=100&url=/
Permalink | Reply |
headers
Fabian Jakobs | 8 Oct 10:04
Favicon

Re: Decoration inheritance

Gaetan de Menten schrieb:
> Hi again,
>
> I see there is a lot of repetition in decorations. For example, the
> "input-focused" and "input-disabled" decorations only differ from the
> "input" decoration for a few keys each. It would certainly make
> decorations declarations shorter to have some kind of inheritance
> system in place.
>
> Does something like this already exist for decorations? If so, why
> isn't it used? Is it a run-time lookup (which would slow things down
> obviously but make the JS files shorter to download), or is it a
> compile-time expansion? Is such a system planned?
>   
There is no inheritance of individual decorations in a theme. We just 
did not see the need for it yet and it is not on our roadmap. Personally 
I am reluctant to add just another level of complexity to the theming 
system. I would rather live with some repetition in the decoration theme.

Best Fabian

--

-- 
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484
(Continue reading)

Permalink | Reply |
headers
Matthew Gregory | 8 Oct 11:19

Re: Decoration inheritance

Although this isn't implemented there is a way to accomplish it if you 
really needed to.

Before your class do something like:
var my_input =
{
   // style info here
};

then later:

"input" : input,
"input-focused" : qx.lang.Object.mergeWith(
{
   // focused propertied here
}, my_input),
"input-disabled" : qx.lang.Object.mergeWith(
{
   // disabled propertied here
}, my_input);

It's not a very neat way but it will work if wanted this in your own 
themes.

Fabian Jakobs wrote:
> Gaetan de Menten schrieb:
>> Hi again,
>>
>> I see there is a lot of repetition in decorations. For example, the
>> "input-focused" and "input-disabled" decorations only differ from the
(Continue reading)

Permalink | Reply |
headers
Hugh Gibson | 8 Oct 12:21

Re: Decoration inheritance

> > I see there is a lot of repetition in decorations. For example, 
> the
> > "input-focused" and "input-disabled" decorations only differ from 
> > the
> > "input" decoration for a few keys each. It would certainly make
> > decorations declarations shorter to have some kind of inheritance
> > system in place.
> >
> > Does something like this already exist for decorations? If so, why
> > isn't it used? Is it a run-time lookup (which would slow things 
> > down
> > obviously but make the JS files shorter to download), or is it a
> > compile-time expansion? Is such a system planned?
> >   
> There is no inheritance of individual decorations in a theme. We 
> just did not see the need for it yet and it is not on our roadmap. 
> Personally I am reluctant to add just another level of complexity 
> to the theming system. I would rather live with some repetition in 
> the decoration theme.

I raised the need for hierarchical theme settings just under 2 years ago
at
http://www.nabble.com/Changing-font-size-for-accessibility-td6877683.html

with regard to font sizing. Not having looked at 0.8.x I'm amazed that it
still hasn't sorted this out. Colours etc should also be central.

Hugh

-------------------------------------------------------------------------
(Continue reading)

Permalink | Reply |
headers
Andreas Ecker | 8 Oct 15:35

Re: Decoration inheritance

Hi Hugh!

> > There is no inheritance of individual decorations in a theme. We 
> > just did not see the need for it yet and it is not on our roadmap. 
> > Personally I am reluctant to add just another level of complexity 
> > to the theming system. I would rather live with some repetition in 
> > the decoration theme.
> 
> I raised the need for hierarchical theme settings just under 2 years ago
> at
> http://www.nabble.com/Changing-font-size-for-accessibility-td6877683.html
> 
> with regard to font sizing. Not having looked at 0.8.x I'm amazed that it
> still hasn't sorted this out. Colours etc should also be central.

I think you mixed up two things that are unrelated. :-( Discussion is
about intra-theme inheritance, which is intentionally not supported to
not add complexity. Of course, inter-theme inheritance is possible, and
used for creating custom themes.

Regarding the feature you mention, in outdated versions of qooxdoo it
indeed wasn't possible to change the font size (or other themable
properties) say of the main document, with those values being
propagated/inherited to the widgets in the hierarchy below. This
limitation has long been gone, it must have been introduced around 0.7
with themable properties being inheritable.

The feature one could add is auto-detection of browser font changes
during runtime. A timer could possibly poll for such changes (AFAIK
there are no native events to detect this?) and force a GUI update. IIRC
(Continue reading)

Permalink | Reply |
headers
Gaetan de Menten | 8 Oct 15:51

Re: Decoration inheritance

On Wed, Oct 8, 2008 at 3:35 PM, Andreas Ecker
<ecker <at> users.sourceforge.net> wrote:
>
>> > There is no inheritance of individual decorations in a theme. We
>> > just did not see the need for it yet and it is not on our roadmap.
>> > Personally I am reluctant to add just another level of complexity
>> > to the theming system. I would rather live with some repetition in
>> > the decoration theme.
>>
>> I raised the need for hierarchical theme settings just under 2 years ago
>> at
>> http://www.nabble.com/Changing-font-size-for-accessibility-td6877683.html
>>
>> with regard to font sizing. Not having looked at 0.8.x I'm amazed that it
>> still hasn't sorted this out. Colours etc should also be central.
>
> I think you mixed up two things that are unrelated. :-( Discussion is
> about intra-theme inheritance, which is intentionally not supported to
> not add complexity. Of course, inter-theme inheritance is possible, and
> used for creating custom themes.

I *was* speaking about inter-theme inheritance, which doesn't seem to
be implemented (or at least used) for decorations, while it *is*
implemented and used for appearances.

--

-- 
Gaëtan de Menten
http://openhex.org

-------------------------------------------------------------------------
(Continue reading)

Permalink | Reply |
headers
Andreas Ecker | 8 Oct 16:02

Re: Decoration inheritance

Hi Gaetan!

> I *was* speaking about inter-theme inheritance, which doesn't seem to
> be implemented (or at least used) for decorations, while it *is*
> implemented and used for appearances.

Yes, this should read inter-appearance inheritance. When talking about
appearances, theme is often used as a synonym, so thanks for bringing up
this point.

Bye,

Andreas

-------------------------------------------------------------------------
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=100&url=/
Permalink | Reply |

Gmane