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
3646
Off-topic / Opera goes WebKit, RIP Presto
« on February 13th, 2013, 03:27 PM »
http://my.opera.com/ODIN/blog/300-million-users-and-move-to-webkit
Farewell Presto, you served us well...
I've been an Opera fan since around 2005. At that time, other browsers really sucked for power users. I discovered tabs in Opera, then the low-memory footprint, and decided to call it quits with Maxthon or whatever default browser I was using at the time.
My best memories of Opera are of the 9.xx line, especially 9.2x which was heavily customized for my needs. It was just THE perfect browser: fast, full-featured and extremely stable. I had at some point over 800 tabs on my 2GB machine. It was unthinkable of. All of these tabs were loaded in memory, i.e. when I switched to them, they showed up instantly.
When I made the switch to 10.x, I was really worried with the many changes they'd done that made it slower and gave less acceptable web site layouts. I switched back to 9.64 or something, and stayed with it for many more months.
Then they went for 10.50 which was an improvement, so I started using it. Version 11, which came out in 2011, was better in every respect. They added stackable tabs, which was something I'd been wanting for a long time. Unfortunately, that feature was buggy, and everytime I quit Opera, I would fear that launching it would present me with a flat list of tabs. They eventually fixed that bug, but not before v12 I think.
Still, these were some good days too. I really liked version 11.
And then Opera 12 came out... And was an awful nest of bugs. I'd never seen that. They'd introduced internally 4 major things:
1- tabs loaded in separate process, so that one tab crashing wouldn't crash the others,
2- Flash ran in its own independent process. Same as above.
3- A 64-bit version, allowing for Opera to use more than 3.5GB of Ram.
4- hardware acceleration, not very noticeable except for one thing: fonts were now rendered using Direct2D, i.e. veeeery smooth job.
So... I had to make the switch. As it turned out,
(1) was useless because Opera had become FAR more prone to random crashes, even with less than 100 tabs. This is something that's crucial to me, and eventually drove me away from it. It was always crash-prone since version 10, but v11 was an improvement on that. v12 was a step down. In the real world, (1) never showed its strength to me, because when tabs crashed, they'd probably crash everything.
(2) actually worked, but it turned out that my Opera crashes were only partly due to Flash misbehaving. So, again, a step down...
(3) was horrible. Because of my tendency to use hundreds of tabs, Opera 64 would use absolutely all of my RAM. It usually isn't a problem, because when you launch another program, it'll just reallocate the extra RAM to it. But in the real world, this never happened, or not fast enough. I had a countless number of "Not enough memory, you should close Opera.exe" error messages showing up during my sleep (I mostly keep my PC on 24/24), and sometimes with some major crashes when I'd turn my screen back on. Yay... So, eventually I reluctantly came back to Opera 32, and guess what...? Much better. Still, Opera would usually crash within a few hours of launching it, and that's with ~100 tabs on. I never dared try with more tabs... It just wasn't there any longer. My Opera fanatism had reached an end.
I think I made the switch to Firefox around last summer, but found it to be so incredibly slow. I loved it when they implemented lazy loading tabs, though. i.e. Firefox no longer tries to load all tabs at startup, it will only load a tab when you activate it. Which effectively makes it currently the best browser for power users with 500+ tabs.
Then I started using Chrome more and more. I always hated its "no geeky stuff" approach, more especially the fact that it removed the vertical tabs feature, which was THE very best Chrome feature. Actually, after trying it out in Chrome (and Firefox's Tree Tabs add-on), I discovered that Opera allowed me to do the same (it has a side tab, and there's a Window feature in it that must be added manually, but then you get a tree-style list that works really well.)
So, what made me switch to Chrome then...?
One word: Sidewise.
It's a plugin that opens a new window on the left side, and attempts to emulate what vertical tabs did. But the developer is hard at work on it, and added many sensible features. For one, you can stack tabs in a tree style. Secondly, you can 'hibernate' a tab, just like in Firefox (using an add-on). Thirdly, and that's for the best -- when Chrome crashes (which it ALSO does on a daily basis, sometimes more), the tab list never gets lost, and it usually reopens my many tabs in hibernating mode, meaning I have the benefits of a fast browser (not many tabs) while still having my tabs available if I choose so. I can also, similarly to Opera (but not Firefox!) search my tabs quickly by entering part of the tab name or URL in an input box at the top. For instance, if I want to clean up all of my local install test tabs, I can just type 'unwedge' in the input text, and then middle-click on all of the tabs that get filtered. It just WORKS.
So... Opera is dropping Presto (only keeping it, from what I understand, for Opera Mini, where pages are generated on their local servers and then dispatched to requesters), and using WebKit.
What does it mean for us? Well, Wedge compatibility will be made easier. I'm a bit sad because I was also very proud about our compatibility with Opera -- I did 90% of my overall testing on it, after all... But it'll be good not to have to focus on so many engines.
Myself, I may very well come back to Opera. If the Sidewide plugin works on it (as it should), then I'll definitely give the new Opera a try. And if it doesn't work, I'll come back to test it on every new version. Because Opera deserves it. It deserves having advocates. Even though version 12 was a failure, it still doesn't mean they should be forgotten for what they did for so many years.
You may ask, why use WebKit and not Gecko..? After all, Opera has always been friends with the Mozilla foundation, and they served as moral support on their fight against the H264 format. But that war was lost last year, and worst of all -- Firefox started losing market shares. Opera knows what it means. It lost market shares to Chrome, too. I think it's simply a matter of Opera finally being realistic (in their decision to dump Presto for another rendering engine), and thus, if they want to be realistic all the way, the only engine they can rely on is WebKit, not Gecko. Because it's no longer about making your point and winning a way; it's about focusing on what they're really best at: user experience and new innovative features. WebKit is now the leader in rendering innovation. Opera will help them stay on that road.
I think it's a good decision that they made. Opera indeed had a superior engine (Presto's HTML, Vega's layout and Carakan's JS), but I don't know of many people who used it for *that*. They used Opera because it was the best user experience they could have -- everything could be modified in the interface. And that's what I mostly miss with Firefox and Chrome. Using plugins for everything isn't always practical. Opera had it all. Now it has even more. I can't wait to try it...
Farewell Presto, you served us well...
I've been an Opera fan since around 2005. At that time, other browsers really sucked for power users. I discovered tabs in Opera, then the low-memory footprint, and decided to call it quits with Maxthon or whatever default browser I was using at the time.
My best memories of Opera are of the 9.xx line, especially 9.2x which was heavily customized for my needs. It was just THE perfect browser: fast, full-featured and extremely stable. I had at some point over 800 tabs on my 2GB machine. It was unthinkable of. All of these tabs were loaded in memory, i.e. when I switched to them, they showed up instantly.
When I made the switch to 10.x, I was really worried with the many changes they'd done that made it slower and gave less acceptable web site layouts. I switched back to 9.64 or something, and stayed with it for many more months.
Then they went for 10.50 which was an improvement, so I started using it. Version 11, which came out in 2011, was better in every respect. They added stackable tabs, which was something I'd been wanting for a long time. Unfortunately, that feature was buggy, and everytime I quit Opera, I would fear that launching it would present me with a flat list of tabs. They eventually fixed that bug, but not before v12 I think.
Still, these were some good days too. I really liked version 11.
And then Opera 12 came out... And was an awful nest of bugs. I'd never seen that. They'd introduced internally 4 major things:
1- tabs loaded in separate process, so that one tab crashing wouldn't crash the others,
2- Flash ran in its own independent process. Same as above.
3- A 64-bit version, allowing for Opera to use more than 3.5GB of Ram.
4- hardware acceleration, not very noticeable except for one thing: fonts were now rendered using Direct2D, i.e. veeeery smooth job.
So... I had to make the switch. As it turned out,
(1) was useless because Opera had become FAR more prone to random crashes, even with less than 100 tabs. This is something that's crucial to me, and eventually drove me away from it. It was always crash-prone since version 10, but v11 was an improvement on that. v12 was a step down. In the real world, (1) never showed its strength to me, because when tabs crashed, they'd probably crash everything.
(2) actually worked, but it turned out that my Opera crashes were only partly due to Flash misbehaving. So, again, a step down...
(3) was horrible. Because of my tendency to use hundreds of tabs, Opera 64 would use absolutely all of my RAM. It usually isn't a problem, because when you launch another program, it'll just reallocate the extra RAM to it. But in the real world, this never happened, or not fast enough. I had a countless number of "Not enough memory, you should close Opera.exe" error messages showing up during my sleep (I mostly keep my PC on 24/24), and sometimes with some major crashes when I'd turn my screen back on. Yay... So, eventually I reluctantly came back to Opera 32, and guess what...? Much better. Still, Opera would usually crash within a few hours of launching it, and that's with ~100 tabs on. I never dared try with more tabs... It just wasn't there any longer. My Opera fanatism had reached an end.
I think I made the switch to Firefox around last summer, but found it to be so incredibly slow. I loved it when they implemented lazy loading tabs, though. i.e. Firefox no longer tries to load all tabs at startup, it will only load a tab when you activate it. Which effectively makes it currently the best browser for power users with 500+ tabs.
Then I started using Chrome more and more. I always hated its "no geeky stuff" approach, more especially the fact that it removed the vertical tabs feature, which was THE very best Chrome feature. Actually, after trying it out in Chrome (and Firefox's Tree Tabs add-on), I discovered that Opera allowed me to do the same (it has a side tab, and there's a Window feature in it that must be added manually, but then you get a tree-style list that works really well.)
So, what made me switch to Chrome then...?
One word: Sidewise.
It's a plugin that opens a new window on the left side, and attempts to emulate what vertical tabs did. But the developer is hard at work on it, and added many sensible features. For one, you can stack tabs in a tree style. Secondly, you can 'hibernate' a tab, just like in Firefox (using an add-on). Thirdly, and that's for the best -- when Chrome crashes (which it ALSO does on a daily basis, sometimes more), the tab list never gets lost, and it usually reopens my many tabs in hibernating mode, meaning I have the benefits of a fast browser (not many tabs) while still having my tabs available if I choose so. I can also, similarly to Opera (but not Firefox!) search my tabs quickly by entering part of the tab name or URL in an input box at the top. For instance, if I want to clean up all of my local install test tabs, I can just type 'unwedge' in the input text, and then middle-click on all of the tabs that get filtered. It just WORKS.
So... Opera is dropping Presto (only keeping it, from what I understand, for Opera Mini, where pages are generated on their local servers and then dispatched to requesters), and using WebKit.
What does it mean for us? Well, Wedge compatibility will be made easier. I'm a bit sad because I was also very proud about our compatibility with Opera -- I did 90% of my overall testing on it, after all... But it'll be good not to have to focus on so many engines.
Myself, I may very well come back to Opera. If the Sidewide plugin works on it (as it should), then I'll definitely give the new Opera a try. And if it doesn't work, I'll come back to test it on every new version. Because Opera deserves it. It deserves having advocates. Even though version 12 was a failure, it still doesn't mean they should be forgotten for what they did for so many years.
You may ask, why use WebKit and not Gecko..? After all, Opera has always been friends with the Mozilla foundation, and they served as moral support on their fight against the H264 format. But that war was lost last year, and worst of all -- Firefox started losing market shares. Opera knows what it means. It lost market shares to Chrome, too. I think it's simply a matter of Opera finally being realistic (in their decision to dump Presto for another rendering engine), and thus, if they want to be realistic all the way, the only engine they can rely on is WebKit, not Gecko. Because it's no longer about making your point and winning a way; it's about focusing on what they're really best at: user experience and new innovative features. WebKit is now the leader in rendering innovation. Opera will help them stay on that road.
I think it's a good decision that they made. Opera indeed had a superior engine (Presto's HTML, Vega's layout and Carakan's JS), but I don't know of many people who used it for *that*. They used Opera because it was the best user experience they could have -- everything could be modified in the interface. And that's what I mostly miss with Firefox and Chrome. Using plugins for everything isn't always practical. Opera had it all. Now it has even more. I can't wait to try it...
3647
Off-topic / Re: Something Nao might enjoy (and others, but Nao especially)
« on February 13th, 2013, 01:46 PM »
I would rather enjoy it.......... if it was actually made of proper words, rather than gibberish thrown in to test your knowledge of regex. Ahum... :^^;:...
3648
Bug reports / Re: Quick editing own posts marks topics unread..?
« on February 13th, 2013, 01:44 PM »
Up early? :PQuote from Arantor on February 13th, 2013, 12:42 PM Is it really finished...? :)
Hmm, just reminds me I forgot to update the French language files for that... Ah well.Quote Personally? I want a quick edit to be visible all right, like it's doing right now... Seems perfectly fine, i.e. if you read a post then come back to the homepage, and the author modified said post, you should be made aware of it.
...........EXCEPT if I'm the one who did the quick edit!
I didn't look into it, I faced down my nemesis: the plugin insanity.
Hmm, just reminds me I forgot to update the French language files for that... Ah well.
There's definitely undesirable behaviour going on. Best question: what do we want it to do, in detail?
...........EXCEPT if I'm the one who did the quick edit!
3649
Features / Re: New revs
« on February 13th, 2013, 01:41 PM »
rev 1923
(48 files, 13kb) (what is it with me and 13kb commits these days..? 2 in a row, 3 in 2 pages?)
* A huge load of crap. Or, in other words, inner works of the Naoist monk. Removing some unneeded spaces that hurt my eyes, or turned all //!! into // !! (our 'regular' way of doing a to-do or I'm-not-sure-about-that-piece-of-code), and //old-code into // !! old-code ?? (because I can, and because at least that's findable through regex.) (48 files, not even going to bother listing them all.)
(48 files, 13kb) (what is it with me and 13kb commits these days..? 2 in a row, 3 in 2 pages?)
* A huge load of crap. Or, in other words, inner works of the Naoist monk. Removing some unneeded spaces that hurt my eyes, or turned all //!! into // !! (our 'regular' way of doing a to-do or I'm-not-sure-about-that-piece-of-code), and //old-code into // !! old-code ?? (because I can, and because at least that's findable through regex.) (48 files, not even going to bother listing them all.)
3650
Features / Re: New revs
« on February 13th, 2013, 12:56 PM »
rev 1922 -- the index language files are my sacred sanctuaries.
(21 files, 13kb)
! If ever calling ask() or say() from within a callback function for another ask() or say() call, Wedge would simply ignore the new one. Costs a couple of extra bytes. Gotta do what you gotta do... (script.js)
* More heavy stuff lifted out of the index language file. This is 1.5KB of data (and 44 array entries) you won't have to load uselessly on every page. Many of these strings are removed because they were either leftovers from pre-SMF2 days (e-mail stuff for instance, it was all moved to EmailTemplates long ago and there were remainders in the Post files), or leftovers from early Wedge days. The rest was mostly moved to the Post language files, because they were mostly used in Post situations. There may be many more entries that can be moved to something else, but... I'm tired all right? And I did all of the 'big' ones I think. (Display.php, Memberlist.php, MessageIndex.php, PersonalMessage.php, Profile-Modify.php, Mailer.template.php, LANGUAGES: Admin, index, Login, ManageMembers, Post, Stats)
- Naoism: removed smiley descriptions out of the smiley cache. My smiley system doesn't allow for descriptions because, frankly, they take bandwidth for nothing (who reads them?), and apparently I forgot to remove them out of the cache. (Subs-BBC.php)
- Naoism: duplicate 'search_for' string. (Admin.language.php)
* Naoism: duplicated 'view_all_members' to both Admin and ManageMembers. Seriously, I'm not going to load a 10KB file just for a single use on all admin pages, or a 40KB file for a single use on Memberlist pages. I'm also not going to keep it in the index language because, well... nah. (Admin.language.php, ManageMembers.language.php, index.language.php)
@ Naoism: the Class-Editor file has no description for most of the popup smileys. Should we add them..? In the meantime, at least I cleaned them up. (Class-Editor.php)
(21 files, 13kb)
! If ever calling ask() or say() from within a callback function for another ask() or say() call, Wedge would simply ignore the new one. Costs a couple of extra bytes. Gotta do what you gotta do... (script.js)
* More heavy stuff lifted out of the index language file. This is 1.5KB of data (and 44 array entries) you won't have to load uselessly on every page. Many of these strings are removed because they were either leftovers from pre-SMF2 days (e-mail stuff for instance, it was all moved to EmailTemplates long ago and there were remainders in the Post files), or leftovers from early Wedge days. The rest was mostly moved to the Post language files, because they were mostly used in Post situations. There may be many more entries that can be moved to something else, but... I'm tired all right? And I did all of the 'big' ones I think. (Display.php, Memberlist.php, MessageIndex.php, PersonalMessage.php, Profile-Modify.php, Mailer.template.php, LANGUAGES: Admin, index, Login, ManageMembers, Post, Stats)
- Naoism: removed smiley descriptions out of the smiley cache. My smiley system doesn't allow for descriptions because, frankly, they take bandwidth for nothing (who reads them?), and apparently I forgot to remove them out of the cache. (Subs-BBC.php)
- Naoism: duplicate 'search_for' string. (Admin.language.php)
* Naoism: duplicated 'view_all_members' to both Admin and ManageMembers. Seriously, I'm not going to load a 10KB file just for a single use on all admin pages, or a 40KB file for a single use on Memberlist pages. I'm also not going to keep it in the index language because, well... nah. (Admin.language.php, ManageMembers.language.php, index.language.php)
@ Naoism: the Class-Editor file has no description for most of the popup smileys. Should we add them..? In the meantime, at least I cleaned them up. (Class-Editor.php)
3651
Bug reports / Re: Quick editing own posts marks topics unread..?
« on February 13th, 2013, 12:33 PM »
Here's the FUNNIEST thing.
Really.
I did a quick edit on my local install... And it didn't mark the topic as read.
Point made!
So, what do you think Pete..? Did you look into it, or not..?
Really.
I did a quick edit on my local install... And it didn't mark the topic as read.
Point made!
Posted: February 12th, 2013, 11:23 AM
So, what do you think Pete..? Did you look into it, or not..?
3652
Features / Re: New revs
« on February 12th, 2013, 07:03 PM »
rev 1917 -- more JS fixes... including an 'amusing' one.
(12 files, 9kb)
! Fixed another bug in the ask() code -- Invisible groups option in Manage Membergroups and de-admin option in Profiles were broken. Let's get technical: we shouldn't call !ask() (emphasis on '!') without ensuring that it isn't being used to actually cancel something, instead we should use its callback feature in these situations. Also, checkbox magic means that some !ask calls can stay in, such as the one in mediadmin. Just sayin'. (ManageMembergroups.template.php, Profile.template.php)
! In-topic moderation was also impacted by the bug above. However, it had 3 more bugs (in such a short function, must be a new record!) that needed fixing: it generated the wrong action URL when pretty URLs were enabled, it tested for '.modrem' against the wrong element, and it took message IDs from the wrong element too. Instead, it needed my now infamous .closest('.root') trick. I still love that one, it saves us so many bytes... Well, in this case the topic JS file is now 28 bytes larger... Most of which is due to the PURL fix. I hate the recycle bin. When do we remove that thing?! (topic.js)
+ Another minor thing, but long coming: added a shortcut to the default skin/theme selection page in the admin page introduction. This is something that even I sometimes had trouble finding, so... Also made some words stand out in the intro text, to ensure you can see what you want at a glance. (Admin.php, Admin.template.php, Admin.language.php)
* Moved total_* stat strings to the Stats language file... Is this never gonna end? ;) (SSI.php, index.language.php, Stats.language.php)
! Harmonized background colors in membergroup manager, and fixed the Add new membergroup page, which didn't get the extra styling of the rewritten board permission form. (ManageMembergroups.template.php, mana.css)
(12 files, 9kb)
! Fixed another bug in the ask() code -- Invisible groups option in Manage Membergroups and de-admin option in Profiles were broken. Let's get technical: we shouldn't call !ask() (emphasis on '!') without ensuring that it isn't being used to actually cancel something, instead we should use its callback feature in these situations. Also, checkbox magic means that some !ask calls can stay in, such as the one in mediadmin. Just sayin'. (ManageMembergroups.template.php, Profile.template.php)
! In-topic moderation was also impacted by the bug above. However, it had 3 more bugs (in such a short function, must be a new record!) that needed fixing: it generated the wrong action URL when pretty URLs were enabled, it tested for '.modrem' against the wrong element, and it took message IDs from the wrong element too. Instead, it needed my now infamous .closest('.root') trick. I still love that one, it saves us so many bytes... Well, in this case the topic JS file is now 28 bytes larger... Most of which is due to the PURL fix. I hate the recycle bin. When do we remove that thing?! (topic.js)
+ Another minor thing, but long coming: added a shortcut to the default skin/theme selection page in the admin page introduction. This is something that even I sometimes had trouble finding, so... Also made some words stand out in the intro text, to ensure you can see what you want at a glance. (Admin.php, Admin.template.php, Admin.language.php)
* Moved total_* stat strings to the Stats language file... Is this never gonna end? ;) (SSI.php, index.language.php, Stats.language.php)
! Harmonized background colors in membergroup manager, and fixed the Add new membergroup page, which didn't get the extra styling of the rewritten board permission form. (ManageMembergroups.template.php, mana.css)
3653
Archived fixes / Re: sb refresh does not update scrollbar
« on February 12th, 2013, 11:52 AM »
There is definitely a problem with the reloadSB function.
What it does is: delete the current SB, remove its DOM elements, then repopulate it from the original, then re-create it, then open it if it was opened before, or focus if it was focused before.
It executes so fast that you never get to see the DOM be modified, and open/focus states are correctly restored. It's just the closeAndUnbind function that never properly sets the event (even though it DOES get executed at this point...)
I'm currently reviewing all .sb calls, and it seems that it's never called when in the middle of an opened SB, which totally makes sense, so indeed it might be best not to reopen the SB after re-creating it.
While doing this review, I also discovered a horrible bug in Wedge... I did, in a few occasions, launch a !ask() request in DOM events. Which is TOTALLY what should be done. Unfortunately, the nature of alert/confirm events is that they stall the execution process until we return, then we get a boolean parameter we can give back to the event. Okay. But say/ask are functions that don't stop any execution, and for that reason I had to had a callback system to allow for use in DOM events. It works very well, but it seems like I forgot to convert a few calls... And because ask() will immediately return false in a DOM event, if you take action after an !ask (rather than an ask), it will be executed.
To make it short (my explanation really sucks): Wedge could no longer un-admin anyone, or make a membergroup invisible, because it would always request confirmation and immediately return to cancelling the action, whatever your decision. Eh.
Of course, I'm fixing that right now...
But it just goes to show how fixing one bug can lead to fixing another... :^^;:
Crap!
My 'bug' wasn't due to sbox.js itself... It was due to the fact that I was refreshing multiple select boxes at the same time. (i.e. $('select').sb()).
There's just a little bit of logic involved... Each select box, when it's opened, attaches a window event to react to a click outside of it. However, the next sbox being re-created will delete said window event... That's why I couldn't click the window to close the current box. Bugger.
I'm not sure what are the odds of this not working...
I did a version of sbox where the dropdown isn't re-created (it just stays closed). It saves 20 gzipped bytes. I don't know what is best right now...
PS: also, for similar reasons, and in ALL cases here, the scrollbar is no longer selectable after a .sb() refresh. This is due, once again, to a document-wide event not being re-created.
What it does is: delete the current SB, remove its DOM elements, then repopulate it from the original, then re-create it, then open it if it was opened before, or focus if it was focused before.
It executes so fast that you never get to see the DOM be modified, and open/focus states are correctly restored. It's just the closeAndUnbind function that never properly sets the event (even though it DOES get executed at this point...)
I'm currently reviewing all .sb calls, and it seems that it's never called when in the middle of an opened SB, which totally makes sense, so indeed it might be best not to reopen the SB after re-creating it.
While doing this review, I also discovered a horrible bug in Wedge... I did, in a few occasions, launch a !ask() request in DOM events. Which is TOTALLY what should be done. Unfortunately, the nature of alert/confirm events is that they stall the execution process until we return, then we get a boolean parameter we can give back to the event. Okay. But say/ask are functions that don't stop any execution, and for that reason I had to had a callback system to allow for use in DOM events. It works very well, but it seems like I forgot to convert a few calls... And because ask() will immediately return false in a DOM event, if you take action after an !ask (rather than an ask), it will be executed.
To make it short (my explanation really sucks): Wedge could no longer un-admin anyone, or make a membergroup invisible, because it would always request confirmation and immediately return to cancelling the action, whatever your decision. Eh.
Of course, I'm fixing that right now...
But it just goes to show how fixing one bug can lead to fixing another... :^^;:
Posted: February 12th, 2013, 11:22 AM
Crap!
My 'bug' wasn't due to sbox.js itself... It was due to the fact that I was refreshing multiple select boxes at the same time. (i.e. $('select').sb()).
There's just a little bit of logic involved... Each select box, when it's opened, attaches a window event to react to a click outside of it. However, the next sbox being re-created will delete said window event... That's why I couldn't click the window to close the current box. Bugger.
I'm not sure what are the odds of this not working...
I did a version of sbox where the dropdown isn't re-created (it just stays closed). It saves 20 gzipped bytes. I don't know what is best right now...
PS: also, for similar reasons, and in ALL cases here, the scrollbar is no longer selectable after a .sb() refresh. This is due, once again, to a document-wide event not being re-created.
3654
Archived fixes / Re: sb refresh does not update scrollbar
« on February 11th, 2013, 11:25 PM »
Hmm... That would be the cop out solution... :P
3655
Bug reports / Re: Quick editing own posts marks topics unread..?
« on February 11th, 2013, 11:24 PM »Nothing, that's the point.
If you edit, it should mark that post only as unread :/
But I don't understand why I have no memories ever seeing the Edit icon -- and I mean, in the two years we've been using Wedge here! I should remember, shouldn't I..?
I must confess I'm not a big fan of seeing my own posts as new. If at the very least we could have a grace period, e.g. if the post is edited within the time period specified in the settings (the setting that prevents showing 'edited by...' under a certain threshold), then it shouldn't be considered as unread, either...
Wouldn't you agree?
There are other side issues with unread stuff - I've seen cases where I've had to read things twice, e.g. the New Revs topic invariably needs reading twice.
Okay... Bed time :(
3656
Bug reports / Quick editing own posts marks topics unread..?
« on February 11th, 2013, 11:13 PM »
What did we change recently with quick edits..?!
Tested this: posted two messages in a row after another message of mine. Topic marked read. Quick edited the older message, ie the one I posted before the last two. Topic marked unread. If I go to the topic, it shows me the last two messages as unread (ie those I posted after that one). If I attempt to quick edit the last post, it marks the topic as unread too (one unread message).
It doesn't make sense to me... This never happened before, AFAIK. And I don't remember seeing any changes to the act of marking topics as read. The only thing I 'fixed', was *unseen items*, i.e. in the gallery..... :-/
Tested this: posted two messages in a row after another message of mine. Topic marked read. Quick edited the older message, ie the one I posted before the last two. Topic marked unread. If I go to the topic, it shows me the last two messages as unread (ie those I posted after that one). If I attempt to quick edit the last post, it marks the topic as unread too (one unread message).
It doesn't make sense to me... This never happened before, AFAIK. And I don't remember seeing any changes to the act of marking topics as read. The only thing I 'fixed', was *unseen items*, i.e. in the gallery..... :-/
3659
Archived fixes / Re: sb refresh does not update scrollbar
« on February 11th, 2013, 11:08 PM »
Ah yes, sorry, always forget about that one...
I thought it was a problem with the way the scrollbar thumb size was calculated... But I must have misread it... It's simply a case of "oh, these are two separate objects, if you remove one you have to remove the other..." -- heck, it took me about 20 minutes of work to generate a dummy situation where the SB would be modified in real time and then refreshed, and about 10 seconds of extra time to find out I just needed to add a 'delete scrollbar' call in reloadSB(). Bit of a shame, writing that code for nothing... :lol:
I changed it to scrollbar = '' because it saves two bytes (that's just me...), seems to work the same.
The only remaining issue is that, ahum, if the SB is open while I'm regenerating it, I can no longer click outside the SB to close it, I have to click the SB itself. And that, hmm... I spent another 10 minutes on that one, and couldn't figure it out. It just evades me for now. I guess I'll work on that one tomorrow.
Heck, it may not even be important... I'm guessing that in 99% of cases, the SB will be closed at the time you're regenerating it, anyway...?
I thought it was a problem with the way the scrollbar thumb size was calculated... But I must have misread it... It's simply a case of "oh, these are two separate objects, if you remove one you have to remove the other..." -- heck, it took me about 20 minutes of work to generate a dummy situation where the SB would be modified in real time and then refreshed, and about 10 seconds of extra time to find out I just needed to add a 'delete scrollbar' call in reloadSB(). Bit of a shame, writing that code for nothing... :lol:
I changed it to scrollbar = '' because it saves two bytes (that's just me...), seems to work the same.
The only remaining issue is that, ahum, if the SB is open while I'm regenerating it, I can no longer click outside the SB to close it, I have to click the SB itself. And that, hmm... I spent another 10 minutes on that one, and couldn't figure it out. It just evades me for now. I guess I'll work on that one tomorrow.
Heck, it may not even be important... I'm guessing that in 99% of cases, the SB will be closed at the time you're regenerating it, anyway...?
3660
Features / Re: New revs
« on February 11th, 2013, 07:10 PM »
rev 1915 -- mouse wheel fix, more love for the skin selector, and index language cleanup.
(16 files, 13kb)
! Fixed mouse wheel no longer working on select boxes. Thanks to jQuery 1.7.1 for that one, ahem... (sbox.js)
* Rewrote wedge_show_skins to return a string rather than echo it. Well, technically I should rename the function as well, but I couldn't care less... The resulting string probably won't be long enough to have any impact on performance, and this has the advantage of filling in a name array where I can then get any skin's name from its path, which surprisingly isn't available from the get go. I really should store skin details in the database or in some kind of cache... Probably will do at some point, unless Pete beats me to it first... Anyway, this was all to allow the skin selector plugin to show the default skin (if it's the one selected) without the Default flag in the select box. (It should only be shown in the dropdown.) Ah, yes, because I added a parameter that enables adding a 'Default' flag next to the default skins (desktop and mobile). Which is cool... Do what you want with it. Again, this is all tested with only ONE theme enabled, so it may break or behave inconsistently on multiple themes. (Themes.php, ManageBoards.template.php, Themes.template.php, index.language.php)
- Got rid of plenty of obsolete index language entries. Apparently, we didn't finish our review process for them..?! (index.language.php)
! Fixed syntax of meta viewport tag. Apparently, BlackBerry devices don't like the semi-colons. Not that I ever tested Wedge on a BlackBerry, mind you... I don't even know if it's spelled BlackBerry or Blackberry. (index.template.php)
* Moved debug language entries to Stats language. Technically, they're debug stats, the stat language files are very short to begin with, and these strings should only be loaded for those who have the rights to see them, i.e. not everyone... No need to spend time loading them for everyone, then. (index.language.php, Stats.language.php, Subs-Template.php)
* Moved (and renamed) totalTimeLogged strings to the two files they really belonged to: Profile and Stats. Also got rid of the first one, which was obsolete. (Profile-View.php, Stats.php, index.language.php, Profile.language.php, Stats.language.php)
* Moved some smiley strings to the Profile language files. (Themes.php, index.language.php, Profile.language.php)
* Memberlist search page needed a bit of extra love. (Memberlist.template.php, sections.css)
(16 files, 13kb)
! Fixed mouse wheel no longer working on select boxes. Thanks to jQuery 1.7.1 for that one, ahem... (sbox.js)
* Rewrote wedge_show_skins to return a string rather than echo it. Well, technically I should rename the function as well, but I couldn't care less... The resulting string probably won't be long enough to have any impact on performance, and this has the advantage of filling in a name array where I can then get any skin's name from its path, which surprisingly isn't available from the get go. I really should store skin details in the database or in some kind of cache... Probably will do at some point, unless Pete beats me to it first... Anyway, this was all to allow the skin selector plugin to show the default skin (if it's the one selected) without the Default flag in the select box. (It should only be shown in the dropdown.) Ah, yes, because I added a parameter that enables adding a 'Default' flag next to the default skins (desktop and mobile). Which is cool... Do what you want with it. Again, this is all tested with only ONE theme enabled, so it may break or behave inconsistently on multiple themes. (Themes.php, ManageBoards.template.php, Themes.template.php, index.language.php)
- Got rid of plenty of obsolete index language entries. Apparently, we didn't finish our review process for them..?! (index.language.php)
! Fixed syntax of meta viewport tag. Apparently, BlackBerry devices don't like the semi-colons. Not that I ever tested Wedge on a BlackBerry, mind you... I don't even know if it's spelled BlackBerry or Blackberry. (index.template.php)
* Moved debug language entries to Stats language. Technically, they're debug stats, the stat language files are very short to begin with, and these strings should only be loaded for those who have the rights to see them, i.e. not everyone... No need to spend time loading them for everyone, then. (index.language.php, Stats.language.php, Subs-Template.php)
* Moved (and renamed) totalTimeLogged strings to the two files they really belonged to: Profile and Stats. Also got rid of the first one, which was obsolete. (Profile-View.php, Stats.php, index.language.php, Profile.language.php, Stats.language.php)
* Moved some smiley strings to the Profile language files. (Themes.php, index.language.php, Profile.language.php)
* Memberlist search page needed a bit of extra love. (Memberlist.template.php, sections.css)