Wedge
Public area => The Pub => Topic started by: colby67 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.
-
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.
-
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!
-
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?
-
Thanks, I'd like that, Nao, if its possible. :)
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).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.
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.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.
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.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 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.
-
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.
-
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.
-
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 ;)
-
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.
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?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.
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.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.
But maybe its better to continue this in another topic, as its abit on the side of the OP's question.
-
Woohoo, another response prefix bug... :)
I split this topic, and it added a 'Re:' tag everywhere, using the French format (Re :), meaning I get a Re: Re : in my last post... Fun.
-
So this is why we need to remove it from subjects and display it *from the template* :lol:
-
(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. :)
-
(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...)
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...
-
(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 only things I changed to 'unseen' code was in AeMe, it's totally unrelated to unread posts.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...
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...)
-
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 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.
-
Here's the thing about threaded mode... by definition you really need a 'reply to this message' button which would cover that, not fudging it through anything else. It's going to get confusing if people press to reply to something and it isn't conjoined on the page (e.g. pressing a button only to have to go back to the bottom to reply)
A popup reply would solve that, even as an overlay of some kind.
This is ultimately why threaded mode causes trouble because of the multitude of UI parts to it.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.
Mods add features, they have to remember to use the right markup - i.e. working to the theme. If you look back through everything we've done, mods are actually more constrained than themes are, by design, to account for this sort of problem. And even we haven't nailed it entirely.So having mods just go right in and change templates are a bad thing, and course themes not rendering mod's output equally bad.
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.
I wouldn't want to write plugins for your setup because they don't give me any freedom in how I design any of it. In your setup, for example, SimpleDesk would have had to use the same layout as given by anything else, which doesn't work because it had its own requirements in terms of content and presentation. This is why the plugin has to have *some* control over what it's doing.
-
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.
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?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.
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.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.
But maybe its better to continue this in another topic, as its abit on the side of the OP's question.
That Elkarte/SMF 2.1 used these functions are more annoying though. But we'll just have to see if its of any consequence to themers when they start making themes. I suspect it won't matter much, which brings me back - what to do when they are going this way - making my own I guess. :D
bloQS is the rewrite and culmination of ViennaBBS and the extra features in my premium themes, which I have moved to Sources instead of forcing templates to do it. ViennaBBS was also a rewrite, but I removed too much from SMF for it..so much I found it hard to focus further on it(plus i created an anticipation of the "next great thing" which was distracting). So bloQS is a fork, yes, with a a few goals: to use boards as different content types so i don't have to use ablog/gallery/etc script/mod.Its not new ideas of course, but I feel its getting where I want it this time. Its only a private project, so forgive me for mentioning it here while not being "public" anywhere yet. :) Theres some random discussion at http://www.bloqs.net but only xarcell was there, really stating his own wishes - not mine lol - and has since started his own fork...(..)
Anyways, this discussion have made me think more over this layer/template problem mentioned and ways to approach this. While it will never be as exhausting as Wedge, at least it gives me something rewarding to work on. :)
-
Here's the thing about threaded mode... by definition you really need a 'reply to this message' button which would cover that, not fudging it through anything else. It's going to get confusing if people press to reply to something and it isn't conjoined on the page (e.g. pressing a button only to have to go back to the bottom to reply)
A popup reply would solve that, even as an overlay of some kind.
This is ultimately why threaded mode causes trouble because of the multitude of UI parts to it.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.
Mods add features, they have to remember to use the right markup - i.e. working to the theme. If you look back through everything we've done, mods are actually more constrained than themes are, by design, to account for this sort of problem. And even we haven't nailed it entirely.So having mods just go right in and change templates are a bad thing, and course themes not rendering mod's output equally bad.
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.
I wouldn't want to write plugins for your setup because they don't give me any freedom in how I design any of it. In your setup, for example, SimpleDesk would have had to use the same layout as given by anything else, which doesn't work because it had its own requirements in terms of content and presentation. This is why the plugin has to have *some* control over what it's doing.
Maybe it isn't possible, but I will try finding that out.
-
So, essentially, what you're saying is, that as a theme designer, you want to not only control the look and feel of the core but have the theme able to control the look and feel of plugins too. Have ever so much fun with that. There are hundreds of mods on the sm.org mod site... you are potentially saying you want a theme to have the option of supporting each of them, individually, in potential... because there aren't so many issues with performance, or reliability or tracing bugs that can happen with that or anything.
Let's take a practical example. Would you, as a theme developer consider manually replacing the output of - say - the most popular shoutbox, most popular portal, and most popular gallery?
You have a core theme and you have a theme changing the look and feel. Are you seriously going to want to support things like the portal, gallery and shoutbox in the theme?
Do you remember the themes that had custom code just for TP support and how many issues that caused? This is no different in any practical respect...
-
The theme controls the output of the core already..all the templates are there to be replaced if you wish, in SMF. Write a theme that replaces all the templates and yes, you essentially rewrite the output. As I mentioned many times, mods have been a obstacle to that, and hooks are a bit better in this..but in a way you don't know what to expect then, just hope that the mod author have some good sense in writing HTML code that will work with your theme - if its the designers wish to change that as well. If not, well theres no issue of course.
I have tried replacing templates for popular mods, and it didn't work for the obvious reasons: keeping up with mod changes, the sheer number of mods to support and sometimes conflicts between mods.I am not denying that, but I also know and love the power of the theme engine in SMF and THATS my focus.
I see wheres this is going lol, you have your experience and views on it, and they will not be what I envision or can fully agreed on. So not taking it the wrong way since that has happened in the past - but I don't think you can ever see it my way. Which is fine, I am only making my thoughts in writing here, they are not ultimate truths. I am not out to change Wedge since I know you have a firm direction for it(thats a good thing of course) and I hope that will be returned. ;)
-
I can see entirely where you're coming from - I always have been able to. The problem is that your envisioning of it does not tie up to the reality of how it works - even you yourself see that it's impossible for a theme to have total control over mods because of keeping up with mod changes.
There is actually *more* power in Wedge's theme engine than in SMF's, vastly more, and it enables plugins to be more flexible by moving blocks of content around, inserting new blocks of content between them. None of that's changed. And plugins have more ability to play nicely with themes now.
I guess what frustrates me about this topic is that we seem to be retreading the same ground every 6 months and nothing has changed in that time, at least not in the practical world.
Your ideas are grand, but unfortunately I don't see how they can possibly stand up to real world use. That's fine if what you're doing is solely for your own use, when you don't have to care about real world users, but we have to.
Go and look at al the platforms out there, every single forum system has the same problems, and the same problems creep into WordPress too... and I hope you're not going to tell me that WordPress is 'less flexible' than SMF because we both know that's not true either. WP gives theme authors the nearest thing to total control and that causes almost as much of a mess for plugins as what SMF does. More, in some respects, because it can be hard to nail down and make sense of it.
I'm sorry, I have to ask this because it's been bugging me: if you understand we have a firm direction (and one that hasn't changed in over a year, I might add), why keep bringing these things up every few months? You don't want to change our minds, you say, and yet by bringing it up again and again, you're trying to. Or at least, I don't understand why you're bringing it up again and again, when you know it's not going to change.
We did take in to account what you were saying; that's how the template skeleton came into being at all. It was the only way we could think of to find any kind of compromise between the two because we believe the two need to work together - and it's the nearest we've got to that point. I'm sorry that you're so unable to understand that we have to have this compromise between the two but that's the curse of working on something that is intended for widespread distribution, not a hobby project.
-
Stubborness? :)
Look, this is getting where I didn't want it to go. The focus here isn't my stuff, but Wedge. If you feel its working great in these areas I've brought up, then fine, I'll check it out.
-
I feel the templlating engine is very good, more flexible than SMF's. In my plugins, I can insert my block virtually anywhere, above or below any known existing block. No complaints there!
Most importantly, I'm not limited to one sub template.
Also, I have to follow the default theme style and markup. Otherwise, if the theme could do its own thing entirely, I couldn't know if my plugin holds up. Equals support issues. I hate those.
To comment on the "stubbornness" apparently being perceived, there is an element of that, certainly. But it works for everyone here giving a crap about. I have more freedom here than with SMF's theme engine, and for that, I'm thankful.