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 - Arantor
1696
Features / Re: Template edits
« on February 2nd, 2013, 10:27 PM »
Quote
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?
I'm not fussed either way. I could rename plugin-info.xml to plugin.xml to be honest ;) I'm not that fussed, skin.xml is fine with me, just as skin-info.xml is.
Quote
Could be message, too... There's no actual reason to go for a 'short' name.
Long names *are* more readable, yes.
Quote
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:
I'm trying :)

Also...
WIZARD NEEDS FOOD BADLY.
Quote
Ah ah. But quite honestly, I'm still unhappy with so many things.
The sign of a true artist, continually evolving, striving to improve it all the time.
1697
The Pub / Re: Wedge templating for designers
« on February 2nd, 2013, 10:23 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.
Quote
My goal is precisely the same: making mods/plugins work together without limiting each other.
Isn't possible.
Quote
My beef with SMF is that mods have always taken precedence, while ideally it should be equal.
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
Mods add features, themes adds design, the two should not interfere..and the theme engine will be the glue between those two.
Missing the point.

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.
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.
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
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.
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.

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.
1698
Features / Re: Pages: [1] 2 3 styling
« on February 2nd, 2013, 10:06 PM »
Quote
There's only Display.php (to indicate "All pages") and the index template (template_page_index) that do this, as far as I know...?
Yup... but how many places is template_page_index used? It's everywhere... the message index can invoke it multiple times (for pagination between pages of topics and for pagination to jump to a given page in a multipage topic), the display can, anywhere that uses the generic list... the list goes on.

(And don't forget it's typically used twice on a page where it is used, top and bottom)
Quote
I quite like the [] myself, but I'm not fussed. I think the main point in [] is that it helps differentiate the current page from other pages when neither the color contrast and font weight (depending on the used font) are enough to spot the difference.
Sure... but remember that back in the day we also had [] for indicating things like the number of unread PMs. Now that we have a bubble look for those, I'm inclined to go for stylistic consistency by dropping the [] from the template-page-index and using something else.

Ultimately, if we move it to CSS rather than hardcoded into the template, that will fix my first objection - because then it's styleable from the theme (even down to the strong, though I'd prefer something more semantic personally in the markup)
1699
Features / Re: Template edits
« on February 2nd, 2013, 09:16 PM »
Quote
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?
Hmm, yeah.
Quote
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?
msg as a suffix works just fine for me for the main post structure, with blog for the main blog post and blog-msg for blog replies, as suggested.
Quote
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.
Thank you :) Mostly it's just about making a UI that doesn't feel put together by developers. There are a lot of things that are put in for the convenience of developers and not users.

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.
1700
The Pub / Re: Wedge templating for designers
« 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...
1701
The Pub / Re: Wedge templating for designers
« 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:
1702
Features / Re: Template edits
« on February 2nd, 2013, 08:48 PM »
Keywords works fine :)

All the suggested names work fine for me (though I'd choose main over root)

skeleton.xml should contain the main one, then skeleton-****.xml for the others.

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.
1703
Off-topic / Re: Interesting concept
« on February 2nd, 2013, 08:42 PM »
Quote from MultiformeIngegno on February 2nd, 2013, 08:25 PM
Uhm nice! But.. isn't this achievable with google search filters too?
No.
Quote from Nao on February 2nd, 2013, 08:32 PM
Or simply by clicking to Page 10 in search results? :P
That exclude the top 100. What about the top 1m?
1704
Off-topic / Interesting concept
« on February 2nd, 2013, 07:28 PM »
http://gb.millionshort.com/

It's a search engine that removes the 'top 100, or top 1k, top 10k, top 100k or top 1m sites' from their result, the idea being to encourage people to find new things that aren't so popular.

Thoughts?
1705
Off-topic / Re: Should I add a cache to this script?
« on February 2nd, 2013, 06:55 PM »
I would definitely be inclined to cache it. Unless you need the data to be absolutely live (and honest I'm not sure you do), cache for probably 10 minutes would be enough and it will limit performance hurts in general.
1706
The Pub / Re : Wedge templating for designers
« 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 ;)
1707
Features / Re: New revs
« on February 2nd, 2013, 05:37 AM »
(1 file, 7KB)

Revision: 1891
Author: arantor
Date: 02 February 2013 04:36:51
Message:
! Ban fixes. It can actually save the correct ban type now, and it should (in theory!!) check the state of bans when you change a ban so people who were hard banned, but should not be (for example) should then become unbanned. Needs infinitely more testing than I've given it thus far. (ManageBans.php)
----
Modified : /trunk/Sources/ManageBans.php
1708
Features / Re: Template edits
« 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)

If you want to just rewrite the icon, actually you'd just change it in the post hook itself, not fart around replacing the template it for it, so we could fuse that into the title or something.

Definitely needs thought.
1709
Features / Re: Pages: [1] 2 3 styling
« on February 2nd, 2013, 12:39 AM »
That's not what I mean, will still have to go edit the source to remove that. Though personally I'd rather not have the [] anyway...
1710
Features / Re: Pages: [1] 2 3 styling
« on February 2nd, 2013, 12:21 AM »
That won't get rid of the [] though...

But yeah, hadn't actually thought of that.