qooxdoo-compiler

qooxdoo-compiler copied to clipboard

The skeleton has always provided a custom theme with appearance, decoration, etc which inherit from a base theme, but would it be better if we simply used the standard theme directly? IE not create myapp/theme/* at all and in compile.json just specify the application theme as "qx.theme.Indigo".

My thought is that if you want to change the theme you're going to have to sit down and read the docs anyway so removing it would make the skeleton app simpler to understand and get started with, and removes cruft for more experienced users.

It would make it simpler, but would make it more difficult to integrate third-party code that ships with custom (icon) themes. The dialog contribution, starting with v1.3 relies on the ability to replace the myapp.theme.Theme#meta.icon property with its own icon theme. If we shortcut to the framework themes, it gets much more difficult to insert the custom theme, I think.

How about if contribs add their own theme elements by providing mixins and entries in compile.json? The compiler would then be able to get these installed into the app automatically.

This would mean that the qx commands to add and remove contribs would be able to easily (and automatically) add and remove the contrib's theme components from the build.

This could be implemented by having the compiler generate it's own theme source files (somewhere under source-output/) that uses all the necessary mixins, icon sets, etc; because it's just a theme .js file this would work without modification to the core framework.

If the developer wants to add their own overrides for appearance/decoration/etc they would specify these as mixins (these could be generated by the skeleton) and the compiler incorporates them in the same way as it does for contribs.

Advanced users would still be able to write their own theme, either from scratch (i.e. as we do now) or by starting with the one generated by the compiler. By writing your own theme from scratch, this would completely turn off the compiler's generated version and allow full control over theming.

That would be much better than what I have now in the contrib, which can no longer work out of the box because of the custom icon theme which needs to be manually integrated. Your solution would allow installation without the end user having to do anything.

@johnspackman I guess there are two cases.

• A contribution provides a Theme. A complete one. So it should not mix in anything.
• A contribution provides new widgets, icons, fonts, etc.

The latter one may by quite complicated as long as you don't force contributions to use an own appearance selector namespace for their own widget appearances: these mixins should not conflict with the existing application.

I don't have an opinion yet apart from a significant interest in making theming more approachable. I think many people initially decide on a framework based on the looks.

@cajus How would you solve the problem of the Dialog contrib trying to provide a custom icon themes for its widgets only without the developer having to include the aliases and assets manually in their application’s theme? Ideas?

Sorry for accidentally closing, writing comments on the Smartphone doesn't always work well. What I mean is that a contrib must be able to NOT mess with the applications general icon theme (the "icon" alias) but be able to add its own aliases that come from different theme files (for example, a theme that uses Oxygen, one that uses Tango, and one that uses a third-party Iconset).

@cboulanger using the current implementation, the user's theme has to be manually patched - but it looks like it would be straightforward for an automated process to do that, ie the compiler could produce the merged version

Changed title to reflect the direction of the discussion.

This seems to be an important issue, but doesn't seem completely trivial. @johnspackman, what are the chances you can implement this (I don't think anyone else can do it) before release of v6?

@johnspackman Revisiting this, because I just had the problem how to import the Dialog package's theme with icon aliases into the eventrecorder. This is how I am currently solving it, hardly ideal:

https://github.com/cboulanger/eventrecorder/blob/cf666f29e163ca34c0b0385cc044eb39f2f81a94/source/class/cboulanger/eventrecorder/UiController.js#L157

The immediate problem for me is the package's icon theme - but a solution should of course be more comprehensive and include all aspects of the plugged-in theme. Maybe it should be some property of Manifest.json/provides which would indicated that a theme is to be exported and to be integrated in the including app?

Another (additional) way could be to have compile.json/applications[].theme optionally take an array of theme classes. However, this would require manually updating compile.json when installing a package. On the other hand, the Dialog package is a case where you can choose from different icon themes, which resolve the aliases to different icons. So the compiler must know which icon theme to use. Probably we therefore need some sort of "default" mode where the package's default theme settings are used, with the possibility to override those in the application.

This is probably not going to happen for v6, is it @johnspackman ?