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
6106
The Pub / Re: Logo Madness
« on March 14th, 2012, 06:47 PM »
Bump for opinions on the latest vertical logos!
(I understand your own, Pete, I'm just waiting to see if someone else than us actually cares about all that at this point :P)
(I understand your own, Pete, I'm just waiting to see if someone else than us actually cares about all that at this point :P)
6107
The Pub / Re: Logo Madness
« on March 14th, 2012, 05:25 PM »
But the badges can be changed to accomodate any changes... ;)
That's the whole point. I got bit in the ass in the past by not keeping all of my assets. Now I have them all, sometimes in double, to give you an idea, my logo folder currently has 958 elements... :P
Added a mockup for a monochrome version of the logo (for use in Wine for instance.)
That's the whole point. I got bit in the ass in the past by not keeping all of my assets. Now I have them all, sometimes in double, to give you an idea, my logo folder currently has 958 elements... :P
Added a mockup for a monochrome version of the logo (for use in Wine for instance.)
6108
The Pub / Re: Logo Madness
« on March 14th, 2012, 05:06 PM »simplest76 is what's used for the badges here, yes?
Whatever's being used in the badges currently, go with that.
I tried doing it as a vertical logo, and here's what I came up with. It looks nice enough. Looking a bit like this one --
Is that what you want on the shirts? :P
6109
Features / Re: Image resizing for non-uploads
« on March 14th, 2012, 04:40 PM »
Hmmm... Basically, it would take this to work:
Code: [Select]
The false is for autosize, which is currently not implemented. There's an additional param where you an set the outline type (array('outline' => 'black') for instance), or an expand delay ('expand' in milliseconds).
I think it should work... But please check first :)
global $context;
loadSource('media/Aeva-Subs-Vital');
$context['header'] .= '
<link rel="stylesheet" href="' . add_css_file('zoom') . '" media="screen">' . aeva_initZoom(false);The false is for autosize, which is currently not implemented. There's an additional param where you an set the outline type (array('outline' => 'black') for instance), or an expand delay ('expand' in milliseconds).
I think it should work... But please check first :)
6110
Features / Re: Image resizing for non-uploads
« on March 14th, 2012, 04:12 PM »
That's exactly what AeMe does when it embeds an item -- but it makes me think, we have to do the change in the database, don't we...? Because it's in the img bbcode... The PHP code... Oh my... I hate that :P
6111
Features / Re: New revs
« on March 14th, 2012, 04:10 PM »
rev 1463
(6 files, 3kb)
* Replaced the Help icon with a white logo from our usual 'provider', Yûsuke Kamiyamane (bless you). Better contrast makes the ? sign more readable, and the color palette is closer to what we'd expect from Weaving. Opinions may vary regarding Wine, but we can always reupload an alternative version for it. Cherry on top: filesize is twice smaller... (images/helptopics.gif, admin.css, sections.css)
* French translation and fixes. (Help.french.php, index.french.php, ManageSettings.french.php)
@ Hopefully you'll like the new help icon :)
(6 files, 3kb)
* Replaced the Help icon with a white logo from our usual 'provider', Yûsuke Kamiyamane (bless you). Better contrast makes the ? sign more readable, and the color palette is closer to what we'd expect from Weaving. Opinions may vary regarding Wine, but we can always reupload an alternative version for it. Cherry on top: filesize is twice smaller... (images/helptopics.gif, admin.css, sections.css)
* French translation and fixes. (Help.french.php, index.french.php, ManageSettings.french.php)
@ Hopefully you'll like the new help icon :)
6112
Features / Re: Privacy options
« on March 14th, 2012, 04:03 PM »OK, last point first, that's mostly historical. MySQL until later on didn't have subselects at all, and we even removed the block on subselects in the code. Not only that, but there's also a performance consideration - going back, the belief was fewer queries = better, and if you can't do subselects, the best method is to denormalise the data somewhat and do what was done.
So to me that's an extra reason to just drop these.
As far as membergroups vs contact lists go, yes, they're fundamentally the same thing - lists of users - but membergroups have a lot more to them. There's multiple types of membergroups, they have badges, they have PM limits and permissions and *stuff* attached to them.
They also get the distinction of having three separate elements of the members table (primary group, post count group, other groups)
I have no real objections to making contact lists and membergroups basically the same thing, provided that proper protections are taken to ensure that the two are not permitted to overlap (e.g. you can't edit or view a contact list anywhere you're not supposed to be able to and vice versa)
I'm more interested in determining whether you think that performance-wise, having a separate membership table would be better for membergroups overall (not only for contact lists.)
In fact, that reminds me of something I considered... I considered the possibility of ditching post count groups as they are currently implemented and reimplementing it separately so that they're not physical groups, but instead a separate entity (that has badges etc.) and rearranging permissions so that they're set up based on being granted at different post counts rather than by groups. Needs more thought to explain what I have in mind but it would simplify this setup and move it closer to what you're looking at doing.
6113
Features / Re: Image resizing for non-uploads
« on March 14th, 2012, 03:21 PM »
Used generally = on every page...
If we use it only for resized attachments, then it's not every page. How many topics does Wedge.org have with a selection of screenshots and other items that would require resizing...? Not many.
Considering zoomedia.js is half the size of sbox.js, that would mean adding at least one kilobyte to the script file, for a feature that's not used everywhere, unlike our select boxes...
So, I would recommend against it.
An extra hit for every page that has a resized image is perfectly acceptable, especially considering caching, and the fact that the image itself already represents an extra hit... ;)
If we use it only for resized attachments, then it's not every page. How many topics does Wedge.org have with a selection of screenshots and other items that would require resizing...? Not many.
Considering zoomedia.js is half the size of sbox.js, that would mean adding at least one kilobyte to the script file, for a feature that's not used everywhere, unlike our select boxes...
So, I would recommend against it.
An extra hit for every page that has a resized image is perfectly acceptable, especially considering caching, and the fact that the image itself already represents an extra hit... ;)
6114
Features / Re: Privacy options
« on March 14th, 2012, 03:16 PM »
Yep, but even 1MB sounds quite big when it comes to doing tests like id_group IN (...) and then you start listing the entire 1MB field in it...
My idea is just that contact lists and membergroups are one and the same thing. They're groups of members. One member can be in multiple groups, and a group can hold multiple members, so it's a many-to-many relationship, and I don't really see why SMF's membergroup memberships are never kept anywhere but in the members table.
Look at ManageMembergroups: to retrieve a list of members for a specific group, it does a query on the members table with a find_in_set... Not exactly optimized.
But even if we leave membergroups aside, and add contact lists in a similar fashion to how UltimateProfile did it (i.e. keep the buddy_list field in the members table for find_in_set searches, and add a relational table that holds lists of user IDs relative to a buddy list owner), the problem is exactly the same... Instead of holding membergroup IDs in the buddy_list field, you hold member IDs, and it's quite likely that there will be many more members than there are membergroups (eh), so if you have hundreds of 'buddies', the field will be overflowing before you know it... AFAIK at least.
So, basically:
With contact lists:
- a contact_lists table that holds a list of all existing contact lists (id_contact_list + id_owner)
- a contacts table that holds a list of all members associated with a specific contact list (id_contact_list + id_member + possibly id_owner)
- a buddy_list field in the members table that holds a list of all members who are in your own contact lists
- possibly replaced with 'simply' a comma-separated list of your contact lists. In which case, a JOIN will be needed to get the member list. Making the comma list a bit useless.
With membergroups:
- the existing membergroups table, with a new field (id_owner) indicating who created it, and maybe add a new type (contacts) or something.
- possibly a memberships table (similar to the contacts table), with id_member, and id_membergroup relationship, and maybe a 'hidden' flag (i.e. whether or not this membership should be disclosed), things like that, and an id_owner to avoid having to join the membergroups table if you want to retrieve a list of someone's friends.
- the existing members table, with a comma-separated list of membergroups that you BELONG to. If you need to obtain the list of your friends, you would do a JOIN on the memberships table, as mentioned above.
I think we already discussed the fact that find_in_set isn't very efficient and that maybe we should move membergroups to outside the members field... If we move it entirely out, then the field size is no longer an issue. Otherwise, it still is, but not for some time at least.
Meh...
My idea is just that contact lists and membergroups are one and the same thing. They're groups of members. One member can be in multiple groups, and a group can hold multiple members, so it's a many-to-many relationship, and I don't really see why SMF's membergroup memberships are never kept anywhere but in the members table.
Look at ManageMembergroups: to retrieve a list of members for a specific group, it does a query on the members table with a find_in_set... Not exactly optimized.
But even if we leave membergroups aside, and add contact lists in a similar fashion to how UltimateProfile did it (i.e. keep the buddy_list field in the members table for find_in_set searches, and add a relational table that holds lists of user IDs relative to a buddy list owner), the problem is exactly the same... Instead of holding membergroup IDs in the buddy_list field, you hold member IDs, and it's quite likely that there will be many more members than there are membergroups (eh), so if you have hundreds of 'buddies', the field will be overflowing before you know it... AFAIK at least.
So, basically:
With contact lists:
- a contact_lists table that holds a list of all existing contact lists (id_contact_list + id_owner)
- a contacts table that holds a list of all members associated with a specific contact list (id_contact_list + id_member + possibly id_owner)
- a buddy_list field in the members table that holds a list of all members who are in your own contact lists
- possibly replaced with 'simply' a comma-separated list of your contact lists. In which case, a JOIN will be needed to get the member list. Making the comma list a bit useless.
With membergroups:
- the existing membergroups table, with a new field (id_owner) indicating who created it, and maybe add a new type (contacts) or something.
- possibly a memberships table (similar to the contacts table), with id_member, and id_membergroup relationship, and maybe a 'hidden' flag (i.e. whether or not this membership should be disclosed), things like that, and an id_owner to avoid having to join the membergroups table if you want to retrieve a list of someone's friends.
- the existing members table, with a comma-separated list of membergroups that you BELONG to. If you need to obtain the list of your friends, you would do a JOIN on the memberships table, as mentioned above.
I think we already discussed the fact that find_in_set isn't very efficient and that maybe we should move membergroups to outside the members field... If we move it entirely out, then the field size is no longer an issue. Otherwise, it still is, but not for some time at least.
Meh...
6115
Features / Re: Privacy options
« on March 14th, 2012, 02:55 PM »
Except if we increase the text field size..?
6116
Features / Re: Privacy options
« on March 14th, 2012, 02:53 PM »
Well... Friend list?
Member groups would get extra fields. I'm sure it'll be all right.
My main concern is that if you have thousands of friends, your membergroup field will overflow in the member table...
Member groups would get extra fields. I'm sure it'll be all right.
My main concern is that if you have thousands of friends, your membergroup field will overflow in the member table...
6117
Features / Re: Privacy options
« on March 14th, 2012, 02:39 PM »
Admin = can control ownerless groups
User = can only control own groups
No?
User = can only control own groups
No?
6118
Off-topic / Re: How to piss Arantor off, part 2: take the view that he's a negative person
« on March 14th, 2012, 12:04 PM »
When I was 13 or 14, I was totally in love with her... Until I watched Beetlejuice and fell forever for Winona. I was mad at Johnny for dating her... :lol: And then he started dating Vanessa. By that time I was over my childhood crushes, so I thought, okay at least this guy is not only a fantastic actor, he also has good taste in women. :P
6119
Off-topic / Re: How to piss Arantor off, part 2: take the view that he's a negative person
« on March 14th, 2012, 11:46 AM »
Or Johnny Depp and Vanessa Paradis.
6120
Off-topic / Re: How to piss Arantor off, part 2: take the view that he's a negative person
« on March 14th, 2012, 11:26 AM »I dont know why she just didnt abandon religion and drop straight to her knees there and then.
Someone should tell her that her doctor was a Mormon, and only Mormons go to Heaven...
So your wife's birth name is Sweetpea? :P