X less elegant than Windows' GDI? (Re: Microsoft Slits their own throats - Re: Microsoft Bans Opensource and Java Development from their tools.)
Donn Miller
> No, XLib is a toolkit, the same way you could consider MFC or any other
> library a toolkit.
>
> XLib is a bunch of routines which translate calls into text data streams to
> be sent to the X Server. The GDI is the equivelant of the X Server itself.
> Technically you could say the link libraries like gdi32.lib are equivelant,
> but they are just wrappers that make the correct syscalls, not complete
> translation systems.
GDI has a some widgets which are used to build windows classes, as well
as drawing routines. Xlib is also a collection of drawing routines.
Maybe Xlib is a wrapper around the X protocol, but it is definitely not
a toolkit. But, we'll never know, because there doesn't seem to be
anyone else that knows anything about GDI and Xlib in this NG (other
than the Ghost in the Machine).
The one hint as to whether or not Xlib is a toolkit can be found on the
gcc command line. When you link with X libraries, the lowest level lib
seems to be -lX11, which is Xlib.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Marc Britten
anyone have a backlog of this thread(mine starts at this message)
marc
In article <3B3C42A3...@cvzoom.net>, "Donn Miller"
The Ghost In The Machine
<dmmi...@cvzoom.net>
wrote
on Fri, 29 Jun 2001 04:56:03 -0400
<3B3C42A3...@cvzoom.net>:
>Erik Funkenbusch wrote:
>
>> No, XLib is a toolkit, the same way you could consider MFC or any other
>> library a toolkit.
>>
>> XLib is a bunch of routines which translate calls into text data streams to
>> be sent to the X Server. The GDI is the equivelant of the X Server itself.
>> Technically you could say the link libraries like gdi32.lib are equivelant,
>> but they are just wrappers that make the correct syscalls, not complete
>> translation systems.
>
>GDI has a some widgets which are used to build windows classes, as well
>as drawing routines. Xlib is also a collection of drawing routines.
>Maybe Xlib is a wrapper around the X protocol, but it is definitely not
>a toolkit. But, we'll never know, because there doesn't seem to be
>anyone else that knows anything about GDI and Xlib in this NG (other
>than the Ghost in the Machine).
You rang? :-)
I'll admit, I am somewhat ambivalent about Windows' GDI. While
a good idea in some respects (one merely changes the handle, in theory,
to generate printed output as opposed to drawn), it appears that there
are so many exceptions (Escape(), for example -- or is it PrintEscape()?)
that in practice, things could get mucky; better to have an
approximation on the soft display (X or Windows) for later generation on
the hard printout (Postscript).
As TeX (or LyX) might put it, "What You See Is What You Meant".
(Pedant point: the data streams are not necessarily text, but are
a very well-specified protocol; look at X11/Xproto.h and Volume 0
of the O'Reilly X Manuals (I forget the precise title). This is
one reason why X is so well-liked; the protocols are bog-standard
and anyone can in theory understand them. I've even seen some
debugging tools that can monitor (and serve as an intermediary)
the stream of bytes going between X and the client, and of course
things like ssh can easily (?) proxy the X connections, which makes
for a lovely environment if one wants to set up a headless high-powered
server with XDMCP-capable X terminals -- or Linux boxes.
Contrast that to Windows Metafiles. At best, they're proprietary.
At worst, they're virtually nonexistent. And the only tool I've
seen that implements remote display functionality is pcAnywhere, which
works, but I'm not sure it would work well over a 56k modem link
(I use X over that routinely). There may be other tools out there,
though, and Win2k apparently has finally gotten a clue and is starting
to allow CLI. We'll see.)
>
>The one hint as to whether or not Xlib is a toolkit can be found on the
>gcc command line. When you link with X libraries, the lowest level lib
>seems to be -lX11, which is Xlib.
Not precisely sure what "toolkit" means, but I'd have to agree; libX11.so
implements an API (X11/X.h, X11/Xlib.h, and I believe X11/Xutil.h as well)
which can draw, monitor events, manage windows (including windows of
other processes -- window managers, for example), and keep the display
more or less in sync with the instructions coming from all these
processes.
And what is a procedure or a function but a tool, anyway? :-)
X is a very solid foundation.
[.sigsnip]
--
ew...@aimnet.com -- insert random misquote here
EAC code #191 13d:21h:48m actually running Linux.
The Usenet channel. All messages, all the time.
Erik Funkenbusch
message news:slrn9jqban...@lexideb.athghost7038suus.net...
In all my years of using the GDI to print output, i've never used those
exceptions you speak of. Primarily because I have never had a need to send
custom escape sequences to the printer. The Printer driver does an
excellent job of translating things on its own.
> (Pedant point: the data streams are not necessarily text, but are
> a very well-specified protocol; look at X11/Xproto.h and Volume 0
> of the O'Reilly X Manuals (I forget the precise title). This is
> one reason why X is so well-liked; the protocols are bog-standard
> and anyone can in theory understand them. I've even seen some
> debugging tools that can monitor (and serve as an intermediary)
> the stream of bytes going between X and the client, and of course
> things like ssh can easily (?) proxy the X connections, which makes
> for a lovely environment if one wants to set up a headless high-powered
> server with XDMCP-capable X terminals -- or Linux boxes.
>
> Contrast that to Windows Metafiles. At best, they're proprietary.
> At worst, they're virtually nonexistent. And the only tool I've
> seen that implements remote display functionality is pcAnywhere, which
> works, but I'm not sure it would work well over a 56k modem link
> (I use X over that routinely). There may be other tools out there,
> though, and Win2k apparently has finally gotten a clue and is starting
> to allow CLI. We'll see.)
Metafiles are not very good solutions. Enhanced metafiles are ok, but
seldom needed except when you have static output that doesn't change much,
you create the metafile and replay it into the DC.
In any event, Windows has had Terminal Services since NT4, and Win2k
includes them in the server version. WinXP includes them in all versions
for administration purposes, but you can turn it on and off.
> >The one hint as to whether or not Xlib is a toolkit can be found on the
> >gcc command line. When you link with X libraries, the lowest level lib
> >seems to be -lX11, which is Xlib.
>
> Not precisely sure what "toolkit" means, but I'd have to agree; libX11.so
> implements an API (X11/X.h, X11/Xlib.h, and I believe X11/Xutil.h as well)
> which can draw, monitor events, manage windows (including windows of
> other processes -- window managers, for example), and keep the display
> more or less in sync with the instructions coming from all these
> processes.
However, most of that API is code that exists in the library, not code that
exists in the server. GDI runs entirely "in the server" so to speak.
Wrapping stuff around the primary interface can give you lots of things, but
each level of abstraction introduces extra overhead.
> And what is a procedure or a function but a tool, anyway? :-)
> X is a very solid foundation.
X is simply overkill for the average user. It imposes serious performance
hits for benefits which only benefit a small percentage of the computing
population (larger for the existing Linux population, because Linux runs on
so many servers, but for the average desktop it wouldn't be).
Basically what you're saying is this: Because a few people need the power
of and flexibility of an SUV, everyone must drive an SUV, rather than some
people driving Yugo's or Geo Metro's that don't need all that.
Donn Miller
> However, most of that API is code that exists in the library, not code that
> exists in the server. GDI runs entirely "in the server" so to speak.
> Wrapping stuff around the primary interface can give you lots of things, but
> each level of abstraction introduces extra overhead.
OK, fair enough. Then why is there a GDI.EXE and GDI32.DLL? I guess
it's for resolving certain run-time dependencies, like deciding whether
or not to use CreateWindowExA or CreateWindowExW, etc.
> X is simply overkill for the average user. It imposes serious performance
> hits for benefits which only benefit a small percentage of the computing
> population (larger for the existing Linux population, because Linux runs on
> so many servers, but for the average desktop it wouldn't be).
Atually, those performance hits aren't that big. Most of the
performance hits are probably at the dynaic linker level, where you have
functions in shared obj. libariers calling other functions in shared
obj. libs., and there could be a complex web of dependencies. I think
that you can increase performance by just upping the memory a bit. For
example, with KDE, you'll get by on 64 megs. But as you start using more
and more apps that require object code in more libraries, you'll start
seeing the performance hit there. It's probably best to go to at least
128 megs for something like KDE with many layers of abstraction (i.e.,
shared object code). With large amounts of memory, you can keep all the
required functions in the shared libraries in memory at all times,
instead of having various pieces being swapped out.
I'm sure you've seen this if you've run KDE or GNOME. Say you have 64
megs of RAM. When you first fire it up, you really aren't using that
many apps. But as you start firing up apps during your session, you'll
start to see the effects of the object code being swapped out. So, if
you're one of those "power desktop" users (KDE or GNOME), you'd be best
served with at least 128 megs. That's really no big deal these days,
because memory is so cheap, and even older boards support this much RAM
very easily.
Erik Funkenbusch
news:3B3D449B...@cvzoom.net...
> Erik Funkenbusch wrote:
>
> > However, most of that API is code that exists in the library, not code
that
> > exists in the server. GDI runs entirely "in the server" so to speak.
> > Wrapping stuff around the primary interface can give you lots of things,
but
> > each level of abstraction introduces extra overhead.
>
> OK, fair enough. Then why is there a GDI.EXE and GDI32.DLL? I guess
> it's for resolving certain run-time dependencies, like deciding whether
> or not to use CreateWindowExA or CreateWindowExW, etc.
GDI.EXE is the 16 bit API, GDI32 is the 32 bit API. The Ansi and Wide
versions of things are both in GDI32. Under Windows 9x, many functions
thunk down to GDI (about half) but on NT this isn't the case.
> > X is simply overkill for the average user. It imposes serious
performance
> > hits for benefits which only benefit a small percentage of the computing
> > population (larger for the existing Linux population, because Linux runs
on
> > so many servers, but for the average desktop it wouldn't be).
>
> Atually, those performance hits aren't that big. Most of the
> performance hits are probably at the dynaic linker level, where you have
> functions in shared obj. libariers calling other functions in shared
> obj. libs., and there could be a complex web of dependencies. I think
> that you can increase performance by just upping the memory a bit. For
> example, with KDE, you'll get by on 64 megs. But as you start using more
> and more apps that require object code in more libraries, you'll start
> seeing the performance hit there. It's probably best to go to at least
> 128 megs for something like KDE with many layers of abstraction (i.e.,
> shared object code). With large amounts of memory, you can keep all the
> required functions in the shared libraries in memory at all times,
> instead of having various pieces being swapped out.
The performance hits I'm talking about are in the translation of calls.
Even with the shared memory implementation of X on a local system, the calls
must be translated to the X protocol, and then translated back to binary.
Further, since X is an asynchronous protocol, there is no immediate
notification of errors, so the application cannot respond as quickly.
GDI is synchronous, which allows each call to know of error at the time the
call is made.
> I'm sure you've seen this if you've run KDE or GNOME. Say you have 64
> megs of RAM. When you first fire it up, you really aren't using that
> many apps. But as you start firing up apps during your session, you'll
> start to see the effects of the object code being swapped out. So, if
> you're one of those "power desktop" users (KDE or GNOME), you'd be best
> served with at least 128 megs. That's really no big deal these days,
> because memory is so cheap, and even older boards support this much RAM
> very easily.
I agree, memory isn't that big of a deal. The biggest issue to me is the
asynchronous nature of X, and the overhead of the protocol. Other issues
include latency between context switches, and the lack of ubiquitious
widgets.
Dan Mercer
"Erik Funkenbusch" <er...@visi.com> writes:
DELETIA
>
> X is simply overkill for the average user. It imposes serious performance
> hits for benefits which only benefit a small percentage of the computing
> population (larger for the existing Linux population, because Linux runs on
> so many servers, but for the average desktop it wouldn't be).
What is an "average user". X does apply a small performance hit
for users whose Xserver and clients reside on the same PC (less
of a hit for multi CPU setups). That hit is often exaggerated
because of design flaws in the client programs - Netscape. for
instance, is abysmally written. Some of the current toolkits
suffer from an excess of debug code, the price of youthfulness.
But as for average users in the X11 community, excepting home
Linux users, many if not most depend on the client - server
relationship X affords. The primary application I support uses
PC's running ReflectionX as the Xservers.In one location alone,
we have 400 users accessing a single application server.
Application upgrades are easy - just change the software in one
location and you were done. I usually do that from home
connecting over X11 (like I am now). That system is being replaced with a
more PC centric one. The 400 megabytes of application software is
about to be replaced by 400 gigabytes of software loaded on 100's
of PC's. System upgrades will now require a dozen techs working
overtime to get things installed and configured on the various
PC's, our testing now has to be QA'd over windows 95,98,NT,2K and
ME and soon XP, yada yada.
The client server design allows me to easily connect to dozens of
different machines, as I routinely do. And the ability to run
Virtual Xservers like Xvnc allows me to run Virtual desktops
on a multitude of machines. I run Xvnc on my Linux host whose
monitor has virtually bitten the dust.
I even run X locally on my WinME just so I can use my favorite
editor Nedit (thank you Cygwin).
While we're at it - Xlib is the API. A toolkit is something that
sits on top of the raw API and makes it easier to use. It is the
toolkit that has the higher level concepts of "buttons",
"windows", "shells" and dialogs. Xt (X tookit) was the first.
Motif was written on top of Xt and you can often interchange
Xt and Xm functions. Other toolkits like Tk, ftlk, gtk and qt
were either written on top of Xt or directly on top of the Xlib
API.
Finally, we might discuss the other benefits of client-server.
In X, the clients generally only have to manage their own
behavior - there is another master client, the window manager,
that manages the interactions between the windows - their size,
placement, iconification, etc. If a client gets hung up, you
can easily iconify it. Not so with windows. And there is a
consistency of behavior with X that is missing with GDI. For
instance, the Solitaire program still does it's own double click
interpretation.
--
Dan Mercer
dame...@mmm.com
>
> Basically what you're saying is this: Because a few people need the power
> of and flexibility of an SUV, everyone must drive an SUV, rather than some
> people driving Yugo's or Geo Metro's that don't need all that.
>
>
>
Opinions expressed herein are my own and may not represent those of my employer.
Erik Funkenbusch
news:9hksi8$efl$1...@magnum.mmm.com...
> What is an "average user". X does apply a small performance hit
> for users whose Xserver and clients reside on the same PC (less
> of a hit for multi CPU setups). That hit is often exaggerated
> because of design flaws in the client programs - Netscape. for
> instance, is abysmally written. Some of the current toolkits
> suffer from an excess of debug code, the price of youthfulness.
"average user" means "average computer user", not "average unix power user".
I'm talking about the desktop. Client-server gui's are so seldom needed on
the desktop that the overhead that X imposes is for the benefit of a few at
the cost of the many.
To quote the sage "Spock" (yes, that's a joke) "The needs of the many
outweigh the needs of the few".
> But as for average users in the X11 community, excepting home
> Linux users, many if not most depend on the client - server
> relationship X affords. The primary application I support uses
> PC's running ReflectionX as the Xservers.In one location alone,
> we have 400 users accessing a single application server.
And just how common is this compared to the average PC useage around the
world?
> Application upgrades are easy - just change the software in one
> location and you were done. I usually do that from home
> connecting over X11 (like I am now).
This is quickly becoming a moot point as remote desktop support software
becomes more prevalent. It simply makes more sense to spend extra effort on
the rare circumstances than to force the common circumstance to perform
worse.
> That system is being replaced with a
> more PC centric one. The 400 megabytes of application software is
> about to be replaced by 400 gigabytes of software loaded on 100's
> of PC's. System upgrades will now require a dozen techs working
> overtime to get things installed and configured on the various
> PC's, our testing now has to be QA'd over windows 95,98,NT,2K and
> ME and soon XP, yada yada.
Decentralization means fewer central points of failure that can bring
everyone down, not just one machine.
> The client server design allows me to easily connect to dozens of
> different machines, as I routinely do. And the ability to run
> Virtual Xservers like Xvnc allows me to run Virtual desktops
> on a multitude of machines. I run Xvnc on my Linux host whose
> monitor has virtually bitten the dust.
>
> I even run X locally on my WinME just so I can use my favorite
> editor Nedit (thank you Cygwin).
Indeed. So, you'd rather impose your needs on everyone, when as you claim,
you can just run a program or service to get the same effect.
> While we're at it - Xlib is the API. A toolkit is something that
> sits on top of the raw API and makes it easier to use. It is the
> toolkit that has the higher level concepts of "buttons",
> "windows", "shells" and dialogs. Xt (X tookit) was the first.
> Motif was written on top of Xt and you can often interchange
> Xt and Xm functions. Other toolkits like Tk, ftlk, gtk and qt
> were either written on top of Xt or directly on top of the Xlib
> API.
XLib is not the base API, the X Protocol is. Technically, sockets is the
API, since you can replace XLib with anything you want.
> Finally, we might discuss the other benefits of client-server.
> In X, the clients generally only have to manage their own
> behavior - there is another master client, the window manager,
> that manages the interactions between the windows - their size,
> placement, iconification, etc. If a client gets hung up, you
> can easily iconify it. Not so with windows. And there is a
> consistency of behavior with X that is missing with GDI. For
> instance, the Solitaire program still does it's own double click
> interpretation.
Putting more work on the application author. Window managers are part of
the problem, really. Since what happens when the window manager dies? The
end-user gets quite confused unless they know exactly how X works.
Bob Hauck
> In all my years of using the GDI to print output, i've never used those
> exceptions you speak of.
Yes you have. In Win16 you had to use Escape() to do pagination. In
Win32 that use was replaced with StartPage()/EndPage(). And of course
you have to use StartDoc() and EndDoc() for printers, but not for a
screen. Nowadays, Escape() is for "specials", but it has not always
been that way and you don't get to treat the screen and a printer
exactly the same anyway.
> However, most of that API is code that exists in the library, not code that
> exists in the server. GDI runs entirely "in the server" so to speak.
Really all you are saying is that X and GDI are factored differently.
Which is of course true, since they are different systems written by
different people at different times.
> Wrapping stuff around the primary interface can give you lots of things,
> but each level of abstraction introduces extra overhead.
While there may be some differences in efficiency, I don't think it is a
huge issue at this point, with Quake running similar framerates in both
environments, full-window-drag working about the same, etc. Most
Windows apps use add-on libraries too you know, the Win32 API is not
exactly easy to use.
There are other, more mundane, reasons that might make X seem less
"snappy", such as giving the foreground task a bit priority boost. You
can get a similar effect by boosting the priority of the X server on
Unix, but this is typically not done by default. It doesn't really
change anything, but it makes it seem faster to the casual user.
> X is simply overkill for the average user. It imposes serious performance
> hits
It uses shared memory or Unix sockets if the display is local. No
trips through the TCP stack. I think you are exaggerating.
> Basically what you're saying is this: Because a few people need the power
> of and flexibility of an SUV, everyone must drive an SUV, rather than some
> people driving Yugo's or Geo Metro's that don't need all that.
Bascially, then, MS has until recently sold only Metro's (or is it
Yugo?) I see MS has finally branched out of selling only Metro's, what
with including TS in XP. Well, sort of, if you don't mind having
stupid limits on it.
--
-| Bob Hauck
-| To Whom You Are Speaking
-| http://www.haucks.org/
Bob Hauck
wrote:
> Putting more work on the application author. Window managers are part of
> the problem, really. Since what happens when the window manager dies?
The same thing that happens when the Windows GUI locks up. Only
difference is that a knowledgeable user has a chance of fixing the X
problem, much less so the Windows one.
If your window manger dies a lot, your system is broken.
Dan Espen
> On Sat, 30 Jun 2001 16:38:27 -0500, Erik Funkenbusch <er...@visi.com>
> wrote:
>
> > Putting more work on the application author. Window managers are part of
> > the problem, really. Since what happens when the window manager dies?
>
> The same thing that happens when the Windows GUI locks up. Only
> difference is that a knowledgeable user has a chance of fixing the X
> problem, much less so the Windows one.
Indeed.
When my window manager dies, I get a prompt asking me if I'd like to strart
a window manager and which one I'd like to start.
Its trivial to set up.
Stephen Young
> strart a window manager and which one I'd like to start.
>
> Its trivial to set up.
why would you run a wm that crashes. pwm is beautifully small and
elegant. Never had it crash and don't expect is to.
what happened to the meaning of "stable release"?!
Dan Espen
I think you misunderstand.
I didn't say that I run a window manager that is prone to crashing.
I'm just pointing out that there is nothing wrong with the window
manager being separate from the rest of X, and the issue of what you
do with your X session if the window manager does happen to crash is
simple to deal with.
I do happen to run lots of window manager betas, but they tend not to
crash, thats not the reason I've put recovery into window manager
invocation. Mainly, I just like to be able to exit out of the window
manager and start a different one.
Aidan Kehoe
Personally, I like being able to run Emacs as my session leader and
changing window managers at will with `kill -TERM' :-) .
9wm, what I normally use in the window managing line, is beautifully
small and mature code, but it's still wont to crash at times. Killing
it and restarting it and keeping your session going is nice :-) .
Dan Espen <da...@mk.telcordia.com> writes:
--
Tosach breá leath na hoibre
Erik Funkenbusch
news:m3y9q82...@cc253090-a.sumt1.nj.home.com...
How exactly does that work? I've never seen such a prompt. When the window
manager crashes, it's gone and you're stuck with windows without any way to
control them.
> Its trivial to set up.
If you know what you're doing. If you don't, you're screwed.
Dan Espen
There are lots of ways to do this, heres what I like, is uses "xprompt"
which you should be able to find with a Google search.
In your .xinitrc where your window manager is invoked, invoke a shell instead.
In the shell, do this:
# Change next line to your default window manager:
wm=fvwm2
while [ 0 ] ; do
$wm
wm=`xprompt -geometry +100+100 -re -warp -rlen 44 -p 'WM/end \
(fvwm2, twm, mwm, olwm)'`
if [ $? != 0 ] ; then
exit
fi
if [ "$wm" = "end" ] ; then
exit
fi
done
This runs the window manager. When the window manager ends, it prompts for
the name of a window manager to start, or you can type "end" to really end.
xprompt "grabs" keyboard input by default.
Erik Funkenbusch
Interesting. But do you really think this wouldn't confuse the average
user? Hell, they wouldn't even know what fvwm2 or twm are.
Charlie Ebert
Do you need me to explain them both to you Erik...
Did your head get hurt again... Is it hurted...
--
Charlie
-------
Dan Espen
I don't know if the users I've propagated this to are average or not,
but I don't think it confuses them.
I think this gives them some insight into the difference between the
X server and the window manager.
Since they are prompted to enter "fvwm2", "twm", they know what to
enter, and the different results are clear enough.
Erik Funkenbusch
We're talking about people that get confused by the term "hit any key".
This is always likely to be a problem with Linux, that the Linux developers
give users too much credit for intelligence or ability to figure things out.
While it's nice to give the user the ability to not have their hand held,
that won't make you #1.
Donn Miller
>
> "Dan Espen" <da...@mk.telcordia.com> wrote in message
> news:m3y9q82...@cc253090-a.sumt1.nj.home.com...
> > When my window manager dies, I get a prompt asking me if I'd like to
> strart
> > a window manager and which one I'd like to start.
>
> How exactly does that work? I've never seen such a prompt. When the window
> manager crashes, it's gone and you're stuck with windows without any way to
> control them.
Actually, Window Maker has this functionality built-in, whereby it says
"Window Maker has caused a segmentation fault...". The rest of the
dialog asks you what you'd like to do: "1.) exit and leave a core dump
2.) restart Window Maker 3.) start another window manager". Most of the
time, I select "restart Window Maker". Window Maker restarts, and
everything is fine, and all my apps are left running as they previously
were.
Thought Explorer.exe was the only window manager capable of doing this,
didn't ya? :-)
Christer Palm
>
> We're talking about people that get confused by the term "hit any key".
> This is always likely to be a problem with Linux, that the Linux developers
> give users too much credit for intelligence or ability to figure things out.
> While it's nice to give the user the ability to not have their hand held,
> that won't make you #1.
Well, some people say that's the worst thing about NT - It doesn't have
any idiot filter. :-)
Windoze is full of this kind of not-very-obvious stuff as well. One of
my favourite examples beeing that you have to select "Start" in order to
shut down the system.
--
Christer Palm
Ayende Rahien
"Christer Palm" <pa...@nogui.se> wrote in message
news:3B4033F9...@nogui.se...
Actually, Windows' learning curve isn't that much different than Linux.
Both are complex systems that require quite a bit of knowledge to be used
correctly.
The difference is that Windows hide most of its complexity from the user,
and he has to encounter it only on rare occasions.
Linux, up until recently, had that complexity up front, which require the
user to learn quite a bit before s/he could use the system.
The trade-off is that it's easier to be a user on a Windows system, but
harder to move to power-user, while it's hard to be a user on a *nix system,
and easier to be a power user.
Mark H. Wood
[snippage]
> We're talking about people that get confused by the term "hit any key".
> This is always likely to be a problem with Linux, that the Linux developers
> give users too much credit for intelligence or ability to figure things out.
> While it's nice to give the user the ability to not have their hand held,
> that won't make you #1.
That sort of user is an uninteresting problem. If I get too many of
them, it's time to find a job somewhere else. Microsoft can have them
all with my blessing, if only MS would recognize my right to be a
different sort of user.
--
Mark H. Wood, Lead System Programmer mw...@IUPUI.Edu
Make a good day.
Dan Mercer
"Erik Funkenbusch" <er...@visi.com> writes:
> "Dan Mercer" <dame...@mmm.com> wrote in message
> news:9hksi8$efl$1...@magnum.mmm.com...
>> What is an "average user". X does apply a small performance hit
>> for users whose Xserver and clients reside on the same PC (less
>> of a hit for multi CPU setups). That hit is often exaggerated
>> because of design flaws in the client programs - Netscape. for
>> instance, is abysmally written. Some of the current toolkits
>> suffer from an excess of debug code, the price of youthfulness.
>
> "average user" means "average computer user", not "average unix power user".
> I'm talking about the desktop. Client-server gui's are so seldom needed on
> the desktop that the overhead that X imposes is for the benefit of a few at
> the cost of the many.
The point I am making is that you probably have a limited
experience with large scale commercial UNIX and VMS installations
in which the clients and servers reside on different machines. Our
large scale servers don't even support frame_buffer consoles -
they have "dumb" HP terminals instead. Our 400 users access
applications on multiple application servers using PC X server
programs (Reflection X primarily because 3M has a special
relationship with WRQ and HP in the development of HP emulation
software).
>
> To quote the sage "Spock" (yes, that's a joke) "The needs of the many
> outweigh the needs of the few".
>
>> But as for average users in the X11 community, excepting home
>> Linux users, many if not most depend on the client - server
>> relationship X affords. The primary application I support uses
>> PC's running ReflectionX as the Xservers.In one location alone,
>> we have 400 users accessing a single application server.
>
> And just how common is this compared to the average PC usage around the
> world?
X11 predates GUI's on desktop PC's. There is an enormous
installed customer base of legacy software. It works, it works
over a LAN, it even works fairly well over high speed WAN's.
>
>> Application upgrades are easy - just change the software in one
>> location and you were done. I usually do that from home
>> connecting over X11 (like I am now).
>
> This is quickly becoming a moot point as remote desktop support software
> becomes more prevalent. It simply makes more sense to spend extra effort on
> the rare circumstances than to force the common circumstance to perform
> worse.
>
>> That system is being replaced with a
>> more PC centric one. The 400 megabytes of application software is
>> about to be replaced by 400 gigabytes of software loaded on 100's
>> of PC's. System upgrades will now require a dozen techs working
>> overtime to get things installed and configured on the various
>> PC's, our testing now has to be QA'd over windows 95,98,NT,2K and
>> ME and soon XP, yada yada.
>
> Decentralization means fewer central points of failure that can bring
> everyone down, not just one machine.
Sorry, we still have a central point of failure and it's the same
one we've always had - the database server.
>
>> The client server design allows me to easily connect to dozens of
>> different machines, as I routinely do. And the ability to run
>> Virtual Xservers like Xvnc allows me to run Virtual desktops
>> on a multitude of machines. I run Xvnc on my Linux host whose
>> monitor has virtually bitten the dust.
>>
>> I even run X locally on my WinME just so I can use my favorite
>> editor Nedit (thank you Cygwin).
>
> Indeed. So, you'd rather impose your needs on everyone, when as you claim,
> you can just run a program or service to get the same effect.
I am not imposing my needs on anyone - I'm just using the tools
that work. And mind you that "service" I'm using still is an
X server talking to X clients. I have also run VNC to my PC at
work to use applications I have no desire to put on my home
machine. Only, because of the GDI, the VNC server on NT has to
poll the screen, a process that is both slow and often
inaccurate.
>
>> While we're at it - Xlib is the API. A toolkit is something that
>> sits on top of the raw API and makes it easier to use. It is the
>> toolkit that has the higher level concepts of "buttons",
>> "windows", "shells" and dialogs. Xt (X tookit) was the first.
>> Motif was written on top of Xt and you can often interchange
>> Xt and Xm functions. Other toolkits like Tk, ftlk, gtk and qt
>> were either written on top of Xt or directly on top of the Xlib
>> API.
>
> XLib is not the base API, the X Protocol is. Technically, sockets is the
> API, since you can replace XLib with anything you want.
A protocol is a protocol, not an Application Programming
Interface. Xlib is the API.
>
>> Finally, we might discuss the other benefits of client-server.
>> In X, the clients generally only have to manage their own
>> behavior - there is another master client, the window manager,
>> that manages the interactions between the windows - their size,
>> placement, iconification, etc. If a client gets hung up, you
>> can easily iconify it. Not so with windows. And there is a
>> consistency of behavior with X that is missing with GDI. For
>> instance, the Solitaire program still does it's own double click
>> interpretation.
>
> Putting more work on the application author. Window managers are part of
> the problem, really. Since what happens when the window manager dies? The
> end-user gets quite confused unless they know exactly how X works.
Well, I can't speak for some of the newer window managers,
particularly under Linux. But I would say the windows managers
I've used - mwm, vuewm, and dtwm, crash about as often as my
UNIX systems panic. And all of our systems together (about 25,
at last count) have paniced once in the last 36 months (latest
figures I have). Except I can't remember even 1 window manager
crash in that length of time.
X11 works. It is more robust than directly writing to the frame
buffer. And with modern PC's is not significantly slower than
writing directly while being much safer. It can be frustrating
to write X11 codesfor people used to writing straight line code.
For anyone whose ever had to work in communications or interface
to a database using callbacks, it is relatively simple.
--
Dan Mercer
dame...@mmm.com
Dan Mercer
b...@this-is.invalid (Bob Hauck) writes:
> On Sat, 30 Jun 2001 16:38:27 -0500, Erik Funkenbusch <er...@visi.com>
> wrote:
>
>> the problem, really. Since what happens when the window manager dies?
>
> difference is that a knowledgeable user has a chance of fixing the X
> problem, much less so the Windows one.
>
>
I had to reboot my NT on Friday because my IE froze in full screen
mode. I couldn't get at my desktop, because there was no window
manager to iconify the window. So I killed it in Task Manager,
but somehow that made the mouse act funny (acting as if the left
button were continually depressed). So, of course, I had to
reboot.
Dan Mercer
> We're talking about people that get confused by the term "hit any key".
> This is always likely to be a problem with Linux, that the Linux developers
> give users too much credit for intelligence or ability to figure things out.
> While it's nice to give the user the ability to not have their hand held,
> that won't make you #1.
Some of my 400 users taped their mouses to their monitors - one
used it as a foot pedal (she was a church organist). And you know
what - they didn't know they were using X11! They double clicked
on an icon to get to the application, they used the mouse almost
exactly as they had in windows (with the exception that they could
cut and paste solely with the mouse). The organization of the
data into menus, dialogs and buttons was identical - and it
should be since both Microsoft and Motif were written to the same
common GUI spec. In short, they had no idea they were using
something different.
Donal K. Fellows
> "Dan Espen" <da...@mk.telcordia.com> wrote:
>> When my window manager dies, I get a prompt asking me if I'd like to
>> strart a window manager and which one I'd like to start.
>
> How exactly does that work? I've never seen such a prompt. When the window
> manager crashes, it's gone and you're stuck with windows without any way to
> control them.
It depends on what you're using as session management software. If your
session manager is set up right, then it could handle all this for you
automatically. I have no idea what the prevalence of such things is though.
What I don't like is where the window manager and the session manager are
closely interlinked (even the same thing) but that seems to be a very common
configuration (not just in the Unix/X world; Windows exhibits similar sorts
of properties except some window manager functions are distributed to the
applications[*].)
</digression>
Anyway, the way it works is that the session manager detects that the window
manager has crashed (via its exit code) and takes appropriate action to deal
with it (starting a new one, popping up a prompt, or whatever.) It is
possible to set things up so that crashes get a restarted X server[**], and
the other kinds of exit codes indicate whether a logout or swap of WM kind
is desired.
Donal.
[* So some kinds of app crashes/deadlocks leave a window you cannot interact
with in any way, not even to kill it off. I've not always even had good
responses from the task manager... ]
[** This is actually non-trivial, since you need to watch out for the case
where the WM is crashing during initialisation. ]
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- Thanks, but I only sleep with sentient lifeforms. Anything else is merely
a less sanitary form of masturbation.
-- Alistair J. R. Young <avatar...@arkane.demon.co.uk>
Christer Palm
>
> The difference is that Windows hide most of its complexity from the user,
> and he has to encounter it only on rare occasions.
>
Not only do they hide it, but most of the time the tools to do
nontrivial tasks are simply nonexistant. At least in my own
experience...
--
Christer Palm
Erik Funkenbusch
What does that have to do with figuring out how to restart the window
manager when it crashes?
Dan Mercer
And what does a window manager crashing have to do with:
"X less elegant than Windows' GDI?"
It's certainly no less difficult for the average user to restart
Windows Explorer than it is to restart a crashing window manager.
(i.e. Ctrl-Alt-Del). The only difference is that a mature window
manager like mwm or dtwm almost never crashes but WE does all the
time.
Erik Funkenbusch
You do realize that topics drift, right? And that you must follow the
thread of the topic and not rely on it's subject all the time?
> It's certainly no less difficult for the average user to restart
> Windows Explorer than it is to restart a crashing window manager.
> (i.e. Ctrl-Alt-Del). The only difference is that a mature window
> manager like mwm or dtwm almost never crashes but WE does all the
> time.
Well, ctrl-alt-del is a simple way to kill a task, less so with X in which
you need to either bring up a command shell and type several commands to
figure out the process ID and kill it, or have some other tool installed
which can be different on every machine.
But that's really not my point. Once it's killed, you need to restart it.
And that means you need to know the name of it, and possibly where it is.
Ayende Rahien
Can you name some of those non-trivial tasks?
It's usually, though not always, ignorance of the tools, rather their
non-existance.
Christer Palm
> > nontrivial tasks are simply nonexistant. At least in my own
> > experience...
>
> Can you name some of those non-trivial tasks?
> It's usually, though not always, ignorance of the tools, rather their
> non-existance.
Sure, first of all, most Windows software is centered around the GUI.
There's seldom a mechanism for simple programmatic interaction and
access to the tools logic. This, in turn, is often essential for
integrating and combining different tools, to extend or customize their
functionality and to use all this for automating tasks.
The base tools available to support this, like the MS-DOS command
interpreter and *shrug* the Macro Recorder is so ridicolously primitive
that they could more or less be considered bad jokes.
So once Joe user realizes that he/she needs to do something beyond the
explicit capabilities of the application in question, he doesn't have
much choice. This could be as simple as beeing able to sort the output
from an application in a particular manner, to be able to access the
application remotely, or to be able to make a complex selection among
numerous data elements presented to the user, just to name a few
examples.
Note that this is more about heritage and philosophy than technical
limitations of the platform.
--
Christer Palm
Ayende Rahien
Indeed, this is based on the philosophy of not doing everything as seperate
executable, but rather as packing code in components.
Scripting is very useful tool on Windows, provided that you know how to use
them.
You can do most of what you can do in unix in Windows, the difference is
that you do it differently.
Marc Britten
type fvwm do?
i've had explorer lockup so bad that you can't get the start button to
come up, so they can't just logout and log back in by clicking.
if explorer dies how does the user restart it?
In article <EN307.6642$B7.12...@ruti.visi.com>, "Erik Funkenbusch"
Buddy Raster
[ 2 lines out of a 74-line message ]
Trim 'em down, please.
Like source code, there's many more readers than writers.
Stuart Fox
"Dan Mercer" <dame...@mmm.com> wrote in message
news:9hpus1$q78$4...@magnum.mmm.com...
> In article <2fQ%6.6434$B7.12...@ruti.visi.com>,
> cut and paste solely with the mouse). The organization of the
Why can't you cut and paste solely with the mouse in Windows? Right click,
Cut, Right Click Paste?
George Peter Staplin
>
> ok, so explorer just locked up. what does this user who won't know how to
> type fvwm do?
>
> i've had explorer lockup so bad that you can't get the start button to
> come up, so they can't just logout and log back in by clicking.
>
> if explorer dies how does the user restart it?
Well, in Win95 to restart explorer when it has problems you can do
ctrl-alt-delete, select explorer, and then wait for the shutdown screen
and select cancel. In a second it should come up with a dialog box
asking if you want to end the explorer task, select yes, and then
explorer will be automatically restarted assuming that your
SHELL=explorer.exe in the system.ini. Not very intuitive I must say.
Anyway, I'm not a winadvocate.
George
Donal K. Fellows
> Why can't you cut and paste solely with the mouse in Windows? Right click,
> Cut, Right Click Paste?
Pasting is a middle-button operation. Everyone knows tha... or do you
lack such standard things as a middle button? :^)
Donal.
--
"While this is anecdotal, and thus bound to be ignored by all the pedanticism-
fascists out there, I have owned a fully-loaded copy of Emacs and many other
gnutilities for many years, and have never had a fatality yet."
Mark H. Wood
[snip]
> Indeed, this is based on the philosophy of not doing everything as seperate
> executable, but rather as packing code in components.
> Scripting is very useful tool on Windows, provided that you know how to use
> them.
Aye, there's the rub. Apparently some people were born with innate
knowledge of these "components", 'cos I've never found a reference for
them anywhere.
> You can do most of what you can do in unix in Windows, the difference is
> that you do it differently.
You do it without correct, complete, or comprehensible documentation,
for one thing. Not that Unix documentation is anything to write home
about, either, but it's better.
There are psychological barriers to entry, as well. I'm still not
entirely convinced that I can make invisible, non-interactive scripts
using a language called *Visual* Basic. Tool Command Language is a
much more reassuring name.
But this is veering off topic, so I'd better shut up now.
Mark H. Wood
> Pasting is a middle-button operation. Everyone knows tha... or do you
> lack such standard things as a middle button? :^)
You mean Button-2. :-)
But again this is moving offtopic. To shove it back in the right
direction....
Either X or GDI is less elegant for some value of "elegant". I value
the ability to export the UI of a single application (which X does but
MS Windows still doesn't) and I use it all the time. While legions of
programmers tackle the task of converting dozens of sysadmin tools to
RPC-aware client/server pairs, on X I can use remotely any tool
written for local use because the server (the X server) already exists
and the client code is in the GUI libraries. And the majority of
useful compute cycles are still accounted for by people who are able
to understand this without developing a headache.
So, which is less elegant: the windowing system that does more under
the covers, or the one that forces *me* to do more in order to get
what I want?
--
Mark H. Wood, Lead System Programmer mw...@IUPUI.Edu
"You misunderstand." -- Gnut
Donal K. Fellows
> The performance hits I'm talking about are in the translation of calls.
> Even with the shared memory implementation of X on a local system, the calls
> must be translated to the X protocol, and then translated back to binary.
> Further, since X is an asynchronous protocol, there is no immediate
> notification of errors, so the application cannot respond as quickly.
>
> GDI is synchronous, which allows each call to know of error at the time the
> call is made.
This is usually not an issue in practise, BTW, and there's always
synchronous mode for when you are trying to track down the most awful
problems. (IME, you can work out what's failing pretty trivially
without it, but what do I know; I just develop X applications...)
> I agree, memory isn't that big of a deal. The biggest issue to me is the
> asynchronous nature of X, and the overhead of the protocol. Other issues
> include latency between context switches, and the lack of ubiquitious
> widgets.
Remember, Unix context switches are faster than Windows context switches
(because it does a lot of them and great effort is put into making them
fast! :^) The protocol overhead is not that great, particularly in
local mode (you're effectively shoving the data into a struct very similar
to the arguments to the function itself and copying that through to the
remote end, which is fast with a local transport mechanism) and the
batching effects that you can get with the protocol can even speed things
up by making several protocol requests get transferred for processing in
one go. Am I correct in saying that, by contrast, every graphics call in
Windows has its own context switch?
The lack of ubiquitous widgets is fair. Except not everyone things that
it is a bad thing. (But that's a different discussion altogether!)
Ayende Rahien
"Mark H. Wood" <mw...@mhw.ULib.IUPUI.Edu> wrote in message
news:9hsi7h$60k$1...@hercules.iupui.edu...
> In comp.windows.x Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
> > Pasting is a middle-button operation. Everyone knows tha... or do you
> > lack such standard things as a middle button? :^)
>
> You mean Button-2. :-)
>
> But again this is moving offtopic. To shove it back in the right
> direction....
>
> Either X or GDI is less elegant for some value of "elegant". I value
> the ability to export the UI of a single application (which X does but
> MS Windows still doesn't)
For crying out loud, how many times do we have to say it?
Yes, it can do it.
Yes, it does do it.
Yes, it's working very good.
The only problem is with fsck-uped application that uses global registry
keys/files to store settings. That would be a problem under X as well.
> and I use it all the time. While legions of
> programmers tackle the task of converting dozens of sysadmin tools to
> RPC-aware client/server pairs, on X I can use remotely any tool
> written for local use because the server (the X server) already exists
> and the client code is in the GUI libraries.
No change of code is neccecary to run an application via Terminal Services.
> And the majority of
> useful compute cycles are still accounted for by people who are able
> to understand this without developing a headache.
>
> So, which is less elegant: the windowing system that does more under
> the covers, or the one that forces *me* to do more in order to get
> what I want?
GDI, because it does more under the covers.
Ayende Rahien
> In comp.windows.x Ayende Rahien <do...@spam.me> wrote:
> [snip]
> > Indeed, this is based on the philosophy of not doing everything as
seperate
> > executable, but rather as packing code in components.
> > Scripting is very useful tool on Windows, provided that you know how to
use
> > them.
>
> Aye, there's the rub. Apparently some people were born with innate
> knowledge of these "components", 'cos I've never found a reference for
> them anywhere.
http://www.msdn.com
Will give you the details of most of the components that ships with windows.
For the rest, you have to ask the vendor for information, just as you would
on linux.
> > You can do most of what you can do in unix in Windows, the difference is
> > that you do it differently.
>
> You do it without correct, complete, or comprehensible documentation,
> for one thing. Not that Unix documentation is anything to write home
> about, either, but it's better.
MS' documentation is pretty good.
It has been increasingly better. I remember checking CArray's documentation
on MSDN 6.0a, the helicopter joke made *sense*, all of a sudden.
Can you give some examples of something that you want to do on Windows that
you couldn't find documentation for?
> There are psychological barriers to entry, as well. I'm still not
> entirely convinced that I can make invisible, non-interactive scripts
> using a language called *Visual* Basic. Tool Command Language is a
> much more reassuring name.
Actually, it's VBScript, so you don't have to do anything visual about it.
You actually *can't* do much about visualization in VBS, the max is dialog
box, IIRC.
Beside, you can use Perl, Pyton, Javascript & (IIRC) EMCAScript too.
So this is a non-issue.
> But this is veering off topic, so I'd better shut up now.
Why? This is actually an interesting subject.
Dan Mercer
You aren't cutting and pasting with the mouse - you are using the
mouse to bring up a menu that cuts and pastes. Still, even this
capability wasn't available until Windows 95. Our users had full
mouse cut and paste in 1991 when we began our project. Of course,
the capability predates 1991.
Dan Espen
> Can you give some examples of something that you want to do on Windows that
> you couldn't find documentation for?
Minimize any window with a single keystroke.
Preferably the same keystroke for all windows.
Using Alt, Shift, Ctrl in combination with the key would be OK
but not required.
Marc Britten
<do...@spam.me> wrote:
> http://www.msdn.com
> Will give you the details of most of the components that ships with
> windows. For the rest, you have to ask the vendor for information, just
> as you would on linux.
hrm, I seem unable to resolve that host name, perhaps you mean
http://msdn.microsoft.com
> Can you give some examples of something that you want to do on Windows
> that you couldn't find documentation for?
well for one thing the vbscript lang. reference never once mentions the
use of logical and in an if statement. you can do it its simply AND, but
its not documented
Marc Britten
typing fvwm isn't much harder. I would rather have my window manager die
than lock up. I've never seen a window manager lockup
and under NT4 it is sometimes possible to get 2 instances of explorer
running and THAT really screws things up, in X only one windowmanager can
run at a time.
marc
In article <3B418484...@XMission.com>, "George Peter Staplin"
Erik Funkenbusch
Well, apart from windows which disable minimizing, you can simply type
alt-space-n or alt-underscore-n for MDI client windows.
You can also create a shortcut key to minimize all windows just by linking
to the Show Desktop icon in the quick launch then assigning your own hotkey
to the shortcut.
Dan Espen
> "Dan Espen" <da...@mk.telcordia.com> wrote in message
> news:m3g0cdy...@cc253090-a.sumt1.nj.home.com...
> > "Ayende Rahien" <do...@spam.me> writes:
> >
> > > Can you give some examples of something that you want to do on Windows
> that
> > > you couldn't find documentation for?
> >
> > Minimize any window with a single keystroke.
> > Preferably the same keystroke for all windows.
> > Using Alt, Shift, Ctrl in combination with the key would be OK
> > but not required.
>
> Well, apart from windows which disable minimizing, you can simply type
> alt-space-n or alt-underscore-n for MDI client windows.
Doesn't work for XEmacs.
Doesn't work for W98->Programs->Accessibility->Magnifier.
Alt space n is one more keystroke than I specified.
I don't want any windows to disable minimizing.
This is the "elegant" OS. Why isn't the OS in control of
its windows. Why is the burden on the applications?
> You can also create a shortcut key to minimize all windows just by linking
> to the Show Desktop icon in the quick launch then assigning your own hotkey
> to the shortcut.
Sorry, I don't understand.
I don't want to minimize all windows, just the one thats currently focused.
I don't have a "show desktop icon".
I'm not sure what a "quick launch" is, but I can tell you that this elegant
OS has a bunch of redundant ways to launch things. The only one thats quick
is the one that lets you use Ctrl-Alt-x to launch an app, but I'm looking
to minimize things.
Marc Britten
<er...@visi.com> wrote:
> Well, apart from windows which disable minimizing, you can simply type
> alt-space-n or alt-underscore-n for MDI client windows.
but can you define this to whatever key combination you want? no, might
be possible w/ system hooks and registering hotkeys, but that would take
some programming
Dan Espen
I don't see how thats possible. The "Alt-space" stuff seems to be
the responsibility of the application.
Erik Funkenbusch
> "Erik Funkenbusch" <er...@visi.com> writes:
>
> > "Dan Espen" <da...@mk.telcordia.com> wrote in message
> > news:m3g0cdy...@cc253090-a.sumt1.nj.home.com...
> > > "Ayende Rahien" <do...@spam.me> writes:
> > >
> > > > Can you give some examples of something that you want to do on
Windows
> > that
> > > > you couldn't find documentation for?
> > >
> > > Minimize any window with a single keystroke.
> > > Preferably the same keystroke for all windows.
> > > Using Alt, Shift, Ctrl in combination with the key would be OK
> > > but not required.
> >
> > Well, apart from windows which disable minimizing, you can simply type
> > alt-space-n or alt-underscore-n for MDI client windows.
>
> Doesn't work for XEmacs.
Isn't XEmacs a DOS program? If so, it's probably trapping the keys.
> Doesn't work for W98->Programs->Accessibility->Magnifier.
Hmm.. works fine for Magnifyer in Win2k and XP.
> Alt space n is one more keystroke than I specified.
Well, I didn't realize that extra keystroke would kill you. You use Emacs,
the king of multi-keyed commands.
> I don't want any windows to disable minimizing.
Well, as a programmer, I sometimes want to disable it (for instance, in
embedded applications).
> This is the "elegant" OS. Why isn't the OS in control of
> its windows. Why is the burden on the applications?
It's not. The OS handles it for you, but if you decide to disable it, you
can.
> > You can also create a shortcut key to minimize all windows just by
linking
> > to the Show Desktop icon in the quick launch then assigning your own
hotkey
> > to the shortcut.
>
> Sorry, I don't understand.
>
> I don't want to minimize all windows, just the one thats currently
focused.
I was just saying that IF you wanted to do this, you could.
> I don't have a "show desktop icon".
If you have 98, you have it, you know.. the icons on the task bar that you
can launch programs from?
> I'm not sure what a "quick launch" is, but I can tell you that this
elegant
> OS has a bunch of redundant ways to launch things. The only one thats
quick
> is the one that lets you use Ctrl-Alt-x to launch an app, but I'm looking
> to minimize things.
And tell me how much you'll appreciate that one key minimize when you
accidentally hit it while typing.
Ayende Rahien
"Dan Espen" <da...@mk.telcordia.com> wrote in message
news:m3g0cdy...@cc253090-a.sumt1.nj.home.com...
Alt+Space+n is fine by you? Works on (nearly) all windows.
Alt+- (hypen) + n for the inner windows in MDI applications
Ayende Rahien
> "Erik Funkenbusch" <er...@visi.com> writes:
>
> > "Dan Espen" <da...@mk.telcordia.com> wrote in message
> > news:m3g0cdy...@cc253090-a.sumt1.nj.home.com...
> > > "Ayende Rahien" <do...@spam.me> writes:
> > >
> > > > Can you give some examples of something that you want to do on
Windows
> > that
> > > > you couldn't find documentation for?
> > >
> > > Minimize any window with a single keystroke.
> > > Preferably the same keystroke for all windows.
> > > Using Alt, Shift, Ctrl in combination with the key would be OK
> > > but not required.
> >
> > Well, apart from windows which disable minimizing, you can simply type
> > alt-space-n or alt-underscore-n for MDI client windows.
>
> Doesn't work for XEmacs.
Probably because it is a port, and not a true Windows application.
> Doesn't work for W98->Programs->Accessibility->Magnifier.
Yes, it does. It doesn't minimize the magnifying bar, but it does minimize
the control window.
> Alt space n is one more keystroke than I specified.
> I don't want any windows to disable minimizing.
Hm, I don't think you can do that.
> This is the "elegant" OS. Why isn't the OS in control of
> its windows. Why is the burden on the applications?
Um, the OS is in control of its windows. But you've to allow the application
to control its windows, otherwise you are severaly limiting what you can do
with the application.
> > You can also create a shortcut key to minimize all windows just by
linking
> > to the Show Desktop icon in the quick launch then assigning your own
hotkey
> > to the shortcut.
>
> Sorry, I don't understand.
>
> I don't want to minimize all windows, just the one thats currently
focused.
Those tools should help you do it:
http://download.cnet.com/downloads/0-1461989-100-913626.html?tag=st.dl.10001
-103-1.lst-7-2.913626
http://download.cnet.com/downloads/0-1461991-100-5066449.html?tag=st.dl.1000
1-103-1.lst-7-4.5066449
> I don't have a "show desktop icon".
WinKey+M would minize all the windows.
Ayende Rahien
"drsquare" <now...@nowhere.com> wrote in message
news:r3u4kt4hir8h03rij...@4ax.com...
> On Tue, 3 Jul 2001 20:19:12 -0500, in comp.os.linux.advocacy,
> ("Erik Funkenbusch" <er...@visi.com>) wrote:
>
> >"Dan Espen" <da...@mk.telcordia.com> wrote in message
> >news:m3ae2ly...@cc253090-a.sumt1.nj.home.com...
>
type
> >> > alt-space-n or alt-underscore-n for MDI client windows.
> >>
> >> Doesn't work for XEmacs.
> >
> >Isn't XEmacs a DOS program? If so, it's probably trapping the keys.
>
How do I minimize an X application via the keyboard?
> >> I don't want any windows to disable minimizing.
> >
> >Well, as a programmer, I sometimes want to disable it (for instance, in
> >embedded applications).
>
> Well, as a user, I want control over my program.
Sorry, you can't do that *anywhere*.
A program does what the programmer told it to do (to the letter, literally.)
not what the users wants it to do.
A programmer may tell the program to do what the user want to, but the user
it limited to the amount of foresight of the programmer.
> >> This is the "elegant" OS. Why isn't the OS in control of
> >> its windows. Why is the burden on the applications?
> >
> >It's not. The OS handles it for you, but if you decide to disable it,
you
> >can.
>
> I thought it was the programmer disabling it?
Yes, using the OS.
> >> I don't have a "show desktop icon".
> >
> >If you have 98, you have it, you know.. the icons on the task bar that
you
> >can launch programs from?
>
> I'm using 98 and I don't have one.
Right click on the taskbar>Toolbars>Quick Launch.
There it is.
Marc Britten
<er...@visi.com> wrote:
> "Dan Espen" <da...@mk.telcordia.com> wrote in message
> news:m3ae2ly...@cc253090-a.sumt1.nj.home.com...
>> Doesn't work for XEmacs.
>
> Isn't XEmacs a DOS program? If so, it's probably trapping the keys.
no, XEmacs is a windows program
>> I'm not sure what a "quick launch" is, but I can tell you that this
> elegant
>> OS has a bunch of redundant ways to launch things. The only one thats
> quick
>> is the one that lets you use Ctrl-Alt-x to launch an app, but I'm
>> looking to minimize things.
>
> And tell me how much you'll appreciate that one key minimize when you
> accidentally hit it while typing.
like that damn windows key that pops up the start button taking the focus
away from my program and when i hit escape the start button is still
focuses just not up?
or how about when a app in the start bar is blinking and i click on the
annoying thing so it can show me why the hell its blinking and it
minimizes itself?
Marc Britten
<do...@spam.me> wrote:
> "drsquare" <now...@nowhere.com> wrote in message
> news:r3u4kt4hir8h03rij...@4ax.com...
>> Well, as a user, I want control over my program.
>
> Sorry, you can't do that *anywhere*.
> A program does what the programmer told it to do (to the letter,
> literally.) not what the users wants it to do.
> A programmer may tell the program to do what the user want to, but the
> user it limited to the amount of foresight of the programmer.
in X the window manager will get the keypress event first, then pass it
through to the actual application, therefor if i want to over ride
something the programmer did w/ a window manager function i can, very
easily, do this.
marc
Dan Espen
> "drsquare" <now...@nowhere.com> wrote in message
> news:r3u4kt4hir8h03rij...@4ax.com...
> > On Tue, 3 Jul 2001 20:19:12 -0500, in comp.os.linux.advocacy,
> > ("Erik Funkenbusch" <er...@visi.com>) wrote:
> >
> > >"Dan Espen" <da...@mk.telcordia.com> wrote in message
> > >news:m3ae2ly...@cc253090-a.sumt1.nj.home.com...
> >
> > >> > Well, apart from windows which disable minimizing, you can simply
> > >> > type alt-space-n or alt-underscore-n for MDI client windows.
> > >>
> > >> Doesn't work for XEmacs.
> > >
> > >Isn't XEmacs a DOS program? If so, it's probably trapping the keys.
XEmacs runs as a native windows program, it just
doesn't honor alt-space-n, exactly like MS Magnifier 1.0.
Its a hit or miss proposition.
Under X, a separate program, the window manager provides the
means to minimize programs. The user controls the window manager.
Under Windows, the application program decides what a key does.
Most applications honor Alt-space-n, but some don't.
> How do I minimize an X application via the keyboard?
On my Sun workstation, I hit the "Open" key. (It makes sense,
the same key toggles window state.)
Given the capabilities of X, its a relatively simple matter to
configure a window manager to close a window on any keystroke, a mouse
click, or even a mouse gesture.
> > >> I don't have a "show desktop icon".
> > >
> > >If you have 98, you have it, you know.. the icons on the task bar that
> > >you can launch programs from?
> >
> > I'm using 98 and I don't have one.
>
> Right click on the taskbar>Toolbars>Quick Launch.
> There it is.
Hmm, everything on my Toolbars menu is grayed out.
I don't think launching programs is the issue though.
If this is leading up to launching programs using a mouse,
don't make me laugh.
Getting back to minimizing windows with a single keystroke,
so far, X can do it, Windows can't.
Seems like I minimize windows quite often. Usually when I'm switching
from one task to another. I sure do appreciate that I can reach for
one key and just press it.
Tim Smith
>(because it does a lot of them and great effort is put into making them
>fast! :^)
Got any actual measurements of this? Last time I actually measured
(2.2.x kernel vs NT 4), they were about the same speed, both for
context switches between processes, and context switches between
threads in the same process.
--Tim Smith
Stuart Fox
> In article <C6f07.755$pj4.1...@news02.tsnz.net>,
> "Stuart Fox" <stua...@nospam.hotmail.com> writes:
> >
> > "Dan Mercer" <dame...@mmm.com> wrote in message
> > news:9hpus1$q78$4...@magnum.mmm.com...
> >> In article <2fQ%6.6434$B7.12...@ruti.visi.com>,
> >> exactly as they had in windows (with the exception that they could
> >> cut and paste solely with the mouse). The organization of the
> >
> > Why can't you cut and paste solely with the mouse in Windows? Right
click,
> > Cut, Right Click Paste?
>
> You aren't cutting and pasting with the mouse - you are using the
> mouse to bring up a menu that cuts and pastes. Still, even this
> capability wasn't available until Windows 95. Our users had full
> mouse cut and paste in 1991 when we began our project. Of course,
> the capability predates 1991.
I'd rather have the context menu thanks, rather than bind my mouse actions
to a particular function.
Michel Bardiaux
>
[snip]
>
> > This is the "elegant" OS. Why isn't the OS in control of
> > its windows. Why is the burden on the applications?
>
> It's not. The OS handles it for you, but if you decide to disable it, you
> can.
>
precisely, the thread handling messages for that window) is in a
CPU-bound loop, minimization is delayed until the CPU task is done.
--
Michel Bardiaux
Peaktime Belgium S.A. Rue Margot, 37 B-1457 Nil St Vincent
Tel : +32 10 65.44.15 Fax : +32 10 65.44.10
Ayende Rahien
"Marc Britten" <yug...@monochromatic.com> wrote in message
news:20010703.230330....@killerloop.monochromatic.net...
What happen if the application doesn't support minimizing?
As for windows, posting WM_MINIMIZE would do for all the application that
support minimizing, I posted the URL of two programs that let you do it.
Ayende Rahien
WinKey+M, MenuKey, Up, enter, Ctrl+Shift+Tab, Tab, Up-Down to play with
resultion size, enter to confirm.
Marc Britten
<do...@spam.me> wrote:
> "Marc Britten" <yug...@monochromatic.com> wrote in message
> news:20010703.230330....@killerloop.monochromatic.net...
>> in X the window manager will get the keypress event first, then pass it
>> through to the actual application, therefor if i want to over ride
>> something the programmer did w/ a window manager function i can, very
>> easily, do this.
>
> What happen if the application doesn't support minimizing?
never heard of such a thing, why would i want a program on my system to
not be iconifyed? some programs support it better than others(giving
more info to the window manager for special icons and actions as an icon)
however all programs can by iconifyed.
windows programs that can't be iconified and don't show up in the
explorer bar are annoying.
> As for windows, posting WM_MINIMIZE would do for all the application
> that support minimizing, I posted the URL of two programs that let you
> do it.
like i said earier, using system hooks and registering hotkeys would do
it, but we are talking about builtin functionality of the system's here.
thats a 3rd party application.
marc
Marc Britten
and probably not customizable.
In article <9hv3t0$loc$1...@taliesin.netcom.net.uk>, "Ayende Rahien"
Marc Britten
to a particular function?
In article <Nrz07.867$pj4.1...@news02.tsnz.net>, "Stuart Fox"
Donal K. Fellows
> "Mark H. Wood" <mw...@mhw.ULib.IUPUI.Edu> wrote:
>> There are psychological barriers to entry, as well. I'm still not
>> entirely convinced that I can make invisible, non-interactive scripts
>> using a language called *Visual* Basic. Tool Command Language is a
>> much more reassuring name.
>
> Actually, it's VBScript, so you don't have to do anything visual about it.
> You actually *can't* do much about visualization in VBS, the max is dialog
> box, IIRC.
But "Tool Command Language" is a much cooler and reassuring name...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- OK, there is the MFC, but it only makes the chaos object orientated.
-- Thomas Nellessen <nell...@gmx.de>
Ayende Rahien
> In article <9hv3su$loc$1...@taliesin.netcom.net.uk>, "Ayende Rahien"
> <do...@spam.me> wrote:
>
> > "Marc Britten" <yug...@monochromatic.com> wrote in message
> > news:20010703.230330....@killerloop.monochromatic.net...
>
> >> in X the window manager will get the keypress event first, then pass it
> >> through to the actual application, therefor if i want to over ride
> >> something the programmer did w/ a window manager function i can, very
> >> easily, do this.
> >
> > What happen if the application doesn't support minimizing?
>
> never heard of such a thing, why would i want a program on my system to
> not be iconifyed? some programs support it better than others(giving
> more info to the window manager for special icons and actions as an icon)
> however all programs can by iconifyed.
>
> windows programs that can't be iconified and don't show up in the
> explorer bar are annoying.
In that case, Show Desktop does the same thing, but for all applications,
not just one of them.
Personally, I rarely, if even, use minimizing, I like to work with maximized
windows.
> > As for windows, posting WM_MINIMIZE would do for all the application
> > that support minimizing, I posted the URL of two programs that let you
> > do it.
>
> like i said earier, using system hooks and registering hotkeys would do
> it, but we are talking about builtin functionality of the system's here.
> thats a 3rd party application.
Not really, this is a functionality that is built into the system, you just
need the tool to utilize it.
Ayende Rahien
> damn! thats uglier than ANY emacs command.
>
> and probably not customizable.
He wanted the key to change resulotions.
Not the way. :-)
Tim Smith
>Can you give some examples of something that you want to do on Windows that
>you couldn't find documentation for?
1. Write a virtual CD-ROM driver that handles audio. I had to spend a
month disassembling CDFS.VXD and stepping throught things with
Soft-ICE to find out what the hell actually happens at the driver
level when an application does an MSCDEX call to start or stop audio
playback.
2. Write a Winsock LSP that uses WPUModifyIFSHandle that does not
cause IE to have trouble loading images on pages with lots of small
graphics.
Here's one that I would have been able to say last week, but they just
came out with a new Knowledgebase entry covering this: transfer data
between a client and server running on the same Win2K machine, via
TCP, at faster than 30 KB/second. (There is a bug: when you make a
connection to 127.0.0.1, Win2K sets the MTU to a very large value,
which makes TCP very inefficient, limiting throughput to about 30
KB/sec. Solution: if there is another network interface on the
machine that has an IP address, just connect to that IP address
instead of 127.0.0.1. If you don't have another network interface, so
you don't have an alternative IP address to use...they have an update
available that replaces the TCP stack).
--Tim Smith
Donal K. Fellows
> I'd rather have the context menu thanks, rather than bind my mouse actions
> to a particular function.
I'd rather have both a context menu *and* mouse-only menu-less
select-and-paste. I've written apps that had that, and which users
used to both the Unix/X and Windows ways of doing things were satisfied
with. (Contact me offline if you want the URL for a trial version. :^)
Donal K. Fellows
Nope. Was just repeating hearsay! (Observed differences in apparent
speed of multiple processes must be due to something else, like the
scheduler or the way memory is managed. Which I could believe.)
Donal ("I saw it on USENET so it must be true!!!")
Dan Mercer
"Donal K. Fellows" <fell...@cs.man.ac.uk> writes:
> Stuart Fox wrote:
>> I'd rather have the context menu thanks, rather than bind my mouse actions
>> to a particular function.
>
> I'd rather have both a context menu *and* mouse-only menu-less
> select-and-paste. I've written apps that had that, and which users
> used to both the Unix/X and Windows ways of doing things were satisfied
> with. (Contact me offline if you want the URL for a trial version. :^)
>
> Donal.
Nedit, IMHO the world's best visual editor, supports both a user
customizable menu (right click) and mouse only cut & paste and
supports rectangular selection and a secondary selection mode that
allows you to swap primary and secondary selections - plus text
dragging. It has become my editor of choice for all platforms -
thank you Cygwin.
--
Dan Mercer
dame...@mmm.com
Opinions expressed herein are my own and may not represent those of my employer.
Erik Funkenbusch
news:3B431BCD...@cs.man.ac.uk...
> Tim Smith wrote:
> > "Donal K. Fellows" <fell...@cs.man.ac.uk> wrote:
> >> Remember, Unix context switches are faster than Windows context
switches
> >> (because it does a lot of them and great effort is put into making them
> >> fast! :^)
> >
> > Got any actual measurements of this? Last time I actually measured
> > (2.2.x kernel vs NT 4), they were about the same speed, both for
> > context switches between processes, and context switches between
> > threads in the same process.
>
> Nope. Was just repeating hearsay! (Observed differences in apparent
> speed of multiple processes must be due to something else, like the
> scheduler or the way memory is managed. Which I could believe.)
I think the biggest difference is in the expense of process creation.
Process creation (with fork()) is much less expensive than creating a
process in Win32, but once the process is created, then context switching is
about the same. Also, it's possible to tune this value on NT.
Also, NT does a bit more during idle-time than Unix. NT is constantly
pairing down working sets to create maximum free memory.
Lew Pitcher
wrote:
>> Nope. Was just repeating hearsay! (Observed differences in apparent
>> speed of multiple processes must be due to something else, like the
>> scheduler or the way memory is managed. Which I could believe.)
>
>I think the biggest difference is in the expense of process creation.
>Process creation (with fork()) is much less expensive than creating a
>process in Win32, but once the process is created, then context switching is
>about the same. Also, it's possible to tune this value on NT.
Pardon my interruption, but...
Wow!! I've finally found someone else who's willing to make a
statement that's contrary to current _popular opinion_.
Thanks ;-)
>Also, NT does a bit more during idle-time than Unix. NT is constantly
>pairing down working sets to create maximum free memory.
>
>
>
Lew Pitcher, Information Technology Consultant, Toronto Dominion Bank Financial Group
(Lew_P...@td.com)
(Opinions expressed are my own, not my employer's.)
Erik Funkenbusch
news:3B42D3C4...@peaktime.be...
> Erik Funkenbusch wrote:
> >
> [snip]
> >
> > > This is the "elegant" OS. Why isn't the OS in control of
> > > its windows. Why is the burden on the applications?
> >
> > It's not. The OS handles it for you, but if you decide to disable it,
you
> > can.
> >
> I doubt that. From my observations, if the applicatioon (or more
> precisely, the thread handling messages for that window) is in a
> CPU-bound loop, minimization is delayed until the CPU task is done.
That's a different issue. The app gets the message first, which is what
allows it to disable it, 99% of the time the app just sends it to the
default window handler which is part of Windows. In earlier versions of
Windows, if the app wasn't responding to messages, then the default handler
was never called. In newer versions (Win2k+) then it does indeed minimize
the app, especially if you "Minimize all apps".
Erik Funkenbusch
> On Wed, 4 Jul 2001 15:52:15 +0200, in comp.os.linux.advocacy,
> >news:20010703.230330....@killerloop.monochromatic.net...
>
> >> > A program does what the programmer told it to do (to the letter,
> >> > literally.) not what the users wants it to do.
> >> > A programmer may tell the program to do what the user want to, but
the
> >> > user it limited to the amount of foresight of the programmer.
> >>
> >> in X the window manager will get the keypress event first, then pass it
> >> through to the actual application, therefor if i want to over ride
> >> something the programmer did w/ a window manager function i can, very
> >> easily, do this.
> >
> >What happen if the application doesn't support minimizing?
>
> whether it likes it or not. Unlike on Windows, with Linux the user
> controls his own computer.
Which would make X a poor choice for an embedded application then, since you
don't want users of your kiosk stand to be minimizing the app.
Lew Pitcher
wrote:
>"drsquare" <now...@nowhere.com> wrote in message
How so? You condem X when the failure is in the sysadm/configurer's
error in not selecting the proper WM for the environment. If you're
running a kiosk, why would you _choose_ a WM that permits the user to
minimize? For that matter, in some cases, why would you choose a WM at
all?
Remember what a WM does: it provides those pretty borders and 'system'
controls that make interaction with multiple apps easy. A WM only does
as much, *or as little*, as it has been programmed to do. I can easily
see a 'minimal WM' for kiosk-like situations that just provides
borders and handles for window movement *and nothing else*. Or, if you
want one (and only one) window open and active, why choose _any_ WM?
Why not just start the X app origined at 0,0, and "maximized" to the
screen size. That way, there are no borders, handles or system
controls to cause problems.
Dan Mercer
Oh, please! Do you even think this stuff through before posting?
Stuart Fox
rght clicked.
"Marc Britten" <yug...@monochromatic.com> wrote in message
news:20010704.092259....@killerloop.monochromatic.net...
Bob Hauck
wrote:
> Process creation (with fork()) is much less expensive than creating a
> process in Win32,
Yes, especially in the common case where a parent is forking off a copy
of itself to handle a request. No disk IO in that case.
> but once the process is created, then context switching is about
> the same.
The last study I saw claimed that NT was slower at context switching
under light loads, but faster under very heavy loads. The conjectured
reason for this was that Linux keeps a simple list while NT has some
more complex data structure that is faster to search when there are
lots of runnable processes, but slower when there are only a few.
Sorry, I don't have a URL handy.
> Also, it's possible to tune this value on NT.
Tune what value? The algorithm for picking a process to run? Or the
time slice? I know you can tune the latter on NT, didn't think you
could do the former.
> Also, NT does a bit more during idle-time than Unix. NT is constantly
> pairing down working sets to create maximum free memory.
Which explains why my NT box will go swap-happy in order to keep 50% of
it's memory free at all times. That does not seem like what you want,
but somebody must have thought so.
--
-| Bob Hauck
-| To Whom You Are Speaking
-| http://www.haucks.org/
r...@swissonline.ch
>> On Tue, 3 Jul 2001 20:19:12 -0500, in comp.os.linux.advocacy,
>>
>> >"Dan Espen" <da...@mk.telcordia.com> wrote in message
>>
>> >> > Well, apart from windows which disable minimizing, you can simply
> type
>> >> > alt-space-n or alt-underscore-n for MDI client windows.
>> >>
>> >> Doesn't work for XEmacs.
>> >
>> >Isn't XEmacs a DOS program? If so, it's probably trapping the keys.
>>
>
> How do I minimize an X application via the keyboard?
I've used most window managers under X. I also have a Sun keyboard connected
to my PC via an adapter. First thing I configure with any window manager is
map the Sun keypad Open key to [de]iconify. The Front key I map to raise/lower.
I've used Sun's and Sun keyboards for so long that I can't live without those
2 keys. Of course I can map any key I want with most window managers to any
funtion they provide. I can add qualifiers like the ctrl key, altkey, etc.
With many window managers you can specify what action to take based on where
the focus is at any time: the title bar, side bars, in an application window.
I know that sometimes window managers break the ICCCM to provide some of
these features but it certaily makes X very configurable.
--
Over 100 security bugs in Microsoft SW last year. An infamous
record. The worst offending piece of SW, by far, IIS. 2001 isn't
looking any better.
Marc Britten
<do...@spam.me> wrote:
> In that case, Show Desktop does the same thing, but for all
> applications, not just one of them.
so we are talking about different functionality. i don't want to minimize
all, i want to minize one
> Personally, I rarely, if even, use minimizing, I like to work with
> maximized windows.
ack
>> > As for windows, posting WM_MINIMIZE would do for all the application
>> > that support minimizing, I posted the URL of two programs that let
>> > you do it.
>>
>> like i said earier, using system hooks and registering hotkeys would do
>> it, but we are talking about builtin functionality of the system's
>> here. thats a 3rd party application.
>
> Not really, this is a functionality that is built into the system, you
> just need the tool to utilize it.
ok, lets put it this way, using the standard X setup on my machine w/ no
extra tools i can do exactly what i want. By doing some custom
programming or using a 3rd party's tool i MAY be able to recreate the
same functionality on windows.
Marc Britten
> Which would make X a poor choice for an embedded application then, since
> you don't want users of your kiosk stand to be minimizing the app.
you can also take away the functionality, like he said the user controls
the functionality. in this case its not the user whos standing in front
of the kiosk its the user(as in username) thats logged in. make it so
the user can only run the one app, and tell the windowmanager that you
don't want that functionality bound to anything
Marc Britten
context menu(if one is supplied by the application). using any tools
availible on windows it is not possible to reregister the right click to
anything else that i'm aware of.
marc
In article <NqK07.923$pj4.1...@news02.tsnz.net>, "Stuart Fox"
Mark H. Wood
> "Mark H. Wood" <mw...@mhw.ULib.IUPUI.Edu> wrote in message
> news:9hsh2s$5ha$1...@hercules.iupui.edu...
>> In comp.windows.x Ayende Rahien <do...@spam.me> wrote:
>> [snip]
>> > Indeed, this is based on the philosophy of not doing everything as
> seperate
>> > executable, but rather as packing code in components.
>> > Scripting is very useful tool on Windows, provided that you know how to
> use
>> > them.
>>
>> Aye, there's the rub. Apparently some people were born with innate
>> knowledge of these "components", 'cos I've never found a reference for
>> them anywhere.
>
> http://www.msdn.com
> Will give you the details of most of the components that ships with windows.
Haha. Been there, done that, couldn't find the tee-shirt. I've lost
hundreds of hours trawling through the MSDN site *and* the stuff that
comes with the tools.
You've heard of spaghetti code? Microsoft practices spaghetti
documentation. It's all in an amorphous heap, and anywhere I reach in
and pull out a strand, it's the wrong strand. It *looks* organized,
but often isn't organized in any way that I find useful.
>> > You can do most of what you can do in unix in Windows, the difference is
>> > that you do it differently.
>>
>> You do it without correct, complete, or comprehensible documentation,
>> for one thing. Not that Unix documentation is anything to write home
>> about, either, but it's better.
>
> MS' documentation is pretty good.
Careful, I've worked with VMS and OS/370 documentation. Study those
corpi carefully before you say that some bit of documentation is
"pretty good".
> Can you give some examples of something that you want to do on Windows that
> you couldn't find documentation for?
Okay. I want to write a screensaver which will, when it triggers,
locate any running instances of the Internet Explorer UI and force
them back to the user's start page.
First, I had to schlep all around the Web looking for something that
would help me figure out how to actually write a screensaver. I found
that, eventually, and wondered why this little bit of information
couldn't have been plainly written into the MSDN material that passes
for screensaver doco. You have to find someone who has actually
written a working screensaver -- apparently the MSDN tech writers
never talked to such a person.
Then I went looking for information on IE's automation interfaces.
I'm still looking for something that actually makes sense.
>> There are psychological barriers to entry, as well. I'm still not
>> entirely convinced that I can make invisible, non-interactive scripts
>> using a language called *Visual* Basic. Tool Command Language is a
>> much more reassuring name.
>
> Actually, it's VBScript, so you don't have to do anything visual about it.
Yup. Visual Basic Script. And I know what MS means by "Visual":
relentlessly interactive, unable to cope with the concept of a
computer doing something without a human to hold its metaphoric hand.
As I said, this is a *psychological* barrier. VBscript isn't really
very "visual", but the name has associations which have prevented me
getting serious about using for many months.
> You actually *can't* do much about visualization in VBS, the max is dialog
> box, IIRC.
Yes, now that I've overcome my reluctance to get involved with it, I'm
actually finding that it is *less* visual than I had hoped.
> Beside, you can use Perl, Pyton, Javascript & (IIRC) EMCAScript too.
> So this is a non-issue.
It is an issue if you want to accomplish something with the tools that
come with the OS. Tcl is not only less off-putting for background
tasks, but I'm far more productive with it; however its presence can't
be assumed on some arbitrary box. Jscript, perhaps, but I'm betting
that its documentation is no better than the pathetic excuse for
VBscript documentation. And again, Jscript is usually discussed in
terms of the pretty visual effects you can get on Web pages, which is
almost but not quite exactly unlike what I want to do.
--
Mark H. Wood, Lead System Programmer mw...@IUPUI.Edu
Make a good day.
Mark H. Wood
> On Wed, 4 Jul 2001 15:52:15 +0200, in comp.os.linux.advocacy,
> ("Ayende Rahien" <do...@spam.me>) wrote:
>>What happen if the application doesn't support minimizing?
>
> whether it likes it or not. Unlike on Windows, with Linux the user
> controls his own computer.
Let's see if I can get this right (just to nudge things back on-topic
for comp.windows.x). The application *thinks* it has created a
top-level window. However, the window manager has created a window
which it decorates with various buttons, captions, handles, etc. and
makes the app's "top" window a child of that window. (It is allowed
to do this because it identified itself to the X server as the current
window manager.)
When you request minimization, the button expressing the request is a
control created by the window manager. It tells the X server to unmap
the toplevel window it created to frame the app, which unmaps all
children as well. So the app's whole window hierarchy gets unmapped.
The app. is notified that its windows have been unmapped, and it could
try to remap them, but the window manager has the veto.
IIRC an app. can refuse to let the window manager have control of a
toplevel, but then it gets no window management services *at all* for
that hierarchy. This is considered so limiting that it is only done
in very special circumstances.
Donal K. Fellows
> "Erik Funkenbusch" <er...@visi.com> wrote:
>> Which would make X a poor choice for an embedded application then, since
>> you don't want users of your kiosk stand to be minimizing the app.
> Why not just start the X app origined at 0,0, and "maximized" to the
> screen size. That way, there are no borders, handles or system
> controls to cause problems.
Just draw directly on the root window. It's not sacred or anything...
(X can be stripped down much harder than Windows, or so it seems. That
makes it much *more* suitable for embedded applications, as anyone that
has ever seen a station or airport announcement board partially obscured
by one of those annoying popup notices - the ones that Windows seems to
be unable to disable - can tell you...)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- US citizens? Remember, I rule the world in this scenario. They aren't
citizens of the US, unless that stands for United Stevenland.
-- Steven Odhner <ta...@primenet.com>
Mark H. Wood
> "drsquare" <now...@nowhere.com> wrote in message
> news:uai6kt40m2ftpnii7...@4ax.com...
>> >What happen if the application doesn't support minimizing?
>>
>> It doesn't get a say in the matter. The window manager minimised it
>> whether it likes it or not. Unlike on Windows, with Linux the user
>> controls his own computer.
>
> Which would make X a poor choice for an embedded application then, since you
> don't want users of your kiosk stand to be minimizing the app.
No. You tell the *window manager* that this app. should not get a
minimize button. In fact, for a kiosk you may want to create a
custom-designed window manager to give you exactly the behavior
appropriate to such a restricted environment.
Dan Espen
> In comp.windows.x drsquare <now...@nowhere.com> wrote:
> > On Wed, 4 Jul 2001 15:52:15 +0200, in comp.os.linux.advocacy,
> > ("Ayende Rahien" <do...@spam.me>) wrote:
> [snip]
> >>What happen if the application doesn't support minimizing?
> >
> > It doesn't get a say in the matter. The window manager minimised it
> > whether it likes it or not. Unlike on Windows, with Linux the user
> > controls his own computer.
>
> Let's see if I can get this right (just to nudge things back on-topic
> for comp.windows.x). The application *thinks* it has created a
> top-level window. However, the window manager has created a window
> which it decorates with various buttons, captions, handles, etc. and
> makes the app's "top" window a child of that window. (It is allowed
> to do this because it identified itself to the X server as the current
> window manager.)
>
> When you request minimization, the button expressing the request is a
> control created by the window manager. It tells the X server to unmap
> the toplevel window it created to frame the app, which unmaps all
> children as well. So the app's whole window hierarchy gets unmapped.
> The app. is notified that its windows have been unmapped, and it could
> try to remap them, but the window manager has the veto.
Most of this seems pretty accurate, but I believe the application can
unmap itself. I don't believe the window manager can stop that, the
most it could do is unmap it again.
I believe some versions of xterm will work that way. If some long
running job in an xterm prints something, I think you get the xterm to
map inself.
> IIRC an app. can refuse to let the window manager have control of a
> toplevel, but then it gets no window management services *at all* for
> that hierarchy. This is considered so limiting that it is only done
> in very special circumstances.
Those are override-redirect windows.
Useful for things like screen savers.
And supremely annoying when used for splash screens.
Colin Day
>
> > But again this is moving offtopic. To shove it back in the right
> > direction....
> >
> > Either X or GDI is less elegant for some value of "elegant". I value
> > the ability to export the UI of a single application (which X does but
> > MS Windows still doesn't)
>
> For crying out loud, how many times do we have to say it?
> Yes, it can do it.
> Yes, it does do it.
> Yes, it's working very good.
>
> The only problem is with fsck-uped application that uses global registry
> keys/files to store settings. That would be a problem under X as well.
>
X in MS Windows, yes. But X in Linux?
--
Colin Day aa #1500
BAAWA-nnabe
r...@swissonline.ch
It is clear that EF is pretty ignorant of X. The ability to configure
window managers is a big plus for X.
A major gripe I have with windows is its inconsistency. At work I run
metaframe on my Sun workstation (running Debian GNU Linux). I need
metaframe to read exchange email. Now my company is 99% MS on the
desktop. The comapany address book is accessible to me from
Outlook. So I want to get someone's email address from the address
book to send to someone else. I use exmh as my Unix MUA. I'm composing
an email and I open the metaframe window to get the persons email
address. I search for the persons name in the address book and select
the email address tab. There's the email address so I try and copy
it. Can't do it. Just not possible. Why? So I decide to email the
person using outlook. I start composing my email and then access the
address book to get the email address. Ok, I already know I can't copy
it so I'll bring my compose window to the front and manually write the
email address shown in the address book. Oops, I can't do it as the
address book popup has taken what we X guys call a global grab. The
email addrees I want to copy is hidden by my compose window. I must
dismiss the address book email addresses popup before I can continue.
What incredible crap.
Ayende Rahien
> In comp.windows.x Ayende Rahien <do...@spam.me> wrote:
> > Can you give some examples of something that you want to do on Windows
that
> > you couldn't find documentation for?
>
> Okay. I want to write a screensaver which will, when it triggers,
> locate any running instances of the Internet Explorer UI and force
> them back to the user's start page.
Personally, I think that this would be rude.
Why would you want to do it?
> First, I had to schlep all around the Web looking for something that
> would help me figure out how to actually write a screensaver.
Index:
screen savers, creating 32-bit
> Then I went looking for information on IE's automation interfaces.
> I'm still looking for something that actually makes sense.
Well, the simplest way to do it would be to iterate over the IE windows, and
close them, then open as many windows as you closed.
*Not* optimal, of course. I don't think that it's possible to do this, you
want to control another proccess(es), this require their cooporation.
Bob Hauck
> I need metaframe to read exchange email.
It would be less expensive to simply enable IMAP on the Exchange server.
> The comapany address book is accessible to me from Outlook.
The Exchange server also exports the address book as LDAP. You can use
one of the OpenLDAP tools to download a copy for your Unix mailer. Or,
you can use Pine or Netscape or Mozilla >= 0.9.2 as your MUA.
> What incredible crap.
Well, they don't call it "Outhouse" for nothing.
The Ghost In The Machine
<r...@swissonline.ch>
wrote
on Thu, 5 Jul 2001 01:21:11 +0200
<7d80i9...@mandrake.swissonline.ch>:
>In article <9hvo35$kp$1...@magnum.mmm.com>,
> dame...@mmm.com (Dan Mercer) writes:
>> In article <G7J07.8668$B7.15...@ruti.visi.com>,
>> "Erik Funkenbusch" <er...@visi.com> writes:
[snip]
>>> Which would make X a poor choice for an embedded application then,
>>> since you don't want users of your kiosk stand to be minimizing
>>> the app.
>>
>> Oh, please! Do you even think this stuff through before posting?
>
>It is clear that EF is pretty ignorant of X. The ability to configure
>window managers is a big plus for X.
The ability to select between them is an even bigger one. :-)
Don't like fvwm? Switch to gwm, twm, olvwm, or ...
Fortunately, ignorance is curable in most cases.
[illustration of Windows' "compatibility" snipped]
--
ew...@aimnet.com -- insert random misquote here
EAC code #191 21d:02h:42m actually running Linux.
Microsoft. When you're not aggravated enough.
The Ghost In The Machine
<er...@visi.com>
wrote
on Wed, 4 Jul 2001 13:20:27 -0500
<G7J07.8668$B7.15...@ruti.visi.com>:
>"drsquare" <now...@nowhere.com> wrote in message
>news:uai6kt40m2ftpnii7...@4ax.com...
>> On Wed, 4 Jul 2001 15:52:15 +0200, in comp.os.linux.advocacy,
>> ("Ayende Rahien" <do...@spam.me>) wrote:
>>
[snip for brevity]
>> >What happen if the application doesn't support minimizing?
>>
>> It doesn't get a say in the matter. The window manager minimised it
>> whether it likes it or not. Unlike on Windows, with Linux the user
>> controls his own computer.
>
>Which would make X a poor choice for an embedded application then, since you
>don't want users of your kiosk stand to be minimizing the app.
Not a problem if there's no window manager. (Yes, X can run in such
a mode, and fairly easily, too.)
Or one can write a very stupid window manager that does nothing,
if one's worried about rogue applications for whatever reason.
(Basically, it would attach itself to the root window (XSelectInput(),
then eat events.)
--
ew...@aimnet.com -- insert random misquote here
EAC code #191 21d:23h:29m actually running Linux.
This is a .sig.
.
> In comp.os.linux.advocacy, Erik Funkenbusch
> <er...@visi.com>
> wrote
> on Wed, 4 Jul 2001 13:20:27 -0500
> <G7J07.8668$B7.15...@ruti.visi.com>:
>>"drsquare" <now...@nowhere.com> wrote in message
>>news:uai6kt40m2ftpnii7...@4ax.com...
>>> On Wed, 4 Jul 2001 15:52:15 +0200, in comp.os.linux.advocacy,
>>> ("Ayende Rahien" <do...@spam.me>) wrote:
>>>
> [snip for brevity]
>>> >What happen if the application doesn't support minimizing?
>>>
>>> It doesn't get a say in the matter. The window manager minimised it
>>> whether it likes it or not. Unlike on Windows, with Linux the user
>>> controls his own computer.
>>
>>Which would make X a poor choice for an embedded application then, since you
>>don't want users of your kiosk stand to be minimizing the app.
> Not a problem if there's no window manager. (Yes, X can run in such
> a mode, and fairly easily, too.)
> Or one can write a very stupid window manager that does nothing,
> if one's worried about rogue applications for whatever reason.
> (Basically, it would attach itself to the root window (XSelectInput(),
> then eat events.)
9wm would seem perfect.
-----.
--
Whats the sound of the world out there?
Those crunching noises pervading the air?
Its man devouring man, my dear, and who are we to deny it in here?
Christer Palm
>
> On Fri, 06 Jul 2001 20:32:48 GMT, in comp.os.linux.advocacy,
> (ew...@lexideb.athghost7038suus.net (The Ghost In The Machine))
> wrote:
>
> >
> >Not a problem if there's no window manager. (Yes, X can run in such
> >a mode, and fairly easily, too.)
>
Huh? I don't see how running an app without a window manager necessarily
makes it "look like shit". Embedded apps often doesn't (shouldn't?) use
window-based UI's anyway but use a single window covering the whole
screen (imagine an ATM that would require you to foul around with a
mouse). If you still want windows you can - as already pointed out -
easily make your own custom window manager, or use one of the many
already available that allows you to configure the behaviour you need.
--
Christer Palm