[Windows Mobile Themes] MichelDiamond:
Yes - that's hardcoded, with which default informations JMLToday provides which Page. And therefore they are updated by JMLToday-Internal - they cannot be transfered between Page1&2. So a Skinner can rely on the informations in this Pages. In 5.4. you could intercept it with the notifications, but must be made without performance loss.

Therefore I explained how to make more than 2 Page - because on Page3,4,5... you can add this informations also by interceptions - without affecting 1&2.

But if you only want to have the weather forecast on Page1 - that would go without 5.4, too: JMLSpecial: Copy the Weather Dates from 2 to 1 in NEW Registry Keys and reference them by the .plg.

And JMLSpecial is always called after Weather update - so then the current weather would be copied again to Page1 - and so, you would have, what you want :)

OR: Using in .plg the SAME Item-Names (IconA, Icon1,...) to save Items - but you would also need the JMLSpecial-Script for your Skin, which always copies the Values in Registry from Page2 to 1 - I think, that would be the best solution.

Yes - I know it - like all other Titanium Plugins, JMLToday uses ATPlugin-Installer to install and also to change the Skins. And you know - it can only install in Standard-CPR - if you use another CPR - that would have no effect.

But there's a solution, which could make it - but that's needs time - and if such a solution would be made - it should made for whole Titanium:

You know that I'm developing TitaniumRSS - and there I have a Preview and a FullView Mode. The Preview is Standard-CPR (at the moment) and the FullView... I developed a C++-Program, which analyses the Titanium - and creates a new cpr - and there it clones the Theme, changes some things and injects new .plg's :) And switch to it by ExtensibilityXML-Entry.

The analysation needs less then 2 seconds - and the Switch takes the Time a Titanium Refresh needs :)

So: If you change JMLToday in Preview - the Full Mode is not affected... so long - as you don't choose "Reanalyse Theme" from TitaniumRSS-Menu - then the new JMLToday-Theme will be carried to the new cpr :)

If you change again JMLToday-Skin in Standard-Titanium - you would have to different JMLToday-Themes - which can be switched on the fly by TitaniumRSS.

This already works fine :) Also that I have a "whitelist" for Plugins, which should be transfered to the FullView-CPR.

So - the program to provide it to whole Titanium is already made. Only need to make it workable for other Plugins than TitaniumRSS would be needed.

But: There must be a concept, that should fulfill the following point:

- Each Titanium-Plugin should be chooseable installed in each Titanium-Plugin, where the user wants it

- You should be able to have as much Standard-Titanium-Themes, which you want, each can have different Plugins,designs

- You should have each other Themes, which you can choose to activate a Plugin with its special design, which fits to this Theme. And also should be actived/deactived on-the-fly

- To make JMLPanex work - the Concept should also be able to change each Non-Default-Theme to TitaniumListView by switching to it on-the-fly.

- therefore that some Plugins uses 24/7-Mortscripts - the Script should be deactivated if you use a theme, which doesn't have the responsible Plugin activated

- Also copying the assigned Bronzeres.dll, if a theme uses special designs

- Much Plugins are not maintained - and so they will only use ATPluginInstaller. So the Concept must consider this and make it possible, to inject everything afterwards on it's own

- Perhaps later on - replacement of ATPlugin-Installer with own setup.dll - that calls the program and shows a User-Interface, in which of his Themes, he wants to install the new Plugin or Skin. And also provide a PostInstall and PreUninstall-Interface.

- some more things...

Right now - I have the solution for all in my head:

Let's call it "TitaniumController" as working title for this program.

It should make at first one: Having a directory structure for all installed Titanium-Themes. On first install, it copies the current Theme to sth like "Titanium_current<res>.cpr" and replaces the Titanium<res>.cpr with an absolutely default standard.

Then the User can install as much Themes he wants, TitaniumConroller would clone them to a new name (so it's indifferent, if they use Standard-Titanium or new cpr-Names) - and if you want to change on the fly - TitaniumController would provide even this by user chosen current Theme to Titanium<res>.cpr - so each Plugin has the possibility to simply update its skin - JMLToday, too.

If a new Skin is needed - Titanium-Controller would mention it - and would ask, if you only want to install it to the current Theme, or all Standard-Themes, or only a special Theme.

So - there must be only made the Plugins like used - but indifferent how much Themes will come - each theme can use his own .plg for a Plugin - that suits to it. And that would be made by a nice User Interface, the user can add it, where he wants. And also to change to this Theme on the fly.

And that's full-automatic - no more developing .cpr's for each new Theme.

That would work - and the Change/Inject-Program is almost already written by me - but only for titaniumRSS at the moment. We would need only .plg's which suits to special Themes, which cannot use the Standard-plg's.

And a Surface, which let's the user choose, to which Theme he wants to change on-the-fly. And in which Skin he wants to have installed the Plugins.

So you would have a Titanium with much Themes (stored in internal storage - only active theme is on Main Storage ;) ) - and fast switchable. And each with free configurable plugins.

The only problem: Time :) I don't have the time, to write it all - and also not to collect plg's for special Themes - and also no time to make this configuration Menu. But I could extract my program from TitaniumRSS to make it workable for this idea.

How about a cooperation? For you it would be easier only to make special .plg's for special Themes - and you still have a configuaration menu to switch to it - should be only expanded for install, too :)

And then we could make it together, that it works. For all Themes - also each future Theme, which will come for Titanium. It's indifferent for the Analyser :)

Would be a benefit for each Skinner, for each Plugin-Developer - and for each user. And it would work for JMLToday perfect, too :)

But at first: The concept must be made. And then we could talk about, how the Analyser has to work and how to interact with On-the-fly-Changer/Installer-Surface.

If you want - you can have a look to the next Beta of TitaniumRSS, then you will know, that the on-the-fly-Change and Injector works already fine :) And absolutely secure, too :) Do you want it?

And when I have the first Release of TitaniumRSS (soon) , then we can have a look, how we can use the Change-Injector for everything. Cooperation? :)

And first Test will be made with JMLToday - because it's the most flexible / skinable Plugin for Titanium - and has no sideeffects because of its performance. And as Theme... all Themes, which you already have in your Portfolio :) Especially Standard-Titanium-Themes, Bliss, Josito Ch., NeoTitanium.

With Cabbing/Setup.dll's for later on - I think I am experienced enogh to do this, too, if we would need it. Depends on the concept for TitaniumController.

I think it would work with rewritten Changer/Injector and the surface from you.

@All: Sorry for the long text, but claus and some other people will understand, what I mean. The Rest can enjoy the Results afterwards, if we would make it together.

Micha