Re: *** SPAM *** Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

View: New views
10 Messages — Rating Filter:   Alert me  

Re: *** SPAM *** Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

by Nicolas Mailhot :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Le Jeu 18 octobre 2007 22:17, Tuomo Valkonen a écrit :
> On 2007-10-18 21:43 +0200, Nicolas Mailhot wrote:
>> FOSS needs to exchange data with other systems (internet remember?).
>> That means sharing encoding conventions.
>
> The internet (HTML) actually does let one specify encoding used,

Data exchange on the internet is more than HTML and besides at least
20% of the HTML pages I see everyday have broken encoding
specification (The W3C spec states plainly encoding must not be
assumed to be ISO-8859-1, change your browser fallback encoding to
anything else and watch the breakage)

>> It's a pity the W3C didn't go the full
>> way and allowed to specify something else – non-UTF-8 XML files win
>> you
>> nothing and are a constant source of bugs.
>
> Uhhh? It wants you to specify encoding in the header tag,

The XML spec does not "want" you to specify encoding, specifying it is
optional, and my experience is any system or person that sets it to
something other than UTF-8 is making an encoding mistake somewhere in
the file.

>> That's a result of trying to cater to every known human script.
>> Which
>> needs to be done to digitalise existing stuff. No one so far has
>> proved
>> it could be done better.
>
> Unicode contains a lot of stuff that really doesn't belong in a
> low-level character mapping -- Unicode it doesn't even really know
> what it is. Much of the maths stuff, for example, is pointless to
> have there,  and should be handled with different fonts in some
> contexts,

Spare me, I've already seen enough dead documents that relied on
special fonts to be read. Math symbols need to be clearly specified
like everything else.

> and at a much higher level in other contexts. Then
> there's the accent duplication fuckup, etc., as a consequence
> you have various normalisation form complications. (Yes, although
> the sound is the same, Finnish ä actually is not in some semantic
> sense the same as German ä. In former it is a proper letter,
> whereas in the latter it is umlauted a. Unicode perhaps
> unintentionally provides both

It is very intentional since people and apps create accented letters
both ways, and round-trip encoding conversions require remembering how
the letters were created.

> -- a separate codepoint, and a
> a combined character -- which complicates many matters a lot,
> and the distinction seems to me to be relevant only at a much
> higher semantic level than Unicode probably should be.

It's not a semantic but a technical distinction.

> Composition
> is the more general approach, so I think it should've been chosen.)

That would be fine if we started with a clean sheat, but then we'd all
be writing esperanto or something like that.

> I think the Chinese have also expressed that the handling of their
> writing system in Unicode is totally fucked up,

The Chinese and Japanese complain they've been conflated, and they
just have to sort it between themselves and suggest unicode changes,
instead of waiting for westerners to do it for them.

> and should be more based on composition,

That's your beef, not what Chinese complain about

> which would safe code points. And so
> on. A lot could be improved,

And in case you haven't noticed it we're at Unicode 5 now and the
standard is being continualy revised and fixed. And maybe if the
points you don't like haven't been changed there's more to them than
you think.

> but settling on a monoculture will
> make it very difficult -- practically impossible.

You can complain of monoculture but there is zero alternative to the
Unicode.org consortium today and people who've looked at the problem
seriously are more than happy to let it handle the mess human scripts
are.

--
Nicolas Mailhot
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

by Tuomo Valkonen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 2007-10-19, Nicolas Mailhot <nicolas.mailhot@...> wrote:
> Data exchange on the internet is more than HTML and besides at least
> 20% of the HTML pages I see everyday have broken encoding
> specification (The W3C spec states plainly encoding must not be
> assumed to be ISO-8859-1, change your browser fallback encoding to
> anything else and watch the breakage)

Email etc. also specify the encoding. It's been a while since I've
seen an email with broken encoding spec., since the newer MUAs tend
to do that instead of the user trying to figure it out. Likewise,
editors should tag files by the encoding they store them in, instead
of the user trying to provide that information.

> Spare me, I've already seen enough dead documents that relied on
> special fonts to be read. Math symbols need to be clearly specified
> like everything else.

I'm speaking of stuff like blackboard bold letters. They really demand
a blackboard bold font, but Unicode includes some of them as special
codepoints. Likewise a few superscript- and subscript symbols are
absolutely mindless. Then there's stuff like double- and triple-
integrals,which is really equal to including 'ff' ligatures and
other such low-level typesetting stuff. There are even different
sizes of operators. Far too detailed. And so on. Maths is written
in LaTeX.

>> Composition
>> is the more general approach, so I think it should've been chosen.)
>
> That would be fine if we started with a clean sheat, but then we'd all
> be writing esperanto or something like that.

What does the language or how people wrote the character matter? It's
just a _glyph_ outside any context that actually tells it's the document
is in some particular language. And in that case there's higher-level
information to tell how to interpret the glyphs. Having many codepoints
that produce the same glyph creates a lot of confusion and troubles in
contexts where such information is not available.

> That's your beef, not what Chinese complain about

>From what I've read, that's exactly what they complain about.

> You can complain of monoculture but there is zero alternative to the
> Unicode.org consortium today and people who've looked at the problem
> seriously are more than happy to let it handle the mess human scripts
> are.

Yepyep, people once again want a global regime that tells other people
how they should do things; a monoculture to be fed down everyone's
throats, with no possibility for alternatives. That's the trend in
everything.

--
Tuomo

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

by Russell Shaw :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Tuomo Valkonen wrote:

> On 2007-10-19, Nicolas Mailhot <nicolas.mailhot@...> wrote:
>> Data exchange on the internet is more than HTML and besides at least
>> 20% of the HTML pages I see everyday have broken encoding
>> specification (The W3C spec states plainly encoding must not be
>> assumed to be ISO-8859-1, change your browser fallback encoding to
>> anything else and watch the breakage)
>
> Email etc. also specify the encoding. It's been a while since I've
> seen an email with broken encoding spec., since the newer MUAs tend
> to do that instead of the user trying to figure it out. Likewise,
> editors should tag files by the encoding they store them in, instead
> of the user trying to provide that information.

One advantage of unicode encoding is that every character has the
same meaning independant of any tag things. That makes it easy to
cut and paste multilingual text between applications without any
out-of-band communication of encoding tags. This statelessness
is the most worthwhile advantage IMO. UTF-8 could be considered
a common inter-app encoding protocol, and apps can use whatever
encoding they want internally.

...
snip
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

by Tuomo Valkonen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 2007-10-19, Russell Shaw <rjshaw@...> wrote:
> One advantage of unicode encoding is that every character has the
> same meaning independant of any tag things. That makes it easy to
> cut and paste multilingual text between applications without any
> out-of-band communication of encoding tags. This statelessness
> is the most worthwhile advantage IMO. UTF-8 could be considered
> a common inter-app encoding protocol, and apps can use whatever
> encoding they want internally.

That's up to for individual protocols to specify, or (preferrably)
not specify. A single protocol is in any case easier to ugprade to
a better encoding than a global monoculture. Applications hardly
can use whatever encoding they want to use internally if libraries
force a monoculture. The best approach is abstraction, an encoding
blackbox, but such a fundamental tenet of good software design
tends to not be appreciated these days, because any possibility for
alternatives is a big no-no. Megalomaniac rigid and bureaucratic
structures are in.

--
Tuomo

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

by Russell Shaw :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Tuomo Valkonen wrote:

> On 2007-10-19, Russell Shaw <rjshaw@...> wrote:
>> One advantage of unicode encoding is that every character has the
>> same meaning independant of any tag things. That makes it easy to
>> cut and paste multilingual text between applications without any
>> out-of-band communication of encoding tags. This statelessness
>> is the most worthwhile advantage IMO. UTF-8 could be considered
>> a common inter-app encoding protocol, and apps can use whatever
>> encoding they want internally.
>
> That's up to for individual protocols to specify, or (preferrably)
> not specify. A single protocol is in any case easier to ugprade to
> a better encoding than a global monoculture. Applications hardly
> can use whatever encoding they want to use internally if libraries
> force a monoculture.

I see what you mean now. That ceased being a problem for me when
i stopped using woeful FOSS stuff and wrote my own. The larger
community still needs better libraries.

> The best approach is abstraction, an encoding
> blackbox, but such a fundamental tenet of good software design
> tends to not be appreciated these days, because any possibility for
> alternatives is a big no-no. Megalomaniac rigid and bureaucratic
> structures are in.

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

by Nicolas Mailhot :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Tuomo,

You're advocating a lot of code churn and backwards-incompatible
changes for what? There is no practical alternative encoding to UTF-8
today. Do you really think people are going to change and rewrite all
the huge existing code base just in case some hypothetical alternative
to UTF-8 emerges one day? (and make no mistake, new code reuses old
code so changing only new code to take encoding into account is
useless)

No one but developers having to deal with unicode complexities mourn
the pile of pre-unicode encoding standards. They didn't work. With or
without encoding tagging. They sort-of worked with single-language
single-script users that never communicated with people outside their
language bubble but that's not what people needed 50 years ago and
that's even less what they need today (globalized world, remember?).
They are not a credible alternative to unicode, never been and never
will be.

And no one is working on a unicode alternative today. Even if someone
was it took decades for the unicode consortium to arrive at the state
you complain of. This is gigantic work. Unicode.org happened because
an international encoding was sorely needed, now there is one (not
pretty but good enough and getting better) I don't seen anyone
investing the same decades of work in something that may or may not
end up less quirky.

If you don't like the unicode consortium choices, and are not willing
to rectify them from within this organisation, found your alternative
organisation and propose a workable alternative to UTF-8. And then
people may see the usefulness of not targeting an unicode monoculture.

But as long as there is effectively a single working international
encoding standard in the world, people will target it exclusively, and
that's not because they are dumb that's because they have other things
on their plate than preparing for something that may or may not happen
in their lifetime. It's totally useless to complain at them unless you
have a workable UTF-8 alternative hidden in your pocket.

--
Nicolas Mailhot
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

by Nicolas Mailhot :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Le Ven 19 octobre 2007 14:03, Tuomo Valkonen a écrit :
> The
> architecture needed to support a potential new encoding is just
> basic good software design.

Good design is not wasting time supporting potentials. Nothing you've
written so far remotely hints anything but UTF-8 will exist mid or
even long term. So why bother? Might as well count the number of
angels that fit on the point of a needle.

--
Nicolas Mailhot
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

by Tuomo Valkonen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 2007-10-19, Nicolas Mailhot <nicolas.mailhot@...> wrote:
> Good design is not wasting time supporting potentials.

Since when has rigid monolithic and non-modular design has
been considered good? Oh, wait! Ever since Linus wrote his
shoddy kernel.

--
Tuomo

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

by Frederic Crozat :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Le vendredi 19 octobre 2007 à 12:29 +0000, Tuomo Valkonen a écrit :
> On 2007-10-19, Nicolas Mailhot <nicolas.mailhot@...> wrote:
> > Good design is not wasting time supporting potentials.
>
> Since when has rigid monolithic and non-modular design has
> been considered good? Oh, wait! Ever since Linus wrote his
> shoddy kernel.

Please, continue this thread in private, it doesn't belong to this
mailing list.

--
Frederic Crozat <fcrozat@...>
Mandriva

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

by Russell Shaw :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Tuomo Valkonen wrote:
> On 2007-10-19, Nicolas Mailhot <nicolas.mailhot@...> wrote:
>> Good design is not wasting time supporting potentials.
>
> Since when has rigid monolithic and non-modular design has
> been considered good? Oh, wait! Ever since Linus wrote his
> shoddy kernel.

I found the biggest flaw in most FOSS is: developers think satisfying
90% is good enough.

However, after only 21 of these points have been encountered, 90% of
users will be dis-satisfied by *something*.

It's why desktop linux will never feel right for *anyone* but a few
developers and very unsophisticated users.

I didn't move to linux for this, so i neither use kde or gnome.

Good design has *scalability* so that even if only 90% of users
are satisfied, the capability is already there to satisfy 100% of
users.

Only with that attitude can you make a larger more complex system
and still hope to satisfy 100% of users.

To achieve this sort of scalability, a lot more parser and compiler
techniques should be employed, but i find any decent know-how in this
area the most lacking in FOSS.
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list