Messages - colby67
31
Features / Re: Something I learned from sm.org
« on June 1st, 2013, 11:28 PM »
Prevention might be better than a post-reminder - separate the buttons better so people don't make the mistake.
32
The Pub / Re: Not using version numbers as such
« on May 29th, 2013, 07:51 AM »
If the names are just meant to distinguish versions from each other, the easiest solution would be to just give them whole numbers, rather than 2-3 decimals.
But, of course, custom names are fun as well. :D
But, of course, custom names are fun as well. :D
33
The Pub / Re: Wedge templating for designers
« on February 3rd, 2013, 09:45 AM »
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.
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.
34
The Pub / Re: Wedge templating for designers
« on February 2nd, 2013, 11:59 PM »
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 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. ;)
35
The Pub / Re: Wedge templating for designers
« on February 2nd, 2013, 11:31 PM »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.Isn't possible.Quote My goal is precisely the same: making mods/plugins work together without limiting each other.Not from SMF's point of view. From the user's point of view, perhaps. They just want it all to work and don't have to care about it. It wasn't until 2.0/2.1 that SMF had anything like features that could support this, and even then SMF doesn't have enough to do it properly, not even in 2.1.Quote My beef with SMF is that mods have always taken precedence, while ideally it should be equal.Missing the point.Quote 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.Which is exactly why they have to work together. Not be separate and glued together. They have to make some compromises, no matter how you might wish otherwise. And bear in mind, this isn't theoretical, most of this stuff works already. As shown on this very site - there are multiple plugins here that integrate just fine.Quote 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 you're saying is what you've been saying since this conversation started, that the theme has total control. That's fine, all the time plugins don't want to do anything outlandish or in any way imaginative because then they're screwed because they're bound to what the theme actually lets them do. For it to work in any practical fashion there must be compromise, not total control in one direction or the other.Quote 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.
36
The Pub / Re: Re : Wedge templating for designers
« on February 2nd, 2013, 11:02 PM »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 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,Ah, yes, that's too bad... ;)Quote since they happen later than the theme's css/javacript.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.)Quote 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?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>.)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.
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.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 At least make it possible to change for example the order of header tags, use lists instead of tables and so on.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 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.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 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.Done.Quote 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. :)
37
The Pub / Re: Re : Wedge templating for designers
« on February 2nd, 2013, 10:14 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 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.
38
The Pub / Re : Wedge templating for designers
« on February 2nd, 2013, 05:21 PM »
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.
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.
39
The Pub / Re : Wedge templating for designers
« 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?
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?
40
The Pub / 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.
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.
41
Archived fixes / [wedge site] Re: background image does not show in Firefox
« on January 14th, 2013, 06:28 PM »
Ah, so that was it. :) Thanks Nao.
I really like Pale Moon, while Chrome and Opera also sits here, I always return to it because of the web developer tools with it.
I really like Pale Moon, while Chrome and Opera also sits here, I always return to it because of the web developer tools with it.
42
Plugins / Re: Post Fields
« on January 14th, 2013, 12:31 PM »
I know you outlined this before, but haven't followed recent development in this area, hence the question - I am still not convinced this will appeal to designers..but of course it makes sure everything just works. In the long run, thats what counts.Design is overrated anyway, according to some sources. :D
43
Archived fixes / [wedge site] Re: background image does not show in Firefox
« on January 14th, 2013, 11:54 AM »
It might not be that..but when i looked at the source those 3-4 /// made the source jump a line - indicating it might be interpreted as escaped charachters?
Anyway, adding embedded images in a stylesheet is a no-no for me as a designer lol, its a chore to update and more a programmers solution. Which in itself is fine, but not something I would recommend. Using a sprite for this, or even CSS3 gradient seems more versatile to me.
Anyway, adding embedded images in a stylesheet is a no-no for me as a designer lol, its a chore to update and more a programmers solution. Which in itself is fine, but not something I would recommend. Using a sprite for this, or even CSS3 gradient seems more versatile to me.
44
Plugins / Re: Post Fields
« on January 13th, 2013, 07:26 PM »
Ok, but will a theme be able then to customise it..or will it be stuck with using the default subtemplate? I would assume it has to use default CSS styles too, to keep the same color choices etc.
This is not a criticism as such, just curious on how it works/will work.
This is not a criticism as such, just curious on how it works/will work.
45
The Pub / Re: Microsoft to turn off Windows Messenger on 15 March
« on January 13th, 2013, 03:04 PM »
Mmm...correction: "myskype.info" is an external site to skype.com, so I am using "skype:{profilename}?userinfo", that will open fin in Skype if you are logged in.