Include Gray in formatting buttons

[EdB]

So should I merge the greay buttoun in, or wait for this instead?

Oh and yeah anything it uses should be in it's own home. Else we end up with more "calendar" creep: that damned plugin has it's fingers in EVERYBODY's pie GRRR!!

For the starting color perhaps use the colored buttons we have now? Like, someone clicks the red R and gets the color picker with a base of red? Just a thought on how to maybe seed it even though I don't really understand what you mean.

[Afwas]

Merge the grey button. I like the rolling aspect of it, as if every merge could be some minor point release.
Of course the grey button is all about nothing. I get my head around the whole submit structure. I must admid I spent equal or more time

• Writing forum
• Creating branch
• Writing bug report

Trivial 'bug' solved

• Commit
• Change bug status
• Propose merge
• Follow up in Forums

To be done

• Follow up in merge stage

So there's quite a lot of overhead. But it leads to better code through more attention from more people reviewing.

The datepicker was mine also. It replaced ugly code (boy was that ugly). Drawback was a folder of images (also the colorpicker has them) and several other files around. The datepicker could have been done differently (plugin) but it was supposed to be available everywhere and re-used in other places. This is really an interesting discussion and if you care set up another thread or ask me to do so.

Yes I 'm thinking of serializing the plugin based on starting colours in the second bar. But only if there's not too much extra bandwith / memory involved. On the other hand, you can create every colo[u]r form the starting colo[u]r.

[EdB]

May be silly but gray is a color needed when text needs to be camouflaged (like the small print in most contracts). Why don't you add it to the colors already printed.

Doing the merge thing now, but this seems pretty damned close to shitty webwork. Camouflaged text? er... just because some shitbags out there want to hide what they're saying doesn't mean it is a good thing to do. Gray should be added because black and white were added and gray is kinda half-way tween the two. Anyway that stuck in my head as a really lame reason to add something. I mean, what next: add "extremely tiny font that picks the background color so we can put tons of text in the page footer to spam search engines because the 80s were so much fun"?

[Afwas]

Gray should be added because black and white were added and gray is kinda half-way tween the two. Anyway that stuck in my head as a really lame reason to add something.

Depending on the background colo[u]r of your skin gr[a|e]y can be a usefull addition.

[Kimberly]

The colour quick tags quickly allow the common colour names to be applied. In CSS you can use colour names such as red, blue, green, grey (or gray; are both recognised by the browser's interpretors for CSS?), yellow and these are specific colours. To get one of the 16 million colours that can be displayed you have to go to either RGB or numeric. Therefore, to me the current colour quick tags should be just for that purpose and we add to the quick tag bars the colour names mostly to be used. I saw the colour picker as a plugin separate from the quick tag colour selector and think that is how it should be. One may decided they don't want the colour picker plugin and just want the quick colour tag plugin, or both, or neither.

As for EdB comment, that same thought came to my mind. Why do you want to hide text except maybe for keyword spamming. If google see hidden text in a page where CSS is used to hide a block of text, it will rank that page very low if at all. However, if text is simply hidden by being the same colour as the background it is possible that google will not catch that the text is hidden. Adding the grey text to the colour quick tag was a legitimate request and one easily added, even if the purpose for requesting it was perhaps not so legitimate.

[EdB]

I just thought of something that probably should get it's own thread to go with the idea of a fancypants full-blown color picker:

What about a half-way point between quicktags using class="foo" and a color picker that would have to use style="color:#foo"? I'm thinking (without coding) that when you click one of the buttons for the ROYGBIV quicktags you get a tiny little popup menu that offers three shades of that color. So light blue, regular blue, and dark blue. That could be done with classes but maybe it would make more sense to do it with styles? Anyway that would take the 7+3 we have and make it be 21+3 offered via quicktags.

Not saying I'm against a fancypants color picker - just that I see Kimberly's view on it and thought hey we could get a wee bit of the way there without being "too fancy" ... whatever that is. QuickTags being, well, just a quickie ya know?

[Afwas]

I've more or less finished the colorpicker in the quicktags plugin. I'll post the plugin here as zip - the good old way. I'll also commit to lp:~foppe/quam-plures/quicktags which should be fine as I saw that EdB already merged the gr[a|e]y thingy.

If you find any oddities please let me know. I'll probably have a look at it for a couple of days before I propose a merger.
I had quite a lot of minor issues to overcome before I was finally satisfied. I used as elegant solutions as I could come up with.

Edit

lp:~foppe/quam-plures/quicktags is gone. Will look for another branch

[gcasanova]

May be silly but gray is a color needed when text needs to be camouflaged (like the small print in most contracts). Why don't you add it to the colors already printed.

Doing the merge thing now, but this seems pretty damned close to shitty webwork. Camouflaged text? er... just because some shitbags out there want to hide what they're saying doesn't mean it is a good thing to do. Gray should be added because black and white were added and gray is kinda half-way tween the two. Anyway that stuck in my head as a really lame reason to add something. I mean, what next: add "extremely tiny font that picks the background color so we can put tons of text in the page footer to spam search engines because the 80s were so much fun"?

I may have used the wrong word "camouflage", but in no way did I mean Spam. In one of my blogs I publish a chapter a week of a novel. The introduction to the idea of publishing one chapter each week was important when the first chapter was published. After that it wasn't so important, but if a reader came for the first time and landed on the second chapter, and wanted to know what it was all about, the introduction, now grayed, is there but because it is gray or grey or shade of black or mixture of colors or colours, it is unobstrusive.
Nothing related to spam, it is, at least for me a legit use and something I want.
But if you consider this a suggestion from a "shitbag", spammer, well...

[EdB]

I read what you wrote and responded accordingly. Perhaps not writing that you want to hide text would have been more in order?

Gray is now an option on the quicktags, but it might not last that long given Afwas' "advanced quicktags color picker" thing. Somewhere there is a link to a daily snapshot, and the new version of QT should be in that zip, so if you want it I'd say grab it now. AFAIK there have been no changes that would make v0.2 of that plugin not work with QP's v0.0.0, but OBVIOUSLY backup backup backup just in case.

hm! It seems that as of right now the link to the daily snapshot is in my signature file thingie, so yay for signature file thingies!

[EdB]

I used the zip version finally and found it to be a little confusing but pretty damn cool. Like for example I had to kinda figure out it was showing the new color and the current color. Fairly common I guess but it wasn't obvious at first glance that was what was happening.

Little bit of a hardship grabbing the sliders but certainly not a show-stopper IMHO.

Oh and I'd get rid of the space after "color:". Do "color:#abcdef;" instead, but that's just the way I roll with inline css stuff. I don't like that in a style sheet but I do like it for stuff you see in the item's html.

Probably much better than the other common model where you have a grid of colors to pick from. Like how this forum gives you color options. BUT I kept thinking of the poor slob who wants to re-use the same color from a different post. Maybe MAYBE one day we can figure out a way to let each user say "remember this as one of my personal favorite 8" or something so they can go back to that color?

Oh and poking through the images in the plugin, it seems there is a dark set and a light set but I didn't notice a way to change from dark to light. Is there? If not could there be?

NOTE to everyone who hasn't tried this: you still get the "quick tags" bars the way they are but you also get a little color-wheel that clicking turns into a color picker. Kinda cool in that we'd still have good old fashioned buttons but we'd also have fancy-poshness.

Oh hey imagine if each user could say "put this shade on the blue button" after picking their favorite shade of blue, meaning the actual color used by each of the 7(+3?) buttons is user-definable. Bye-bye doing it via a class and a style sheet, but hello total ownership per user

BUT one step at a time. Afwas if you're satisfied with this I'd love to see it as a branch in R2Mistan