Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Nao
3721
Features: Forward thinking / Re: jQuery support
« on February 2nd, 2013, 09:43 PM »
Still annoyed with .prop().
jQuery basically says, "you can keep using .attr, but you'll have to use .prop on a few things."
They never actually explain what the exact difference is.
Another blog says "you should convert EVERYTHING to .prop, it'll always work. Just work .attr if you need the original state of checkboxes and things like that."

I have yet to try the second solution, but it's quite tempting...

From what I could read online, there's an easy way to see the difference between attr and prop: take an anchor link where href="file.html". If you ask for .attr("href"), it'll return "file.html", while .prop("href" returns the entire path (including domain). In fact, .attr() is the equivalent of doing $('something')[0].getAttribute('attr'), while .prop is the equivalent of doing $('something')[0].prop -- now, that makes more sense to me! This is never actually explained in the jQuery documentations...
So, it does mean I should be able to convert .prop('src') and all things like that. But I don't know about, for instance, accessing XML tree attributes... Hopefully .prop() works. If I just need to rename all .attr to .prop, it'll just be easier for me. (And subsequent plugin authors.)
3722
Features / Re: Template edits
« on February 2nd, 2013, 09:39 PM »
Woohoo, I just realized that by saving skeletons in their own files, I can actually get rid of the index template's skeleton now, and just include it in skin/skeleton.xml, and just consider that if a skeleton isn't found in a skin folder, it should use the parent folder's... :)
(Well, I *think* this is how it could and should be done. I haven't looked at the specifics yet. There may be another reason why I did it that way... But I don't think there was.)
(Then again, the index template's skin shows that it can be injected programmatically through wetem::build(). Maybe that's good enough a reason to keep it that way... But I'd probably rather have a 'sample plugin' that does the rewriting and build() calling by itself.)
Quote from Arantor on February 2nd, 2013, 09:16 PM
Hmm, yeah.
If we have everything in skeleton-*.xml, then skin.xml can stay skin.xml. Or be renamed to skin-info.xml (which I like less), to be consistent with plugin-info.xml. What do you prefer?
Quote from Arantor on February 2nd, 2013, 09:16 PM
msg as a suffix works just fine for me for the main post structure,
Could be message, too... There's no actual reason to go for a 'short' name.
Quote from Arantor on February 2nd, 2013, 09:16 PM
with blog for the main blog post and blog-msg for blog replies, as suggested.
Or 'blog-comment'. Would make more sense, semantically...
Quote from Arantor on February 2nd, 2013, 09:16 PM
Thank you :) Mostly it's just about making a UI that doesn't feel put together by developers.
Yup. Going the Wizard route is something that the early SMF devs tried to do (e.g. installer), but they stopped midway I guess. You're continuing their legacy.
Oh, and with my select box code, wizards just feel so cool to use. :lol:
Quote from Arantor on February 2nd, 2013, 09:16 PM
And for the look of Wedge, you do it very well :) I would even go as far as saying that your flair for making it look good has rubbed off on me, I never used to worry about making things look good.
Ah ah. But quite honestly, I'm still unhappy with so many things. I'm relatively happy with Weaving (I only changed the header font recently), I was very unhappy with Wuthering but the many changes I appled to it made it look much better. I don't know what to do about Wine, to me it's more a variation on Weaving that was mostly kept as a reminder that Wedge used to look like this by default. Once Warm and Wuthering become actual children of Weaving, I don't know if I'll include Wine in the default package (unless you want to.)
Finally, Warm is a bit of a bugger to me... I'm always tempted to drop most of its color set and go for something really "web 2.0" or whatever, with very bright and saturated colors... Oh, if you could see my local Warm... I'd never commit it, it's too.... It's just plain too much ;)
3723
The Pub / Re: Wedge templating for designers
« 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...)
3724
Features / Re: Template edits
« on February 2nd, 2013, 09:12 PM »
Quote from Arantor on February 2nd, 2013, 08:48 PM
Keywords works fine :)
If we set filenames to be the entire keyword, we need to rename 'skin.xml' to something more descriptive, like 'options.xml', 'skin-options.xml', 'settings.xml' or even... 'skin-info.xml'. I think?
Quote from Arantor on February 2nd, 2013, 08:48 PM
All the suggested names work fine for me (though I'd choose main over root)
root has the advantage of implying it encapsulates everything (as in 'document root'), while main could be seen as either 'only shows the <div id="main"> section' or 'default skeleton' (which doesn't mean anything...)
Quote from Arantor on February 2nd, 2013, 08:48 PM
skeleton.xml should contain the main one, then skeleton-****.xml for the others.
Works for me. If it's skeleton.xml, then either root or main, it doesn't matter.
Any suggestion for the default post skeleton keyword..? Something that would work for you?
Quote from Arantor on February 2nd, 2013, 08:48 PM
Fun is a relative definition, I personally do not think I would find it fun, but that's sort of how I felt about the ban system and it was more fun than expected when getting down to it.
Thankfully we enjoy our programming differently... And that's for the best: because we focus on what we enjoy the most, we tend to work on two different areas that complement each other, i.e. the front-end and back-end code. I absolutely love that you're 'unofficially' in charge of the admin area (and have done wondrous things to it!), and that I can do my best on trying to make it look good. :)
3725
The Pub / Re: Wedge templating for designers
« 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. :)
3726
The Pub / Re: Wedge templating for designers
« 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.
3727
The Pub / Re: Re : Wedge templating for designers
« 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.
3728
Features / Re: Template edits
« on February 2nd, 2013, 08:39 PM »
Quote from Arantor on February 2nd, 2013, 12:46 AM
Well... I can envisage one scenario where we would want multiple per page: blog layout (one for the blog post, one for replies)
Hmm yeah, that's true... My proposal wasn't very thoroughly considered anyway.

So we'll have to work with keywords...
i.e. main skeleton = 'main'? Or 'root'?
Any other mini-skeleton = code gets to choose the name... We could have 'msg' for generic posts, 'blog' for blog posts, 'blog-msg' for blog comments (with a fallback to msg..?), 'gallery' for a gallery item, etc...
Of course, it also depends on whether we're ready to multiply the number of stand-alone functions in each template... ;) We already did a good share of that in the past, though.

So, skin.xml could have only the main options.
skeleton.xml or root.xml could have the root skeleton
skeleton-msg.xml or msg.xml could have the msg skeleton, etc... (Please submit any filename structure standards you'd see as more 'logical' to users.)
Having them in different files allows a skin to redefine only the way posts are shown. Even more power to the people.

Worst of all, I think it's actually going to be fun implementing this change... :)
3729
Off-topic / Re: Interesting concept
« on February 2nd, 2013, 08:32 PM »
Or simply by clicking to Page 10 in search results? :P
3730
The Pub / Re : Wedge templating for designers
« 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.
3731
The Pub / Re : Wedge templating for designers
« 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!
3732
Features / Re: Template edits
« on February 2nd, 2013, 12:43 AM »
14*15 function calls is a lot.
And it doesn't help much if you want to rewrite just the message icon for instance. Well technically it'll be okay I guess.

How about one skeleton file per source file..? Like, skeleton-Display.xml? Or do we want to be able to have multiple mini skeletons per page?
3733
Features / Re: Pages: [1] 2 3 styling
« on February 2nd, 2013, 12:38 AM »
Pseudo class!

:before
    content: "["
3734
Features / Re: Pages: [1] 2 3 styling
« on February 2nd, 2013, 12:14 AM »
Why not just use the strong tag and just this one?
It can be restyled all the same...
3735
Features / Re: Pages: [1] 2 3 styling
« on February 1st, 2013, 11:52 PM »
Sorry?