|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> What would be the problem of, for example, supporting soft links natively
> in Windows Explorer?
Part of the problem comes from programs that don't support soft links
getting caught in loops.
Why the heck would
> What would be the problem of adding an option to Windows Explorer to show
> exact byte sizes of files?
The properties page already tells you that. And which byte count do you
want? Compressed bytes? Uncompressed bytes? Bytes of disk space occupied? Do
you count alternate streams? How about overhead streams like ACLs and crypto
keys? "dir" already shows that.
So write an extension, if it bothers you. That's the cool thing about
Windows. Once you learn how to talk between parts, you can do all kinds of
things. Like the tortise svn client, for example.
> I really can't think of any drawback. If someone
> wants to use the current mode, go ahead, but why not offer exact byte counts
> for people who want them? What would be the problem?
There are a zillion things that some people want.
> (That's actually something I really hate in MacOS X Finder. There's no way
> to make it list the actual size in bytes of files. Instead, it shows a rounded
> size like Windows... but of the disk space the file is taking rather than the
> actual size of the file.
Which makes perfect sense if you care, because people want to know whether
the file will fit somewhere.
> You can get this info from a context menu the hard way, but it's very
> inconvenient.)
In Windows, you select the files and pick "properties" and it tells you the
size. Not that hard.
> Why is it so hard to show exact byte counts in graphical file browsers?
> Even Konqueror (the default file browser in OpenSUSE) is able to show them
> easily.
You're bitching that a nerd feature is convenient in Linux and not Windows?
You're a nerd. Exact file sizes are important to programmers, not users.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Orchid XP v8 wrote:
>>> ...so how do you actually do this then?
>
>> That's what the whole COM thing is all about, along with things like
>> "Windows Scripting Host" and "Power Shell".
>
> I find it telling that if the question would have been something like
> "how do you find files in the current directory containing a certain string"
> the answer could have been given in one line,
Yes. Every window has a search box on it.
> but when the question is how
> to do those complex searches in Windows you mentioned... there's no simple
> answer, only obscure references to something else.
Nope. Every window has a search box in it, *and* that search box handles the
complex file formats too. If all you want to do is search for a text string
in a directory tree, Windows has that. If all you want to do is search for a
regular expression in a directory tree, it's trivial to add that to Windows
either with a GUI or without. If you want to know how to do searches that
are difficult in Linux, then it's going to be complex in Windows too. I'm
not going to teach you how to do that any more than you're going to explain
how to write the same searches using Linux tools. If you want to do
something complex beyond searching strings, you have to use the parsers.
Unlike Linux, all the Windows tools are based on the same technology, so you
only have to learn that once.
It's no different than saying "what if I wanted to count the number of times
the Beatles show up in my music library" you'd have to ask where your music
library is storing those tags. I'm not going to show you how to do that in
Linux.
In other words, grep doesn't work on SQL databases. Simple string search is
there. Complex structured queries are there. Regular expressions requires
you download a free program, or to write a script that used the built-in
regular expression objects and directory tree objects to walk the tree and
regexp each file, because non-programmer users don't do that stuff.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I'm just not very eager to spend something like 200 euros on a Windows
> which does things that my *current* Windows should do already (if nothing
> else, as a free upgrade).
I didn't ask you to. :-)
> I have used Windows (98 and newer) for over 10 years, and I still can't
> figure out how to do such things.
Like what, grep? I already pointed you to Agent Ransack, and I've found
that putting "win32" on the front of a query usually gives you back the
ported version of that software.
> I have been using Unix-likes for about
> the same amount of time, and it didn't take me long to figure out, and it
> just feels comfortable. (I'm not saying that you can do every possible
> operation in existence easily, but common tasks just are much easier there
> than in Windows, where often I don't know even where to start, even though
> I'm not exactly a newbie. Windows is just that good at hiding all the stuff.)
Yeah. I sat down and read thru all the V7 man pages and source code, so I
know how the basics of UNIX works. I never did that with Windows. When I
want to do something complex, like rename all my new photographs based on
the camera that took them combined with the EXIF date, I write a program to
do that, just like I would in Linux. I don't use Windows like a regular user
does, because I'm a programmer. So I have added the tools a programmer
uses. These programs are not always well-advertised, and are often
distributed as part of "an SDK" which really doesn't tell you what's there.
There are a number of tasks I do frequently that I have little scripted
programs to do.
Similarly, people look at me funny when I say I don't use facebook,
linkedin, etc. But that's not the sort of thing I do. I imagine someone
working in an HR department has all different kinds of programs and scripts
and macros to use their Windows conveniently than I do.
If there's something you want to do on Windows that's hard to do, it's
probably because that's not how it's done on Windows. Just as an example, I
have never seen a soft link used in Windows, or seen the need for a soft
link other than to fix broken programs that hard-coded file names that they
were supposed to be pulling out of the environment. People don't use soft
links to point to the right location - they use configuration variables.
The whole "file format" issue is exactly that. People don't try to implement
programs that can create Excel files or pull information out of Word files
on Windows, any more than they write programs that can part MyISAM files on
Linux. They talk to the program that knows the format through a well defined
interface to manipulate the files in an upward-compatible way.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > What would be the problem of, for example, supporting soft links natively
> > in Windows Explorer?
> Part of the problem comes from programs that don't support soft links
> getting caught in loops.
Soft links are and should be invisible to programs (unless the program
explicitly wants to distinguish them, as a file explorer would).
> Why the heck would
Did you mispaste that?
> > What would be the problem of adding an option to Windows Explorer to show
> > exact byte sizes of files?
> The properties page already tells you that.
I don't want to see it in a separate dialog. I want to see it in the file
listing.
> And which byte count do you want?
The size of the file. How many bytes it contains. If I opened it with a
program and started reading bytes, how many I would get before EOF. (And
please don't start nitpicking about special files. The file listing doesn't
need to show any byte size for special files.)
Windows Explorer already shows that size in the file listing... but not
in bytes (unless the file happens to be smaller than 1 kB or such). That's
what's annoying about it.
> So write an extension, if it bothers you.
You make it sound like it's easy.
> > I really can't think of any drawback. If someone
> > wants to use the current mode, go ahead, but why not offer exact byte counts
> > for people who want them? What would be the problem?
> There are a zillion things that some people want.
Seeing the exact size of a file is a pretty common and useful thing to
want.
> > (That's actually something I really hate in MacOS X Finder. There's no way
> > to make it list the actual size in bytes of files. Instead, it shows a rounded
> > size like Windows... but of the disk space the file is taking rather than the
> > actual size of the file.
> Which makes perfect sense if you care, because people want to know whether
> the file will fit somewhere.
Except that it doesn't tell that. If you try to copy it to another file
system or an archive file, it will most probably end up taking a completely
different amount of space.
Showing how much disk space a file takes is *useless* information. *That*
is what should be in some info dialog. The file listing should show the
exact byte size. Apple has done it completely in reverse of what it should be.
> > You can get this info from a context menu the hard way, but it's very
> > inconvenient.)
> In Windows, you select the files and pick "properties" and it tells you the
> size. Not that hard.
Yeah, start doing that to a dozen files, rather than seeing it in one
glance in the file listing. It *is* extremely inconvenient.
> > Why is it so hard to show exact byte counts in graphical file browsers?
> > Even Konqueror (the default file browser in OpenSUSE) is able to show them
> > easily.
> You're bitching that a nerd feature is convenient in Linux and not Windows?
> You're a nerd. Exact file sizes are important to programmers, not users.
And that's why they just *can't* include an option somewhere to turn on
showing exact byte sizes? "Hey, it's a nerd option, we must not include
such a thing! Heaven forbid if we start appealing to the nerd users!"
I ask once again: What exactly would be the *problem* here?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 21-4-2010 22:15, Darren New wrote:
> Warp wrote:
>> Darren New <dne### [at] sanrrcom> wrote:
>>> Orchid XP v8 wrote:
>>>> ...so how do you actually do this then?
>>
>>> That's what the whole COM thing is all about, along with things like
>>> "Windows Scripting Host" and "Power Shell".
>>
>> I find it telling that if the question would have been something like
>> "how do you find files in the current directory containing a certain
>> string"
>> the answer could have been given in one line,
>
> Yes. Every window has a search box on it.
>
>> but when the question is how
>> to do those complex searches in Windows you mentioned... there's no
>> simple
>> answer, only obscure references to something else.
>
> Nope. Every window has a search box in it, *and* that search box handles
> the complex file formats too. If all you want to do is search for a text
> string in a directory tree, Windows has that.
IME the Windows that I use indeed have those search options. Except that
they don't seem to work as advertised. They often don't find files that
are clearly there. Typical situation: I am editing a file that calls a
function. I search for all other files that call or contain that
function in a tree starting one level above the file I am editing. No
results, not even the file that I am editing. WTF? IIRC it can also give
results outside the search criteria and it is definitely slow. In short,
it drove me mad.
Then I tried googledesktop. Great program, much faster. Will also find
files and e-mails that contain the text item you searched for. Lots of
options to refine your search. If only it would be so kind to look at
the options it would be even greater. In short, it too drove me mad.
Sometimes I connect a removable disk to a PC with an older version of XP
or 2000 just to be able to do a reliable search.
I know it is probably something that I do wrong, but what?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Orchid XP v8 wrote:
> >>> ...so how do you actually do this then?
> >
> >> That's what the whole COM thing is all about, along with things like
> >> "Windows Scripting Host" and "Power Shell".
> >
> > I find it telling that if the question would have been something like
> > "how do you find files in the current directory containing a certain string"
> > the answer could have been given in one line,
> Yes. Every window has a search box on it.
I just wish it would work. It doesn't. Yes, I have tried, and I have
become exasperated.
> > but when the question is how
> > to do those complex searches in Windows you mentioned... there's no simple
> > answer, only obscure references to something else.
> Nope. Every window has a search box in it, *and* that search box handles the
> complex file formats too. If all you want to do is search for a text string
> in a directory tree, Windows has that.
Do you honestly think I would be claiming that it doesn't work if I hadn't
tried it already? It doesn't work.
I really got once stuck because I just *couldn't* find what I was
searching for. I knew the string was in some files and I wanted to know
which of them, but the damn thing simply refused to tell me, no matter
what I tried. (IIRC I was searching for C++ files which include a specific
header or something like that. I ended up having to figure that out by
other means.)
> If all you want to do is search for a
> regular expression in a directory tree, it's trivial to add that to Windows
> either with a GUI or without.
You have a really odd definition of "trivial".
My definition of "trivial" is if it would be something like "write 'xyz'
here, and it will work".
Apparently your definition of "trivial" is "not impossible".
> If you want to know how to do searches that
> are difficult in Linux, then it's going to be complex in Windows too.
"grep 'xyz.hh' *" isn't very difficult in Linux. It seems to be in Windows
(at least when using Windows Explorer).
> I'm
> not going to teach you how to do that any more than you're going to explain
> how to write the same searches using Linux tools.
Do you know why? Because it's *not* trivial in Windows.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> What would be the problem of, for example, supporting soft links natively
> in Windows Explorer?
> What would be the problem of adding an option to Windows Explorer to show
> exact byte sizes of files?
Go for it! :-)
http://msdn.microsoft.com/en-us/library/bb773177%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/dd940376%28v=VS.85%29.aspx
Note that all the interactions with explorer are via COM. If you wanted to
change how Gnome or KDE displays that sort of thing, out of curiosity, what
would you do? (Serious question there.) Would you have to change source
code, or is there some sort of interface like COM or REXX or something to
allow access?
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 21 Apr 2010 21:50:06 +0200, Warp <war### [at] tagpovrayorg> wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
> I have used Windows (98 and newer) for over 10 years, and I still can't
> figure out how to do such things. I have been using Unix-likes for about
> the same amount of time, and it didn't take me long to figure out, and it
> just feels comfortable. (I'm not saying that you can do every possible
> operation in existence easily, but common tasks just are much easier
> there
> than in Windows, where often I don't know even where to start, even
> though
> I'm not exactly a newbie. Windows is just that good at hiding all the
> stuff.)
>
I installed Ubuntu Ultimate Edition 2.4 recently.
Wow! I can change the way the OS looks and I don't have to buy Blinds to
do it! =D
I had a bit of trouble installing my 3G modem, but I managed - I need to
plug it in before I fire up Linux. Apparently that's fixed in 2.5 but I
don't have the bandwidth to download it. I also managed to install the
graphics card drivers.
I installed Code::Blocks but I need WXwidgets which is another big
download.
But I still haven't been able to install Pov-Ray except in Wine... :(
I'm a total n00b as I can't seem to install anything without the Package
Manager...
--
-Nekar Xenos-
"The spoon is not real"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Just as an example, I
> have never seen a soft link used in Windows, or seen the need for a soft
> link other than to fix broken programs that hard-coded file names that they
> were supposed to be pulling out of the environment. People don't use soft
> links to point to the right location - they use configuration variables.
Well, duh. People don't use soft links because Windows doesn't support
them. Seems plainly obvious.
I'm pretty sure you wouldn't be writing that if Windows had full support
for soft links from day one to this day.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 21-4-2010 22:39, Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Nope. Every window has a search box in it, *and* that search box handles the
>> complex file formats too. If all you want to do is search for a text string
>> in a directory tree, Windows has that.
>
> Do you honestly think I would be claiming that it doesn't work if I hadn't
> tried it already? It doesn't work.
>
> I really got once stuck because I just *couldn't* find what I was
> searching for. I knew the string was in some files and I wanted to know
> which of them, but the damn thing simply refused to tell me, no matter
> what I tried. (IIRC I was searching for C++ files which include a specific
> header or something like that. I ended up having to figure that out by
> other means.)
Seems like you have the same problem as me.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|