[Owncloud] Theming and Formfactors

Robin Appelman icewind at owncloud.com
Wed Feb 1 14:46:15 UTC 2012


On Wednesday 01 February 2012 15:18:31 Frank Karlitschek wrote:
> Hi,
> 
> 
> it seams that a lot of users want to modify the look and feel of ownCloud
> like replacing the logo, changing colors or make other custom interface
> changes. This is important if you integrate onwCloud into an existing
> system like a groupware or some other webservice. At the moment the users
> have to fork ownCloud and change the stuff manually. This changes have to
> be done again after every ownCloud update.
> 
> 
> The idea is to support theming in ownCloud to make this kind of changes
> easiert. It´s very important to make the life of the ownCloud App developer
> as easy as possible and not force them to maintain a lot of different theme
> files. App developers should concentrate of implementing the functionality
> and all the theming should be optional and done by someone else.
> 
> Different formfactors:
> Another important topic is that we have to support different formfactors
> beside the current interface which is mainly done for desktop users.
> ownCloud should provide an interface for desktops, mobil phones, tablets
> and a standalone view where an ownCloud App is displayed without the header
> and the side navigation. This is cool if you want to us just one part of
> ownCloud as a desktop app replacement. Mozilla Prism is a nice tool for
> this and I think the GNOME browser and Chrome also supports that. It´s
> handy for apps like media player, calendar, contacts and others to have
> them as stand alone apps on your desktop.
> 
> 
> 
> I propose the following changes to make this two features possible:
> 
> Formfactors:
> All parts of the core and every app has a template, a js and a css folder.
> We could extend the templating and the js/css loader that it first looks
> for a foo-mobile.php template if the app wants to load the foo.php template
> and the current formfactor is "mobile". If it finds the file it loads it.
> If not if falls back to the default foo.php. The same logic for the js and
> css files. By doing this we don´t have to implement the complete interface
> right now for all formfactors. We can do this over time. And if one App
> developer want´s to provide a special tablet optimized css he just add an
> additional css with this special name and it´s automatically used.

I had exactly the same idea for formfactors :)
I would suggest one tiny change though, use foo.mobile.php instead of 
foo-mobile.php

> 
> The formfator is already detected in base.php so we only have to extend the
> templating to use this information. Later we could add a button to the
> interface to switch to a different interface.
> 
> 
> Theming:
> I propose a similar system for the theming. We add a "theme" config option
> to the config.php so that the theme can be configured during deployment and
> controlled from the outside without the need to understand our database
> structure. We add "themes" directory into /core where every theme has a
> directory named after the theme name. The template and css loader looks
> into the selected theme directory first for templates and css files and
> loads them if a file is present. If not it just falls back to the default
> files in the individual app directories. This has the benefit that the
> person who creates the themes can override what ever has to be changed but
> don´t have to provide a complete new frontend. The directory structure
> inside the themes folder is the same as the rest of owncloud. This means
> that a theme developer can just put a different
> "apps/contacts/css/styles.css" in the theme directory to change the style
> of the contacts app.

Sounds good, although I would not put the styles in the core folder, maybe add 
a top-level themes folder?
> 
> 
> Does this make sense?
> 
> 
> 
> Cheers
> Frank

 - Robin Appelman



More information about the Owncloud mailing list