Text only | Text with Images

ElkArte Community

Elk Development => Feature Discussion => Topic started by: emanuele on December 23, 2012, 05:17:10 am

Title: Unify themes and mods behaviour?
Post by: emanuele on December 23, 2012, 05:17:10 am
Moving here as new feature request.

Quote from: emanuele – mmm...would be scary to "unify" themes and mods and give them (almost) the same powers?
It shouldn't be too difficult, I already changed theme installation to use the xmlArray class (or whatever it is) and some of the packages related functions. Give them the remaining power would allow to unify the interface too and the versioning... O:-)
Title: Re: Unify themes and mods behaviour?
Post by: TestMonkey on December 23, 2012, 06:12:14 am
Thanks! We've been contemplating this one way or the other for a long time.

Lets see... 8)

Essentially, they are two different beasts: one changes behavior/functionality, the other presentation. That aside. We need to discuss specificities.
What can be brought closer?

[just brainstorming]

# Installation.
Sure. Installers on one side (package manager and theme installer), "drop files and it just works" on the other side (we have some bits, package manager can install from /Packages/package_name subfolder; works for addons following dispatcher patterns and/or hooks)
# Removal.
The forum is good enough without a theme (well it works, and you'll crawl to change the theme), same without an addon that would only use the dispatcher (but that's a simple one or fully external pages), respectively for an extra-subscription (same principle, dynamic loading); it doesn't work for addons based on hooks even.
# Package manager and theme installer.
 At the level of code: make them a single installer.
 At the level of behavior: for a mod with files in a subdirectory of /Packages, respectively for a theme added manually to /Themes, can we unify behavior of the installer.
 Extra-functionality. Package servers for themes.
# Versioning...
Two issues: make theme installer recognize and compare version of the forum with the version the theme works for; and, versioning system for themes (recognize an update, install it).

A few more questions.
# Do themes use hooks? Is it recommended to?
# Do we need or want template hooks?
Title: Re: Unify themes and mods behaviour?
Post by: emanuele on December 23, 2012, 07:32:21 am
Pre-question: will addons (is that the name of mods for D?) be allowed to edit files as in SMF or will they just use hooks and similar things?
Title: Re: Unify themes and mods behaviour?
Post by: TestMonkey on December 23, 2012, 09:06:57 am
/me didn't realize this question may be asked for the next version... and it's surprised that Ema asks it. :)

My personal take: I think it's obvious for 1.0 it's supported just like any SMF mod. ('tis not on the roadmap either). I think it's the almost the same for 2.0, from my perspective. (don't shoot me, please remember I'm hardwired in a two-versions-ahead mode atm, lol, the other topic stretches it). I can see the possibility it will change for 2.0, for all or a part of the core software.

But I don't know about many of the details or intentions you folks have so far. And, you can always change it when I ain't looking, hey. :D

It's a feature of package manager, and while it's not making me happy (in a way), it's our current most used "extensibility mechanism" (yeah it's not "extensibility"), and it works. Why would we change it, soon?
Title: Re: Unify themes and mods behaviour?
Post by: Antechinus on December 23, 2012, 02:06:27 pm
Quote from: TestMonkey – Thanks! We've been contemplating this one way or the other for a long time.

Lets see... 8)

Essentially, they are two different beasts: one changes behavior/functionality, the other presentation.
You just made your first mistake. In fact, it's common for themes to change functionality and it's common for mods to change presentation. The boundaries between mod and theme are a bit blurry sometimes.

QuoteThat aside. We need to discuss specificities.
What can be brought closer?

[just brainstorming]

# Package manager and theme installer.
 At the level of code: make them a single installer.
 At the level of behavior: for a mod with files in a subdirectory of /Packages, respectively for a theme added manually to /Themes, can we unify behavior of the installer.
 Extra-functionality. Package servers for themes.
# Versioning...
Two issues: make theme installer recognize and compare version of the forum with the version the theme works for; and, versioning system for themes (recognize an update, install it).
That all sounds pretty good as a starting point (haven't thought about it in great detail). Something like this has been talked about for ages, and in general I think it makes sense.

QuoteA few more questions.
# Do themes use hooks? Is it recommended to?
# Do we need or want template hooks?
If by the first you mean "Should themes rely on hooks for any template changes they make to default?" then I would very definitely say "No." In fact, if you go down that route I would have no interest in working on such a beast.

If you mean "Should custom themes include, as far as possible, any hooks which are also in default templates?" then sure, that makes sense.
Title: Re: Unify themes and mods behaviour?
Post by: Antechinus on December 23, 2012, 02:08:03 pm
Quote from: emanuele – Pre-question: will addons (is that the name of mods for D?) be allowed to edit files as in SMF or will they just use hooks and similar things?
They should be allowed to edit files, but they should also avoid it as much as possible. Again, if you totally disallow editing of files then I'm out the door.
Title: Re: Unify themes and mods behaviour?
Post by: emanuele on December 23, 2012, 04:22:41 pm
Quote from: TestMonkey – /me didn't realize this question may be asked for the next version... and it's surprised that Ema asks it. :)
/me likes to ask innocent questions... O:-)

Quote from: TestMonkey – But I don't know about many of the details or intentions you folks have so far.
Me neither and that's why I asked! :P

Quote from: TestMonkey – It's a feature of package manager, and while it's not making me happy (in a way), it's our current most used "extensibility mechanism" (yeah it's not "extensibility"), and it works. Why would we change it, soon?
Good.

Quote from: Antechinus –
QuoteEssentially, they are two different beasts: one changes behavior/functionality, the other presentation.
You just made your first mistake. In fact, it's common for themes to change functionality and it's common for mods to change presentation. The boundaries between mod and theme are a bit blurry sometimes.
In theory the separation should be very well defined.
Unfortunately with SMF is not.
The theory is: you want to create a theme with new functionality? You create a mod and you create a theme that works with that mod.

But: I have to partially agree with Ant and I feel a mod with a template is somehow not so different from a theme with an addon.
Yes, the mod shouldn't replace an entire template, but at the moment nothing forbids them to do so.

So another way to ask my question is: how far we want to push the distinction "for now" (see the end of the post)?

Quote from: TestMonkey – # Do themes use hooks? Is it recommended to?
I think themes should be encouraged to use some of the available functions.
What I have in mind at the moment more than anything else is loadCSSFile and loadJavascriptFile (and equivalent for inline js and js variables).
Unfortunately at the moment I don't think it's so easy (themes can use them easily, but if they have to load something on a specific action it could be annoying).
Not sure of other ways to "use hooks" in themes.

Quote from: TestMonkey – # Do we need or want template hooks?
Depends on how they would work.
A thing I like (and I used in some of my mods) is the custom fields system: in other words I add something to $context['custom_field'] (or whatever it is) "source-side" and these things are displayed somewhere in the template with a predefined style.
But I would avoid the use of call_integration_hook in templates (this facilitates the misuse of the separation between presentation and computation). If someone wants to add something to the template there are already layers (that in some cases would take advantage of a bit more granular subdivision).
For example the "advanced and other options" thing here below would be much cooler if converted to an array of variables moved to source (/me hears Ant screaming) and a foreach of sort for the display, that would give mods a much easier way to add things to the template.
The moment mods will have enough possibilities to add/remove things from the interface without touching a theme file, then a clear distinction between mods and themes would make sense.

tl;dr: I'm still very confused and I don't have an answer yet... lol
Title: Re: Unify themes and mods behaviour?
Post by: TestMonkey on December 23, 2012, 04:47:19 pm
Quote from: Antechinus –
Quote from: TestMonkey – Thanks! We've been contemplating this one way or the other for a long time.

Lets see... 8)

Essentially, they are two different beasts: one changes behavior/functionality, the other presentation.
You just made your first mistake. In fact, it's common for themes to change functionality and it's common for mods to change presentation. The boundaries between mod and theme are a bit blurry sometimes.

I didn't know. I didn't spend hundreds of hours on broken installations because they do exactly that. I didn't fix endless conflicts because they do exactly that. I didn't contemplate dozens of potential security issues because themes write to superglobals even. None of them does it in a standard, extensible, friendly to the other, way.

I am well aware that the mods vs themes system is broken, thank you for the news.

Sounds like you're not aware of what code design principles are. Here's a bit for you: mods/addons extend or change the functionality, and should be able to format their output and send it over (where they lose control over it, the theme may choose not to display it). Themes shouldn't provide extra-functionality, but be able to process data and extra-data on their own, including extra-output from mods/addons.
"mods" shouldn't just replace code in the templates, to provide the display of their data. And "themes" shouldn't just replace everything, at install/loading, without accepting extra data for sections or sections entirely.

Quote
QuoteA few more questions.
# Do themes use hooks? Is it recommended to?
# Do we need or want template hooks?
If by the first you mean "Should themes rely on hooks for any template changes they make to default?" then I would very definitely say "No." In fact, if you go down that route I would have no interest in working on such a beast.

If you mean "Should custom themes include, as far as possible, any hooks which are also in default templates?" then sure, that makes sense.

I have a different suggestion: take a deep breath and calm down. I don't appreciate you put words in my mouth. And out of the blue, at that. Sounds like this is your day of doing exactly that, then bitching at it.

To the point: I'm not convinced we should add template hooks. That's what a question is, you know: I am asking if others think we should and why.
Title: Re: Unify themes and mods behaviour?
Post by: Antechinus on December 23, 2012, 05:13:47 pm
Quote from: emanuele –
Quote from: Antechinus – You just made your first mistake. In fact, it's common for themes to change functionality and it's common for mods to change presentation. The boundaries between mod and theme are a bit blurry sometimes.
In theory the separation should be very well defined.
Unfortunately with SMF is not.
The theory is: you want to create a theme with new functionality? You create a mod and you create a theme that works with that mod.

Ok, but I can see a problem with that. What if you only want the extra functionality on one theme? At the moment it's easy.

QuoteBut: I have to partially agree with Ant and I feel a mod with a template is somehow not so different from a theme with an addon.
Yes, the mod shouldn't replace an entire template, but at the moment nothing forbids them to do so.
One of mine does. :D

It was simply the cleanest and easiest way of dealing with it.
Title: Re: Unify themes and mods behaviour?
Post by: Antechinus on December 23, 2012, 05:21:29 pm
Quote from: TestMonkey –
Quote from: Antechinus –
Quote from: TestMonkey – Thanks! We've been contemplating this one way or the other for a long time.

Lets see... 8)

Essentially, they are two different beasts: one changes behavior/functionality, the other presentation.
You just made your first mistake. In fact, it's common for themes to change functionality and it's common for mods to change presentation. The boundaries between mod and theme are a bit blurry sometimes.

I didn't know. I didn't spend hundreds of hours on broken installations because they do exactly that. I didn't fix endless conflicts because they do exactly that. I didn't contemplate dozens of potential security issues because themes write to superglobals even. None of them does it in a standard, extensible, friendly to the other, way.

I am well aware that the mods vs themes system is broken, thank you for the news.
You're welcome. :D


QuoteSounds like you're not aware of what code design principles are. Here's a bit for you: mods/addons extend or change the functionality, and should be able to format their output and send it over (where they lose control over it, the theme may choose not to display it). Themes shouldn't provide extra-functionality, but be able to process data and extra-data on their own, including extra-output from mods/addons.
Well that's great as a principle, but unfortunately it doesn't work like that in practice. Case in point: that test theme I've been working on. It relies on adding new functionality in the theme itself.

Could it be done another way, by installing a separate mod and them calling that functionality into the theme? Sure, it could, but that's an extra layer of complication for absolutely no benefit. Why on earth would anyone bother?


Quote
Quote
QuoteA few more questions.
# Do themes use hooks? Is it recommended to?
# Do we need or want template hooks?
If by the first you mean "Should themes rely on hooks for any template changes they make to default?" then I would very definitely say "No." In fact, if you go down that route I would have no interest in working on such a beast.

If you mean "Should custom themes include, as far as possible, any hooks which are also in default templates?" then sure, that makes sense.

I have a different suggestion: take a deep breath and calm down. I don't appreciate you put words in my mouth. And out of the blue, at that. Sounds like this is your day of doing exactly that, then bitching at it.

To the point: I'm not convinced we should add template hooks. That's what a question is, you know: I am asking if others think we should and why.
I wasn't bitching. I was asking what you meant. :P And providing my opinion on answers to the possible meanings of your questions.

Ok, what, exactly, do you mean by "template hooks"? How do you envisage them working?
Title: Re: Unify themes and mods behaviour?
Post by: TestMonkey on December 25, 2012, 10:13:23 am
Quote from: Antechinus –
QuoteSounds like you're not aware of what code design principles are. Here's a bit for you: mods/addons extend or change the functionality, and should be able to format their output and send it over (where they lose control over it, the theme may choose not to display it). Themes shouldn't provide extra-functionality, but be able to process data and extra-data on their own, including extra-output from mods/addons.
Well that's great as a principle, but unfortunately it doesn't work like that in practice. Case in point: that test theme I've been working on. It relies on adding new functionality in the theme itself.

Could it be done another way, by installing a separate mod and them calling that functionality into the theme? Sure, it could, but that's an extra layer of complication for absolutely no benefit. Why on earth would anyone bother?

The question is, how are themes doing it. Lets imagine this (roughly), for the sake of the experiment:
# you write a theme, where you display your wanted functionality nicely
# you provide a php file where you implement your wanted functionality, using only hooks (lets say you can, the hooks system is great yada-yada)
# your implementation sends all kinds of extra-data to $context, where your theme picks them up
# you provide a function, to install the hooks, and one to remove them
# the admin will install your theme using Teh New Theme Installer (emanuele @ 2013)
# Profit.

Lets have at this scenario. :)
Title: Re: Unify themes and mods behaviour?
Post by: Antechinus on December 25, 2012, 01:12:21 pm
Sounds awfully complicated, for absolutely no benefit over the current way of doing it. I ask again, why would anyone bother? If you want to change something to a more complicated way of doing things, it's up to you to be convincing about the benefits.

Ok, having at it:

# Yay! I like this bit. :)

# Why would I bother? Seriously. Your assuming I want to write and support mods, not make a theme.

# Same question again. For some things there's no need to go anywhere near $context.

# See 2. Talk about convoluted.

# That's the general idea.

# Not in it for the money. :P

You have to remember the way I tend to code themes: ruthlessly, cleanly, and with absolutely no qualms about ditching crap I don't need. If it's not directly useful to me, it wont stay in the templates.

That even extends as far as language strings. For a default theme that has to handle i18n, language strings are essential. However, for custom work on sites where the interface is basically monolingual, hard coding text is easier and is better for performance.
Title: Re: Unify themes and mods behaviour?
Post by: emanuele on December 25, 2012, 01:22:49 pm
Quote from: Antechinus – Your assuming I want to write and support mods, not make a theme.
Well, you cannot assume we are writing a forum for your own use. :P
We are writing it for anyone and it should have "a way to work" that works.
Title: Re: Unify themes and mods behaviour?
Post by: TestMonkey on December 25, 2012, 01:38:04 pm
Well. To implement functionality, addons use hooks. (lets say it's usual)
To implement functionality, why would themes break that (in addition to implementing functionality itself, which isn't 'display existing functionality any way you freaking please').
Mods could be written without hooks, too. (and some will). We're talking about trying to make the core approach give people tools to do the job differently. What they do with the tools is up to them in the end, but that's not really the point.

But I agree that "if it's too complicated then I won't do it", this is a fair point. Lets make it less complicated (if it is).
What is currently complicated about hooks? (I has a couple beefs tbh).
What is complicated about setting variables to $context?1

For the record, this is the recommended standard for core: to implement functionality separately from presentation of the functionality. (where 'recommended' = 'required').
This is the recommended standard for addons: to implement functionality separately from presentation of the functionality.
(where 'recommended' = 'recommended').
In the context of this discussion, I will propose the following statement: themes are about presentation of existing functionality, but if they implement new functionality, then they should do it separately (at file/code design/implementation level) from the presentation of the functionality.

1 we could also provide a gateway function if it makes any sense... it could also help the core track what the extension [addon/theme] are adding... probably not a good idea though
Title: Re: Unify themes and mods behaviour?
Post by: Antechinus on December 26, 2012, 03:02:00 pm
Quote from: emanuele – Well, you cannot assume we are writing a forum for your own use. :P
We are writing it for anyone and it should have "a way to work" that works.
Yeah sure. I get that. I'm just saying that people should still have the option to code things how they like, without being locked into one path because somebody thought that was the right way.
Title: Re: Unify themes and mods behaviour?
Post by: Antechinus on December 26, 2012, 03:15:29 pm
Quote from: TestMonkey – Well. To implement functionality, addons use hooks. (lets say it's usual)
To implement functionality, why would themes break that
Easy answer: because it's quicker and cleanner to code, and will give better performance. To me, those sound like good reasons. It depends what you want to support though.


QuoteWe're talking about trying to make the core approach give people tools to do the job differently. What they do with the tools is up to them in the end, but that's not really the point.
Fair enough.


QuoteBut I agree that "if it's too complicated then I won't do it", this is a fair point. Lets make it less complicated (if it is).
What is currently complicated about hooks? (I has a couple beefs tbh).
What is complicated about setting variables to $context?1

For the record, this is the recommended standard for core: to implement functionality separately from presentation of the functionality. (where 'recommended' = 'required').
This is the recommended standard for addons: to implement functionality separately from presentation of the functionality.
(where 'recommended' = 'recommended').

In the context of this discussion, I will propose the following statement: themes are about presentation of existing functionality, but if they implement new functionality, then they should do it separately (at file/code design/implementation level) from the presentation of the functionality.
Ok just for examples, take multi-option themes. So we're inheriting the 2.0.x theme variant system, which is good up to a point. The point comes when some silly bugger decides to get creative. This is, basically, what themes are about, and it's also why I fight against the "let's put everything in Sources" stuff. For someone who is into code architecture, it probably seems like a great idea to put as much as possible in Sources, whereas for themers it's the exact opposite: they want the absolute minimum locked away in Sources.

Anyway, for the latest guinea pig I wanted several layout options as well as several background/colour options. I've gone for four of each.* If you try to do all of that with the existing theme variant system, it becomes a wheels within wheels scenario when you want to choose your preferred option. The theme would have to be set up to take account of all the permutations, which would be a PITA. Simple way to do it: allow people to choose their preferred background independently of the layout option.

That's what I've done, and it can be done in the template with very little code. This is obviously new functionality, but I don't see any reason to have to make it a separate mod.

*BTW, the reason I did this was because I've been thinking for some time that the variant system is ideal for offering different layout options, but that didn't mean I wanted to restrict colour/background options either. I want it all and I want it now. :D
Title: Re: Unify themes and mods behaviour?
Post by: TestMonkey on December 26, 2012, 03:55:01 pm
Thanks for the explanation and case scenario. :)
OK, I admit that the percentage of blood left in alchohol at this exact time is quite low. But I'm sure this stands: can you please share the code (or give us a link to it), so we can see the problem of this functionality on the code, concretely?

Disclaimer: I actually am not sure I am well aware of the latest fixes/changes Spuds and Ema did for multi-variant themes, and I would need to look closely into it anyway.
Title: Re: Unify themes and mods behaviour?
Post by: Antechinus on December 26, 2012, 04:08:46 pm
Ok, but said guinea pig is 1.1.x, not 2.0.x or 2.1 or the dreaded Los el Cartos Amigos. Code is quite simple though. It's the same basic idea used in all 1.1.x multis, and in some of Bloc's themes for background pickers. Goes like this:
Code: [Select]
	 // Layout changer.
	if(!$context['user']['is_guest'] && isset($_POST['options']['theme_layout']))
	{
		include_once($GLOBALS['sourcedir'] . '/Profile.php');
		makeThemeChanges($context['user']['id'], $settings['theme_id']);
		$options['theme_layout'] = $_POST['options']['theme_layout'];
	}
	elseif ($context['user']['is_guest'])
	{
		if (isset($_POST['options']['theme_layout']))
		{
		  $_SESSION['theme_layout'] = $_POST['options']['theme_layout'];
		  $options['theme_layout'] = $_SESSION['theme_layout'];
		}
		elseif (isset($_SESSION['theme_layout']))
		  $options['theme_layout'] = $_SESSION['theme_layout'];
	}

	// Background changer.
	if(!$context['user']['is_guest'] && isset($_POST['options']['mypic']))
	{
			include_once($GLOBALS['sourcedir'] . '/Profile.php');
			makeThemeChanges($context['user']['id'], $settings['theme_id']);
			$options['mypic'] = $_POST['options']['mypic'];
	}
	elseif ($context['user']['is_guest'])
	{
		if (isset($_POST['options']['mypic']))
		{
			$_SESSION['mypic'] = $_POST['options']['mypic'];
			$options['mypic'] = $_SESSION['mypic'];
		}
		elseif (isset($_SESSION['mypic']))
			$options['mypic'] = $_SESSION['mypic'];
	}

}

// The main sub template above the content.
function template_main_above()
{
	global $context, $settings, $options, $scripturl, $txt, $modSettings;

	// Show right to left and the character set for ease of translating.
	echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"', $context['right_to_left'] ? ' dir="rtl"' : '', '><head>
	<meta http-equiv="Content-Type" content="text/html; charset=', $context['character_set'], '" />
	<meta http-equiv="X-UA-Compatible" content="chrome=1" />
	<meta name="viewport" content="width=device-width" />
	<meta name="description" content="', $context['page_title'], '" />', empty($context['robot_no_index']) ? '' : '
	<meta name="robots" content="noindex" />', '
	<meta name="keywords" content="cemb, ex muslim, former muslim, council of ex-muslims, leaving islam, discuss islam, islam, murtad, apostate, sharia, koran, quran, hadith" />';

	// Any layout set by user?
	if (isset($options['theme_layout']))
		$settings['theme_layout'] = $options['theme_layout'];

	// If not set, or if not allowed to set
	if(!isset($options['theme_layout']) || (isset($settings['allow_layout_change']) && $settings['allow_layout_change'] == 'no'))
	{
		// Defaults.
		($context['browser']['is_touchscreen']) ? ($options['theme_layout'] = 'Mobile') : ($options['theme_layout'] = isset($settings['theme_layout']) ? $settings['theme_layout'] : 'Standard');
		$settings['theme_layout'] = $options['theme_layout'];
	}

	// Any backround set by user?
	if (isset($options['mypic']))
		$settings['mypic'] = $options['mypic'];

	// If not set.....
	if(!isset($options['mypic']))
	{
		// Defaults.
		$options['mypic'] = isset($settings['mypic']) ? $settings['mypic'] : '1';
		$settings['mypic'] = $options['mypic'];
	}

	// Load stylesheets before javascript. Avoids FOUC on page load.
	echo '
	<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/style_Standard.css?116" />';
	if ($settings['theme_layout'] !== 'Standard')
	echo '
	<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/style_' , $settings['theme_layout'] , '.css?116" />';

Then it just has a couple of selects anywhere else for the pickers. Now of course you could do this with the variant system. In that case you'd just decide which function you wanted to run via variants, and which one you wanted to run via the custom code (one instance of, instead of two).

Selects are coded like this:
Code: [Select]
	// Layout selection.
	if (isset($settings['allow_layout_change']) && $settings['allow_layout_change'] == 'buttons')
	{
		echo '
					<form name="layout_select" action="' . $_SERVER['REQUEST_URL'] . (strpos($_SERVER['REQUEST_URL'], '.php?') !== false ? ';' : '?') . '" method="post">
						Layouts&nbsp;
						<select size="1" name="options[theme_layout]" onchange="submit()">
							<option value="Mobile"		', (!empty($options['theme_layout']) && $options['theme_layout'] ==		'Mobile') ? 'selected="selected"' : '' ,'>Mobile</option>
							<option value="Smallscreen"	', (!empty($options['theme_layout']) && $options['theme_layout'] =='Smallscreen') ? 'selected="selected"' : '' ,'>Smallscreen</option>
							<option value="Standard"	', (!empty($options['theme_layout']) && $options['theme_layout'] ==	  'Standard') ? 'selected="selected"' : '' ,'>Standard</option>
							<option value="Widescreen"	', (!empty($options['theme_layout']) && $options['theme_layout'] ==	'Widescreen') ? 'selected="selected"' : '' ,'>Widescreen</option>
						</select>
					</form>';
	}
	// Background selection.
	if ($settings['theme_layout'] !== 'Mobile')
	{
		echo '
					<form id="background_select" name="background_select" action="' . $_SERVER['REQUEST_URL'] . (strpos($_SERVER['REQUEST_URL'], '.php?') !== false ? ';' : '?') . '" method="post">
						Styles&nbsp;
						<select size="1" name="options[mypic]" onchange="submit()">
							<option value="1" ', (!empty($options['mypic']) && $options['mypic']=='1') ? 'selected="selected"' : '' ,'>Light stone</option>
							<option value="2" ', (!empty($options['mypic']) && $options['mypic']=='2') ? 'selected="selected"' : '' ,'>Dark grunge</option>
							<option value="3" ', (!empty($options['mypic']) && $options['mypic']=='3') ? 'selected="selected"' : '' ,'>Evening sky</option>
							<option value="4" ', (!empty($options['mypic']) && $options['mypic']=='4') ? 'selected="selected"' : '' ,'>Dark sunset</option>
						</select>
					</form>';
	}

The !Mobile conditional is just because there's no point in a pretty background on a phone, because you can't see it anyway. So for phones the css just sets a basic white background on body, regardless of which background option is set.
Title: Re: Unify themes and mods behaviour?
Post by: emanuele on December 26, 2012, 06:19:09 pm
Quote from: Antechinus –
Quote from: emanuele – Well, you cannot assume we are writing a forum for your own use. :P
We are writing it for anyone and it should have "a way to work" that works.
Yeah sure. I get that. I'm just saying that people should still have the option to code things how they like, without being locked into one path because somebody thought that was the right way.
Then I'm not sure where the issue is.

In your own forum you can do pretty much whatever you want. We are not arguing about what you do with your own site/code. We are arguing about coding standards for all the people out there that would like to build something on top of elkarte and make it compatible with an indefinite amount of other things.

Anyway, to have an idea of what means have "source" mixed in the template have a look at TinyPortal. Try to modify it. I tried and I can assure you it's not easy at all.
Title: Re: Unify themes and mods behaviour?
Post by: Antechinus on December 26, 2012, 06:43:01 pm
Not sure what you mean with TP. I haven't really looked at the 1.0.x series of TP, but I find the earlier 0.9.8.x series quite easy to modify.
Title: Re: Unify themes and mods behaviour?
Post by: emanuele on December 26, 2012, 06:53:04 pm
No, it's not.
SimplePortal is easy to modify and expand.
Title: Re: Unify themes and mods behaviour?
Post by: Bloc on December 26, 2012, 06:58:59 pm
Uhm, I have to agreed somewhat, TP is quite "compact" and could surely use some cleaning up in templates. The problem is that its layer upon layer of ideas, and some of them did not start as what they ended up as lol. Anyways, its a big mod and changes enough to warrant a fork IMHO. Its part of the reason I stopped working on it, my goals could not be set without making almost a total rewrite, especially on the way different layouts was made for block setups. The trouble was, as always, that SMF do not have support for doing things like blocks and panels that go around the main content. And thats perfectly fine...and explains why portals seem to do complex things just to add them lol. Take PortaMX, at least as complex as TP and a lot more mixing in templates + using the more challenging OOP programming..it even has a total rewrite of frontpage that overrides the normal theme lol, quite a annoyance for anyone making a theme for it. Anyway, Simpleportal adressed things much better so it can be done. I just didn't have the desire to wrestle TP into it. Plus the users would not have anything changed, the changes I did make always meant going back too after some time, for compatibility reasons...

But back to mods/themes, agreed with Antech about how its used..but its also that: many people change little things in themes, just a few does more creative stuff. Should Elkarte support the first or the latter? I suspect the answer is the first, and thats then logical to not add too much freedom in themes. Mods will be complex either way, since users don't change them - mod authors do.

Me, I WANT more freedom in themes. ;D But I have to make it myself lol, that I have long since realized.
Title: Re: Unify themes and mods behaviour?
Post by: Antechinus on December 26, 2012, 07:05:40 pm
Yeah Ema and I may be talking about different things. I've been mainly concerned with changing the presentation/markup/css in the old TP, which isn't really any worse than anything else in SMF. Haven't gotten involved in trying to write new blocks for it, or stuff like that.

I agree that by default the idea should be to support the "no brainer" way of doing things, as far as possible. I'd just prefer to not make more advanced coders jump through hoops if they don't want to. If we can do the former without imposing the latter, that would be great.

And don't tell me that themers don't change mods. I do it all the time. :D
Title: Re: Unify themes and mods behaviour?
Post by: Bloc on December 26, 2012, 09:12:11 pm
Themers yeah...but not the typical admin I would suspect. :)
Title: Re: Unify themes and mods behaviour?
Post by: Antechinus on December 26, 2012, 09:16:47 pm
True. I see the whole thing as very blurry. Take the choice between hover drops and click drops. You can argue that it's a change in presentation, or you can argue that it's a change in functionality. I'd say it's both.
Title: Re: Unify themes and mods behaviour?
Post by: TestMonkey on March 06, 2013, 04:20:25 am
Tracked: https://github.com/elkarte/Elkarte/issues/229

Just as quick note: I'm not sure when we get to more on this, as a priority. At this time it doesn't seem on the radar with a few exceptions? Not on the roadmap atm, afaict.
But this is a good example of one of those discussions for whose status, if you want to participate and keep tabs, will be in the tracker.
Text only | Text with Images