Other window systems

Other window systems

Post by jik- » Sat, 14 Nov 1998 04:00:00



I do not understand this sudden migration of people wanting to get rid of
X!!
X is a great desktop environment platform, code written for X is very
portable...only the underlying non-X code is not compatable,...which is
why Xlib has all sorts of function wrappers to replace these non-standard
utility functions.  The X consortiums idea of designing a 'system, not a
policy' I think is one of the best things about X,...although granted it
does result in a wide range of programs which have differentr looks and
are likely not friendly....it does allow you do do whatever you want.

Anyway, without going on and on and on about this,....I personally think
we would do much better to create systems on top of X, hopefully complying

to the X standards and protocols so that they are compatable with other
programs.

 
 
 

Other window systems

Post by Christopher B. Brow » Sun, 15 Nov 1998 04:00:00


The *main* problem with X is in that none of those "abundant" widget
toolkits have ever been sufficiently superior to "kill off" the
alternatives.

You either get:

a) NeXTStep, that might be superior, but where the "license
management" issue prevents widespread adoption, or

b) Motif, which was the "least worst" alternative that the UNIX
vendors agreed on, which isn't particularly *good* by many metrics,
but that at least *is* specified, documented, and supported by many
vendors, or

c) Some "toolkit du jour," which is nice, fulfils some immediate need,
and someone else will write another one next week.  There are *lots*
of these.

Then you get
d) A language-dependent toolkit like Qt,

e) A "bandwagon-driven" toolkit like Gtk (which might become a
reasonable replacement for Motif),

f) Clones, like GNUStep, Lesstif, and Harmony, which seem to take
*years* to write because they have to replicate the bugs in the
environments they're replicating...

I'd say that GTK has the best chance (at this point) of anything out
there of being "the next toolkit."  It appears to be reasonably well
designed, and it comes "out of the box" with bindings to a good
half-dozen languages.

All that being said, then there's the *second* problem, which is that
the window managers all use different configuration schemes.  I can't
switch WMs, and have most of my configuration come along for the ride.

The *third* problem is that building a new windowing infrastructure
requires that you have a whole series of "levels of technology"
involved, from the "talkin' to chips" layer at the bottom, to the
applications up top.

Getting X to where it is today has been a 15 year project.  It would
perhaps only be a 5 year project if we restarted today, but note that
this sort of schedule means that there's not a usable system until
about 2004.

I'm not joking here at all; the Berlin Project is hoping to do
somewhat better than 2004, but I don't think they're expecting to have
a particularly useful system until into the next millennium.  Parallel
this with Be; they have been working * releases of Be for on the
order of 2 years now, and really only provide useful systems within
some tiny niches.

A "replace NeWS" project could be interesting; I keep hearing rumor of
there being some other GUI system at Sun that got squelched that might
even have been potentially better than NeWS.

But if a replacement system means that:

- AIS has to rewrite Xess [as an example of a commercial app],

- Tk isn't available, nor AWT or Swing [or some other widely-used
script-oriented toolkit],

- GNOME/KDE don't work (significant in that there is a *lot* of effort
going into them in the Linux community),

- There isn't a version of GhostScript/Xdvi available (or whatever
other bit of such infrastructure that gets used a lot),

- [Pick some crucial app written using an X library] doesn't work,

then the replacement will not get adopted, and probably won't get
these sorts of features.

GNUStep may provide a "route to replacement," as it can run atop X,
and is close now to the point of allowing the construction of useful
applications to the end of replacing the functionality that *needs* X.
In theory, we could build a frame buffer-based Display Ghostscript,
and eliminate the X component.

On the other hand, GNUStep doesn't support Tk/AWT/... applications,
and isn't likely to any time soon, so while it is a possible candidate
for the "let's build a new GUI system and new apps that don't have to
depend on X," it won't provide the rich functionality that X does, so
it is still not realistically an X replacement.
--
The real problem with the the year 2000 is that there are too many zero
bits and that adversely affects the global bit density. -- Boyd Roberts



 
 
 

Other window systems

Post by Scott Benn » Sun, 15 Nov 1998 04:00:00


: I do not understand this sudden migration of people wanting to get rid of
: X!!

I believe that the original post would have made more sense if it was
titled "other widget systems", not "window systems".  The writer appeared
to be quite happy with X, just not the programming layers above it that
we are sometimes forced to use.

I'm of the opinion just use Xaw and Xt.  Everything else has too many
contingencies, plus Xaw has been a default install for as long as I've
known of it, which means in all likelyhood, the user doesn't have to install
anything extra to make the app work.

-- Scott

Two *s were eating a clown. One * says to the
  other "Does this taste funny to you?"

 
 
 

Other window systems

Post by Michael Lankto » Sun, 15 Nov 1998 04:00:00



> I'm of the opinion just use Xaw and Xt.  Everything else has too many
> contingencies, plus Xaw has been a default install for as long as I've
> known of it, which means in all likelyhood, the user doesn't have to install
> anything extra to make the app work.

Carburetion was the standard means of delivering the air-fuel mix to
internal combustion engines since the 19th century.  Does that mean that
we shouldn't opt for fuel injection, which enjoys many benefits over
carburetion, simply because carburetion has been around longer?  Xaw is
a horrible tool kit.  Gtk is maturing quickly, is very full featured,
and has no offensive license to*anyone off.
 
 
 

Other window systems

Post by Roman Beleno » Sun, 15 Nov 1998 04:00:00



> I'm of the opinion just use Xaw and Xt.  Everything else has too many
> contingencies, plus Xaw has been a default install for as long as I've
> known of it, which means in all likelyhood, the user doesn't have to install
> anything extra to make the app work.

But Xaw looks UGLY. Patches like Xaw3d or neXtaw helps, but anyway Xaw
lucks some widgets like notebook or color selection dialog, so
different applications need to create them theirselves in different
ways.

Xaw is standard and it works Ok for small progs, but I don't think
that general user will prefer Xaw-based wordprocessor to Motif or Gtk
one.

--
                                                        With regards, Roman.

 
 
 

Other window systems

Post by Scott Benn » Sun, 15 Nov 1998 04:00:00



> Carburetion was the standard means of delivering the air-fuel mix to
> internal combustion engines since the 19th century.  Does that mean that
> we shouldn't opt for fuel injection, which enjoys many benefits over
> carburetion, simply because carburetion has been around longer?  Xaw is
> a horrible tool kit.  Gtk is maturing quickly, is very full featured,
> and has no offensive license to*anyone off.

Does that mean everyone who drives an automatic shift car should bust on
those that drive a manual, just because a manual drive doesn't have the
"features" of an automatic?

: But Xaw looks UGLY. Patches like Xaw3d or neXtaw helps, but anyway Xaw
: lucks some widgets like notebook or color selection dialog, so
: different applications need to create them theirselves in different
: ways.

There is an important saying that applies here: "To each their own."

Xaw does everything I need it to do, and if it doesn't, I dredge out the
docs and *learn* how to make it do what I want it to do.  

-- Scott

Two *s were eating a clown. One * says to the
  other "Does this taste funny to you?"

 
 
 

Other window systems

Post by jih » Sun, 15 Nov 1998 04:00:00




Quote:> X is a great desktop environment platform, code written for X is very
> portable...

That's about all that _is_ great about X.  The APIs are not so bad, even
the toolkit thing once you get used to it, and portability really is a
strong suit with X.

But those are programmer's concerns, which can be both myopic and
superficial.  There are other things in life, such as actually using
the machine to do something other than program it.

In other words, if it's such a great desktop enviornment _platform_,
why is it not a great desktop _environment_?


 
 
 

Other window systems

Post by Michael Lankto » Sun, 15 Nov 1998 04:00:00


Automatic transmissions are fine for Grandma's Corvair, but if you want
real performance you have to use a manual transmission.  But that has
nothing to do with GNUstep, and Xaw is still not an acceptable
alternative when there are such vastly superior toolkits available.  But
you are entitled to your opinion, as am I.


> Does that mean everyone who drives an automatic shift car should bust on
> those that drive a manual, just because a manual drive doesn't have the
> "features" of an automatic?

--
    .###.      
  /#######\##  -==============================================-
 ;#####    ;#                 Mike's WindowMaker
 ;#####    ;#  http://tasteslikechicken.ml.org/windowmaker.html
  \#      /##  -==============================================-
 ###'---'####
 
 
 

Other window systems

Post by jik- » Sun, 15 Nov 1998 04:00:00




> > I'm of the opinion just use Xaw and Xt.  Everything else has too many
> > contingencies, plus Xaw has been a default install for as long as I've
> > known of it, which means in all likelyhood, the user doesn't have to install
> > anything extra to make the app work.

> But Xaw looks UGLY. Patches like Xaw3d or neXtaw helps, but anyway Xaw
> lucks some widgets like notebook or color selection dialog, so
> different applications need to create them theirselves in different
> ways.

The thing about Xaw is, first it does come with the X system....second, for
computers with low resources it runs much smoother then any other widget set ever
will....third...if you have high performance there are excelent alternatives to
Xaw available which actually make it a rather nice alternative to the others....I
happen to really like Xaw-Xpm as a widget set not even considering it is Xaw....I
would use it if it were something new.  Granted, it lacks a lot of widgets....but
for apps that don't need a gob of widgets it is a very good alternative to the
monster toolkits that do.

There are good and bad things about Motif....it is considered a standard toolkit
although X does not come with it yet (I do believe that was the plan at one time
at least)  It at least follows current standard protocols.....and one thing I
like about it is that it does a lot of the ICCCM work for you....new shells
respond to delete by default, and the Text widgets respond to selections.  I
guess Gtk does respond to selections, but GIMP doesn't (so I just assumed Gtk
didn't either since gimp is the showline of GTK)

Thing about Gtk is that most of the standard widgets do not look all that
great...and without having xresources and translation tables I think it really
lacks a great deal as a development toolkit.  Also, I don't know how many people
know this, but Gtk failed to display on MI/X when I tried it....it must be
possible to get it to since gimp runs on win95, but it refused when run from a
distant Linux box.

ALL widget sets will have to be extended by the developer at some point....the
toolkit should not contain every widget that could ever be needed, and in fact
cannot.

But, with widget wars aside....I think what could really help out X is a
development style guidline that would allow more fo the similar widgets share the
same names...so that resources could be generally specified and a person could
get a similar l&f from a variety of different sets...a standard widget set will
never be accepted as a whole....people have to many different oppinions on the
matter.

Also, resources could be added to widgets that would allow for some setup program
to specify styles or something (more sofisticated then editres).  This could be
done in a protocol way as well, for those sets that refuse to respond to
xresources and editres.

Anyway, an idea....protocols and resources can be added on top of what already
exists in X which could dramatically improve the situation....throwing in new GUI
systems and widget sets does not help at all.

GGI might be all well and good when it is finished since it will be able to run X
among other things,...it doesn't really affect the problem we face at the moment.

 
 
 

Other window systems

Post by jik- » Sun, 15 Nov 1998 04:00:00


Quote:> In other words, if it's such a great desktop enviornment _platform_,
> why is it not a great desktop _environment_?

Because that is not what X was designed to be.X was designed to be an
extreemly portable, network efficient graphical display platform.
How is it worded in the books "X was designed to be a system, not a policy,
for windowing systems" or something like that.
Developing environments is stricktly up to the people who wish to develope
such a thing.  X has lots of ways in which protocols and systems can be
added to the entire system as a whole.  You can even extend the server by
loading in modules so that later extended protocol calls can be made (this
of course is less portable then plain X, but good protocols will be
implemented)  Shoot, Xlib and friends are only APIs to the X
protocol...don't like them, make something better,...but make sure it
complies to current standards (we all hate it when someone reinvents a
standard,...one large monster company comes to mind here).
Resources and translations allow the experienced user to modify most
everything in the applications they use.  There is not yet a way to do this
for the less experienced user, although the syntax is not hard to learn.
Since X is NOT designed as a policy, policies have to be designed and
published which all can use if they wish....developers need to cooperate to
create programs which can interact well together....the ICCCM takes care of
some of this, but there is some more that needs done.  Motif attempted to
do some of this, and since they use the current X protocol scemes, I think
thier attempt was a much more valid one,...
Granted, maybe some of the programmers do not like the X development model,
I do....but you are free to design a new one.  Its just that when you do,
this new model should respond to the same types of things that the old
do,...with some additions if you wish.  Gtk's rc file thing is all well and
good, but I for one think they should have either stuck with xresources, or
added them.
There are thousands of things that can be done to improve X, though none
seem to be happening.  I think one of the best things about X is the
freedom it expresses.  But freedom comes with a price, responsibility comes
to mind....
 
 
 

Other window systems

Post by lvir.. » Sun, 15 Nov 1998 04:00:00



:that general user will prefer Xaw-based wordprocessor to Motif or Gtk

If it's the general user that one truly cares about, then provide them with
the same, or better, functionality, in a _reasonable_ implementation (don't
require a 20 button mouse, or the user to type all text in backwards and
upside down, etc.) and they will be willing to use it.  They certainly
were willing to take a step down from MacOS to Windows - or down from
X and Xaw to Windows and Motif for that matter.
--

<*> O- <URL:http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

 
 
 

Other window systems

Post by Matthias Wark » Mon, 16 Nov 1998 04:00:00


jiho schrieb:



> > X is a great desktop environment platform, code written for X is very
> > portable...

> That's about all that _is_ great about X.  The APIs are not so bad, even
> the toolkit thing once you get used to it, and portability really is a
> strong suit with X.

> But those are programmer's concerns, which can be both myopic and
> superficial.  There are other things in life, such as actually using
> the machine to do something other than program it.

> In other words, if it's such a great desktop enviornment _platform_,
> why is it not a great desktop _environment_?

You understand nothing. Desktop environments are supposed to run on
top of it. Give me a sensible reason why a windowing system should
come with a desktop environment instead of allowing several ones to be
pluggend into it.

It's the X Windowing System, Version 11, Release 6. It's not the X
Desktop Environment or the Big Integrated X Desktop, GUI Library, User
Interface and Office Suite Gumball. Expect that kind of stuff from
other people.

mawa
--

My site's been cracked but it'll go up on another server soon. My Geek
Code is no longer in my .signature.  It's available on e-mail request.
/\/\/\\/\//\ (mawa) <-- this is why ASCII art in signatures is no good

 
 
 

Other window systems

Post by Chris Hans » Tue, 17 Nov 1998 04:00:00



Quote:(Christopher B. Browne) writes:

   GNUStep may provide a "route to replacement," as it can run atop X,
   and is close now to the point of allowing the construction of useful
   applications to the end of replacing the functionality that *needs* X.
   In theory, we could build a frame buffer-based Display Ghostscript,
   and eliminate the X component.

   On the other hand, GNUStep doesn't support Tk/AWT/... applications,
   and isn't likely to any time soon, so while it is a possible candidate
   for the "let's build a new GUI system and new apps that don't have to
   depend on X," it won't provide the rich functionality that X does, so
   it is still not realistically an X replacement.

GNUstep is a realistic X replacement because it is the most promising
route to getting extremely high quality end-user applications running
natively on Linux.

My gut tells me that many Mac developers would be more than happy to
do Linux versions of their software, provided it wasn't overly
difficult and provided they wouldn't be killed by support costs.

GTK, Qt, and friends don't address this, but GNUstep definitely does.
Write your applications for Yellow Box and run on MacOS X (Rhapsody)
and Windows 95/98/NT4, and also compile them GNUstep so they can run
on Linux (as well as Solaris, SunOS, HP-UX, AIX, Digital Unix,
BSD...).

There's also some great OPENSTEP software that already exists and
needs only to be ported.  If GNUstep isn't complete enough to port
these applications, they should be a good indicator of what needs to
be worked on.

GNUstep is also realistic because while it *can* be an X replacement,
it doesn't have to be.  Once the graphics API is sufficiently
abstracted, people like me may be able to run Display GhostScript or
some such and not deal with X at all (or deal with it by using
something like XNeXT to run X on top of DGS), while those who need to
use X still can use GNUstep on top of it.

 
 
 

Other window systems

Post by David B. Lew » Tue, 17 Nov 1998 04:00:00


|> I do not understand this sudden migration of people wanting to get rid of
|> X!!

I think people are very much swayed by what is "hot" as opposed to what
really works, what they can use today, what is widely available, etc.  A
mature technology becomes less interesting despite its advantages. Perhaps
there is an idea what whatever comes along must necessarily be an improvement
on what has gone before; but I don't think that this is true of the
alternatives available now.

I think, also -- and I say this in recognition of the countless
programmer-years that have gone into freely-available software and into
improvements in the base X software -- that the many people who say "let's do
something new" are in fact not the ones who do the work.

--
David B. Lewis      Editor, The Motif Developer: http://www.motifzone.com/tmd/

 
 
 

Other window systems

Post by David B. Lew » Tue, 17 Nov 1998 04:00:00


|> But Xaw looks UGLY. Patches like Xaw3d or neXtaw helps, but anyway Xaw
|> lucks some widgets like notebook or color selection dialog, so

But this is a general problem for any toolkit. Widget sets are designed to
handle 99% of the needs of 90% of the applications (substitute appropriate
numbers). That is, they provide almost all of the user interface capabilities
for the majority of programs, but they can't anticipate all the possible
application-specific widgets. Motif has added widgets; Xaw could, if it were
still being maintained actively. But there are many widgets available,
including supported commercial additions, to satisfy additional needs; and
the process of widget-writing is not so difficult as to preclude writing
additional widgets.

|> Xaw is standard and it works Ok for small progs, but I don't think
|> that general user will prefer Xaw-based wordprocessor to Motif or Gtk

I believe the original poster made the case for Xaw based on its wide-spread
availability and reasonable competence, not on UI issues.

--
David B. Lewis      Editor, The Motif Developer: http://www.motifzone.com/tmd/

 
 
 

1. windows desktop too slow compared to others: windows folder configuration question

Hello,

In Windows 2000 one can go to Control Panel -> Folder Options and
configure one of the following global options:
1. "Open each folder in the same window"
2. "Open each folder in its own window"

There are many instances when you would want to use both behaviors
(1 and 2) simultaneously. For example it could be that a user wants
to compare folder C:\A\B\C\D\foo\ with C:\A\B\C\D\E\bar\ . In this
case the user wants to end up with only two windows open.

With configuration 1, the user would have to travel from C: to foo
and then from C: to bar which means (2 clicks to open "My Computer"
and then "C:", followed by 4 clicks to open D plus one click to open
foo) + (2 + 5 clicks to open folder E + 1 click to open folder bar)
= 15 clicks in total.

With configuration 2, the user would have to click twice to open
"My Computer" and then C:, then click four times to open D\, which
is 6 clicks. Then the user needs to open foo\ with one click, and
E\bar\ with two clicks. That is 9 clicks. Finally, many redundant
folders cluttering the desktop will have to be closed which requires
7 clicks to close the "My Computer", C:, A, B, C, D, and E folders.
This sums up to a total of 9 + 7 = 16 clicks.

So, in each case, things are pretty long and tedious for the user.
Insetead, what Windows ought to do is give the user both options
(1 and 2) simultaneously from each folder. With such strategy
the above comparison of folders would require 2 clicks to
open "My Computer" and then "C:" followed by 3 clicks to
open folders A, B, and C using folder option 1. Then the
user would open two views of folder D with folder option
2. requiring 2 clicks. Then three clicks would be necessary
to open folders foo, E, and bar, using method 1. again.
No redundant windows are open on the desktop at this
stage so we are done. This is a total of 10 clicks
which beats the above methods by making desktop
usage speed roughly 50% times faster for this
particular example.

The way Windows could implement this improvement
is by allowing clicks on folders to use method
1. and double clicks to use method 2. or some
similar strategy. So why is this option not
available in Win2K. Does WinXP have it?
The Linux GNOME desktop seems to be
ahead of Windows with regards to
this desktop usability feature.

Neil Zanella

2. How long can a PATH env. variable be in Solaris 2.5.1

3. HELP- Shell to start several windows where typing in one window is echoed by others?

4. Setting up redhat linux 5.1 for a webserver

5. System functions in BSD and others *nix systems.

6. 2.x kernel reads behind end of HPFS partition

7. Can I prevent pinging from others and still ping others?

8. Failed to load Apache.pm

9. Teeing a Class of my X windows to others

10. More Windows Web Servers than all others combined

11. Watching others X windows

12. seeing the windows partition from Redhat 7.1, C: works, but not others

13. Finding out TCP peer receive window size using Berkeley Sockets (on Solaris and others) ?