One more question about themes
23 views
Skip to first unread message
Yakov
Feb 2, 2011, 3:14:38 PM2/2/11
to TiddlyWiki
It is known that the
<html><a href="javascript:;"
onclick="story.switchTheme(config.options.txtTheme)">apply</a></html>
link "reprocess" the theme so that if the cookie value is changed, a
new theme is applied. Now, how do I use OPTION and OPTGROUP elements
to create a "select theme" ~popup (or how is it called?) which
launches the reprocessing function when a theme is choosen by
clicking?
Also, what are the main reasons to use plugins for theme switching
aside that they provide some macros (say, if I have a solution
described above)?
<html><a href="javascript:;"
onclick="story.switchTheme(config.options.txtTheme)">apply</a></html>
link "reprocess" the theme so that if the cookie value is changed, a
new theme is applied. Now, how do I use OPTION and OPTGROUP elements
to create a "select theme" ~popup (or how is it called?) which
launches the reprocessing function when a theme is choosen by
clicking?
Also, what are the main reasons to use plugins for theme switching
aside that they provide some macros (say, if I have a solution
described above)?
PMario
Feb 3, 2011, 5:06:49 AM2/3/11
to TiddlyWiki
There is SwitchThemePlugin from TiddyTools, which has some init and
exit scripts, that can be executed if a theme is changed.
And SelectThemePlugin from Simon Baird (MPTW) can also change the
ColorPalette.
Both do what you suggest. Both have about 80 lines of code + inline
description. Both are automatically aware of new Themes, if a tiddler
is tagged systemTheme / systemPalette.
<html> inline code is imo "ugly". I won't use it, if a macro is
available.
<html> inline code may be filtered by TiddlySpace, like
{{tiddler.title}}
If your suggested solution uses less lines, and is as flexible, ....
-m
Yakov
Feb 4, 2011, 2:50:26 AM2/4/11
to TiddlyWiki
Aha, I see. Thanks PMario.
> Both are automatically aware of new Themes, if a tiddler
> is tagged systemTheme / systemPalette.
The first thing is the automatic aggregation of existing tiddlers.
Though both plugins don't provide the dropdown selector to select
among *chosen* themes (not all the themes available). And in my case
this could be important in further writing since themes provide not
only appearence, but also "language" and author/reader(/contributor)
mode.
> <html> inline code may be filtered by TiddlySpace, like {{tiddler.title}}
This is interesting. I still don't use TiddlySpace, so could you give
an example or some link which shows what this "filtering" filters? I
mean I have no idea what you are talking about.
Yakov.
> Both are automatically aware of new Themes, if a tiddler
> is tagged systemTheme / systemPalette.
Though both plugins don't provide the dropdown selector to select
among *chosen* themes (not all the themes available). And in my case
this could be important in further writing since themes provide not
only appearence, but also "language" and author/reader(/contributor)
mode.
> <html> inline code may be filtered by TiddlySpace, like {{tiddler.title}}
an example or some link which shows what this "filtering" filters? I
mean I have no idea what you are talking about.
Yakov.
PMario
Feb 4, 2011, 5:10:18 PM2/4/11
to TiddlyWiki
On Feb 4, 8:50 am, Yakov <yakov.litvin.publi...@gmail.com> wrote:
> The first thing is the automatic aggregation of existing tiddlers.
> Though both plugins don't provide the dropdown selector to select
> among *chosen* themes (not all the themes available).
Have a look at my FreeStyle [1] space. Top menue. It uses
> The first thing is the automatic aggregation of existing tiddlers.
> Though both plugins don't provide the dropdown selector to select
> among *chosen* themes (not all the themes available).
SelectThemePlugin and lists all tiddlers tagged systemTheme, that I
made available to this space.
> .. And in my case
> this could be important in further writing since themes provide not
> only appearence, but also "language" and author/reader(/contributor)
> mode.
I think themes can handle this.
> only appearence, but also "language" and author/reader(/contributor)
> mode.
> > <html> inline code may be filtered by TiddlySpace, like {{tiddler.title}}
>
> This is interesting. I still don't use TiddlySpace, so could you give
> an example or some link which shows what this "filtering" filters? I
> mean I have no idea what you are talking about.
but eg:
<<tiddler AnyTemplate with: {{tiddler.title}}>>
the {{tiddler.title}} is evaluated by the tiddler macro prior to
giving the result to AnyTemplate. It's value is the title of the
containing tiddler. Which is quite usefull. But tiddly space blocks
this type of evaluation, because of security reasons.
There is some discussion, that also inline <html> blocks can bring in
scripts, that may contain malicious code, and should be filtered,
prior to rendering. Similar things happen to svg, because it also can
contain javascript code.
If you have a look at the TiddlyWeb and TiddlyWikiDev group, and
search about "tiddlyspace security" sorted by date, you'll find more.
-m
[1] http://freestyle.tiddlyspace.com/
Yakov
Feb 7, 2011, 1:32:34 AM2/7/11
to TiddlyWiki
> I think themes can handle this.
Sure, but it's not the point. The point is when I want to make three
styles and two languages, I need to create 6 themes; and after this, I
want to allow user to choose style and language separately ("choose
style", "choose language" in the menu, not "choose the style-language
pair"). So I need those selectors two list only calculated set of
themes, not all of them. Sure, this can be done with switchTheme
macros but it's not very beatiful, I mean "links" instead of
selectors.
> ...
> If you have a look at the TiddlyWeb and TiddlyWikiDev group, and
> search about "tiddlyspace security" sorted by date, you'll find more.
Ok, thanks, I'll look into this a bit more.> search about "tiddlyspace security" sorted by date, you'll find more.
PMario
Feb 7, 2011, 6:36:03 AM2/7/11
to TiddlyWiki
On Feb 7, 7:32 am, Yakov <yakov.litvin.publi...@gmail.com> wrote:
> > I think themes can handle this.
>
> Sure, but it's not the point. The point is when I want to make three
> styles and two languages, I need to create 6 themes; and after this, I
> want to allow user to choose style and language separately ("choose
> style", "choose language" in the menu, ...
> > I think themes can handle this.
>
> Sure, but it's not the point. The point is when I want to make three
> styles and two languages, I need to create 6 themes; and after this, I
> want to allow user to choose style and language separately ("choose
All core texts, are hardcoded. So if you want to switch them it needs
a translation tiddler which is tagged systemConfig. Switching language
means to disable systemConfig tag. The problem is, that most themes
also contain some tiddlers, that have language specific text with it.
Changing systemConfig won't change them.
> .. not "choose the style-language
> pair"). So I need those selectors two list only calculated set of
> themes, not all of them. Sure, this can be done with switchTheme
> macros but it's not very beatiful, I mean "links" instead of
> selectors.
===
> themes, not all of them. Sure, this can be done with switchTheme
> macros but it's not very beatiful, I mean "links" instead of
> selectors.
You are right. multi-language multi-themes handling includes some
extra work and concept.
But I don't see, how your original post would solve anything of this.
Since core and plugin texts are "hardcoded" I would solve language
switching by using different URLs.
I'd do it the tiddlySpace way:
helper spaces
A) data
a) myThemes contains all the themes.
b) german
c) anyLanguage
1) myTW-en
2) myTW-ge
1) and 2) both include a)myThemes space, So it is possible to switch
themes. Even if the user downloads the space.
1) and 2) both include A)data space, which contains the initial info
tiddlers.
1) myTW-en is finished, since the core TW language is english and most
plugins come with english texts :)
2) myTW-ge needs to include the b)german space to have german language
support (core only).
===
The advantage of this structure is:
* if you change something in a)myThemes, your spaces 1)2) are updated
automatically.
* automatic update 1)2) if the langauge spaces are changed
* you can have different A)data spaces if needed.
The disadvantage is:
*increased file size
**may be this is not true. because a fileTW that contains all
supported languages, and themes will also be big.
===
There are several translation spaces [1], where you can see, how to
handle it.
[1] http://showroom.tiddlyspace.com/#Translations
Yakov
Feb 10, 2011, 2:30:09 PM2/10/11
to TiddlyWiki
Sorry for a long silence, got some work to do.
> I don't see, how your original post would solve anything of this.
Well, this is simple. If I knew the markup which make the selector
which launches some scripts after each choise, I would be able to make
a script which would generate the markup (for choosing a language, for
example) depending on what other choises were made (style for
example). Though, afterall the approache with switchTheme macros and
some CSS and scripting are much simpler.
> All core texts, are hardcoded. ...
While switching language of the interface is also of concern, at first
I need to be able to switch languages of the content. I've already
written the themes and markuped the content along with adding extra
field for titles in another language and themes to represent them. Now
only a simple system of theme switching, interface translation and
cookies initiation for the first visit are of concern.
Your solution is not absolutely clear for me. Does the A) space
contain the english content with the b) containing the german? What's
the c) for? (I mean, in your example there are only 1) and 2)). In
fact, I need test this, but I'm not sure I want to work in the cloud
initially. I would be excelent if the IncludePlugin ([1]) worked with
the same syntax as TiddlySpace, but as I understand, it doesn't. Also,
the space you've mentioned doesn't include the russian translation and
TiddlySpace works badly in Opera. :D So many annoying things.
Anyway, thank you for your attention and help.
[1] http://tiddlywiki.abego-software.de/#IncludePlugin
> I don't see, how your original post would solve anything of this.
which launches some scripts after each choise, I would be able to make
a script which would generate the markup (for choosing a language, for
example) depending on what other choises were made (style for
example). Though, afterall the approache with switchTheme macros and
some CSS and scripting are much simpler.
> All core texts, are hardcoded. ...
While switching language of the interface is also of concern, at first
I need to be able to switch languages of the content. I've already
written the themes and markuped the content along with adding extra
field for titles in another language and themes to represent them. Now
only a simple system of theme switching, interface translation and
cookies initiation for the first visit are of concern.
Your solution is not absolutely clear for me. Does the A) space
contain the english content with the b) containing the german? What's
the c) for? (I mean, in your example there are only 1) and 2)). In
fact, I need test this, but I'm not sure I want to work in the cloud
initially. I would be excelent if the IncludePlugin ([1]) worked with
the same syntax as TiddlySpace, but as I understand, it doesn't. Also,
the space you've mentioned doesn't include the russian translation and
TiddlySpace works badly in Opera. :D So many annoying things.
Anyway, thank you for your attention and help.
[1] http://tiddlywiki.abego-software.de/#IncludePlugin
Reply all
Reply to author
Forward
0 new messages