Re: website: background color in css

[Arne Babenhauserheide]

Am Sonntag, 15. November 2009 23:17:59 schrieb Arne Babenhauserheide:
> Am Sonntag, 15. November 2009 19:44:57 schrieb Michal Suchanek:
> > They can offer alternate dark and bright themes.
> 
> But that requires setting all colors again.

And thinking your stance a bit further gets us to "each site which either sets 
any foreground text color or uses any image with some overlayed text or any 
image with tranparency has to set all colors". 

That's what I call quite extreme, because it requires almost all sites to 
define all colors. 

Best wishes, 
Arne


signature.asc
Description: This is a digitally signed message part.

Re: website: background color in css

[Arne Babenhauserheide]

Am Sonntag, 15. November 2009 19:44:57 schrieb Michal Suchanek:
> They can offer alternate dark and bright themes.

But that requires setting all colors again. 

It makes it impossible for people to get into webdesign bit by bit - either 
you define all colors or you leave your hands off colorchanges. 

If you set the background, you also have to set all other colors, else the 
custom user color for a visited link could be invisible. 

> Yes, you cannot set just link color and expect it would work. 

Then HTML+CSS is broken, because it allows just that without supplying default 
colors which should be used whenever even a single custom color is set or 
defining a clear way to deal with conflicting colors (invisible/unreadable 
foreground). 

If there's a language which makes it the easiest to change just one detail, 
but which breaks when authors do just that, where's the bug: In the language 
(and implementation) which supplies that default or in the authors who use the 
language in the way in which it is most comfortable for 95% of the authors and 
users? 

(I'm pretty sure that 95% of the users don't use deep blue or red backgrounds, 
and very many pages don't supply a custom background color - including the 
general GNU pages which also have spaces where no background color is defined 
but the text color is defined as a grey). 

I generally try to change as little as possible to get the effect I want (do 
you know how a bright background color hurts late at night when you've been 
working with dark backgrounds for a few hours?)

> So you can either have completely colorless pages 

...and lose the wide range of options you have when you use colors for 
different parts of the text. Since people began using different colors for 
titles, the web looks far more friendly to me. 

> which are based on
> the user style or completely styled pages. Anything in between is
> broken.

Or seen from a different angle: browsers aren't built to handle efficient 
colorchanges (allow authors to set one color by only using the custom color if 
it mixes well with the other colors used for the site). 

In the beginning there was a standard colorscheme (white background, blue 
links, black text). At some point graphic browsers added custom stylesheets, 
so I as user could select to see pages with the colors I chose. 

There the style setting got jarred, because it misses a standard way to react 
to custom author colors which don't work with the custom user scheme. 

So I'd say, in this point you're wrong. If a user wants to use a color scheme 
which doesn't work with many sites, he can tell his browser to ignore the 
sites CSS colors. That shouldn't stop a site author from using a different text 
color which works with most backgrounds, though. 

He can also disable his styling temporarily. 

If you browse my sites with a red background, you're running into a problem, 
that's true. But on the other hand they look good with bright background and 
mostly good with dark background, and they keep their identity, though the 
background color changes. 

What's broken is that I can't say "as long as the background color is in the 
range xx-xx, use red for the text". 

...

But I just found that the reason why some pages look jarred to me is not that 
they define a text color and not a background-color, but that there's a long 
standing konqueror bug which makes konqueror ignore my text color setting and 
use black instead: 
- https://bugs.kde.org/show_bug.cgi?id=47320

Morale of the story: It's good to sign bug reports with wishes, even when the 
wishes aren't easy ones, because one might find similar bug reports which give 
useful additional information :) 


signature.asc
Description: This is a digitally signed message part.

Re: website: background color in css

[Michal Suchanek]

2009/11/15 Arne Babenhauserheide :
> Am Sonntag, 15. November 2009 16:27:13 schrieb Michal Suchanek:
>> Yes, you either set all colors or set none, anything else is broken
>> (as is your web site).
>
> That's a quite extreme view - and mine differs.

It's not extreme. It's based on observed behavior of broken sites such as yours.

>
> I prefer websites which I visit to set colors so they work in both dark and
> bright setting, but I normally don't like to get websites with forced bright
> background.

They can offer alternate dark and bright themes.

For example, http://mplayerhq.hu does.


That's much better than setting a broken style.

>
> Your view would force everyone which uses color for anything to always specify
> the background color explicitely.
>
> So someone who changes the default link color (in html 4.01 you could even do
> that by simply adding link="#159" in the body tag) would have to set the
> background color (and consequently also all other colors, as teh default
> colors might not be compatible with bright background) - and that way most
> people who use the web with dark background would use a custom stylesheet to
> ignore all color settings - and we'd be back at the beginning where we'd have
> a web without custom colors.

Yes, you cannot set just link color and expect it would work. If I
have default background which the same or similar as your link color I
would not be able to see or read your links unless I select them.

There are two kinds of custom colors. User custom colors and author
custom colors. As the authors cannot  know the user's colors nor the
other way around these two do not mix well.

So you can either have completely colorless pages which are based on
the user style or completely styled pages. Anything in between is
broken.

Thanks

Michal

[PATCH 3/3] Update dependency patch

[Guillem Jover]

* config.status.dep.patch: Refresh.
---

This is needed due to AM_SILENT_RULES.

---
 config.status.dep.patch |   34 +-
 1 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/config.status.dep.patch b/config.status.dep.patch
index 871fd77..868737b 100644
--- a/config.status.dep.patch
+++ b/config.status.dep.patch
@@ -1,18 +1,18 @@
 config.status.save 2006-10-09 22:28:47.0 +0200
-+++ config.status  2006-10-09 22:29:34.0 +0200
-@@ -1610,7 +1610,14 @@
-{ (exit 1); exit 1; }; }; }
- 
- # echo "creating $dirpart/$file"
--echo '# dummy' > "$dirpart/$file"
-+# Try to guess what file this dependency file is from...
-+f=$srcdir/`dirname "$fdir"`/`basename "$file" .Po | sed s/lib[^-]\*-//`
-+for f in "$f"*; do
-+  case $f in
-+  *.c | *.S) echo "$f"': $(filter-out $(DIST_SOURCES),$(SOURCES))';;
-+  *) echo '# dummy';;
-+  esac
-+done > "$dirpart/$file"
+--- config.status  2009-10-26 23:57:14.0 +0100
 config.status.new  2009-10-27 00:04:26.0 +0100
+@@ -1553,7 +1553,14 @@
+ s/.*/./; q'`
+   as_dir=$dirpart/$fdir; as_fn_mkdir_p
+   # echo "creating $dirpart/$file"
+-  echo '# dummy' > "$dirpart/$file"
++  # Try to guess what file this dependency file is from...
++  f=$srcdir/`dirname "$fdir"`/`basename "$file" .Po | sed s/lib[^-]\*-//`
++  for f in "$f"*; do
++case $f in
++*.c | *.S) echo "$f"': $(filter-out $(DIST_SOURCES),$(SOURCES))';;
++*) echo '# dummy';;
++esac
++  done > "$dirpart/$file"
+ done
done
- done
-  ;;
+ }
-- 
1.6.5.2

[PATCH 1/3] Add a .gitignore file

[Guillem Jover]

* .gitignore: New file.
---
 .gitignore |   38 ++
 1 files changed, 38 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..fe5d53a
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,38 @@
+.deps
+.dirstamp
+.Tpo
+*.o
+*.a
+*.defs.*
+*.user.*
+*.server.*
+*.info
+*.info-*
+autom4te.cache/
+build-aux/
+mach/
+INSTALL
+Makefile
+Makefile.in
+aclocal.m4
+config.h*
+config.log
+config.status
+config.status.orig
+configure
+gnumach
+gnumach-undef
+gnumach-undef-bad
+gnumach.msgids
+stamp-h1
+stamp-vti
+version.c
+version.texi
+
+i386/i386/i386asm.h
+tests/test-mbchk
+
+# Ignore arch symlinks
+machine
+linux/src/include/asm
+linux/dev/include/asm
-- 
1.6.5.2

[PATCH 0/3] gnumach: Build system fixes

[Guillem Jover]

This serie includes some improvements to the build system. The silent
rules enabled by default will make it easier to see warnings, even if
currently you get easily drown by their quantity. If there's an error
they can be temporarily disabled using “make V=1” or disabled for the
whole build with “configure --disable-silent-rules”. Something I will
be doing in the Debian package so that we get useful build logs.


Guillem Jover (3):
  Add a .gitignore file
  Enable silent builds by default if available
  Update dependency patch

 .gitignore  |   38 ++
 Makefile.am |   12 
 Makefrag.am |4 ++--
 Makerules.am|   16 
 Makerules.mig.am|   24 ++--
 config.status.dep.patch |   34 +-
 configure.ac|3 +++
 7 files changed, 94 insertions(+), 37 deletions(-)
 create mode 100644 .gitignore


regards,
guillem

[PATCH 2/3] Enable silent builds by default if available

[Guillem Jover]

* configure.ac (AM_SILENT_RULES): Add silent rules support if available,
and enable it by defualt.
* Makefile.am (NM_V, NM_V_, NM_V_0): New variables.
(gnumach-undef): Use NM_V in front of NM.
(gnumach-undef-bad): Use AM_V_GEN in front of sed.
(clib-routines.o): Use AM_V_at in fron of undefined symbols check. Use
AM_V_CCLD in front of CCLD.
* Makefrag.am (gnumach.msgids): Use AM_V_GEN in front of cat.
* Makerules.am (AWK_V, AWK_V_, AWK_V_0): New variables.
(%.symc): Use AWK_V in front of AWK.
(%.symc.o): Use AM_V_CC in front of COMPILE.
(%.h): Use AM_V_GEN in front of sed.
(GZIP_V, GZIP_V_, GZIP_V_0): New variables.
(%.gz): Use GZIP_V in front of GZIP.
* Makerules.mig.am (MIGCOM_V, MIGCOM_V_, MIGCOM_V_0): New variables.
(%.server.h %.server.c %.server.msgids): Use MIGCOM_V in front of MIGCOM.
(%.user.h %.user.c %.user.msgids): Likewise.
(%.server.defs.c): use AM_V_GEN in front of command.
(%.user.defs.c): Likewise.
---
 Makefile.am  |   12 
 Makefrag.am  |4 ++--
 Makerules.am |   16 
 Makerules.mig.am |   24 ++--
 configure.ac |3 +++
 5 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index d6fbb54..bc4df2c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -123,6 +123,10 @@ include doc/Makefrag.am
 # Kernel Image
 #
 
+NM_V = $(NM_V_$(V))
+NM_V_ = $(NM_V_$(AM_DEFAULT_VERBOSITY))
+NM_V_0 = @echo "  NM $@";
+
 # We need the following junk because of the include-files-from-libc.a magic.
 # TODO.  Is the following kosher from a Automake point of view?  (I.e. a
 # program `gnumach.o' that is then later used again as an object file.)
@@ -139,15 +143,15 @@ clib_routines := memcpy memmove memset bcopy bzero
\
 udivdi3 __udivdi3  \
 etext _edata end _end # actually ld magic, not libc.
 gnumach-undef: gnumach.$(OBJEXT)
-   $(NM) -u $< | sed 's/  *U  *//' | sort -u > $@
+   $(NM_V) $(NM) -u $< | sed 's/  *U  *//' | sort -u > $@
 MOSTLYCLEANFILES += gnumach-undef
 gnumach-undef-bad: gnumach-undef Makefile
-   sed '$(foreach r,$(clib_routines),/^$r$$/d;)' $< > $@
+   $(AM_V_GEN) sed '$(foreach r,$(clib_routines),/^$r$$/d;)' $< > $@
 MOSTLYCLEANFILES += gnumach-undef-bad
 clib-routines.o: gnumach-undef gnumach-undef-bad
-   if test -s gnumach-undef-bad; \
+   $(AM_V_at) if test -s gnumach-undef-bad; \
then cat gnumach-undef-bad; exit 2; else true; fi
-   $(CCLD) -nostdlib -nostartfiles -r -static \
+   $(AM_V_CCLD) $(CCLD) -nostdlib -nostartfiles -r -static \
  -o $@ `sed 's/^/-Wl,-u,/' < $<` -x c /dev/null -lc -lgcc
 
 gnumach_LINK = $(LD) $(LINKFLAGS) $(gnumach_LINKFLAGS) -o $@
diff --git a/Makefrag.am b/Makefrag.am
index c33a378..9648ece 100644
--- a/Makefrag.am
+++ b/Makefrag.am
@@ -487,8 +487,8 @@ nodist_libkernel_a_SOURCES += \
 MOSTLYCLEANFILES += \
gnumach.msgids
 gnumach.msgids: $(filter %.msgids,$(nodist_libkernel_a_SOURCES))
-   cat $^ > $...@.new
-   mv $...@.new $@
+   $(AM_V_at) cat $^ > $...@.new
+   $(AM_V_GEN) mv $...@.new $@
 # `exec_' prefix, so that we don't try to build that file during when running
 # `make install-data', as it may fail there, but isn't needed there either.
 exec_msgidsdir = $(datadir)/msgids
diff --git a/Makerules.am b/Makerules.am
index 37d383a..eff1405 100644
--- a/Makerules.am
+++ b/Makerules.am
@@ -17,14 +17,18 @@
 # Building foo.h from foo.sym.
 #
 
+AWK_V = $(AWK_V_$(V))
+AWK_V_ = $(AWK_V_$(AM_DEFAULT_VERBOSITY))
+AWK_V_0 = @echo "  AWK$@";
+
 EXTRA_DIST += \
gensym.awk
 %.symc: %.sym gensym.awk
-   $(AWK) -f $(word 2,$^) $< > $@
+   $(AWK_V) $(AWK) -f $(word 2,$^) $< > $@
 %.symc.o: %.symc
-   $(COMPILE) -S -x c -o $@ $<
+   $(AM_V_CC) $(COMPILE) -S -x c -o $@ $<
 %.h: %.symc.o
-   sed < $< > $@   \
+   $(AM_V_GEN) sed < $< > $@   \
  -e 's/^[^*].*$$//'\
  -e 's/^[*]/#define/'  \
  -e 's/mAgIc[^-0-9]*//'
@@ -36,8 +40,12 @@ include Makerules.mig.am
 # gzip files.
 #
 
+GZIP_V = $(GZIP_V_$(V))
+GZIP_V_ = $(GZIP_V_$(AM_DEFAULT_VERBOSITY))
+GZIP_V_0 = @echo "  GZIP   $@";
+
 %.gz: %
-   $(GZIP) -9 < $< > $@
+   $(GZIP_V) $(GZIP) -9 < $< > $@
 
 #
 # strip files.
diff --git a/Makerules.mig.am b/Makerules.mig.am
index b3f76da..2b6b1fe 100644
--- a/Makerules.mig.am
+++ b/Makerules.mig.am
@@ -57,6 +57,10 @@
 # Building RPC stubs.
 #
 
+MIGCOM_V = $(MIGCOM_V_$(V))
+MIGCOM_V_ = $(MIGCOM_V_$(AM_DEFAULT_VERBOSITY))
+MIGCOM_V_0 = @echo "  MIG$@";
+
 # TODO.  Get rid of that stuff, lib_dep_tr_for_defs.a and the four following
 # rules.  See the thread at
 #  about what
@@ -72,20 +76,20 @@ lib_dep_tr_for_defs_a_CPPFLAGS = $(AM_CPPFLAGS) \
-E
 
 %.server.defs.c: %.srv
-   rm -f $@
-   cp -p $< $@
+   $(AM_V_

Re: GNU/Hurd in german news

[Samuel Thibault]

Da Zheng, le Mon 16 Nov 2009 00:57:32 +0800, a écrit :
> Samuel Thibault wrote:
> > Da Zheng, le Sun 15 Nov 2009 12:05:01 +0800, a écrit :
> >> I thought GNOME or KDE couldn't work because Hurd components or libraries 
> >> were still using cthreads instead of pthreads.
> > 
> > I don't see why.  Could you find a post explaining that?
> No, I just heard that GNOME and KDE use pthreads but Hurd components use 
> cthreads. Or maybe it's just my misunderstanding.

That's true, but they live in separate processes, so that's not a
problem.

> If GNOME or KDE uses some Hurd libraries which use cthreads, then it should 
> be a problem.

Yes, but only translators use cthreads.

Btw, a newer iceweasel got build against the newer xulrunner, so it
should be installable again.

Samuel

Re: GNU/Hurd in german news

[Da Zheng]

Hi,

Samuel Thibault wrote:
> Da Zheng, le Sun 15 Nov 2009 12:05:01 +0800, a écrit :
>> I thought GNOME or KDE couldn't work because Hurd components or libraries 
>> were still using cthreads instead of pthreads.
> 
> I don't see why.  Could you find a post explaining that?
No, I just heard that GNOME and KDE use pthreads but Hurd components use 
cthreads. Or maybe it's just my misunderstanding.
If GNOME or KDE uses some Hurd libraries which use cthreads, then it should be 
a problem.
But I'm very unfamiliar with this stuff. I should have written it as a question 
rather than a statement.

Best regards,
Zheng Da

Re: website: background color in css

[Arne Babenhauserheide]

Am Sonntag, 15. November 2009 16:27:13 schrieb Michal Suchanek:
> Yes, you either set all colors or set none, anything else is broken
> (as is your web site).

That's a quite extreme view - and mine differs. 

I prefer websites which I visit to set colors so they work in both dark and 
bright setting, but I normally don't like to get websites with forced bright 
background. 

Your view would force everyone which uses color for anything to always specify 
the background color explicitely. 

So someone who changes the default link color (in html 4.01 you could even do 
that by simply adding link="#159" in the body tag) would have to set the 
background color (and consequently also all other colors, as teh default 
colors might not be compatible with bright background) - and that way most 
people who use the web with dark background would use a custom stylesheet to 
ignore all color settings - and we'd be back at the beginning where we'd have 
a web without custom colors. 

Best wishes, 
Arne


signature.asc
Description: This is a digitally signed message part.

Re: website: background color in css

[Michal Suchanek]

2009/11/15 Arne Babenhauserheide :
> Am Sonntag, 15. November 2009 14:55:09 schrieb Michal Suchanek:
>> You cannot make a site which has no background, has text color set,
>> and expect it to be readable. The default background color may be any
>> color, including the one you chose for some of your text.
>
> You can try to fit the most common cases: bright background and dark
> background.
>
> But you can't fit all use cases when you use absolute color as signifier.
>
> And to my (outdated) knowledge css isn't flexible enough to be able to say
> "color: alternate" or "color: emphasized" (as we can do in the shell).
>
> (that would be really flexible webdesign: first create a color scheme, then
> assign colors to different elements. But currently that only allows us to
> assign a color to , but not to define a standardized color scheme as base
> which browsers can change in a clearly defined way which is compatible accross
> different websites.)
>

Yes, you either set all colors or set none, anything else is broken
(as is your web site).

Thanks

Michal

Re: website: background color in css

[Arne Babenhauserheide]

Am Sonntag, 15. November 2009 14:55:09 schrieb Michal Suchanek:
> You cannot make a site which has no background, has text color set,
> and expect it to be readable. The default background color may be any
> color, including the one you chose for some of your text.

You can try to fit the most common cases: bright background and dark 
background. 

But you can't fit all use cases when you use absolute color as signifier. 

And to my (outdated) knowledge css isn't flexible enough to be able to say 
"color: alternate" or "color: emphasized" (as we can do in the shell). 

(that would be really flexible webdesign: first create a color scheme, then 
assign colors to different elements. But currently that only allows us to 
assign a color to , but not to define a standardized color scheme as base 
which browsers can change in a clearly defined way which is compatible accross 
different websites.)

Best wishes, 
Arne


signature.asc
Description: This is a digitally signed message part.

Re: website: background color in css

[Michal Suchanek]

2009/11/15 Arne Babenhauserheide :
> Am Sonntag, 15. November 2009 01:42:19 schrieb olafbuddenha...@gmx.net:
>> (Not everyone likes reading text on a white background! It regularily
>> makes my eyes hurt. I wonder what morons created the myth that it would
>> be more ergonomic :-( )
>
> I currently read with a dark grey background, but when I have the option of
> black on dark grey or black on white, I prefer black on white.
>
> The problem is, that we can't easily avoid the black font color (except by
> using color for the text as I do for autoparsed static sites and my main
> website
> - http://1w6.org/rpg_logs/sskreszta/Sskreszta-log-notizen-2009-05-03.html
> - http://draketo.de/licht-lumo-light
>
> Both are readable with dark and white background, but the price to pay is that
> the font is colored - which some people might dislike.
>

You cannot make a site which has no background, has text color set,
and expect it to be readable. The default background color may be any
color, including the one you chose for some of your text.

Thanks

Michal

Re: GNU/Hurd in german news

[Samuel Thibault]

Da Zheng, le Sun 15 Nov 2009 12:05:01 +0800, a écrit :
> I thought GNOME or KDE couldn't work because Hurd components or libraries 
> were still using cthreads instead of pthreads.

I don't see why.  Could you find a post explaining that?

> Has porting these components to pthreads been done?

The components I can think of are libtriv/net/diskfs & such, the work
hasn't been done but Gnome/KDE doesn't use them.

Samuel

Re: OT: automation

[Arne Babenhauserheide]

Hi, 

Am Samstag, 14. November 2009 23:38:21 schrieb olafbuddenha...@gmx.net:
> That's where the Hurd comes in: with the extensible VFS, it's possible
> for every component to offer a filesystem interface that can be used
> by other components, by external scripts, or even by users directly.
> That's a much more transparent, convenient, and universal interface --
> and thus offers an approach to modularity that actually could work for a
> change :-)

How about a server which exposes dbus interfaces via the filesystem to give 
instant benefit for dbus-enabled programs? 

Would that be doable? 

Best wishes, 
Arne


signature.asc
Description: This is a digitally signed message part.

Re: OT: automation

[Arne Babenhauserheide]

Am Samstag, 14. November 2009 23:57:07 schrieb olafbuddenha...@gmx.net:
> > find -print0 | shuf -z | xargs -0 mplayer
> >
> > I can't control the mplayer from the shell now...
> 
> Problem is that xargs doesn't reset stdin -- not only xargs, but also
> the actual program exectuted reads from the pipe... Which obviously
> doesn't work to well with interactive programs. (I stumbled over this a
> few times myself with vim.)
> 
> I don't know how to work around this either :-(

Damn. I had hoped I could completely replace my script by an alias... 

> > How can you best reach that goal?
> 
> What goal exactly?...

Having a gui and a cli interface to every command. 

Best wishes, 
Arne


signature.asc
Description: This is a digitally signed message part.

Re: website: background color in css

[Arne Babenhauserheide]

Am Sonntag, 15. November 2009 01:42:19 schrieb olafbuddenha...@gmx.net:
> (Not everyone likes reading text on a white background! It regularily
> makes my eyes hurt. I wonder what morons created the myth that it would
> be more ergonomic :-( )

I currently read with a dark grey background, but when I have the option of 
black on dark grey or black on white, I prefer black on white. 

The problem is, that we can't easily avoid the black font color (except by 
using color for the text as I do for autoparsed static sites and my main 
website
- http://1w6.org/rpg_logs/sskreszta/Sskreszta-log-notizen-2009-05-03.html 
- http://draketo.de/licht-lumo-light

Both are readable with dark and white background, but the price to pay is that 
the font is colored - which some people might dislike. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- 
Unpolitisch sein
heißt politisch sein, 
ohne es zu merken. 
- Arne (http://draketo.de)
--- --- --- --- --- --- --- --- --- 



signature.asc
Description: This is a digitally signed message part.