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
2656
Archived fixes / Re: Popup event doesn't bubble properly
« on October 9th, 2012, 06:46 PM »
It didn't work for me, it just triggered the event underneath. But that could be another bug in the Chrome beta.
2657
Features / Re: New revs - Public comments
« on October 9th, 2012, 06:15 PM »
Well, it might be primarily for me but it's not even a case of 'I don't know, let me think about it', but simply a 'I have no idea which is the best course of action'. There's simply so much stuff that it relates to, potentially, that I can't tell you which would be best.
What I will say is that I dislike a, either the sidebar should be full height or not at all. I will note that I am personally not averse to using tables to fulfil this, but that's because I don't give two hoots about good design :lol:
As far as 2 goes, that sounds very nice and flexible.
What I will say is that I dislike a, either the sidebar should be full height or not at all. I will note that I am personally not averse to using tables to fulfil this, but that's because I don't give two hoots about good design :lol:
As far as 2 goes, that sounds very nice and flexible.
2658
Archived fixes / Popup event doesn't bubble properly
« on October 9th, 2012, 06:12 PM »
http://wedge.org/pub/plugins/7612/active-members/ is where I noticed it.
I clicked on the (1) to see the likes popup, which appeared over the top of the embedded image. But when I clicked on the Close button of the popup, the event was captured by the embedded image and triggered the expand there - and never propagated the event to the close button.
I clicked on the (1) to see the likes popup, which appeared over the top of the embedded image. But when I clicked on the Close button of the popup, the event was captured by the embedded image and triggered the expand there - and never propagated the event to the close button.
2659
Plugins / Re: Active Members
« on October 9th, 2012, 06:11 PM »
Well, we did, a long time ago, haha.
Also, I noticed a bug which I'll report in a minute.
Also, I noticed a bug which I'll report in a minute.
2660
Plugins / Re: Active Members
« on October 9th, 2012, 05:50 PM »
Funny, when I suggested a variation on this idea (putting it as a link in the message index to a similar sort of popup) you weren't so keen.
The reason for suggesting it that way is performance saving ;)
The reason for suggesting it that way is performance saving ;)
2661
Archived fixes / Re: Large images jut out of post area
« on October 9th, 2012, 05:27 PM »
How about this page? This page, with a browser width of about 1100px and you'll see the problem. Different variation on it, sure, but the same basic problem.
The image is constrained to 650px but that's no use because it's still overflowing out of the container. Were it using max-width: 100%, there wouldn't be a problem - but it's not.
bbc images are fixed to a max width of 650px, regardless of the container's size, Aeva images inserted by media bbc are not constrained at all and display at natural size.
The image is constrained to 650px but that's no use because it's still overflowing out of the container. Were it using max-width: 100%, there wouldn't be a problem - but it's not.
bbc images are fixed to a max width of 650px, regardless of the container's size, Aeva images inserted by media bbc are not constrained at all and display at natural size.
2662
Archived fixes / Re: Large images jut out of post area
« on October 9th, 2012, 04:57 PM »
For regular posted images, the container .bbc_img has a max-width of 650px which doesn't do any good if the container is below that in width (e.g. this page, narrower than 1100px or so, where there's enough room for the sidebar still to be on the side, but not enough to leave the main body of posts with 650px or more.
For gallery images inside posts, img.aext does not supply a max-width at all, neither does its parent a.zoom container tag.
For gallery images inside posts, img.aext does not supply a max-width at all, neither does its parent a.zoom container tag.
2663
Archived fixes / Re: Large images jut out of post area
« on October 9th, 2012, 04:17 PM »
Well, it's there on Weaving since that's what I'm using ;) But I have to shrink the window a bit for it to be visible.
2664
Archived fixes / Re: Large images jut out of post area
« on October 9th, 2012, 04:04 PM »
Eh, it's not specifically Wuthering. Weaving does it as well. And it's still the same as in SMF.
(Also, gallery images can't be fixed as easily as regular images - regular images can be fixed by a max posting size, which isn't set here)
(Also, gallery images can't be fixed as easily as regular images - regular images can be fixed by a max posting size, which isn't set here)
2665
Archived fixes / Re: Large images jut out of post area
« on October 9th, 2012, 03:58 PM »
Hmm, those are gallery images, not normal images.
Same problem is in SMF, though...
Same problem is in SMF, though...
2666
Plugins / Re: Active Members
« on October 9th, 2012, 03:16 PM »
Is that test forum using the database I think it is? :lol:
2667
Features / Re: New revs - Public comments
« on October 8th, 2012, 07:48 PM »I hadn't looked into it before, but your change made me realize that my local install capitalizes month names in French, unlike what should be done. It works here on wedge.org, but not on my local install.
In which case these arrays will be serialized twice, and then unserialized back into a serialized array, which should ensure that you don't even have to fix your code... (You can, of course.)
It correctly uses French & lowercase on names. If I don't, it will actually return dates in capitalized English...?! (Using strftime.)
I'm not exactly sure where this needs fixing...
Refer back to http://wedge.org/pub/bugs/7158/smf-bug-4870-incorrectly-capitalised-month-names/
2668
Features / Re: New revs - Public comments
« on October 8th, 2012, 06:16 PM »
Firstly, serializing a serialized string gives you a doubly serialized string. Yes, no kidding, there was a bug in earlier releases of Project Tools where this was happening. So you have to unserialise it before unserialising it.
Secondly, the point I have been making is that certain things in prepareDBSettingsContext already have arrays, and it serialises them before sending to updateSettings.
If you want to add it, you go add it. I just want nothing to do with the debugging that I know will result. (You'll need to update Topic Solved and possibly other plugins too)
Secondly, the point I have been making is that certain things in prepareDBSettingsContext already have arrays, and it serialises them before sending to updateSettings.
If you want to add it, you go add it. I just want nothing to do with the debugging that I know will result. (You'll need to update Topic Solved and possibly other plugins too)
2669
Features / Re: New revs - Public comments
« on October 8th, 2012, 06:06 PM »I don't understand... Why can't we simply change these variables to use arrays instead, and have them go through the code I suggested?
But more than that, I guarantee it WILL introduce issues because it's not just the loading code that needs to be fixed, all of the saving code also all needs to be fixed. Which means potentially affecting everywhere in the admin panel that uses the generic saving code, because that won't cause bugs or anything.
And if you're writing a plugin that accesses a serialized array in the settings, you don't want to have to unserialize it yourself, because when are you supposed to do that..? As a plugin author I'd expect Wedge to do it for me. (But then again that's just me...)
Do it if you really want but I'm really not keen on it because I'm not convinced it actually saves anything. The problem isn't loading, it's saving. That, and all the fun code related to editing settings in the admin panel, which was crappy enough to write the first time.
2670
Features / Re: New revs - Public comments
« on October 8th, 2012, 05:08 PM »
It doesn't make life any easier, on the contrary it makes plugin code more complicated because unless they're using a simple page (where we can hide the real complexity away from them), they have to do fudge things themselves. There are already examples in SMF and Wedge of doing crap like this (cf the warning settings, post moderation settings) only without being serialised, just comma-separated and that's messy enough.
All it does is keep things marginally smaller in the database, it doesn't make anything easier per se. I'd honestly rather leave it alone because the extra complexity, the extra performance hit for a marginal (at best) saving of space with no improvement in convenience for anyone, and the potential to introduce new bugs unnecessarily puts me off. It is an interesting idea but it's got way more downsides than upsides.
As far as the sidebar, I'm not fussed either way, just whatever is most flexible for theme designers.
All it does is keep things marginally smaller in the database, it doesn't make anything easier per se. I'd honestly rather leave it alone because the extra complexity, the extra performance hit for a marginal (at best) saving of space with no improvement in convenience for anyone, and the potential to introduce new bugs unnecessarily puts me off. It is an interesting idea but it's got way more downsides than upsides.
As far as the sidebar, I'm not fussed either way, just whatever is most flexible for theme designers.