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
7846
Features: Posts & Topics / Re: Like/dislike
« on September 12th, 2011, 11:04 PM »
Doesn't make sense.
7847
Off-topic / Re: Help with background image (html)
« on September 12th, 2011, 11:03 PM »
It's what I'm doing with the gradient background on Wedge.org, if you look at the CSS ;)
7848
Other software / Re: New One
« on September 12th, 2011, 11:01 PM »
Pete, please don't understimate the amount of eye-candy I put into Wedge... It's precisely going to help with the 'wow' effect :P
BTW, earlier today I updated the FAQ about the authors. I cleared up what Pete and I were specializing in (hopefully got the point right for Pete :^^;:), and generally expanded the post.
Quote from mforum on September 12th, 2011, 09:48 PM Yes. At least a couple of weeks...
As for the demo, you already all have the link to it -- those who didn't ask for it probably just aren't too interested ;)Quote Yes.
I could even convert it today, but (1) we'd lose many features, most aren't interesting but we lose the though system, custom profiles, blogs, etc. (2) still the problem with avatars and attachments...
So, honestly, I think we'll share the demo link in a week or two, or whatever, then we'll release a private alpha for a few days, and then to the public.
BTW, earlier today I updated the FAQ about the authors. I cleared up what Pete and I were specializing in (hopefully got the point right for Pete :^^;:), and generally expanded the post.
Posted: September 12th, 2011, 10:58 PM
are you planning to give the project for a ride to beta testers before it goes public ?
As for the demo, you already all have the link to it -- those who didn't ask for it probably just aren't too interested ;)
will you convert this forum to wedge when is stable enough so we can criticise its features ? :P
I could even convert it today, but (1) we'd lose many features, most aren't interesting but we lose the though system, custom profiles, blogs, etc. (2) still the problem with avatars and attachments...
So, honestly, I think we'll share the demo link in a week or two, or whatever, then we'll release a private alpha for a few days, and then to the public.
7849
Features / Re: New revs
« on September 12th, 2011, 10:47 PM »
rev 996
(1 file, 8kb)
+ Added support for 'before' and 'after' in loadBlock(). That one was quick... It's because I just recycled code eheh. loadBlock('block', 'menu', 'after') will add a block called 'block' right after the main menu block. I'm not sure it's great to be able to specify a target block (instead of just a layer), but I'll think about it. (Load.php)
(1 file, 8kb)
+ Added support for 'before' and 'after' in loadBlock(). That one was quick... It's because I just recycled code eheh. loadBlock('block', 'menu', 'after') will add a block called 'block' right after the main menu block. I'm not sure it's great to be able to specify a target block (instead of just a layer), but I'll think about it. (Load.php)
7850
Features / Re: New revs
« on September 12th, 2011, 10:26 PM »
rev 995
(6 files, 15kb)
+ Added proper support for 'replace' in loadBlock(). It's easy enough when a layer only has blocks in it, so the hard part was to keep layers in while deleting the rest. If you want to delete layers as well, just use the new 'erase' parameter instead. It will cancel the rescue mission for layers. (Load.php)
* Updated all loadBlock() calls that provided a boolean parameter, and replaced them with the 'add' param instead. (index.php, Aeva-Gallery.php, Subs-Menu.php)
* Updated documentation on blocks and added a 'left' hint to the Warm and Wine sidebars. (index.template.php, Warm/skin.xml)
* Ensured mods can't replace sidebar elements by mistake. Well, they can still delete the sidebar entirely, but then they know they're doing it wrong. (Load.php)
! Fixed support for multiple hints in skeleton. (Load.php)
(6 files, 15kb)
+ Added proper support for 'replace' in loadBlock(). It's easy enough when a layer only has blocks in it, so the hard part was to keep layers in while deleting the rest. If you want to delete layers as well, just use the new 'erase' parameter instead. It will cancel the rescue mission for layers. (Load.php)
* Updated all loadBlock() calls that provided a boolean parameter, and replaced them with the 'add' param instead. (index.php, Aeva-Gallery.php, Subs-Menu.php)
* Updated documentation on blocks and added a 'left' hint to the Warm and Wine sidebars. (index.template.php, Warm/skin.xml)
* Ensured mods can't replace sidebar elements by mistake. Well, they can still delete the sidebar entirely, but then they know they're doing it wrong. (Load.php)
! Fixed support for multiple hints in skeleton. (Load.php)
7851
Features / Re: Template skeleton!
« on September 12th, 2011, 07:15 PM »Regarding replace vs append, there's one fairly good reason why I'd suggest it should be append: mods.
What I could do: loadBlock will do a replace when called on ':main', and an add when called on anything else. Would that be reasonable, or would it confuse users?
If we end up changing all of Wedge's loadBlock calls to specify 'replace', modders may also be confused, I don't know... I mean, I think most of the loadBlock() calls, even from within mods, will be made on ':main'...
That said, if the core code does 300 vs 20, then it should probably stand and modders will just have to use it the way I've used it thus far :lol:
Ah well.
I can think of reasons why you might.Quote What if they 'simply' want to discard the blocks in the layer and keep the child layers?
Hmm... Yeah, I can already hear you say, "who would do that anyway"
Of course, mods could still potentially modify $context['template_layers'] directly by themselves. It's not like the array is locked once we get out of loadBlock and loadLayer...
Oh my, I realize I'm getting confused by my own implementation. Not by the basics of it, but by whether or not I should allow mixing layers and blocks together, etc... :-/
I don't even remember my original question :lol:
7852
Off-topic / Re: PHP IDE for windows
« on September 12th, 2011, 06:20 PM »
It still looks good. I just gave it a try and my first opinion is positive. Now I'll have to see if it's configurable...
Like, clicking a tab to minimize it.
Like, clicking a tab to minimize it.
7853
Other software / Re: New One
« on September 12th, 2011, 05:56 PM »
Depends on what you're looking at testing, of course... If you test for the PM system, you'll find it hasn't been changed in a while. And that the PM template has been broken for just as many months :P
7854
Other software / Re: New One
« on September 12th, 2011, 04:38 PM »
All of the Consultants have read access to Wedge. They are not forced to actually test it, though... It's just provided as a convenience for them. We don't have any 'proper' testers for now. live627 and a couple others do make sure to test it for last-minute problems!
7855
Off-topic / Re: PHP IDE for windows
« on September 12th, 2011, 04:36 PM »
Looks like it indeed...
The scrollbar, however, looks a little strange! Isn't there a way to have a normal one...?
The scrollbar, however, looks a little strange! Isn't there a way to have a normal one...?
7856
Features / Re: Template skeleton!
« on September 12th, 2011, 03:43 PM »
BTW, last commit has a tiny issue in that it inverts the boolean values for $where, which won't matter since I planned to rewrite that anyway (done.)Quote from Arantor on September 12th, 2011, 03:29 PM Nope... main_wrap has two layers in it. The 'top' layer is empty by default. <top></top> defines an empty layer, while <top /> defines a block.
Maybe I should reconsider the way I'm doing it, though...? Maybe not use pseudo-HTML, but something else? Or use a <layer:mylayer:side,left> and <block:myblock> instead of <layer> and <block />?Quote Because of the main layer, yes it should be :)
loadBlock() is called over 300 times in the entire codebase. loadBlock with a $where parameter (i.e. "don't replace, do something else") is called less than 20 times...
I could limit loadBlock() to the main layer though, and have addBlock() and removeBlock() functions that are for other situations. (But then I'd probably have to change loadLayer(), too... ;))Quote What if they 'simply' want to discard the blocks in the layer and keep the child layers?
Hmm... Yeah, I can already hear you say, "who would do that anyway" ;)Quote But doing that in the main layer will break it. For instance, if you go to the Change Skin page, and disable the replacement of blocks, loadBlock() will add the 'pick' block to the lot, so it will call both 'main' and 'pick', which in turns will generate errors because it'll start to show the Admin Theme area... ;)Quote Yeah, jQuery probably got it right... ;)
Maybe I should reconsider the way I'm doing it, though...? Maybe not use pseudo-HTML, but something else? Or use a <layer:mylayer:side,left> and <block:myblock> instead of <layer> and <block />?
I honestly wouldn't make replace the default;
loadBlock() is called over 300 times in the entire codebase. loadBlock with a $where parameter (i.e. "don't replace, do something else") is called less than 20 times...
I could limit loadBlock() to the main layer though, and have addBlock() and removeBlock() functions that are for other situations. (But then I'd probably have to change loadLayer(), too... ;))
if someone does want to replace the entire contents of a layer, fine, but don't make that the default state of play. (And if they do want to replace, discard the entire contents of that layer and be done with it)
Hmm... Yeah, I can already hear you say, "who would do that anyway" ;)
Instead, I'd suggest append should be the default of the day, if someone adds to a layer, the typical behaviour is going to be to add it to the end of the layer.
If in doubt, think about the typical DOM methods exposed in jQuery as the sorts of operations people do actually want to do: replaceWith, before, after, prepend, append, and wrap.
7857
Features / Re: Template skeleton!
« on September 12th, 2011, 03:20 PM »
Okay, I'll still need opinions on something...
This is from the default skeleton:
Code: [Select]
Alternatively, I've added header_wrap and footer_wrap layers:
Code: [Select]
These layers are unused, but the second version ensures that no single layer holds a combination of layers and blocks. Meaning that a layer can only hold either one or more layers, or one or more blocks.
The code that is currently in SVN allows for layers to have both layers and blocks. The good point is that it gives flexibility to themers. The bad point is that once you start mixing these together, it might lead into unexpected results -- which I can control through code, but I'm wondering whether it's best to leave freedom to themers, or force them to put blocks away from layers. However, the solution of putting everything into layers may not be better actually.
Right now I'm only seeing ONE potential problem with layer/block mixes, and it is when using the default setting for loadBlock, i.e. replace existing blocks in a layer with the new one.
- In the second version, it'll be all good, because all I'll be doing is replace the contents of the parent layer. BUT... If a layer is found within the parent layer though, what do I do? Create a new layer and insert the block in it? What name do I give it?
- In the first version though, if I want to insert a block in <content_wrap>, what do I do? Do I remove all of the existing child layers and child blocks? Do I delete only the child blocks? If yes, should I insert the block in place of the first one (which will be removed), or after the last layer? -- Of course, it's likely that if someone tries to replace blocks in such a non-trivial layer, they made a mistake. However, if I just want to add a block to <content_wrap>, it's easy enough, I don't have to create a dummy layer for it.
What do you think would be best, then...?
This is from the default skeleton:
<wrapper>
<header />
<menu />
<linktree />
<content_wrap>
<sidebar_wrap>
<sidebar:side></sidebar>
</sidebar_wrap>
<offside_wrap>
<main_wrap>
<top:top></top>
<main:main>
<main />
</main>
</main_wrap>
</offside_wrap>
</content_wrap>
<footer />
</wrapper>Alternatively, I've added header_wrap and footer_wrap layers:
<wrapper>
<header_wrap>
<header />
<menu />
<linktree />
</header_wrap>
<content_wrap>
<sidebar_wrap>
<sidebar:side></sidebar>
</sidebar_wrap>
<offside_wrap>
<main_wrap>
<top:top></top>
<main:main>
<main />
</main>
</main_wrap>
</offside_wrap>
</content_wrap>
<footer_wrap>
<footer />
</footer_wrap>
</wrapper>These layers are unused, but the second version ensures that no single layer holds a combination of layers and blocks. Meaning that a layer can only hold either one or more layers, or one or more blocks.
The code that is currently in SVN allows for layers to have both layers and blocks. The good point is that it gives flexibility to themers. The bad point is that once you start mixing these together, it might lead into unexpected results -- which I can control through code, but I'm wondering whether it's best to leave freedom to themers, or force them to put blocks away from layers. However, the solution of putting everything into layers may not be better actually.
Right now I'm only seeing ONE potential problem with layer/block mixes, and it is when using the default setting for loadBlock, i.e. replace existing blocks in a layer with the new one.
- In the second version, it'll be all good, because all I'll be doing is replace the contents of the parent layer. BUT... If a layer is found within the parent layer though, what do I do? Create a new layer and insert the block in it? What name do I give it?
- In the first version though, if I want to insert a block in <content_wrap>, what do I do? Do I remove all of the existing child layers and child blocks? Do I delete only the child blocks? If yes, should I insert the block in place of the first one (which will be removed), or after the last layer? -- Of course, it's likely that if someone tries to replace blocks in such a non-trivial layer, they made a mistake. However, if I just want to add a block to <content_wrap>, it's easy enough, I don't have to create a dummy layer for it.
What do you think would be best, then...?
7858
Features: Posts & Topics / Re: Like/dislike
« on September 12th, 2011, 02:28 PM »
If you write the feature, sure :P
7859
Features: Posts & Topics / Re: Like/dislike
« on September 12th, 2011, 02:02 PM »
There won't be a 'dislike' feature, as far as I'm concerned.
7860
Other software / Re: New One
« on September 12th, 2011, 02:00 PM »
The code I'm responsible for is not broken, AFAIK... :P
I finished most of what I wanted to do, mostly in the 'minor' features. I'd like to go gold with AeMe used in avatars & attachments, as well as support for blogs, topic privacy and threading. These are likely to be my next goals for 1.0. As far as alpha is concerned, the thing is -- we have to release the software in a state that is working correctly, even though we'll be halfway through on some implementations. It's not exactly easy to do.
...Or we could just way for a few extra months to release an alpha. I don't know.
Regardless of what we do --- the first online demo is coming this month. And possibly, we'll upgrade the Wedge.org site to use Wedge as well. Although I think that one depends on the aeme+avatar implementation to be done first.
I finished most of what I wanted to do, mostly in the 'minor' features. I'd like to go gold with AeMe used in avatars & attachments, as well as support for blogs, topic privacy and threading. These are likely to be my next goals for 1.0. As far as alpha is concerned, the thing is -- we have to release the software in a state that is working correctly, even though we'll be halfway through on some implementations. It's not exactly easy to do.
...Or we could just way for a few extra months to release an alpha. I don't know.
Regardless of what we do --- the first online demo is coming this month. And possibly, we'll upgrade the Wedge.org site to use Wedge as well. Although I think that one depends on the aeme+avatar implementation to be done first.