Me like. :)
The green menubar looks nice, although the highlighted buttons seems a bit fuzzy on the edges. But the windowbg's and catbg's - very nice. The titlebg on info-center (among others) - not so much, it sticks out now so I would suggest changing it. And great that all the(or most of them) dropshadows were..dropped. Too much of anything isn't good for you, so they say.
The dark-grey background: also great, this theme really has some balls now. :D
There's a "like" button now :P (currently hidden unter the "More...." near "Quick Edit")
Ah, I see it. :)
/me can't see the like button! :'(
Looks like it was not enabled for the GM group ... I enabled that just for you :D
/me can likez!
Well, another button I'm not going to use... :P
/me cannot see teh likez button. :P
/me not that keen on likez as a feature, but is happy to test it when someone complements the new theme I made. :D
/me massive ego FTW. :P
I agree. Was thinking of tweaking it. That (and other gradient highlights) are going to be changed for W3 syntax CSS3 gradients anyway.
Yeah wasn't entirely happy with those, but just went with something dead basic for the moment until a better idea occurred.
I'll be throwing out a lot of remnant 2.1 alpha styling, but will probably leave most of the styling hooks in the markup, just in case anyone wants them (and because leaving them is the lazy option).
ETA: Oh and I'll be going full-on OOCSS on the menus soon anyway, so that will involve a total re-write of them. Will look at tweaking colours and borders after that. I think the drop menu system is one place where going mental on classes is worth the extra HTML. It will make styling menus a lot easier for beginners.
Should be fixed now as well
Yup. It works.
ETA: Ok, I'm gonna change those quickbuttons to use pseudos for the icons. They start looking like crap pretty fast with non-standard font sizes. @todo.
Well, likes are funny, can't deny that, I'm just not used to them.
Y'know it's currently a bit weird with the buttons, in that to like a post you have to open the "More..." droppy, but once a post has been liked there's a like button which doesn't do anything. I think this should be changed. A separate button may be the way to do it, given that likes do seem to be rather popular these days.
I was thinking about the "Quote to new topic" thing as well. Having that as a droppy under "Quote" is currently buggy with click menus enabled, since you have to click to open the droppy, and clicking quotes the post to quick reply. :D
We'll have to do a bit more thinking about the quickbuttons strip.
May also tweak things a bit with regard to the heavier font-weights in some areas. I'm running W7 and use Firefox by preference. With that combo, font-weight: 600; adds emphasis, while still being a lot more elegant than plain bold (700). However, I've noticed that browsers other than FF seem to default to bold for those declarations. I may lighten the colour fractionally for those browsers, but it's not a priority at the moment.
Also, Opera seems to slightly bork vertical paddings/cell heights on the board index. Other browsers are all consistent.
Hey how about something like this for the on/off icons?
Btw, tweaked those on local. Dropped the font-size back to 1.1em and it's more balanced now.
I can add a fat moose to the folder. :D
On/off icons looking better. :)
Is the titlebg style updated here?
No it isn't. Only on local. I'll put some code in so they can play with it on GitHub.
Oh and I nicked those icons from somewhere else and then modified them to suit. License is non-commercial, so should be alright for the moment. I'll contact the maker though and see if he's cool with them being used for the release stuff. Icons are a pain to make, but I could do something like these if I had to.
Oh and I've converted my local copy over to CSS3 gradients and ditched the images. I'm totally converted now. So easy to tweak stuff if you think it's not quite the right shade. Firefox supports diagonal/angled gradients on W3 syntax too. :D
Here's what the info centre looks like now.
If I understand correctly, "non-commercial" means proprietary non-commercial. That is not acceptable. We don't need any custom waivers. The maker can license it open source. If they don't (which is their right), we don't use it, and we will choose other options.
What about green Tango:
http://commons.wikimedia.org/wiki/File:Folder-new.svg
http://commons.wikimedia.org/wiki/File:Document-open.svg
http://commons.wikimedia.org/wiki/File:Folder-open.svg
There are the svg available in PD, we can adjust them the way we want.
For reference: http://commons.wikimedia.org/wiki/Tango_icons
ETA: suggested because while searching for something similar to a folder those have been the first popping up.
Or perhaps we can find something from the icon libs we are already using ....
Which one is it that one? ???
I downloaded what I thought it was the whole pack and I didn't find anything...that's why I started looking somewhere else... lol
Yeah could play with those. Didn't spot those before. Would want them in either .psd for Photoshop or layered .png for Fireworks. Plain .png or some weird Linux shiz aint no fun at all. :P
Oh come on adobe is still supporting only his formats and nothing else? lol
Point is it's common, not some weird format some nutter randomly pulled out of his backside just to confuse things. :P
GIMP will do layered .png too. That Oxygen stuff is compressed in some weird format I've never even heard of before. WTF opens it?
You talking about the .xz extension on the archive ?
Yup. :D
Kthnx. WinRAR will do ordinary tar.gz and .bz2, but has never heard of .xz.
I grabbed Inkscape for the .svg's. Not that I really want to learn another gfx app right at the moment, so if someone else gets inspired to do some cool icons.................
Hey found a few hot contenders. One good one has a free WTF license. Another is LGPL. Another has no license at all, but I could email the author. Another is free for personal use, but asks for linkback. May be amenable to doing a deal.
So looks like no probs. One of those will work.
Ok, got them. Now I just need to talk the author into ok'ing it.
http://www.softicons.com/free-icons/folder-icons/triganno-folders-icons-by-tongsky/folder-green-2-icon
Sounds like he should be amenable to us using them if he gets some credit. Will email him and find out for sure. These are perfect. Just needed a tiny bit of Photoshoppery.
ETA: By the way, it's worth checking out this guy's gallery on DeviantArt. His icon work is insanely good.
http://tongsky.deviantart.com/gallery/
I do like those. Some great icons for sure! A note in the credits should be fine I think.
Much as I like the green moose, I do have to admit that these are a little more professional in appearance.
WTF (I suppose that's WTFPL) and LGPL are fine (strictly speaking WTFPL is not OSI-approved, but yeah, OSI-approved is not a 100% criterion).
"Free to use, but commercial use not allowed" is not fine. (http://www.softicons.com/free-icons/folder-icons/triganno-folders-icons-by-tongsky/folder-green-2-icon)
It does not match the "you may use in any way [...] as long as you respect the work and credit it appropriately.". The two are not the same: the first is proprietary-for-no-charge, the second is likely free and open source, along the lines of CC-BY.
Stray off-hand example #1: "commercial use" is to mold Elk into an online downloads for pay site, and use the icons to decorate your 'special promotion board'.
Stray off-hand example #2: "commercial use" is to make a forums hosted site, for paid memberships.
Stray off-hand example #3: "commercial use" is to make a commercial proprietary package, forked of Elk.
They're all allowed by free and open source software/design (well the proprietary bit of the latest, only by BSD/CC-BY, not by MPL/LGPL/CC-BY-SA, but that's about proprietary, not about 'commercial use').
Commercial endeavours are an endeavour like any other, free and open source software doesn't discriminate against them.
But I sort of agree that by the sound of it, the author is thinking at commercial proprietary software of some company, that include the icons and claim the whole as their own, such as compiled desktop applications.
Anyway, what we need, is for them to explicitly license it as one of the open licenses. If what they mean is this: http://files.softicons.com/download/folder-icons/triganno-folders-icons-by-tongsky/Notice.txt, then we can ask them to license CC-BY.
If they want any modifications to the icons to be licensed under the same conditions, then CC-BY-SA.
I've messaged the guy over on DeviantArt. Waiting for him to respond. :)
Editing the editor script is IMO a mistake, it makes upgrading to newer revisions cumbersome. If the editor is not right then a request should be made against that project for a change or new option if whatever you are doing can not be accomplished with a plugin.
Well how can you customise it then? There's already custom code for Elk tied in with the editor, and there's no point making a request to Sam Clark for stuff that is specific to another project. Also, the options that are edited are minor and are highly unlikely to inhbit upgrades.
Also, is anyone going to downlaod the pile of code I did? It's been sitting there for over 48 hours without being touched, but the tiny zip for the editor has already been downloaded.
options.resizeMaxHeight and the others are already ways to customize the max height and width of the editor (AFAIR).
I see that its minor, but its still a difference, so unless someone wants to create a elk fork of the editor and maintain it and make PR's back to Elk when it changes, etc and bla bla bla personally I'd like the editor, in total, to be maintained by the Sam so upgrading is a simple file replace. (that resize code actually changed a lot from various versions due to complications with various browsers supported)
I just downloaded the code, don't get yer knickers in a knot :P
ETA: https://github.com/elkarte/Elkarte/pull/574 But I probably missed some of the image updates
Ok, where are the settings for them? In the file I edited, or hiding somewhere else? If there's a better way of setting them I'm happy to use it, but I think the default behaviour doesn't really make sense.
I often want a textarea larger, often a lot larger, but I've never wanted one to collapse below its default size. It's sort of messy at the moment, and IMO would be better if the textarea was constrained so it couldn't go below its default height or width, or above its default width. It would feel more stable when dragging it to expand it.
I have sometimes wanted a textarea to expand past default width, but that only applies to tiny ones. Our editor is already sufficiently wide.
The default max-height limit makes no sense at all. That's just a PITA.
Yeah but I had to kick you first. :P
(http://galleryqui.files.wordpress.com/2011/01/12-arewethereyetlogo.jpg)
Ok cool. I found out how to do it properly. :P
* Max resize to height, set to null for double textarea height or -1 for unlimited
* @type {int}
*/
resizeMaxHeight: null,
/**
* Max resize to width, set to null for double textarea width or -1 for unlimited
* @type {int}
*/
resizeMaxWidth: null,
/**
* If resizing by height is enabled
* @type {Boolean}
*/
resizeHeight: true,
/**
* If resizing by width is enabled
* @type {Boolean}
*/
resizeWidth: true,
Change to:
* Max resize to height, set to null for double textarea height or -1 for unlimited
* @type {int}
*/
resizeMaxHeight: -1,
/**
* Max resize to width, set to null for double textarea width or -1 for unlimited
* @type {int}
*/
resizeMaxWidth: null,
/**
* If resizing by height is enabled
* @type {Boolean}
*/
resizeHeight: true,
/**
* If resizing by width is enabled
* @type {Boolean}
*/
resizeWidth: false,
That doesn't set a fixed min-height equal to default height, but does stabilise the width and allow unlimited max-height.
Hey would that be acceptable, since it's in the options section of the file, or do you want it set somewhere else? If the options can be set where the editor is intiialised or somewhere else, I don't mind doing that before resubmitting the code. Just need to be pointed at the right bit of the right file.
Ok you Webkit and Presto peeps, your silly browsers wont handle numerical font-weight. They only know normal or bold. Firefox, and even IE, will do a font-weight of 600, which in many places is much better than either bold or normal.
Since I don't have to look at what Webkit and Presto do, I don't much mind which they get. If the consensus is that the bold is too heavy, I can serve them normal weight. We haz body id by browser (someone clever though of that).
I've found a mix of color and bold/normal goes a long way in separating items and/or lowering their visibility. Different bold values seems a bit too unreliable, both on the account of the failing support in browsers(webkit as it seems) and the slight differences there will be in different systems regarding the chosen font-type. Plus the different resolutions yield different results in the anti-aliasing and rendering of said fonts. There is a noticeable difference in quality between 1080p and something like 1024px screens.
In short, it can never be 100% the same all over - thus very small differences in appearance, like bold/slightly less bold, will be less effective than other things IMHO. I've opted to NOT do browser-specific styles/adjustments even, only adding vendor-specific on certain css3 styles just to trigger the styles. That means less amount of styles to work with(less alternatives to figure out) but also a requirement that the ones I do use, must work acceptable all over, if not exactly 100% copies of each other.
But, of course, a broader palette is always nicer to work with. :)
600 is pretty safe, because it just defaults to bold anyway. It doesn't seem to do anything weirder than that, and it does look much better in Firefox and IE, which are a significant chunk of the target market.
Then again, I suppose I should fire up Browsershots again and check everything they've got. There might be an odd surprise lurking in some dark corner.
PS: Firefox and IE will also do a pretty good 100 weight, although it's of limited practical use (large text only, really).
Seems to be pretty good in just about any combo. http://browsershots.org/requests/9060392
Don't know if you know, but Presto is going to die with the next release of Opera that will use Webkit. ;)
Well that will leave Webkit being the problem, but just on more browsers.
If you have a moment in one of the next updates, consider changing the color of the numbers in the menu (for example the number of PMs), the current black is really difficult to read with the dark-green background. ;)
Yeah saw that yesterday. I was thinking a small pop-up link might be good. With the click menus you can see you've got a message, but you have to open a droppy before you can go to inbox.
So if I hack teh sauces a bit and make a little anchor that pop-ups and goes straight to inbox on click, that might be handy.