« This describes me somewhat
Wedge templating for designers
Remove flash dependency from AeMe? »
Wedge templating for designers
« on February 2nd, 2013, 12:33 PM »
You do realize by limiting what a theme can do in this way, allowing things to be rendered a certain way regardless of what the theme wants to do(the titles for example, fixed to a common look in all themes), or letting plugins inject HTML that the theme will never know about, you put the burden of making it look nice more on you, the devs(and more fearsome, on the plugin authors, who generally will not live up to the challenge)?

While certainly not bad for you as devs, I cannot see Wedge ever having other than color versions of the offical theme(s) then..and in that respect become even less interesting for themers than SMF itself.

I am not saying abandon the current systen..but at least allow a theme to change the HTML from titles or plugins... I am of course assuming theme variation is a goal in Wedge. If not then its a moot point I guess.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re : Wedge templating for designers
« Reply #1, on February 2nd, 2013, 12:46 PM »
Quote from Bloc on February 2nd, 2013, 12:33 PM
You do realize by limiting what a theme can do in this way, allowing things to be rendered a certain way regardless of what the theme wants to do(the titles for example, fixed to a common look in all themes), or letting plugins inject HTML that the theme will never know about, you put the burden of making it look nice more on you, the devs(and more fearsome, on the plugin authors, who generally will not live up to the challenge)?

While certainly not bad for you as devs, I cannot see Wedge ever having other than color versions of the offical theme(s) then..and in that respect become even less interesting for themers than SMF itself.

I am not saying abandon the current systen..but at least allow a theme to change the HTML from titles or plugins... I am of course assuming theme variation is a goal in Wedge. If not then its a moot point I guess.
I think they're allowing the themes to modify the skeleton itself, hence allowing theme variations. I can be wrong though.
The way it's meant to be

Nao

  • Dadman with a boy
  • Posts: 16,080
Re : Wedge templating for designers
« Reply #2, on February 2nd, 2013, 01:29 PM »
Wedge has themes and skins.
Themes are complete rewrites of the templates, while skins can be simple color variations, but also complete CSS rewrites, AND layout rewrites as well.
90% of all cases a designer would like to try out will be possible with skins.
For the rest, they can use themes.

The problem with themes is that they require frequent updates to be made compatible with Wedge's new releases. Hopefully, skins won't require that. (Of course, maybe in the first year or two, there may be rewrites that break compatibility with skins... Hopefully not when we go public!)

Anyway... Power to the people, and that's both developers and designers :) We provide multiple tools, you just pick your favorite!
And Bloc, don't forget, if you want SVN read access, just ask!
Re : Wedge templating for designers
« Reply #3, on February 2nd, 2013, 03:19 PM »
Thanks, I'd like that, Nao, if its possible. :)

Ok, maybe I don't see the full extent of what a Wedge theme can change...Dragooon, I understood it from this topic at least, that while the skeleton can be changed from a theme(?) the items cannot, like the titles for example. I am assuming that if admin set a certain title style, that will be brought over into another theme. If its not, how do the theme see whats in it, in order to change it? (other than of course examine the source code)

Plugins, again from this topic, seem to be able to inject HTML code through hooks, but how can the theme have any influence on that, other than changing whatever css is used on it? SMF is not perfect by a long shot, but it provides only (in 2.0) hooks for the dataset - not the HTML output. In real life it might not be any difference if the plugin give both HTML and data at the same time..but if you try to make something new and radical(which of course assume someone wants to lol) you hit this limit. Its a limit that elkarte also shares to some degree, in that they opted to add more of the theme stuff into Sources, thereby making it so that themes HAVE to use it - unless they hack up the cooked content or construct it themselves(which i assume was the whole idea of it, to avoid that). Thats one thing I def. do NOT want in bloQS, and something I am bit sad to see happen in Elkarte(though it may be hope yet). I am not so sure about Wedge, but from this discussion it seems on a similar path?

Nao

  • Dadman with a boy
  • Posts: 16,080
Re : Wedge templating for designers
« Reply #4, on February 2nd, 2013, 04:44 PM »
Quote from Bloc on February 2nd, 2013, 03:19 PM
Thanks, I'd like that, Nao, if its possible. :)
You used to have it, you know ;)

Pete? Can you do that please? I don't remember the basics.
In the meantime, I've added you to the Friends and Beta Testers groups, so you should be able to download the older alphas (early November '12).
Quote
Ok, maybe I don't see the full extent of what a Wedge theme can change...Dragooon, I understood it from this topic at least, that while the skeleton can be changed from a theme(?) the items cannot, like the titles for example.
Titles can be changed through macros.
Any title in Wedge is a <we:title> or title2 or head pseudo-tag, which gets translated to a proper piece of HTML at the end of the process. Any plugin (or skin) can override the HTML code for that, and replace it with their own. So, you can do it by CSS (just extend the CSS for a header), or by HTML... (by replacing the macro.) Or, or course, by changing the theme entirely, but it's less fun.
Quote
Plugins, again from this topic, seem to be able to inject HTML code through hooks, but how can the theme have any influence on that, other than changing whatever css is used on it? SMF is not perfect by a long shot, but it provides only (in 2.0) hooks for the dataset - not the HTML output.
You mean it provides hooks in Sources, not Themes, right..?
I don't what's best, to be honest... But I think it's best to add hooks 'as needed', i.e. per request from plugin authors, rather than estimate where they'd want to see a hook, and end up with a hook that never gets used.
Quote
In real life it might not be any difference if the plugin give both HTML and data at the same time..but if you try to make something new and radical(which of course assume someone wants to lol) you hit this limit. Its a limit that elkarte also shares to some degree, in that they opted to add more of the theme stuff into Sources, thereby making it so that themes HAVE to use it - unless they hack up the cooked content or construct it themselves(which i assume was the whole idea of it, to avoid that). Thats one thing I def. do NOT want in bloQS, and something I am bit sad to see happen in Elkarte(though it may be hope yet). I am not so sure about Wedge, but from this discussion it seems on a similar path?
I don't really get what you're trying to explain.

I never considered myself a designer, more of a coder with a preference for visual stuff, and in the 2+ years I worked on Wedge, I had many issues with how to easily change something in the visuals, so I implemented helpers. In the end, there are tons of different ways to do something, and I'm sure you'll like at least one of them... :^^;: That's the idea. Trying to cater to multiple ways of doing it.
Re : Wedge templating for designers
« Reply #5, on February 2nd, 2013, 05:21 PM »Last edited on February 2nd, 2013, 05:30 PM by Bloc
ok. :)

What I meant with Elkarte/SMF 2.1 was that they added specifically two functions that call javascript and css, thereby making a bit impossible to override any mods output of those, since they happen later than the theme's css/javacript.  Just the possibility to use another JavaScript library(like Mootools) is impossible now, since JQuery is already baked into the script. In bloQS I use Mootols, but the call to it is clearly visible in the theme, and all calls to using it is baked into a PHP function call - which again may be overriden to for example be compatible with JQuery.

TBH I haven't checked it too thoroughully in SMF2.1/Elkarte, just noticed those things. And if they go down that road, then i guess more will be limited too.

I guess also that it comes down to my firm belief that themes should be able to decide the visual output from a dataset - not just sending it further unchanged. Its that separation that are a bit blurred in SMF in some places, and now a bit more in Elkarte. Wedge is a different beast lol, and as I remember last time I had SVN acces(I do remember :) ) it had better division into smaller subtemplates, thereby making it easier to change one small thing instead of the whole thing.

So what I do in bloQS isn't particular new in that respect, but I am not shielding anything from themes. I feel its better to leave things as open as possible, if it should have any chance of being the ultimate theme machine - and thereby create interest as a versatile script for designers too. The problem with SMF themes have always been the mods doing things to templates, which made it impossible to change anything but index.template. With hooks it is bit more leeway for the theme, but its still "out there" , in that mods can output anything in those hooks (in the Sources, in Themes only buttons-sets can be expanded upon) . What i am working on is changing the template specific hooks so that mods can only send off the datasets - with a proposed layout/HTML bit. Not there yet, but the idea is that the theme should then be able to decide what HTML or design that output should be. At least make it possible to change for example the order of header tags, use lists instead of tables and so on.

EDIT: one of the obstacles is actually the best of the theme engine, namely the layers. A theme won't know about any layers added by mods unless they check the layer index, and even then cannot know what templates are added..or at least target them without physically having them in their own theme folder. That is also something I'd like to change, but not sure of the best way yet. Why do I want to do that? lets say i build a responsive theme that shuffle a sidebar around to fit everything nicely..it will be pointless if a mod add a layer that adds two sidebars lol. For some years I added TP specific templates in my themes just to cater for that - and that was of course only taking control over TP added layers. I did try some of VBgamers mods too, since they are impossible to theme around, with heavy use of tables and old-school HTML(as in SMF 1.1 code) :P

But maybe its better to continue this in another topic, as its abit on the side of the OP's question.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re : Wedge templating for designers
« Reply #6, on February 2nd, 2013, 06:42 PM »
Honestly something like jquery should be global, not theme specific. Its not a theme preference, its something that affects the entire framework and things become ugly when one starts switching between two different frameworks. jQuery does mainly affect the visual output but if a standard library is default then plugins can freely use them to its full potential.

PS: Typed this from my tablet, would've given a longer answer but this is more or less what I mean.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re : Wedge templating for designers
« Reply #7, on February 2nd, 2013, 06:53 PM »
Done and done.

This subject is one where ultimately we are going to have to disagree on it. Theme flexibility is a wonderful thing, sure, but so are plugins that 'just work'. No plugin of *any* kind can do template edits, I've seen to that, which means there necessarily has to be some compromise to allow plugins to add all kinds of new features.

Templates are not as chunky in Wedge as they are in SMF and they're much more simplistic markup, e.g. as mentioned a template will only use <we:cat>, or <we:title> or similar, whose markup is defined entirely by the theme. By the core and plugins using such markup, themes are free to mess it around pretty much at will. Pretty much everything else is straightforward markup with classes that can modify it.

The reality is that if you allow themes to have total control, you knacker up plugins, and allowing plugins to have total control, themes don't bother having more unusual markup because plugins don't work. Thus we've taken a path that explicitly doesn't give total control to either side but that represents the best compromise we could come up with. It won't be your cup of tea entirely, but that's what I've been saying for the last 18 months ;)
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Re : Wedge templating for designers
« Reply #8, on February 2nd, 2013, 09:00 PM »
Quote from Bloc on February 2nd, 2013, 05:21 PM
What I meant with Elkarte/SMF 2.1 was that they added specifically two functions that call javascript and css, thereby making a bit impossible to override any mods output of those,
I remember seeing loadJavaScriptFile and loadCSSFile functions in their codebase, but couldn't be arsed to find out what they did in comparison to our own add_css_file and add_js_file functions. (Except of course Wedge gets to minify, compress and cache the files automatically, which I don't think Elk or SMF will ever do... And if they plan to, just let me say one thing: get yourselves prepared to spend months on this, fixing bugs and adding new features :P)
Quote
since they happen later than the theme's css/javacript.
Ah, yes, that's too bad... ;)
Quote
Just the possibility to use another JavaScript library(like Mootools) is impossible now, since JQuery is already baked into the script.
I don't think you could remove jQuery from Wedge, but it's not something that could be done anyway, given that everything's using it, saving us tons of kilobytes of code. (As a reminder, SMF's script.js is about 50KB, Wedge's is 24KB, and is cached to under 5KB... Add to this the select box code which I chose to embed in script.js, this adds exactly 2 kilobytes of code.)
MooTools is used by over 10 times less websites than jQuery is. It doesn't mean it's any less good -- it simply means that jQuery managed to get traction faster, and people tend to stick to what's used the most, because it means the community is bigger. It's understandable. jQuery thus has the advantage of offering tons of plugins or snippets that can easily be reused by beginner programmers.
Then again, you can still use MooTools but only if there's a way to ensure Moo doesn't use $. It's silly, but since we unconditionally use $ everywhere, you can't just do add_js("\n\tjQuery.noConflict();"), I'm afraid..!

Also, I don't know anything about bloQS. What is it? A new fork? A ViennaBBS rename? A new product not based on SMF? A theme for SMF?
Quote
I guess also that it comes down to my firm belief that themes should be able to decide the visual output from a dataset - not just sending it further unchanged. Its that separation that are a bit blurred in SMF in some places, and now a bit more in Elkarte. Wedge is a different beast lol, and as I remember last time I had SVN acces(I do remember :) ) it had better division into smaller subtemplates, thereby making it easier to change one small thing instead of the whole thing.
Again, one of Wedge's interests is in having many ways to do something when it comes to templating. So many ways, I tend to forget some. (Heck, I even mentioned <we:head> when Pete correctly referred to it as <we:cat>.)
Its main drawback is that as of now, I have zero documentation written for these methods... You'll have to rely on reading my code, mainly in Subs-Cache, Class-CSS and Subs-Template.
Quote
At least make it possible to change for example the order of header tags, use lists instead of tables and so on.
Just try running Wedge in IE 6 or IE 7. You'll notice that they use tables to show the sidebar. While IE 8 and other browsers use a div :)
Quote
EDIT: one of the obstacles is actually the best of the theme engine, namely the layers. A theme won't know about any layers added by mods unless they check the layer index, and even then cannot know what templates are added..or at least target them without physically having them in their own theme folder.
I don't remember if you can check the 'layer' list in Wedge... Technically it's possible, but I may have prevented it. Hmm, just looked into it. Indeed I'm preventing direct access to the skeleton, but I'm allowing users to retrieve the name of the parent layer of a specified block/layer. And, of course, you can retrieve a particular block/layer and make modifications to it... For instance, move it to another parent or before/after another item, add a layer between its parent and it, or below it, rename the block, add a block/layer before or after it, remove the block entirely, remove the parent layer without removing the block itself, etc... It's nearly endless. And again, only documented in Subs-Template. :^^;:
Quote
That is also something I'd like to change, but not sure of the best way yet. Why do I want to do that? lets say i build a responsive theme that shuffle a sidebar around to fit everything nicely..it will be pointless if a mod add a layer that adds two sidebars lol.
If your code is executed after, you can always check for that I guess... But it'd be simpler to just get in touch with the author and try to do something that doesn't break either ;)
Quote
But maybe its better to continue this in another topic, as its abit on the side of the OP's question.
Done.
Re: Wedge templating for designers
« Reply #9, on February 2nd, 2013, 09:01 PM »
Woohoo, another response prefix bug... :)
I split this topic, and it added a 'Re:' tag everywhere, using the French format (Re&nbsp;:), meaning I get a Re: Re : in my last post... Fun.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Wedge templating for designers
« Reply #10, on February 2nd, 2013, 09:03 PM »
So this is why we need to remove it from subjects and display it *from the template* :lol:

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Wedge templating for designers
« Reply #11, on February 2nd, 2013, 09:06 PM »
(And again, I did a quick edit to my post above, before you replied to it, and it seems to have reset my unseen post count for this topic... Bug? Recent one? I don't remember this ever happening to me before...)

Definitely should remove it...
I'm thinking we should add an icon that looks like ╙ or ⇒ or ╙⇒, just to the left of the post title, and have that icon clickable and point to the message we're replying to -- since Wedge so helpfully stores that information. :)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Wedge templating for designers
« Reply #12, on February 2nd, 2013, 09:10 PM »
Quote
(And again, I did a quick edit to my post above, before you replied to it, and it seems to have reset my unseen post count for this topic... Bug? Recent one? I don't remember this ever happening to me before...)
The act of editing is resetting something for it... not sure what.

Having an icon, sure. Making it clickable? Not so sure. Wedge stores the message we're replying to, but invariably that's the last message in the topic...

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Wedge templating for designers
« Reply #13, on February 2nd, 2013, 09:15 PM »
Quote from Arantor on February 2nd, 2013, 09:10 PM
Quote
(And again, I did a quick edit to my post above, before you replied to it, and it seems to have reset my unseen post count for this topic... Bug? Recent one? I don't remember this ever happening to me before...)
The act of editing is resetting something for it... not sure what.
It happened to me twice this week, and never before...
The only things I changed to 'unseen' code was in AeMe, it's totally unrelated to unread posts.
Quote from Arantor on February 2nd, 2013, 09:10 PM
Having an icon, sure. Making it clickable? Not so sure. Wedge stores the message we're replying to, but invariably that's the last message in the topic...
It depends. I can decide to reply to something a couple of posts above, and delete the quote. If my post doesn't make any sense when thought as a reply to the last post, it's a good thing to have the icon.
Remember, if we end up adding some sort of threaded mode, people don't tend to keep the quote because in this format you tend to keep to very short answers. Those reading the same topic in flat mode will end up being a bit lost. (Although it's also very likely that I'd add a more visible link to the original post, precisely because of that...)
Re: Re : Wedge templating for designers
« Reply #14, on February 2nd, 2013, 10:14 PM »
Quote from Arantor on February 2nd, 2013, 06:53 PM
Done and done.

This subject is one where ultimately we are going to have to disagree on it. Theme flexibility is a wonderful thing, sure, but so are plugins that 'just work'. No plugin of *any* kind can do template edits, I've seen to that, which means there necessarily has to be some compromise to allow plugins to add all kinds of new features.

Templates are not as chunky in Wedge as they are in SMF and they're much more simplistic markup, e.g. as mentioned a template will only use <we:cat>, or <we:title> or similar, whose markup is defined entirely by the theme. By the core and plugins using such markup, themes are free to mess it around pretty much at will. Pretty much everything else is straightforward markup with classes that can modify it.

The reality is that if you allow themes to have total control, you knacker up plugins, and allowing plugins to have total control, themes don't bother having more unusual markup because plugins don't work. Thus we've taken a path that explicitly doesn't give total control to either side but that represents the best compromise we could come up with. It won't be your cup of tea entirely, but that's what I've been saying for the last 18 months ;)
I know lol, you have said it numerous times. Still..I think we are closer to the end goal than you might think. My goal is precisely the same: making mods/plugins work together without limiting each other. My beef with SMF is that mods have always taken precedence, while ideally it should be equal. Mods add features, themes adds design, the two should not interfere..and the theme engine will be the glue between those two. So having mods just go right in and change templates are a bad thing, and course themes not rendering mod's output equally bad.

I can't say much about Wedge's approach in this area, i have to try it a bit(and with a different mindset than for 6-7 months ago i guess, I've calmed considerable down, and lowered my own goals to something than can actually be reached lol) and see I guess.

What I do want though is that plugins also *just work*..but ultimately the theme makes them look great. Binding the HTML+CSS in such a way that the theme cannot reach them is a then a dead end IMO. But I have no definite answers to how to get there..only ideas to try out.
« This describes me somewhat
Remove flash dependency from AeMe? »