[dev] ideas on suckless file manager
Le Tian
--
Tian
Dieter Plaetinck
ranger is quite okay.
http://ranger.nongnu.org/
though it's limited by the typical shell/terminal limitations we've
talked about earlier (i.e. previewing images is done with an
external tool, which uses inefficient conversion to vague
escape-character-based terminal sequences)
Dieter
Jakub Lach
I'm waiting for suckless BonziBUDDY.
pancake
Many years ago i wrote 'canoe' a lightweight filemanager in gtk. I did it for the n770.. So clicking on icons is better than Using the shitty onscreen keyboard that n770 had
It has some segfaults, and supports icon themes and virtual filesystems implemented in shellscript.
Check out the source as always in my http://hg.youterm.com/canoe repo
Rob
I like rox, I used to use thunar but it stopped loading thumbnails,
which is the only reason I use a file manager, so I switched. IMO, rox
without all the desktop-panel extras is good enough. When not looking at
thumbnails though, coreutils do the job fine.
Le Tian
Tian
Connor Lane Smith
On 7 June 2011 15:53, Le Tian <tian...@gmail.com> wrote:
> There are occasions, when u need to see or show some lovely icons.
With the exception of image thumbnails, icons are really completely pointless.
On 7 June 2011 16:17, Le Tian <tian...@gmail.com> wrote:
> like a girlfriend, she needs icons and stuff
Yeah, it's well-known that females can't read, and rely on pictures
instead... No, don't be silly, she doesn't need icons, people
unfamiliar with shells just find the terminal intimidating. Once they
get over that fear it's really no problem. (I find inverting the
colours actually helps to a worrying degree.)
My thoughts on a suckless file manager, though my file manager is 'ls':
Orthodox: two paned, plus command line. At compile time you just
define commands like,
{ CTRL('m'), "mv $+ $@" }
You select a bunch of files on the left, navigate to a directory on
the left, and hit C-m. Simple, effective. It's not amazing, but it
would do its job.
cls
Le Tian
pancake
pancake
v4hn
> Yes, icons are not efficient, but there are cases, when not only you will
> use the pc, like a girlfriend, she needs icons and stuff). I think it's a
> bad habit of a windows user, to see everything in rows of thumbs. But still
> like clicking a video file with a mouse in a file manager, when editing
> happens only in console.
If your girlfriend uses your pc and got problems with suckless/non-bloated
software then get her a parallel setup of debian/arch/.. with a nice KDE/Gnome.
(works quite fine over here ;))
v4hn
pancake
Bjartur Thorlacius
> What's phycology?
>
> Oh, well.. Wikipedia informs: "the scientific studies of algae"
>
Jakub Lach
> What's phycology?
> Oh, well.. Wikipedia informs: "the scientific studies of algae"
Hey! Just because they can't use terminal does not mean
they're algae. That could be somebody's mother you
know.
Le Tian
Tian
Benjamin R. Haskell
> On Tue, Jun 7, 2011 at 11:25 AM, Connor Lane Smith wrote:
>
>> [...] (I find inverting the colours actually helps to a worrying
>> degree.)
>>
>>
> Interesting... Yeah, "I find inverting the colours actually helps to a
> worrying degree." I think this should be a default in all linux
> distros, due a phycological factor.)
Inverting the colors = light text on dark background?
And the dark background is less scary? I'd have expected the opposite,
but maybe I've been conditioned by movies to think that dark terminals
are 'leet'. To me, light backgrounds feel warmer and more natural, dark
ones feel more cold and mechanical.
--
Best,
Ben
Le Tian
--
Tian
Connor Lane Smith
> > And the dark background is less scary? I'd have expected the opposite
>
Indeed. This is how it is in Plan 9 and OS X, too. I used
dark-on-light for a while, actually, and it just didn't feel right.
Maybe I'm just used to light-on-dark. (I usually use greys on either
extreme.)
People who use green on black, on the other hand... -.-;
cls
pancake
Andreas Wagner
https://bbs.archlinux.org/viewtopic.php?id=66662&p=1
Hootiegibbon
On 7 Jun 2011 18:45, "Andreas Wagner" <andreas...@gmail.com> wrote:
I like dmenfm (dmenu based file manager):
https://bbs.archlinux.org/viewtopic.php?id=66662&p=1
On Tue, Jun 7, 2011 at 10:53 AM, Le Tian <tian...@gmail.com> wrote:
> Continuing these threads abo...
Hootiegibbon
Ok the last mail to the list,is proof that all smartphones suck...
What are the thoughts on 'pilot ' alpones file manager (its available as a standalone app iirc)
Jase
On 7 Jun 2011 20:29, "Hootiegibbon" <hootie...@gmail.com> wrote:
> On 7 Jun 2011 18:45, "Andreas Wagner" <andreas...@gmail.com> wrote:
>
> I like dmenfm (dmenu b...
Ethan Grammatikidis
Rob <robpi...@gmail.com> wrote:
> I like rox, I used to use thunar but it stopped loading thumbnails,
> which is the only reason I use a file manager, so I switched. IMO, rox
> without all the desktop-panel extras is good enough. When not looking at
> thumbnails though, coreutils do the job fine.
I wouldn't have thought of mentioning it on this list but if it's thumbnails you're after, I found Eagle Mode hard to beat. It's a medium-large C++ app but navigation is far faster than with any other file manager I've ever used and the file manager buttons all run simple Perl scripts. (Actually I think they can use any interpreter.) You can zoom right into pictures which is useful in cases where the thumbnail isn't so helpful.
As well as pictures it displays text files, although I don't find the columnar layout easy to navigate. Still, I've had quite a bit of use out of this feature.
The biggest problem is it's not so hot if you have a very large number of pictures in one dir; using it becomes less efficient. Conversely it can be good with extremely long text files.
It's also good for unpacking archives, I much prefer its zoom-to-unpack to mucking about with tar (or especially zip,) although it's not as clean as p9's `hget url | gunzip | tar -x`.
Noah Birnel
> With the exception of image thumbnails, icons are really completely pointless.
>
> My thoughts on a suckless file manager, though my file manager is 'ls':
>
> Orthodox: two paned, plus command line. At compile time you just
> define commands like,
> { CTRL('m'), "mv $+ $@" }
> You select a bunch of files on the left, navigate to a directory on
> the left, and hit C-m. Simple, effective. It's not amazing, but it
> would do its job.
>
Can of worms. There's always another damn command, or another archive
format. And the user must learn what is essentially another shell.
I was looking for a tolerable file manager for a long time, and found
nothing fast and simple enough - lfm was closest. I realized that
from the shell, all I (occaisionally) miss in an fm is the ability to
quickly select an arbitrary group of files to operate on. Not scriptable
/ machine stuff like
mv chapter-[0-9][0-9].pdf dest/
but human stuff like
mv chapter-02.pdf chapter-16.pdf appendix.pdf dest/
Obviously tab-completion makes that quick and easy, but for longer lists my
non-fm solution is a little tedious:
ls >listing && vim listing && mv `cat listing` dest
So a suckless file manager would maybe throw away the whole file manager
concept and have a sort of dmenu-like multiple file selector? I suppose
zenity could do this, but it's hardly suckless.
Proposed man page snippets:
NAME
sfm -- suckless file manager
SYNOPSIS
sfm [-av] [directory]
DESCRIPTION
sfm pops up a dmenu-like selector where multiple filenames can be
selected and printed to standard out. Click or tab selects, Esc
cancels, return submits.
By default sfm shows the current directory and does not show
dotfiles.
Example of use would be:
mv `sfm` dest_dir/
--Noah
Patrick Haller
> ls >listing && vim listing && mv `cat listing` dest
define $EDITOR then ^x^e
Patrick
Petr Sabata
> If you need thumbs use an image viewer. Gqview works quite well for this.
>
sxiv is my image viewer of choice, currently...
http://github.com/muennich/sxiv
--
# Petr Sabata
Patrick Haller
yeah, edit the current command using $EDITOR
file manager
= file selection + file (pre)viewing
= ls/awk/$EDITOR + i_give_my_files_retarded_names
=> fix your naming convention
Patrick
pancake
it's 2088LOC..but it's config.h friendly, simple, clean and fast. x))
thanks for noticing, im gonna package it in slpm
pancake
> I like dmenfm (dmenu based file manager):
>
> https://bbs.archlinux.org/viewtopic.php?id=66662&p=1
- it's bash, should be rewritten to be posix
- there's spaguettis in the file opening code
- doesnt honor default unix environ (EDITOR...)
- dinamic configuration of dmenu colors is just sucky
those changes will make dmenfm much more simpler and clean.
--pancake
Nick
> It's also good for unpacking archives, I much prefer its zoom-to-unpack to mucking about with tar (or especially zip,) although it's not as clean as p9's `hget url | gunzip | tar -x`.
you know you can do something like
`curl url | zcat | tar x` or `wget -O - url | zcat | tar x`
on any respectable unix variant, right?
Yoshi Rokuko
>
> White background terminals harm my eyes.
>
> I cant think on anybody spending lot of time on a white background terminal.
> Its anti natural.
>
no for me it is not, i'm using black on white for a long time now:
UXTerm*foreground: black
UXTerm*background: white
UXTerm*cursorColor: red
UXTerm*font: -*-terminus-medium-r-*-*-16-*-*-*-*-*-*-*
Troels Henriksen
> So a suckless file manager would maybe throw away the whole file manager
> concept and have a sort of dmenu-like multiple file selector?
This patch may be useful: http://tools.suckless.org/dmenu/patches/multiselect_and_newline
--
\ Troels
/\ Henriksen
Yoshi Rokuko
thank you for pointing out - i immediately�switched from
feh to sxiv it's so much better and tiling friendly ...
ilf
>> sxiv is my image viewer of choice, currently...
>> http://github.com/muennich/sxiv
I use feh only for --bg-center, any way to do that with sxiv?
--
ilf
Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung
pancake
> On 06-08 11:23, Yoshi Rokuko wrote:
>>> sxiv is my image viewer of choice, currently...
>>> http://github.com/muennich/sxiv
>> thank you for pointing out - i immediately?switched from feh to sxiv
>> it's so much better and tiling friendly ...
>
> I use feh only for --bg-center, any way to do that with sxiv?
>
write an ssetroot or so linking against imlib2 and allowing opaque
colors like xsetroot does..
but well.. changing the background is not something we do everyday
unless you have any kind of mental disease..so probably we can just
embed the jpg/gif/png inside the same program at compile time. So load
time is much shorter because it just have to dump the buffer to X, no
need to uncompress or so. and if we place the image buffer aligned in
memory it should load even faster.
What do you think?
you can configure an sxiv keybinding to compile "ssetroot" with the
given image and execute it.
anybody wanna write a PoC?
--pancake
Bert Münnich
> On 06/08/11 11:49, ilf wrote:
> >On 06-08 11:23, Yoshi Rokuko wrote:
> >>>sxiv is my image viewer of choice, currently...
> >>>http://github.com/muennich/sxiv
> >>thank you for pointing out - i immediately?switched from feh to
> >>sxiv it's so much better and tiling friendly ...
> >
> >I use feh only for --bg-center, any way to do that with sxiv?
> >
> i dont think this is a task for an image viewer. we should probably
> write an ssetroot or so linking against imlib2 and allowing opaque
> colors like xsetroot does..
I second this. I will not add any bg setting routine to sxiv.
> but well.. changing the background is not something we do everyday
> unless you have any kind of mental disease..so probably we can just
> embed the jpg/gif/png inside the same program at compile time. So
> load time is much shorter because it just have to dump the buffer to
> X, no need to uncompress or so. and if we place the image buffer
> aligned in memory it should load even faster.
>
> What do you think?
In the meantime, have a look at imlibsetroot:
http://robotmonkeys.net/2010/08/03/imlibsetroot-1-3/
Bert
Andrew Hills
> changing the background is not something we do everyday unless
> you have any kind of mental disease..
I like to change my background to a random color every 2-10ms; it's
easier on the eyes than the plain black I used formerly, especially
with my transparent terminals.
--Andrew Hills
Mate Nagy
Bryan Bennett
>easier on the eyes than the plain black I used formerly, especially
>with my transparent terminals.
I hate to say it but this makes some sense. However, the tools to
use to get it right are already around (cron+xsetroot+sh), so I
would ignore this corner usecase.
pancake
>> I like to change my background to a random color every 2-10ms; it's
> http://dagobah.net/flash/epilepsy-with-nice-music.swf
>
Noah Birnel
> file manager
> = file selection + file (pre)viewing
> = ls/awk/$EDITOR + i_give_my_files_retarded_names
> => fix your naming convention
>
all of the files you see fit a universal naming scheme that is machine
sortable across all interesting selections? I wonder why your computer
needs you at all, once you've written a script for it to solipsisticly
touch, sort, and unlink rationally named files.
--Noah
Kurt H Maier
> Really? You never work with files created and named by other people? And
> all of the files you see fit a universal naming scheme that is machine
> sortable across all interesting selections? I wonder why your computer
> needs you at all, once you've written a script for it to solipsisticly
> touch, sort, and unlink rationally named files.
it is impossible to rename a file
--
# Kurt H Maier
Corey Thomasson
O wow, I definitely missed the sarcasm here, was about to say
> rename(2) ?
I must be tired.
Noah Birnel
> it is impossible to rename a file
Har. Yes, sometimes I want to to rename some arbitrarily named files.
ilf
>> i dont think this is a task for an image viewer. we should probably
>> write an ssetroot or so linking against imlib2 and allowing opaque
>> colors like xsetroot does..
Yay!
>> but well.. changing the background is not something we do everyday
>> unless you have any kind of mental disease..
My background is set in .xinitrc, and I start (and quit) X several times
a day.
> In the meantime, have a look at imlibsetroot:
> http://robotmonkeys.net/2010/08/03/imlibsetroot-1-3/
"imlibsetroot is pretty much Esetroot, but *much* more feature rich."
http://robotmonkeys.net/2010/03/30/imlibsetroot/
Mate Nagy
On Wed, Jun 08, 2011 at 08:40:48PM +0200, ilf wrote:
> On 06-08 12:13, Bert M�nnich wrote:
> >>i dont think this is a task for an image viewer. we should
> >>probably write an ssetroot or so linking against imlib2 and
> >>allowing opaque colors like xsetroot does..
one scenario: if it finally had decent support for xinerama. Because
currently there is _no_ _such_ _thing_.
regards,
Mate
Ethan Grammatikidis
pancake <pan...@youterm.com> wrote:
> White background terminals harm my eyes.
>
> I cant think on anybody spending lot of time on a white background terminal. Its anti natural.
I've been through a lot of (old) screens and I have to say it depends on screen and font.
Still, I really don't think full brightness white should be used for anything other than image highlights, but it's far too late to convert the world to that.
Ethan Grammatikidis
zcat isn't quite so clean as having gunzip work properly in a filter, but yeah.
Incidentally, I compared executable sizes of curl wget and p9p hget the other day, finding hget to be larger than curl. Maybe it's the p9p libs, but Plan 9 hget is about as large.
Connor Lane Smith
> Incidentally, I compared executable sizes of curl wget and p9p hget the other day, finding hget to be larger than curl. Maybe it's the p9p libs, but Plan 9 hget is about as large.
P9P executables are huge. It's ridiculous. I suspect the reason P9's
hget is a similar size is that it is statically linked?
cls
Suraj N. Kurapati
> On Tue, 7 Jun 2011 19:09:25 +0200 pancake wrote:
> > White background terminals harm my eyes.
> >
> > I cant think on anybody spending lot of time on a white
> > background terminal. Its anti natural.
>
> I've been through a lot of (old) screens and I have to say it
> depends on screen and font.
I agree. Newer trends, like the Solarized color scheme[1], seem to
favor thick fonts with supplemental anti-aliasing, such as DejaVu
Sans Mono. Using bitmapped and inherently aliased fonts, such as
Tamsyn[2], with such color schemes is not as good[3]. Instead, I
find that they are much easier to read on a dark background[4].
[1]: http://ethanschoonover.com/solarized
[2]: http://www.fial.com/~scott/tamsyn-font/
[3]: http://ompldr.org/vOHo2Nw
[4]: http://ompldr.org/vOHo2YQ
--
E Pluribus Unix
Ethan Grammatikidis
If I may say so on brief acquaintance with it, that's a well-made bitmap font, that is.
Ethan Grammatikidis
It is statically linked. P9P execs are statically linked with the P9P libraries too.
Suraj N. Kurapati
> On Wed, 8 Jun 2011 13:50:14 -0700 "Suraj N. Kurapati" wrote:
> > [2]: http://www.fial.com/~scott/tamsyn-font/
>
> If I may say so on brief acquaintance with it, that's a well-made
> bitmap font, that is.
Indeed, Tamsyn is the fairest monospaced font of them all, IMHO. :-)
--
Systems programmers are the high priests of a low cult.
-- R.S. Barton
Petr Sabata
ilf
Been using that for a while. Doesn't do it for me with rxvt-unicode
9.09 any more, because it doesn't set XROOTPMAP on the root window. Too
busy to fix.
hiro
Connor Lane Smith
> The Tamsyn guy says it's an "aliased font". What does it mean?
It means it isn't anti-aliased.
Nice font, btw.
cls
Ethan Grammatikidis
hiro <23h...@googlemail.com> wrote:
> The Tamsyn guy says it's an "aliased font". What does it mean?
It's not, but it has some overlap in places which makes it look smoother.
Ethan Grammatikidis
My bad, I thought he said "anti-aliased". I'm not sure "aliased" is quite an appropriate word for a font since it's the display which does the aliasing by virtue of its pixellated nature.
Eckehard Berns
He means it's not anti-aliased. See also
http://en.wikipedia.org/wiki/Aliasing
--
Eckehard Berns
hiro
> I'm not sure "aliased" is quite an appropriate word for a font since it's the display which does the aliasing by virtue of its pixellated nature.
I think neither would be appropriate because in the artistic task of
creating the font each pixel was put there by purpose. A chess board
is not aliased either just because it has a grid.
I agree that anti-aliased stuff at 100dpi isn't sharp enough, I'm
mostly using the olde hinted Microsoft fonts.
Suraj N. Kurapati
> The Tamsyn guy says it's an "aliased font". What does it mean?
Here's a reply from the author of Tamsyn regarding this matter:
Begin forwarded message:
Date: Thu, 09 Jun 2011 14:04:43 -0700
From: Scott Fial <sc...@fial.com>
To: "Suraj N. Kurapati" <sun...@gmail.com>
Subject: Re: Tamsyn font - aliased or smoothed?
Hi Suraj,
Now that I'm done I realize that I've written more than this subject
probably deserves, but its close to my heart so bear with me.
To be honest, I'm no expert in fonts or the terminology. I'm just
some guy and somehow this font became my hobby. It seems the words
"aliased" and "anti-aliased" have meaning beyond my simplistic
interpretation. I naively used the term "aliased" to mean: not
anti-aliased, hinted, or smoothed in any way. But that's because I
vaguely equate "anti-aliasing" with the blurring and blending of a
font to smooth the jagged edges. And if that's the case, then the
jagged edges must be the "aliasing" (right?) since the true curves
and angles of each character can't be represented perfectly as
pixels. Such was my logic. Its a vector font in my mind; I have a
mental picture of the true shape of each character, but I'm faced
with aliasing effects as I try to represent that shape as pixels.
The fun comes in finding designs which look nice given that
constraint while avoiding as much of the resulting visual "static"
as possible.
The point I'm trying to make on the web page is that the font will
look the same wherever you use it and has no dependency on
sophisticated font rendering technologies. So, given all that I've
said here, what *is* the term I should be using to describe this
kind of font? I want the web page to be correct. Please put it to
your forum and let me know if anyone has the answer.
thanks,
Scott
On 6/9/2011 9:07 AM, Suraj N. Kurapati wrote:
> Hello,
>
> There has been some discussion on whether Tamsyn is "aliased"
> here:
>
> http://thread.gmane.org/gmane.comp.misc.suckless/6178
>
> I thought you'd like to comment on this to clarify your
> definition, or perhaps revise your description on the Tamsyn
> homepage accordingly.
>
> Cheers.
>
> P.S. Many thanks for Tamsyn: it's the best monospaced font ever! :-)
--
hiro
but idiotic as it might sound the only technically clear term is
really "not antialiased".
I guess I (we?) should get a life :D
Ethan Grammatikidis
Probably. :D I like what he said, to. I think all art is like that; he medium of expression influences or even changes what you produce.
Nicolai Waniek
> Its anti natural.
It's not.
Because I asked myself which is the best working environment regarding
ones eyes some time ago, I looked around for some scientific research on
the topic of black-background vs white background.
There's not that much research to be cited (and to be honest, after
reading the papers I removed them) but the overall conclusion is that
most probants had a higher reading speed and slightly less reading
errors with black text on white background. Nevertheless, the
differences are very small.
In the end it comes down to personal preference.
Additionally, I looked around for some research regarding eye health
w.r.t. black- vs white-background because one common 'understanding'
seems to be that your eyes will be treated more friendly with a black
background. Again, none of the research papers I read (origin from about
1970 - 2008 or so, when I have some time and the will to I'll search the
papers) came to the conclusion that this is true. Quite the opposite,
that they could not detect any difference.
The only clear direction stated was that when you have to work with a
monitor and feel that your eyes are tiring, you should probably go to an
optician as you might have a minor amblyopia (+.25, -.25 something like
that) and proper way to work against it is to try eyeglasses.
regards
Connor Lane Smith
> Quite the opposite, that they could not detect any difference.
So uh, not *quite* the opposite.
I'm willing to believe people have a higher reading speed with
black-on-white, though I suspect this is in part because that's how we
read the vast majority of the time. However, especially when I'm
tired, I can *feel* my eyes strain against the brightness (and if you
lower the brightness you get an unreadable grey-on-grey). We may be
good at reading black-on-white, but perhaps not black-on-fluorescent.
It's possible I'm an outlier, being almost blind in one eye, but I
doubt that has much of an effect in this case.
Thanks,
cls
pancake
I remember in the msdos5.0 age where everybody was using a 80x25 text console to run programs and graphical mode was just for games..
Many text editors used a blue background. This is: wordperfect/wordstar/edit.com ..
I remember my teacher arguing this as something medically prooft that white or black on blue is better than b/w or w/b.
Another point in this topic is that many ebook readers (iBooks) allow to change the background color to 'sepia'. Which is good for long readings, as the contrast is lower than b/w.
I think that for long readings you use to be in a fixed position and your eyes get more tired if there's more bright on the screen.
Also crt and lcd/tft screens have differet brightness effects. Tft are less damaging to eyes than crt.. So i think discussion about colors on text moved to only stethical and personal issue because its no longer dramatic as it was in the crt era.
--pancake
Pieter Praet
> On 06/07/2011 07:09 PM, pancake wrote:
> > Its anti natural.
>
> It's not.
>
> Because I asked myself which is the best working environment regarding
> ones eyes some time ago, I looked around for some scientific research on
> the topic of black-background vs white background.
>
> There's not that much research to be cited (and to be honest, after
> reading the papers I removed them) but the overall conclusion is that
> most probants had a higher reading speed and slightly less reading
> errors with black text on white background. Nevertheless, the
> differences are very small.
Was there any mention of ambient lighting?
I suspect these tests weren't conducted at 4am in a typical coder's
cave, but rather in some fluorescent tube infested lab...
Just take your laptop outside for a while, that's all the research you need ;)
> [SNIP]
> The only clear direction stated was that when you have to work with a
> monitor and feel that your eyes are tiring, you should probably go to an
> optician as you might have a minor amblyopia (+.25, -.25 something like
> that) and proper way to work against it is to try eyeglasses.
"The only clear direction stated was that when you have to walk and feel
that your legs are aching, you should probably go to a radiologist as
you might have a broken leg and proper way to work against it is to try
immobilization."
OR
"You mean your eyes get tired after staring at a bright light for long
stretches of time? That's not normal, you have bad eyes dude..."
I'm aching to see that study :D
>
>
> regards
Peace
--
Pieter
Pieter Praet
> Just to add my 5c to the thread..
>
> I remember in the msdos5.0 age where everybody was using a 80x25 text console to run programs and graphical mode was just for games..
>
> Many text editors used a blue background. This is: wordperfect/wordstar/edit.com ..
>
> I remember my teacher arguing this as something medically prooft that white or black on blue is better than b/w or w/b.
Your teacher is full of shit.
Google "photoreceptor cell apoptosis induced by in vivo blue light exposure".
Hint: "apoptosis" means DEATH.
> Another point in this topic is that many ebook readers (iBooks) allow to change the background color to 'sepia'. Which is good for long readings, as the contrast is lower than b/w.
>
> I think that for long readings you use to be in a fixed position and your eyes get more tired if there's more bright on the screen.
>
> Also crt and lcd/tft screens have differet brightness effects. Tft are less damaging to eyes than crt.. So i think discussion about colors on text moved to only stethical and personal issue because its no longer dramatic as it was in the crt era.
>
>
> --pancake
>
> On 12/06/2011, at 12:20, Connor Lane Smith <c...@lubutu.com> wrote:
>
> > On 12 June 2011 10:53, Nicolai Waniek <roc...@rochus.net> wrote:
> >> Quite the opposite, that they could not detect any difference.
> >
> > So uh, not *quite* the opposite.
> >
> > I'm willing to believe people have a higher reading speed with
> > black-on-white, though I suspect this is in part because that's how we
> > read the vast majority of the time. However, especially when I'm
> > tired, I can *feel* my eyes strain against the brightness (and if you
> > lower the brightness you get an unreadable grey-on-grey). We may be
> > good at reading black-on-white, but perhaps not black-on-fluorescent.
> >
> > It's possible I'm an outlier, being almost blind in one eye, but I
> > doubt that has much of an effect in this case.
> >
> > Thanks,
> > cls
> >
>
Peace
--
Pieter
Michael Farnbach
Jakub Lach
<noble....@gmail.com> napisał(a):
> Then the easiest to read is amber on black. There is a lot we can
> learn from the sharp shooters, and the old dumb terminals.
Wondering if this concept is related to "selective yellow" [1]
[1] http://en.wikipedia.org/wiki/Selective_yellow
"The intent of selective yellow is to improve vision
by removing shorter, blue wavelengths from the projected
light, as these wavelengths are difficult for the human
visual system to process properly(...)"
On the side note, I use white on black with selective
yellow cursor. W&B is no-brainer for me, maximizes
contrast while minimizing screen brightness.
To add another one, I'm not entirely sure LCD vs CRT
eyes health debate is settled.
regards,
- Jakub Lach
David J Patrick
> To add another one, I'm not entirely sure LCD vs CRT
> eyes health debate is settled.
>
debate is well over..
djp
Ethan Grammatikidis
> Also crt and lcd/tft screens have differet brightness effects. Tft are less damaging to eyes than crt.. So i think discussion about colors on text moved to only stethical and personal issue because its no longer dramatic as it was in the crt era.
Really? Who made this screaming bullshit up? My eyes haven't been right since I bought my first TFT monitor, and I've run into several people ONLINE who tell me they can't use LCD monitors AT ALL. Imagine that; relying on the internet and yet you can't use LCDs. Given how many people would simply forget about using computers if they had such a problem, I expect LCD screens make a LOT of peoples' eyes bleed. I think you're blindly believing _lies_ spewed by monitor manufacturers.
Pancake... I'm sorry to say this but I get a "wtf moment" from nearly every post you send to this list. I realize that's not constructive criticism... You may want to consider how information flows especially how and when it it is possible to determine truth from lies. I don't mean how data flows; I mean how _meaning_ gets passed from human to human, and what can be lost in transit, especially when the sending humans are working on behalf of a megacorp (or government, for that matter).
Pieter Praet
While I won't comment on the rest of pancake's message
(I've already done so for one of his other points):
You can verify all this CRT-related "screaming bullshit" [sic]
empirically, in the comfort of your own home:
Eye-related:
+ greater contrast ratio and color depth (degrades over time)
+ multisync (= scaling to different resolutions)
+ higher response time
- constant flicker
- image loss/distortion at boundaries
- uneven brightness
- more susceptible to glare
- difficult to position ergonomically
Other:
+ cheap
- prone to imploding (and setting fire to the elderly)
- emits high-pitched tone
- wasteful:
- greater size (especially considering equivalent viewing area)
- higher weight
- higher power consumption (+ heat output)
(ionizing radiation and "filled to the brim with toxic crap" omitted
due to requiring specialized equipment to determine)
Peace
--
Pieter
hiro
by the concentrated day-long staring without blinking once.
Personally I hate the typical CRT flickering (especially if set to <85 Hz)
Pieter Praet
> Most people getting eye problems in front of the computer are caused
> by the concentrated day-long staring without blinking once.
^ Also rather influential.
Especially for Ethan, who (based on his reference to deviantART today [1])
appears to be a pixel-pusher. Probably started around the same time he bought
his LCD. Would explain alot.
> Personally I hate the typical CRT flickering (especially if set to <85 Hz)
>
Peace
--
Pieter
[1] id:"20110704115...@kolari.ethans.dre.am"
Ethan Grammatikidis
Pieter Praet <pie...@praet.org> wrote:
> On Mon, 4 Jul 2011 14:55:38 +0200, hiro <23h...@googlemail.com> wrote:
> > Most people getting eye problems in front of the computer are caused
> > by the concentrated day-long staring without blinking once.
>
> ^ Also rather influential.
>
> Especially for Ethan, who (based on his reference to deviantART today [1])
> appears to be a pixel-pusher. Probably started around the same time he bought
> his LCD. Would explain alot.
I started doing something arty about 6 months before I bought my LCD, yeah. The LCD took some of the fun out of it (which would be a color depth issue,) but I'm not even comfortable using that particular LCD for plain text any more. Aside from a little burst a few months ago, my artwork has trailed off entirely. It might be related to viewing angle and posture; I find I subconsciously hold my head in a very fixed position for the LCD monitor where I don't remember doing that with CRTs at all. I guess I'm trying to get the position where the color depth is the least bad.
> > Personally I hate the typical CRT flickering (especially if set to <85 Hz)
Yeah... I didn't have much of a problem with flickering myself but I'm not trying to say it wasn't bad for anyone else. I just got angry at the blanket "TFT is better", especially when stated as if it had scientific backing. If some scientists have produced 'proof' of that, they constructed their experiments badly. It also reeks of the "better is better" circle-jerk... eh, I'll stop now.
I do seem to have less of a problem when there's a color management system in the display, but I can't imagine anything more sucky in a display than a system to adjust every already-rendered pixel. That reminds of how elegant a CRT is in its way - there's only 15 connections to the tube, compared to all the rows and columns of an LCD. Still, pushing a CRT up to 85Hz non-interlaced requires some fairly extreme engineering.
Pieter Praet
> [...]
> I do seem to have less of a problem when there's a color management
> system in the display, but I can't imagine anything more sucky in a
> display than a system to adjust every already-rendered pixel.
Color calibration [1] (and frequent recalibration) is mandatory when
doing *anything* graphics-related for production purposes, as the output
of any and every visual output device known to man *will* be distorted,
due to used materials, quality, aging, environmental variables, ...
CRTs aren't exempt from this.
Peace
--
Pieter
Noah Birnel
> Color calibration [1] (and frequent recalibration) is mandatory when
> doing *anything* graphics-related for production purposes, as the output
> of any and every visual output device known to man *will* be distorted,
> due to used materials, quality, aging, environmental variables, ...
>
color printouts for trial displays. We don't attempt to calibrate our
monitors for that very reason - we know they *will* be distorted. The
proof of the pudding is in the eating, and what we care about is the
print appearance, not the monitor.
(This has certainly drifted from 'suckless file manager'.)
Cheers
noah
hiro
the display instead?
Noah Birnel
> I don't get it, are you calibrating your printer so that it matches
> the display instead?
>
hope for that. What matters to us is the print.
I am not arguing that no one should attempt to calibrate their monitor -
but that it is not a necessity for all graphics work. In our case, it
would be a waste of time.
-noah
Pieter Praet
So you'll just keep on printing 1x1.3m's until the colors seem right?
Do you have stock options on ink/toner cartridge manufacturer shares?
> -noah
>
Peace
--
Pieter
Suraj N. Kurapati
> On Mon, 4 Jul 2011 11:18:16 -0700, Noah Birnel wrote:
> > I am not arguing that no one should attempt to calibrate their
> > monitor - but that it is not a necessity for all graphics work.
> > In our case, it would be a waste of time.
>
> So you'll just keep on printing 1x1.3m's until the colors seem
> right?
That reminds me of an old Calvin and Hobbes comic strip:
http://picayune.uclick.com/comics/ch/1986/ch861126.gif
--
Nothing is ever a total loss; it can always serve as a bad example.