Remove `handheld`, add `speech` as default media types.

Typo fix.

Revert the http_cached line to the one already in the code to keep changes at a minimum.

Code Cleanup. Replaced \t with 4xSpace.

Changed the cache initialisation: it does not use the list of files with an md5 (due to redundancy and time consumption) but the flavour and the type (previously removed).

Use the flavour system to create individual css files. Only the default flavour (style / style.ini) will have the default styles for interwiki and filetypes. There are two new events:

1. CSS_STYLES

Use the flavour system to create individual css files. Only the default flavour (style / style.ini) will have the default styles for interwiki and filetypes. There are two new events:

1. CSS_STYLES_INCLUDED to modify the list of stylesheet files for a certain mediatype or prevent the mediatype or styles within it. This event is fired for the interwiki and filetypes too, to prevent that they are included
* The Data that is being sent to the event contains: list of files or the keyword DW_DEFAULT for the interwiki / filetypes; the mediatype, the flavour, if the data should be encapsulated by a default @media and the encapsualation prefix (e.g. @media screen)
2. CSS_CACHE_USE to prevent the use of a cached version of the CSS, just like the JS event that already exists.

show more ...

Add flavours to template ini files. The template will now be checked for multiple ini files and inserts them as a custom flavours. The css.php can detect these flavours and reads the stylesheet + rep

Add flavours to template ini files. The template will now be checked for multiple ini files and inserts them as a custom flavours. The css.php can detect these flavours and reads the stylesheet + replacements from there. If the flavour is not the default one (style.ini), replacements are loaded from the default flavour first to ensure that the colours are available. Flavours can define their own set of replacements.

show more ...

Remove type and caching mechanism. The cache will be checked later and the type will be replaced by an md5 hash of the list of style files.

Spaces, not tabs.

Add Event to modify the list of javascript files before they are processed. This allows plugins to not have their - or other plugins - script delivered to the client. Creating the list of files upfro

Add Event to modify the list of javascript files before they are processed. This allows plugins to not have their - or other plugins - script delivered to the client. Creating the list of files upfront might add a little overhead which I think is OK when you can be certain that only JavaScript that really is needed will be delivered to the client.

Multiple Javascript requests, e.g. to only send the jQuery part or just editor/administrator scripts, could be implemented with this modification (I know, jQuery has already been split).

show more ...

admin screen: override fill attribute of paths

When an svg has a fill attribute directly on the path, we need more
specifity to override it.

send correct mime for local jquery. should fix #1824

added RTL styles

smaller icons, less vertical space

optimized SVGs

ran svgo over all the admin svg files to strip all unneeded cruft.

created distinct create image, optimized images

I used svgo to strip all unneeded cruft from the svgs

made pageToolItem() more flexible

Now any arbitrary attributes can be passed as 4th argument. This way
classes etc could be added by plugins.

adjust the event

This will open up the discussion from #236 again and I'm not sure how to
solve this best.

The TEMPLATE_PAGETOOLS_DISPLAY event is very specific to the dokuwiki
template in theory.

adjust the event

This will open up the discussion from #236 again and I'm not sure how to
solve this best.

The TEMPLATE_PAGETOOLS_DISPLAY event is very specific to the dokuwiki
template in theory. In practice many other templates implemented not
only the same event but also use the same HTML (and often even the same
CSS). Which makes the event more like a core event.

This branch now changes the HTML the event expects back from handlers.
When merged it would immeadiately break all plugins implementing this
event (and by broken I mean the layout/design of the template breaks).

Since the expected data changes, I would argue this should be a new
event or at least be implemented in a way to not break the design by
installing an old plugin and by giving the plugin a chance to know if
it's running on the old or the new code.

This is what this commit does. By changing the view names, old plugins
should not display (because they hopefull do not handle those views) but
gives them an easy way to handle the old and new views in one plugin.

However, I'm not perfectly happy with it, yet.

The way I implemented the new SVG handling is by means of a new class
dokuwiki\template\dokuwiki\tpl which provides a pageToolAction() method.
Plugins could use this method to easily return the proper HTML for the
pagetool items and we could adjust this method later on to make
adjustments to the pagetools without breaking anything again.

However this method is template specific again. While it would possible
for plugins to use this method even when the wiki runs another plugin
emitting the event, it would be a bit weird.

A better way would be for the event to not expect HTML at all, but
instead a data structure of the data currently passed to
pageToolAction(). Templates could then decide to implement the event,
but still render the data in a completely different way...

OTOH this means plugins are no longer free to add whatever they want
into the pagetools. We once argued plugins might want to add submenus or
other fancy stuff there. But in fact no plugin ever did.

If we decide to go this new way of making the event more of a first
class citizen of template development, then we would probably have to
move parts or all of the tpl class back to the core.

show more ...

adjusted function name

translation update

proper action handling for pagetools

The whole pagetool items are now build in an extra helper class that can
be reused by plugins.

first very simple attempt at implementing svg pagetools

todos:

* edit action (and maybe others) use different icons depending on state,
we can't rely on passing $post
* media details screen not a

first very simple attempt at implementing svg pagetools

todos:

* edit action (and maybe others) use different icons depending on state,
we can't rely on passing $post
* media details screen not adjusted, yet
* no RTL styles
* no focus/active styles
* the event needs to be adjusted (maybe throw it away and do a new one)
* some icons are not good (create = edit)
* possibly more

show more ...

translation update

remove unused code

use lower case class names