We are almost at mid-march, but TBH I'm not sure the code is at RC level... :-(
At the moment there are still 2 "real" issues marked as blocker:
https://github.com/elkarte/Elkarte/issues/1400
https://github.com/elkarte/Elkarte/issues/1274
Of the other three one if fixed, one is a placeholder and the third is fixed (the German translation with fixes for the English text), but still open for reference.
1274 is easily "workaroundable" (flipping to the left).
1400 is a bit more tricky and TBH I'm not sure how to fix it. It looks like SCEditor "eats" tabs if they are present in the HTML of the textarea, and if the tabs are not into a code block they are replaced with spaces as well.
Then there are some bugs reported in bug reports that have to be fixed (i.e. almost all those reported by
@scripple ).
So maybe end of march becomes a good date for RC instead of final... :(
Oh well, a couple of weeks more. :P
No problem. I know how much work you people put on it.
Sorry for pushing your schedule back, but bug hunting is part of what betas are for right?
On 1400, I notice that if I use the "insert quote" buttons on the posts below the editor box that it correctly preserves tabs inside of code boxes when calling the insert function on the sceditor. Could you not insert the original preview code the same way the insert quote button works? Render it the same way quotefast does and then insert it into the box the way onDocReceived does?
This does still shift tabs into spaces outside of code tags, but it's perhaps a start.
Oddly enough if you have wysiwyg mode enabled and use quick reply with a code section with tabs they will go through to sceditor correctly. And you can then push the show source button to go back and forth from source and wysiwyg mode and the tabs remain. But calling setTextMode (or calling sceditor's sourceMode(true) at the time you do somehow causes the tabs to get lost. Not sure if it's an sceditor bug or something to do with the elkarte plugins but it's definitely timing sensitive.
And the reason tabs live on in code blocks (when it works) and nowhere else is here in bbcode.js from sceditor
if($node.parents('code').length === 0)
ret += node.wholeText.replace(/ +/g, " ");
else
ret += node.wholeText;
So if you really want tabs to live on everywhere you can deliver a modified version of bbcode.js that doesn't replace all whitespace with spaces.
Well if anyone wants to pick this up I've traced the difference to bbcode.js base.signalToSource = function(html, $body) when it calls $.sceditor.dom.removeWhiteSpace($body[0]) which sets off some recursive white space removal.
For some reason this recursion isn't the same depending on whether the wysiwyg to source conversion is done right at creation (like when wysiwyg is off by default in user settings) versus manually clicking the view source button after the page is 100% loaded.
Maybe this will help someone spot what's causing the difference.
Better push it, than send out a broken script!
You are doing a great work of testing! :D
Thanks on the testing. Glad to help.
On the quick reply to sceditor eats tabs in code blocks. It's caused by the style not being applied by the time the conversion from bbcode -> wysiwyg -> source is handled. (Most importantly the part where it goes back to source.) So the elkarte code {white-space: pre;} is not being honored. I edited jquery.sceditor.js (I'm working with unminimized copies pulled from the sceditor github page) and added a style sheet directly in the header to set white-space pre on code and now the tabs are maintained whether I start in wysiwyg mode or source mode.
Is this helpful to you? Or should I stop?
Ok, here's a proposed fix for quotes in code blocks not surviving clicking preview from quick reply when using the sceditor in text mode.
in themes/default/GenericControlsTemplate.php make the following change.
$(".sceditor-container").width("100%").height("100%");', $editor_context['rich_active'] ? '' : '
$("#' . $editor_id . '").data("sceditor").setTextMode();', '
$(".sceditor-container").width("100%").height("100%");', $editor_context['rich_active'] ? '' : '
$("#' . $editor_id . '").data("sceditor").css(\'code {white-space: pre;}\');
$("#' . $editor_id . '").data("sceditor").setTextMode();', '
Nice debugging and fix :D
Looks like that works very well. We were exploring passing the original post data to setTextMode() so it would populate the editor box when you swap to the post screen from quick reply. That also seems to work although its a few more edits. So far I've only seen code blocks affected so your fix may be the best one to use.
Inserting directly into source mode would work too. I just got curious as to what the difference was. Also if you want to save some space you can ditch your setTextMode function and just use the sourceMode(true) call built into sceditor.
Thanks, and indeed we have some left over helper functions that have since been added to sceditor that we could make use of !
Committed here:
https://github.com/emanuele45/Dialogo/commit/2f985f6cd2ec287a5895ecdd33ec770969a5355d
TBH, I was wondering: go directly with an RC or release a beta3?
Recently, thanks to
@scripple and @AaronB reports I realised there are still several buglets around that may or may not be annoying depending how the script is used.
I think that if we were to release Elkarte 1.0
today it may not really be up to a "stable" release and it wouldn't be nice.
On the other hand, we could try to use a "slightly" different release schedule for micro updates (i.e. 1.0.X versions), like monthly if we can setup an easy way (e.g. instead of a "patch", directly replace the files, that would also encourage further the use of hooks instead of code edits), but that's just some random thought while writing, so it may have several drawbacks... :-(
Release often and push hard use of plugins
Beta 3 definitely, unless you want to do SMF 2 "release candidates". :D Realistically, this thing aint ready for a real RC yet. In my understanding, a real RC is when you have all outstanding issues fixed, and are just trying to see if any new ones pop up before you call the thing stable. Elk's not quite there yet.
Both methods are useful. I'd rather see 6 or 8 betas than 3 RCs. More than 1 RC release should be
rare.
What does "push hard use of plugins" have to do with trying to get 1.0 stable? I don't get it. Surely plugins are customisations you add to a release after it's stable.
Dunno. I just like the
release often part.
groundup surely has an explanation.
It's all about prioritizing bugs. If an issue is an edge case, it shouldn't be blocking. If it's about getting the theme to look even better, it's not blocking. If there aren't blocking bugs, release it. Releases get attention; attention gets developers; developers fix bugs. More events in the code means less worrying about edge cases. You can even have a plugin fix a bug before a release. More events also means a lot less (hopefully zero) touching the code. So, you can just overwrite the file and be done with it.
Depends what you want to call "blocking". I wouldn't want to take it to the level of doing a "Microsoft stable". ;D But yeah I can see the sense, to a degree. It does seem a bit bonkers to go overboard on plugins for everything that really should be fixed in the codebase. That's just going to piss people off.
My definitions:
blocker - something that breaks *badly the "user" experience (e.g. a call to undefined function, a feature that doesn't work as expected, an unreadable text because it's the same color of the background, a menu that doesn't work at all on a supported browser, etc.),
important to fix - something that makes the script look bad, but that doesn't break the overall user experience (e.g. an undefined index on an hardly used page or in the admin panel, a button without background, a 1px error in positioning of a non-prominent element, some inconsistency in the mark-up, etc.),
nice to fix - anything else.
Of course "blockers" are bugs that must be fixed before a release. "Important to fix" are bugs that would be of course important to fix before a release, but if a date has been set and it's already gone, I wouldn't mind put a note in the release notes and in case plan a micro release with the fix. "Nice to fix" are bug that can stay there since either a micro release or the next minor if no micro are planned.
Microsoft stable? You mean the massive memory leaks of Windows 98?
Or the rushed completion of Windows ME?
Oh, of course you mean the half-assed implementation of
every damn feature in Windows Vista?
No, I guess you're referring to more of the backwards momentum of Windows 8's shotgun marriage of the Windows desktop and Metro.
Please, define what you mean by stable. :P
Zackly. Would hate to see "Elk stable release" equivalent to "Microsoft stable release" and everyone told "Oh don't worry, we have a plethora of plug-ins". That seems like an exercise in foot shooting to me.
But as long as it's done sensibly (meaning more conservatively than he probably wants it to be :D) I can see what Josh is on about.
ETA: BTW, I noticed that W7 is about the only MS OS that didn't make your crap list. There's a reason why I stuck to it and avoided W8.
I should have added in Windows 95, to be honest. But I doubt anyone, in their right mind, fondly remembers any of the Windows 9x releases.
Windows 3.1, XP and 7 are their only true success stories.
Yup. I used XP for yonks until my old pooter blew up, then went straight to W7. I suspect W9 will be pretty good too.
Sorry for completely derailing this topic. crawls back inside her hole
Windows 2000 too. nods
Ohh so you really want me to change the headers two times? :P
/me wonders if we can haz a beta 3 out before Easter.
Yeah, 2 weeks and a half, I suppose is doable.
I just Well, I just realised that from my previous post here was 6 days ago, in the last 6 days we had 4 new bug reports.
TBH I don't see the situation as tragic as Antechinus is describing.
Also the current week is the first since October that there are days without commits to master (I worked mainly on the development branch).
So: few bugs to squash, not many bugs reported...what is wrong with an RC?
The CSS is half-finished?
The template works (at least I haven't see anything badly broken since a while).
If you think it requires work, and want to do it, feel free.
Otherwise wait until it fixes by itself is not feasible, and I prefer to release a theme that works but can be improved, rather than wait years for someone with the knowledge and the will that arrives and says "okay I'm teh man".
The CSS is no different from the code: the current code is not perfect, in many places is not even nice to read, but it works and is in a state good enough for a 1.0 release. In 1.1 will be improved. In 1.2 (or 2.0) will be improved further.
ETA: of course that's only my opinion, if you (all) think it's better to wait and wait until everything is perfect... well I can always for ElkArte. :P
Ok. SMF RC FTW. :P
Not really, to me it can even go "stable" in that conditions.
As long as it works it's fine.
Yeah I wasn't all that serious. It's nowhere near as rough as 2.0.x RC1 (or even 2.0.x RC2). As I've threatened, I should have time to do a bit of polishing this month anyway. It all basically works but some of the CSS could be better organised, just to keep up with the "make theming easier for peeps" plan.
Oh, serious suggestion here: at the moment the menu suystem defaults to hover, with click only available for logged-in members.
This is not good for guests on touchscreen, who realistically will make up a significant proportion of anyone using an Elk site. It's a bit silly feeding people a responsive and mobile-capable theme, but with a menu system that is tailored for operation with a mouse.
The current setup is a relic from the days before touchscreen was important. It came about via CSS-only drops being added to 2.0.x, then Superfish being added to 2.1 Alpha, then Superclick being finally added to Elk, with the result that Superclick was the "afterthought".
Gvien the whole mobile-first emphasis these days, it would be better to make the menu system default to click/tap operation, with hover being selectable for logged-in members that want it.
I'd like to have the ability to have a dark variant including editor theming before it goes RC, Final, Happy, whatever. But I guess if going to that next state of readiness means code changes should slow down I'm fine with just hacking up the code to work.
Oh I thought the dark variant shiz was being sorted. If not, then that defo should be done before RC. That's a pretty major oversight.
I think there's a commit for the wysiwyg portion being handed off to the sceditor class (although it was hard coded to the default theme instead of using the current_theme variable available :( ) but custom.css go moved up to load before various other css scripts like some whoxxx.js and for the editor jquery.sceditor.css that loads all the styling for the non-wysiwyg parts of the editor like the normal text edit box and the bbc buttons. So a variant can't restyle that now.
Makes no sense to promote a variant system for styling stuffz if a major component of the interface cannot be styled via the variant system. Logic 101.
This should be a called a blocker. If it gets called a blocker, someone will get motivated to fix it. ;)
Hover vs click. Obviously click by default is bad on desktop browsers. Just enable it on (window.touch) browsers that aren't logged in.
Or alternatively rewrite your menu code. Wedge for instance works for mobile with clicks without the need to add a silly library. Its almost 100% css3 code.
There's nothing "obviously" about it. I prefer click on desktop.
ETA: I should explain that a bit. The advantage of click is that I can get a menu exactly wheh I want it, and never get a menu when I don't want it.
Hover is a nusiance if the gui is heavily reliant on droppies. They will sometimes trigger accidentally, even with hoverIntent, which is annoying and can slow down use of the interface. This is particularly true if you are trying to provide good accessibilty for the droppies (as you should) .
Among other things, good accessibility requires a significant mouseout delay. Note the use of the word "significant". The whole point of having the mouseout delay is to help people who have poor tracking skills, and/or less than perfect reactions. What has happened with the current Elk droppies is that the mouseout delay has been reduced, to try and mitigate the problems with opened droppies getting in the way. It has been reduced to an extent that effectively makes it useless to the people it is intended to help.
If you use click (with click anywhere to instantly close) there are no problems with accidental opening or with lingering opened droppies. You also don't need hoverIntent, which means you can open a menu faster even though it requires a click. Yes, it's true: click menus are not slower to use. They are just more controllable and less likely to cause problems.
You make a valid point, but my analysis is also based on usability.
I'd gathered that the timeout should be at around 250ms: enough to allow 'clumsy' users to move their pointer back to the menu if they got lost, and also short enough not to get in the way if the menu was triggered involuntarily.
Now, here's the trick: when I started playing with CSS animations (up until a few months ago, Wedge had been using JS animations for menu timeouts), I realized that once you started an animation, *the hover effect was valid until the animation was finished*. That is, if the timeout animation was running, you could STILL move your mouse back to the menu area, and it would stop the animation, and proceed to bring back the menu. Not only does this look cool, but it also solved many of my problems when I was using JS animations -- most notably, I was able to get rid of all JS to control timeouts, because CSS3 was now handling that for me...!
And believe me, I'll never look back. It's just... Natural. And it works fine on mobile, as long as you don't forget that Android devices tend to disregard a submenu being opened if its parent item has a clickable link. You just need to disable the clicking for these, and you're done. SMF menus always offered a 'copy' of the parent links inside their submenus, so this isn't even a problem for usability.
Best of both worlds, really... 8)
And here's your first mistake. Average human reaction time is around 0.25 seconds. To set a mouseout delay that will be useful to people who need it, you have to use a value that not only allows for average reaction time (at an absolute minimum) but also allows getting back to the menu. 0.25 seconds is simply not enough. More suitable values are in the 0.5 to 0.7 second range.
So now you'll say "But at those values, opened menus will get in the way". I know. That's what I've been telling you. If you pick a reasonable value for a11y, as opposed to just picking a value that will hide menus fast because you want to hide menus fast, you get problems.
As for the rest, from an a11y perpsective it doesn't really matter if you're using js or CSS to control the thing. The advantage of js was support for IE8. That will be less significant in future versions.
ETA: Oh, the other problem with pure CSS, assuming you are using a mouseout delay that is long enough to be useful, is when you open the wrong menu in a complex area like admin or profile, then have to go find the right one. You can quickly end up with a mess of opened menus if they are all triggered by hover.
Javascript was invented to control behaviour. It's good at that. Sometimes it's worth using.
My main menu was done 50% CSS 50% JS back in the day. Actually, I learned JavaScript in order to write that menu. I was very proud of it. I even force-pushed it into Aeva Media 2.10, even though it was most useless in there (too few menu entries to show!).
The fact that I managed to turn it into 100% CSS while actually improving usability is a bonus for me.
Of course, usability != accessibility. And I'm not talking about accessibility here. I try to keep my code accessible, but if I truly wanted to make Wedge accessible, I wouldn't be using menus, because even a click-to-open menu requires some targeting, which disabled users might not be comfortable with.
You've got to draw a line and determine whether you want your software to be "reasonably X, and great at Y", or "great at X, and reasonably Y". It always trumps being "perfect at X/Y, and very bad at Y/X".
Click menus are fully keyboard accessible if done properly, so you don't have to require manual targeting via mouse. OTOH, hover menus are useless to anyone who can't use a mouse.
I'm up for usability too. I wouldn't like click menus if I found them bad for usablility, and my reactions and tracking ability are still good enough that I can generally use CSS2 drops without problems (ie: no delays on anything). Personally, I don't find click menus at all bad for usability. I find them to be fast and clean in operation. It's not as if I'm advocating a system I wouldn't use myself.
???
I can open any menu here with the tab of my keyboard. Am I missing something?
Yes you can, because this menu runs js that allows you to do that. Nao was talking about droppies with no js (not so good for keyboard a11y).
ETA: You can get limited keyboard a11y without js, but you have to mess around with focus a lot and it gets rather tricky.
Come to think of it: if you want to use hover menus, but still provide decent a11y for people with less than perfect reactions and tracking ability, what you should be doing is using a long mouseout delay combined with the click-anywhere-to-close functionality that most click menus offer. This is a bit of an oversight in Superfish, and might be worth mentioning as an issue.
If Superfish had the same click-anywhere-to-close as is offered by Superclick, you could use a long mouseout delay while still having the ability to clear the decks instantly if things started getting all messed up.
Not working here (or at Wedge). I'm using Opera 21.
Probably fixable with a tabindex... Can't really bother™ for now though.
(Hey ema, I'm 10 minutes away from making it official that I've voluntarily stopped my github 'longest streak' at 100 days, by not committing my importer fixes to the repo... It feels liberating not having to watch that silly stat anymore... Plus you get to win by 12 days 8))
I can get it to work for everything but the Profile menu, tabbing blows right by it.
Hey yeah. Hadn't tried that before. Thatza bug. No RC yet, kids. :)
Work here.
What (crappy) browser?
Crappy Firefox on crappy Windows 7 64 bit here.
Oh buggery. I forgot that for click menus you have to hit "Enter" when focus is on the top level linky. It works if you do that. :P
However, there's another genuine bug! Yay! :D
If you keyboard access a droppy with the click menus, the droppy will stay open all the time, even when focus has shifted to another top level link or another droppy.
This is bad behaviour. Bad droppies. Naughty droppies. Need a good spanking.
They should auto close when you shift focus to something else. :P
ETA: Just tested with hover option and keyboard access. No problems with Firefox. Works perfectly.
You said click is best, and now is broken? :P
Click is best. :D However, it appears Superclick has a bug in it. Not my fault. I didn't code Superclick. :P
Fixed? How? I run with a buggy ElkArte which has this problem and yes, if I could fix this would be great! I would like to use german language files, but can't right now.
Ooop, sorry a bit confusing: I meant that the German translation forumsearch0r is doing has fixes for the English language... heck what I wrote in my first post doesn't make sense... LOL
If you want a fairly up to date German translation, I think you can grab the package from here:
https://github.com/dertuxmalwieder/Elkarte
copy the German directory to your Elk dir and it should work.
Oh, there we go. Somehow the tab index for Profile comes after Community, not after New Replies like you'd expect.
Firefox 28 on Ubuntu 13.10 right now. Ant can confirm on FF Winx64 if he likes.
Thanks. I have the german files, but my ElkArte installation don't want to use them. I have the bug TE posted here: https://github.com/elkarte/Elkarte/issues/1527 :-[
That's because that's the order they're in in the menu. The profile is only off to the right because the CSS for it (and the up shrink button) is float:right while the others are left.
This is a grumbling thread right? Ok. The up shrink button annoys me because it disappears on mobile. I know, done to save space. But given it's not really an everyday button anyway (I mean you leave the header until you figure out you can hide it right?) I think it really should be a Look and Feel option. Then it's available to mobile users same as desktop and you don't have to worry about it ever wasting space.
Of all the things to put as a top level button that one really isn't it.
https://github.com/elkarte/Elkarte/issues/1230 <= closed because I had no idea what to do (and still don't have any)
And it annoys me because is misleading.
Ant, you placed it there, any idea where to move it? :P
BTW, yes, this is grumbling, but it's usually better to track each bug to a different topic. ;) (In fact this is grumbling because several people started to post bugs and is now difficult to remember what is a bug, what is a personal preference, what is fixed and what is still valid.... at least I have difficulties. :()
Well I put it here not in its own thread as I don't view it as a critical bug or anything. Just overkill. Why not just make it a sub-button to the profile button. You already have a look and feel in there. Just make a "show header"/"hide header" button where the name change appropriately like the arrow direction.
I can't reproduce it, at least, the point is that if you ever saved your account settings the language has been updated to the default one "at the time", so once you have set the new forum default, you have to go to the profile and set it there again to German (and the same all your users).
That's the same behaviour as SMF from my tests.
Indeed, indeed. :)
Dunno about the sub-menu though.
There is always the plan B that would be remove the upshrink entirely. O:-)
Personally I'd rather not see the upshrink removed entirely.
I'm in two minds about it. It often is missing from a lot of custom themes anyway. It's of most use when an admin sets a site up with an idiotically large header and banner (Look at the Size of My Genitals Syndrome) but these are also the admins that are most likely to want to disable header collapse. Hey ho. :D
What the Ant said is what I was thinking as well...
Also the current set up is not exactly "wanted" either: originally the upshrink was meant to collapse just the name and the logo, I added the newsfader because I was playing with the theme (see "that theme is white" topic), but at a certain point it became the "standard" (I'm not even sure how and when lol).
Don't get me wrong, I like the upshrink and I keep the header always collapsed, but... dunno, I'm starting wondering if it is really useful or not.
Maybe in 2.0 the new theme will not have an upshrink. :P
I kind of like scripple's idea of having it in Look and Layout. If it's only useful to logged-in members anyway, then keep it as a profile option, not as a part of the theme.
Well it used to be available to guests too, via a cookie.