Re: Control hidden folder/file settings?

On Sat, 21 Jan 2006 04:05:52 GMT, mayayana staggered into the Black Sun
and said:
> Sorry, I was just writing offline in a text file and pasting it in.
> That's why it wasn't standard quoting.

Ah. OK, no worries.

> I wasn't expecting you to respond again (since I got my answer that I
> cannot change the meaning of "." systemwide) but I appreciate your
> efforts.

It's all about the follow-through. Make sure the questioner really
understands what they need to know, and they won't ask the same
questions over again :-) .

>> > At this point I don't have a clear idea of how things fit together
>> > on Linux.
>> Linux GUIs typically run on top of X, which is roughly analogous to
>> the "display driver" in OS X/Windows. X's window manager doesn't
>> really have an analogue in Windows/OS X. The window manager controls
>> where the windows are on the screen and draws the frame and
>> decorations for each window.
>>
>> Apps can use any widget set they want. GTK+ is really the most
>> common, KDE the next most, [...] All widget sets look different, but
>> they all behave basically the same way except for Athena's weird
>> scrollbars.
> I think I have an idea of what you're describing. I guess it will
> become more clear if I look into the APIs of X, GTK, etc.

Maybe not. X's core functions are in Xlib and are both very basic (draw
line from point X,Y to point Z,W) and somewhat arcane. GTK+/KDE are
much more friendly, but they're also complex. If you really want to do
some programming in GTK+, it's fairly easy to install the Gtk2::Perl
module. The Perl bindings for GTK2 allow you to do things without
worrying about memory management, which is always nice.

> It sounds like X is the basics - the hardware interface functions -
> but with only basic functionality to actually draw "widgets". (By
> widgets I gather that you mean component windows like buttons, text
> boxes, etc.)

Yep, "widget" seems to be what people who program GUI apps call those
things. I think that even MSDN may use that term....

> window managers are each a complete kit of relatively-easy-to-use GUI
> parts?

Nope. All that a window manager does is control the position and size
of the windows X clients are displayed in, and draw the borders and
frames of those clients' windows. You may be thinking of a "desktop
environment" here. A desktop environment is a relatively large
collection of programs, all using the same widget set, all designed to
help a user get work done.

KDE and GNOME are the big desktop environments. They're considered
"heavyweight" because they define a protocol that apps can use to talk
to each other, they're themeable, they use a fair amount of RAM, and
they start a fair number of processes.

> Does one typically use both X and a window manager, or is X accessed
> through the window manager functions?

You're always using a window manager in X unless you're running a
special-purpose kiosk app. <ANALOGY TYPE="BAD"> X is the road. The
window manager is the steering wheel. The desktop environment is the
climate control and stereo. </ANALOGY>

>> This is weird. Firefox 1.0.7 here, the "open file" dialog has a
>> checkbox called "show hidden files" in the bottom left corner.
> Odd. I've got Firefox 1.5 and there's no such checkbox.

2 steps forward, one step back. Maybe there's a bug open?

>> Wine is a special case. Um... hmm, if I do "wine pq.exe" I get
>> ProgressQuest's normal dialog. Pick "Open File", I get a standard
>> Win2K-like "open file" dialog. I can put ".wine" into the "file
>> name" portion of that dialog, and pq.exe shows my ~/.wine directory.
> what you describe doesn't work for me in anything I test it with.
> Using Wine.9.5. Trying running as 98 and 2000. If I enter .wine
> there's just no response.

wine 9.5? Hmm, wine --version gives me "Wine 20050930" which may be
older or newer than your wine. Yes, ProgressQuest is a free-beer game
that's fairly silly, but it is a Windows app and it shows a bug in wine
that I'm still wondering if they're ever going to fix. (I don't know
enough about the lowlevel bits of Win32 to really help them fix it
though.)

>> For kwrite, File->Open File. The open file dialog will appear. You
>> should be able to find the icon that looks like a hammer and wrench
>> in that open file dialog, click on it, then select "show hidden
> Ah, that worked. Thanks. I'll have to be more mindful of differences
> with these GUIs. I hadn't even noticed that the KWrite dialogue had
> extra buttons.

In KDE, if it looks like a button, it probably is a button, and you
should click it at least once to find out what it'll do. For example,
right-click a directory, choose Properties, click the button that
contains a picture of a file folder. Neat, huh? MacOS < X used a
similar scheme to change the icons of various things. HTH,

--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin / mail: TRAP + SPAN don't belong
http://www.brainbench.com / "He is a rhythmic movement of the
-----------------------------/ penguins, is Tux." --MegaHAL
.