"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jfhfaq$e9g$1@digitalmars.com...
> On 1/22/12 1:55 AM, Daniel Murphy wrote:
>> The bugzilla links up the top don't work for me.
>
> Do they work now?

Yep.

>
>> Are you inculding dups in the resolved count?
>
> Everything with the status RESOLVED, so I think so.
>

It's probably best to exclude dups from the graph, they don't say much about progress on the lanugage.  Of course this would require deciphering bugzilla's report interface...

On Sunday, January 22, 2012 01:18:04 Andrei Alexandrescu wrote:
> We just put together a page that counts the bugs per category. It's linked from "Bug tracker" in the navigation panel.
> 
> http://dlang.org/bugstats.php
> 
> The format is sketchy. Looking forward to your suggestions for improvements.

By the way, if you want the page to look 100% consistent, you're going to need to make it so that the boxes that show the bug counts have a white background and black text. As it is, they use whatever the browser defaults to, whereas the rest of the page chooses the colors. So, in any browser that uses its own defaults when the page doesn't specify, the boxes stand out, whereas in browsers which default to black on white, you can't even really tell that the boxes are there.

- Jonathan M Davis

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.725.1327294880.16222.digitalmars-d-announce@puremagic.com...
> On Sunday, January 22, 2012 01:18:04 Andrei Alexandrescu wrote:
>> We just put together a page that counts the bugs per category. It's linked from "Bug tracker" in the navigation panel.
>>
>> http://dlang.org/bugstats.php
>>
>> The format is sketchy. Looking forward to your suggestions for improvements.
>
> By the way, if you want the page to look 100% consistent, you're going to
> need
> to make it so that the boxes that show the bug counts have a white
> background
> and black text. As it is, they use whatever the browser defaults to,
> whereas
> the rest of the page chooses the colors. So, in any browser that uses its
> own
> defaults when the page doesn't specify, the boxes stand out, whereas in
> browsers which default to black on white, you can't even really tell that
> the
> boxes are there.
>

There's a basic, trivial rule of design that needs to be plastered all over the cubicle walls of every software developer on the planet. I've spent years trying to shout it out at every opportinity, but so far I've barely made even a microscopic dent.

Here it is:

"When you set a foreground or background color: SET THE OTHER ONE TOO!!!"

Always. Period. No matter what. In *anything*. Yes, that means YOU, no matter who the "YOU" is!!

Either *both* system-default, or *both* application-set: NEVER cross those streams! Never, never, never, never, NEVER!

Honestly, it's an absolute *travesty* that any interface APIs, HTML/CSS, etc., ever even *allow* the developer to have one set as system-default and not the other.

On Monday, January 23, 2012 01:47:23 Nick Sabalausky wrote:
> There's a basic, trivial rule of design that needs to be plastered all over the cubicle walls of every software developer on the planet. I've spent years trying to shout it out at every opportinity, but so far I've barely made even a microscopic dent.
> 
> Here it is:
> 
> "When you set a foreground or background color: SET THE OTHER ONE TOO!!!"
> 
> Always. Period. No matter what. In *anything*. Yes, that means YOU, no matter who the "YOU" is!!
> 
> Either *both* system-default, or *both* application-set: NEVER cross those streams! Never, never, never, never, NEVER!
> 
> Honestly, it's an absolute *travesty* that any interface APIs, HTML/CSS, etc., ever even *allow* the developer to have one set as system-default and not the other.

While I agree with you, that's not the problem here. The problem is that the majority of the page doesn't use the brower's defaults, but the boxes don't. Now, it's quite possible that the boxes are screwed up to the point that one of the two defaults is messed up, but that wasn't my complete.

Actually, Konqueror (which is my primary browser) has a long-standing bug that makes it so that if the page doesn't set the foreground and background colors, the system color is used for the background, but black is always used for the foreground. It sucks for me, since I end up with black on darker blue, and it's hard to read (unfortunately, any attempts to report it have been lumped in with the complaints about pages not looking correct when the page sets the colors in some places but not all - which isn't the browsers fault at all - so it continues to remain broken). So, I'm screwed even if neither color was set rather than the web developer screwing up and setting only one of them.

- Jonathan M Davis

22.01.2012 11:18, Andrei Alexandrescu пишет:
> We just put together a page that counts the bugs per category. It's
> linked from "Bug tracker" in the navigation panel.
>
> http://dlang.org/bugstats.php
>
> The format is sketchy. Looking forward to your suggestions for
> improvements.
>
>
> Andrei

https://github.com/D-Programming-Language/d-programming-language.org/blob/master/bugstats.php.dd#L24
width="48em" height="18em"

Font size is about 14px so these areas for few digits are very big: ~700px x 250px. Opera and Chrome incorrectly displays it as if 1em = 1px. Firefox displays correctly (and ugly) unless you rewrite it into `width="48.0em" height="18.0em"`.

So am I missing something? If no, why does Opera, Chrome and Firefox incorrectly display such a simple page? Why does Andrei use `em` in this case instead of px?

[OT] Why is that dirty, slow, hard-to-implement, hard-to-understand, and hard-to-write-in (error-prone) HTML used everywhere with it's dirty friend XML?!!! Let's, at least, remove XML support from D as a protest when D will became popular enough! (Sorry, just can't keep it in any more)

"Denis Shelomovskij" <verylonglogin.reg@gmail.com> wrote in message news:jfj92f$m30$1@digitalmars.com...
>
> [OT] Why is that dirty, slow, hard-to-implement, hard-to-understand, and hard-to-write-in (error-prone) HTML used everywhere with it's dirty friend XML?!!! Let's, at least, remove XML support from D as a protest when D will became popular enough! (Sorry, just can't keep it in any more)

For at least a few years now, I've dreamt of creating a *sane* alternative to (X)HTML/CSS that's *ACTUALLY DESIGNED* for UIs instead of documents. The idea is to create a normal standard web browser, and then sneak in this new system as an additional feature - which I figure is about the only way it would have so much as a snowball's chance in hell of ever catching on at all.

Unfortunately, my pet-project plate already resembles that of a one-trip buffet: Piled up, overflowing and more than one person should ever be able to handle.

(I'm hungry...)

== Quote from Denis Shelomovskij (verylonglogin.reg@gmail.com)'s article
[...]
>
https://github.com/D-Programming-Language/d-programming-language.org/blob/master/bugstats.php.dd#L24
> width="48em" height="18em"
> Font size is about 14px so these areas for few digits are very big:
> ~700px x 250px. Opera and Chrome incorrectly displays it as if 1em =
> 1px. Firefox displays correctly (and ugly) unless you rewrite it into
> `width="48.0em" height="18.0em"`.
> So am I missing something? If no, why does Opera, Chrome and Firefox
> incorrectly display such a simple page?
> Why does Andrei use `em` in this case instead of px?

The HTML attributes width and height are not equivalent to the CSS properties of the same names. The HTML attributes are not meant to hold em values. Undefined behaviour fun is the result. Both of the browers' approaches to handle the situation are sensible.

The idea behind using em there is probably to get an iframe that matches the text in height, even if the user agent uses an exotic font-size. However, using an iframe is working against that: The em values refer to the font-size of the context its in, but really you want something proportional to its content. But that's not possible as far as I can tell. Generally, using iframes there is just calling for trouble.

On Monday, 23 January 2012 at 04:09:37 UTC, Daniel Murphy wrote:
> It's probably best to exclude dups from the graph, they don't say much about progress on the lanugage.  Of course this would require deciphering bugzilla's report interface...

That also means the should be excluded from the list of new bugs, I'm not sure how easy it would be to relate them.

On 1/22/12 6:17 PM, Piotr Szturmaj wrote:
> DISPLAY=$(TR $(TD <font color=$3>$(LINK2
> http://d.puremagic.com/issues/buglist.cgi?$2, $1)</font>) $(TD <iframe
> scrolling=no frameborder=0 width="4.8em" height="1.4em"
> style="width:4.8em;height:1.4em;" vspace="0" hspace="0" marginwidth="0"
> marginheight="0"
> src=fetch-issue-cnt.php?$2&format=table&action=wrap&ctype=csv></iframe>))

Did so. On Chrome things look the same. Is there improvement on other browsers?

Thanks,

Andrei

Andrei Alexandrescu wrote:
> On 1/22/12 6:17 PM, Piotr Szturmaj wrote:
>> DISPLAY=$(TR $(TD <font color=$3>$(LINK2
>> http://d.puremagic.com/issues/buglist.cgi?$2, $1)</font>) $(TD <iframe
>> scrolling=no frameborder=0 width="4.8em" height="1.4em"
>> style="width:4.8em;height:1.4em;" vspace="0" hspace="0" marginwidth="0"
>> marginheight="0"
>> src=fetch-issue-cnt.php?$2&format=table&action=wrap&ctype=csv></iframe>))
>
> Did so. On Chrome things look the same. Is there improvement on other
> browsers?

Yes, it fixed Firefox rendering.