Re: X is painful
On Tue, 19 Nov 1996, Karl M. Hegbloom wrote: Isn't X the GUI that started it all though? And the codes are there for all to see; so perhaps it served as the reference from which MSWindows, MAC and the others have evolved? The guys who wrote MAC and Windows must have studied X-Windows in college, right? Nah, Xerox at PARC invented the GUI, they actually made a computer that used it, but it was really bad. Both Steve Jobs (Mac guy) and Bill Gates visited PARC and saw their GUI. They both saw that this was where the computer interface should head. The rest is history. Bill And that environment is supposed to justify the complete Bill piece of crap that resulted? You're complaining about hand-me-downs. I'll bet there's some really neato in-house X stuff out there. Not just in-house stuff, CDE is pretty nice, and so is NEXTSTEP as has been mentioned. On a sidebar, has anyone noticed that all of Jobs's companies have had good UIs. Apple, Next, Shaya -- Shaya Potter [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: X is painful
On Wed, 13 Nov 1996, Bill Bumgarner wrote: Maybe I'm just spoiled by years of NEXTSTEP-- but, damnit, NEXTSTEP really is the most well-inntegrated user inrface *ever* built. Seriously. i suppose that's a matter of personal preference. I have to work with nextstep machines and can't stand it. it's bloated and it's horribly slow and i can't customise it anywhere near as much as i can X fvwm (and fvwm derivatives). I especially don't like the dock stealing an inch or so down the entire right-hand side of my screen. I much prefer clicking on the root window and getting a menu up: left-click for a launch menu, middle-click for window operations, and right-click for list of open windows. Functionality when i need it *WITHOUT* cluttering up my screen with crap i dont need all the time. I also intensely dislike next-style menus. I want menus inside the application window, not cluttering up the top left hand corner of my screen. I am also far from impressed by nextstep's lack of stability - damnit, unix boxes are *supposed to* stay up for months, not crash randomly for no apparent reason. It's also extremely fussy about what hardware it will run on - a big problem when motherboard models change every few months and it's almost impossible now to get the old pentium boards which nextstep will run on...newer HX VX boards either crash randomly or dont work at all. the latest compatibility problem is the adaptec 2940 driver. cant get the old 2940 cards any more...can only get 2940-AU cards. The driver notes for NS say that it works on 2940-AU cards. In practice it doesn't work at all...fails at install time with a message about can't get config space. (note, i've only really worked with intel version of nextstep, so can make no comment on stability of versions for other architectures except that black box next stations are slow by today's standards) All in all, my opinion of nextstep (as a user interface AND as a unix) can be accurately summed up as it was fabulous for 1988however it's 1996 now. Another summary: i'd rather use linux. A good user interface should be layered on top of a stable, reliable operating systemit shouldn't become an excuse for not creating that stability. Functionality stability come first. Prettiness second. I guess you like what you get used to. Craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: X is painful
On Wed, 20 Nov 1996, Shaya Potter wrote: On a sidebar, has anyone noticed that all of Jobs's companies have had good UIs. Apple, Next, But they still operate under the assumption that the user has three hands. Or at least a prehensile, well, never mind... | This is OFFICIAL WRITTEN notification that I want to be REMOVED | | from ALL commercial mailing lists. EVERY message sent from this | | account has had this request posted. ALL UNSOLICITED ADVERTISEMENTS | | SENT TO THIS ACCOUNT ARE IN VIOLATION OF FEDERAL (U.S.) LAW.| -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: X is painful
From: Shaya Potter [EMAIL PROTECTED] snip Nah, Xerox at PARC invented the GUI, they actually made a computer that used it, but it was really bad. Both Steve Jobs (Mac guy) and Bill Gates visited PARC and saw their GUI. They both saw that this was where the computer interface should head. The rest is history. snip Just a little aside. One of my jobs is for Xerox, and the Xerox workstations are pretty good. The UI and networking (XNS) are fully integrated, giving some very interesting and powerful side-effects. So interesting in fact that I understand that Novell licensed some it for NetWare 4. The workstations are Sparc based. Unfortunately they are dying out, as only Xerox internal development supports them, because neither the UI nor XNS became commercial products (don't ask me why). I know that Mac OS, Windows and Solaris are based on the PARC UI projects (there is even a thank you note to Xerox in the Solaris documentation), but this is not surprising seeing as Xerox developed the mouse, an early windowing environment, etc, whilst most other people hadn't even thought about a simple menu system. Thanks for listening | [EMAIL PROTECTED] | http://www.geocities.com/SiliconValley/Park/1152 | Simon Martin | Old software engineers never die, | they just fail to boot | | Any Trademarks used in this document are recognized | as Registered Trademarks of their respective owners. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
[OFF TOPIC]Re: X is painful
Is there a debian-talk list? This is surely a candidate. Bill So far the 'differences' have primarily been comprised of Bill just plain crappy UI. Some apps let you double-click to Bill select a word, some don't. Some let you triple-click to Bill select a paragraph, some don't. Some tab between fields, Bill some don't. Some have point to focus within individual Bill fields [tkman comes to mind], some don't. During editing, Bill some are bright enough to realize the user likely doesn't Bill want to lose focus on the field until they take some action Bill to end editing (ie; partial modality), most are not. It seems that the real problem is that the whole world doesn't agree with you. If everybody would just listen to you, we wouldn't have this problem, right? I'd rather be able to configure this behavior on a case by case basis. If there were a set of UI behaviors identified in this manner that could be offered as a set of configurable options, with perhaps some canned default option sets, I'd go for it. Outside of that, I don't think this is as big an issue as you're making it. Maybe I'm just not that uptight. Bill As well, now that OpenStep is being distributed by Sun [as Bill well as NeXT] and the GnuStep project is progressing nicely, Bill it will hopefully make inroads into more of the academic and Bill scientific computing centers. Just as long as it stays out of the Real World. We have a couple of Next boxes here and I can't think of a goofier, uglier GUI. I'm not a GUI programmer, so maybe its a neato devel platform, but 99.99% of people using computers aren't writing GUIs. Bill Regardless, whether or not OpenStep actually survives Bill through the end of this century, any developer who is Bill working on generic user interface coding projects-- such as Bill a window manager or process manager-- who has studied and Bill understood what NeXT has achieved is wasting their time. Again, I'm not a developer, but NeXT seems to have achieved virtual bankrupcy. Where's the lesson there? You know I've had plenty of great ideas too. The problem is that most of them sucked. Sort of like the NeXT interface. Bill NEXTSTEP/OpenStep is likely the single best example of Bill object oriented programming on a large scale in the Bill industry. The APIs are clean. The various frameworks work Bill together transparently. Portability is *not* an issue Bill [except when importing/exporting data]. Nothing touches it. Bill Period. Great. Another computer environment JUST for programmers. Bill So far, all signs indicate that software deployed within the Bill X community has made the same mistakes over and over Thats no reason to panic start thinking that NeXT step is the answer! I don't pretend to know the Right Thing to do, but I sure don't wish NeXT on anyone. The best thing I can think of doing in a GUI is offering the user the ability to configure it. Thats a whole lot more attainable than building THE GUI to beat all GUIs an forcing it on everyone. Just my $.02 Richard G. Roberto [EMAIL PROTECTED] 011-81-3-3437-7967 - Tokyo, Japan -- *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: [OFF TOPIC]Re: X is painful
From: Richard G. Roberto [EMAIL PROTECTED] I'm not a GUI programmer, so maybe its a neato devel platform, but 99.99% of people using computers aren't writing GUIs. Yes, it was wonderful to develop for. Again, I'm not a developer, but NeXT seems to have achieved virtual bankrupcy. I agree that Steve seems to spend a lot more time at Pixar these days. However the real problem with the NeXT interface was that it was too far ahead of its time - for example, it ran a PostScript renderer on a 68030 to operate the GUI, and that was a good lot of load for a 68030. Memory also cost 10 times more than it does now, so none of those systems had enough of it. They also had to license the renderer from Adobe for big bucks, or they would have been able to give the software away (which is what everyone else does when they want something to catch on in the market). The interface wasn't so bad, it's just that the computer wasn't up to running it. Hopefully GNUstep will catch on. I hope we can straighten out the compiler issues and have good GNUstep support on Debian. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: X is painful + GPLed solution
On Fri, 15 Nov 1996, Bill Bumgarner wrote: # Have look at the kde project. The problem with kde is that they use qt, which has a very restrictive license that makes it non-free software (in particular, they do not allow any modified version of the library to be distributed). Remember it is OO so you can easily create new classes Of course you are allowed to distribute your classes under the gpl. Yours, -- martin // Martin Konold, Muenzgasse 7, 72070 Tuebingen, Germany // // Email: [EMAIL PROTECTED] // Linux - because reboots are for hardware upgrades -- Edwin Huffstutler [EMAIL PROTECTED] -- Just go ahead and write your own multitasking multiuser os ! Worked for me all the times. -- Linus Torvalds -- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: X is painful + GPLed solution
Bill Bumgarner wrote:
# Have look at the kde project.
I will-- and if it is as cool as you make it sound, I'll happily put
together the debian packaging information...
The problem with kde is that they use qt, which has a very
restrictive license that makes it non-free software (in
particular, they do not allow any modified version of the
library to be distributed).
--
Debian GNU/Linux 1.1 is out! { http://www.debian.org/ }
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
{ http://greathan.apana.org.au/~herbert/ }
PGP Key: [EMAIL PROTECTED] or any other key sites
--
This message was distributed manually by [EMAIL PROTECTED] after the list
initially failed to distribute it.
Re: X is painful
Stephen Early wrote:
Ah. The X Window System is not a user interface. It is a standard by
which applications can drive displays and input devices. It provides
mechanism, not policy.
Sure. But I must remind you that we are concerned with
developping Debian, not X per se. Using the above as an
excuse to not making a coherent, and pretty graphical user
interface is IMHO not acceptable.
Creating a user interface under X that is as good as NextStep is just
a matter of getting every X application author to agree to adhere to
the same policy. I wish you luck.
I agree that this is very diffcult. But the Debian developers
should do their best at getting Debian programs to cooperate.
--
Debian GNU/Linux 1.1 is out! { http://www.debian.org/ }
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
{ http://greathan.apana.org.au/~herbert/ }
PGP Key: [EMAIL PROTECTED] or any other key sites
--
This message was distributed manually by [EMAIL PROTECTED] after the list
initially failed to distribute it.
Re: X is painful
[claws out] [box on] I have to vent. OK, I cannot believe that after HOW MANY years of development, X windows is still such a completely inconsistent and painful user interface. # I think you forgot to include open, free, expandable, flexible, . . . Free, yes. Expandable-- kinda, but not easily. Programming X is as painful as using X. Flexible-- sure... as a matter of fact, it is so flexible that almost *none* of the apps actually work with each other! The STUPIDITY of the whole thing is frustrating. # Oh, really! You would rather have a Mac type world then? # (Pay thru the nose, and get what you get from THE vendor) Hey, at least the Macintosh user interface is CONSISTENT! At least you can use the machine [well, when it doesn't crash] and know that certain fundamental primitives within the User Interface will work *the same*. I'd even go so far as to say the Mac-- in some respects-- is MORE customizable then X because it has a unified toolkit that everyone uses! You simply customize the toolkit and everything changes appropriately! Look-- X has been in development for, what, 10-15 years? As long or longer than the Mac, Windows, or NEXTSTEP... As well, the list of contributors covers all walks of life with the commputer industry-- quite literally the best and the brightest have contributed to X over the years. It is an open box developped with the constraints of 'market realities'. And that environment is supposed to justify the complete piece of crap that resulted? I think not; within that environment, I would think that *at least* one toolkit would have emerged as a sort of standard. Or, at the very least, the plain text pasteboard would work between all fields. From the sound of it, the above statement seems to indicate that BECAUSE X is free, it will always be inferior in quality to pay-through-the-nose UI? Along the same line of thought, one would think that Linux would be inferior to, say, NT or Mac OS. I'd like to think not... For example: Text fields between applications do not work the same. One is not guranteed to be able to copy/paste text between fields. Some fields must have the mouse pointer within them during the editing process, some don't. # The kind of car you and I drive ARE going to be different # (hopefully), cause we are allowed to do so. Just as the # programmers are allowed to express themselves through the # toolkits that they choose and/or write. I'm perfectly happy in a world where things look and act differently-- as long as the differences are because the behaviour is more ideally suited to the application in question. So far the 'differences' have primarily been comprised of just plain crappy UI. Some apps let you double-click to select a word, some don't. Some let you triple-click to select a paragraph, some don't. Some tab between fields, some don't. Some have point to focus within individual fields [tkman comes to mind], some don't. During editing, some are bright enough to realize the user likely doesn't want to lose focus on the field until they take some action to end editing (ie; partial modality), most are not. Yes-- it is WONDERFUL that X supports such a diverse and customizable environment. But that does not excuse the horrible excuses for UI that are rampant throughout the X community! # With X, a user can control the App thru X resources, granted # some of them are alittle brain-dead in this area, but this is # not the fault of X. But X resources have *nothing* to do with little things like some of the behaviour I described above or other trivialities such as There is no inter-application communication or awareness to speak of. # There are several. Again not the fault of X, they exist at a # different layer. There are many more than several. They are *all* incompatible. There is *no* standard means of encapsulating, communicating, or identifying the information that is passed around. The current stuff is just fine for two apps that are tightly bound-- but it just plain sucks within an environment where the user defines what apps will play which roles within their human-computer experience. The window manager has no awareness of what is running-- only what windows are on the screen. Because of this, various 'dock' programs are nothing more than a 'click the button to launch an app' system-- one cannot click on a button second time to simply activate the app in question. # Why should the WM be aware of what is running? # # It is a Window Manager, not a process manager and never was the # developers intentions. Well-- The window manager, as a manager of windows, really ought to know which windows are assigned to which processes. For example, what if I want to hide all the windows but those owned by, say, Mathematica? Hmmm... hiding windows-- sounds
Re: X is painful + GPLed solution
Oh well, scratch that one off the list of possible solutions to be
investigated... I guess I'm back at square one; pining for GnuStep.
b.bum
Begin forwarded message:
From agent Fri Nov 15 20: 35:17 1996
Sender: [EMAIL PROTECTED]
Date: Sat, 16 Nov 1996 13:34:49 +1100
From: Herbert Xu [EMAIL PROTECTED]
Organization: Core
X-Mailer: Mozilla 3.0Gold (X11; I; Linux 2.1.9 i586)
To: [EMAIL PROTECTED]
CC: debian-user@lists.debian.org
Subject: Re: X is painful + GPLed solution
Content-Type: text/plain; charset=us-ascii
Bill Bumgarner wrote:
# Have look at the kde project.
I will-- and if it is as cool as you make it sound, I'll happily put
together the debian packaging information...
The problem with kde is that they use qt, which has a very
restrictive license that makes it non-free software (in
particular, they do not allow any modified version of the
library to be distributed).
--
Debian GNU/Linux 1.1 is out! { http://www.debian.org/ }
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
{ http://greathan.apana.org.au/~herbert/ }
PGP Key: [EMAIL PROTECTED] or any other key sites
--
This message was distributed manually by [EMAIL PROTECTED] after the list
initially failed to distribute it.
Re: GnuStep Re: X is painful
Bill Bumgarner writes: Now that I have an answer on the libc front (ie; 1.2 will ship with = 5.4.7), I'm going to reboot to Linux and produce 'official' 5.4.7 = compliant GCC 2.7.2.1 + GnuStep Threading Patches in short order. =20 BTW: For now, I'm using the built in MIT_POSIX_THREADS. Who is = maintaining LinuxThreads-- it seems like a superior package and I would = like to move to it as soon as possible... BUT: If I move to using LinuxThreads, gcc will DEPEND on the LinuxThreads = package. Does that offend anyone? This makes me nervous. What exactly are you proposing to do to gcc? Why would it have to depend on any thread package? I sent a message the other day, but it bounced because the lists were down. IMO, we should stick with MIT pthreads as included in libc5. It has been available for quite a while and is reported to work, though I don't know of any Debian packages using it. We can switch to LinuxThreads when we go to libc6. FYI, LinuxThreads is already available as a compile-time add-on for libc6, so I would expect it to be well supported. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- This message was distributed manually by [EMAIL PROTECTED] after the list initially failed to distribute it.
Re: X is painful
[EMAIL PROTECTED] (Stephen Early) wrote on 15.11.96 in [EMAIL PROTECTED]: Creating a user interface under X that is as good as NextStep is just a matter of getting every X application author to agree to adhere to the same policy. I wish you luck. Actually, this is a very good description of the problem. And I agree with Bill. The situation we have sucks big rocks through straws. It sucks even more because it seems there is *no* way to solve this problem. (Maybe the FSU can do something. Well, I can dream, can't I?) The designers of X made one *big* error. It's nice to be able to configure how the system looks. But the X window manager system doesn't actually do that, it only handles a very small part of the system (window decorations, window focus, and similar stuff). Had that interface only been richer ... MfG Kai -- This message was distributed manually by [EMAIL PROTECTED] after the list initially failed to distribute it.
Re: X is painful
Herbert Xu [EMAIL PROTECTED] wrote: Stephen Early wrote: Creating a user interface under X that is as good as NextStep is just a matter of getting every X application author to agree to adhere to the same policy. I wish you luck. I agree that this is very diffcult. But the Debian developers should do their best at getting Debian programs to cooperate. This isn't trivial. As Stephen said, X provides the basics for graphical development; it doesn't provide any fancy schmancy stuff like menus, push buttons, etc. That's done by such things as Motif, xforms, Qt, etc. Converting an X program from one such library to another is a less than easy task.. so any attempt to produce a uniform interface is going to fail. Simple as that. It's a nice idea, but... :-) -- This message was distributed manually by [EMAIL PROTECTED] after the list initially failed to distribute it.
Re: X is painful
Stephen Early wrote: Creating a user interface under X that is as good as NextStep is just a matter of getting every X application author to agree to adhere to the same policy. I wish you luck. Herbert Xu wrote: I agree that this is very diffcult. But the Debian developers should do their best at getting Debian programs to cooperate. Stuart Lamble wrote: This isn't trivial. As Stephen said, X provides the basics for graphical development; it doesn't provide any fancy schmancy stuff like menus, push buttons, etc. That's done by such things as Motif, xforms, Qt, etc. Converting an X program from one such library to another is a less than easy task.. so any attempt to produce a uniform interface is going to fail. Simple as that. But we have some fairly powerful tools at our disposal. Probably the most powerful of which is the shell command line. If we define simple set of shell command line operations to do menus, push buttons, etc., for our purposes, we can provide arbitrary programs to fill those needs. If we do it properly (just focus on providing the semantics we need, from simple commands), we should be able to plug in new programs as technology advances. Note that, in the long run, this doesn't tie us to X. Simple technologies which may lead in the right direction are TK (wish/wishx/expectk/..), and perhaps things like xmessage or 9menu. I think it's a good idea to avoid being too closely tied to the featurism of things like motif, or even xlib. [I think that patterning our efforts after the technologies developed at lucent (plan9, etc.) would be a good thing -- but I don't want to push this *too* hard.] -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: X is painful + GPLed solution
Actually-- I thought it was appropriate for the devel list since it may affect future development of debian at the user interface level. Regardless, my followup is to debian-user only. There is no inter-application communication or awareness to speak of. # This can be handelt via sockets,fifos But that is a completely inadequeate and unacceptable solution! With any kind of a standard, 'inter-application communication' yields an environment where you have small 'pools' of applications that are can communicate with each other-- but cannot communicate between the 'pools'! By inter-application communication, I mean: - cut/paste works across multiple data types between *any* applications - drag and drop is a standard part of the UI and works between *any* applications [again, across multiple data types] - applications can provide services to each other; ie-- a filter service could automatically convert between one image format and another transparently]. - and, of course, all of this functionality is either automatically included in your application simply by using the components that support it OR is very easy to integrate. BTW: by multiple data types, I mean each component can consume or produce a standard set of data types that include formatting information, typed data such as text, images, or sounds. # Have look at the kde project. I will-- and if it is as cool as you make it sound, I'll happily put together the debian packaging information... b.bum -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: X is painful
I'll repost this again now that the lists are back up. :-) --- Bill Bumgarner wrote: I have to vent. Vent on, dude. I cannot believe that after HOW MANY years of development, X windows is still such a completely inconsistent and painful user interface. The STUPIDITY of the whole thing is frustrating. For example: There is no inter-application communication or awareness to speak of. I think that'll change in a year or so. We're going to see an all-out battle for the hearts and minds of free-software maintainers. Some contending technologies: GNUstep, CORBA/ILU, Java Beans?, DCOM/OLE, OpenDoc? They're all coming on the scene soon, and they weren't available a few years ago. The solution that works the best, and inter-operates the best, and is free, will win out. The window manager has no awareness of what is running-- only what windows are on the screen. Because of this, various 'dock' programs are nothing more than a 'click the button to launch an app' system-- one cannot click on a button second time to simply activate the app in question. Try tkgoodstuff. It has a Windows 95 style toolbar. It's slow to load and pretty ugly, but it does the job. There's something similar in fvwm-95. The various 'toolkits' available for developping apps don't help the situation-- while they make it easier to develop X apps, they certainly don't make the apps any more impressive. There have been too many widget sets. I think the main problem has been that most widget sets (Motif for example) have had restrictive licenses. Also, many of them are tied too closely to a particular set of development tools. Now that there are many widget sets available in the public domain, and the technology to separate them from particular tools is available (ie. ILU), I think that we will start to see them mutate and combine together in some interesting combinations. And the best solution will eventually become dominant. Just give it some more time. I've got a list of 20 or so sets of widgets I'm interested in, but I haven't had enough time to try many of them. But a year from now, I'll probably have tried most of them. X completely lacks a decent mail reader [outside of Messages from the Andrew Consortium-- it is awesome... but oncee one decides to use it, it is hard, hard, hard to leave. as well, there is no source available, so porting is out of the question [though a port already exists for x86 linux]]. No, emacs/xemacs is not acceptable. I like exmh. It's a bit slow in places, but overall, it's pretty good. Maybe I'm just spoiled by years of NEXTSTEP-- but, damnit, NEXTSTEP really is the most well-inntegrated user inrface *ever* built. Seriously. I've never tried NEXTSTEP unfortunately. I'm itching to try GNUStep. Does anyone know what the status of it's development is, and when a likely ETA for a Debian package will be? Cheers, - Jim -- This message was distributed manually by [EMAIL PROTECTED] after the list initially failed to distribute it.
Re: X is painful
[box on] I have to vent. OK, I cannot believe that after HOW MANY years of development, X windows is still such a completely inconsistent and painful user interface. I think you forgot to include open, free, expandable, flexible, . . . . The STUPIDITY of the whole thing is frustrating. Oh, really! You would rather have a Mac type world then? (Pay thru the nose, and get what you get from THE vendor) For example: Text fields between applications do not work the same. One is not guranteed to be able to copy/paste text between fields. Some fields must have the mouse pointer within them during the editing process, some don't. The kind of car you and I drive ARE going to be different (hopefully), cause we are allowed to do so. Just as the programmers are allowed to express themselves through the toolkits that they choose and/or write. With X, a user can control the App thru X resources, granted some of them are alittle brain-dead in this area, but this is not the fault of X. There is no inter-application communication or awareness to speak of. There are several. Again not the fault of X, they exist at a different layer. The window manager has no awareness of what is running-- only what windows are on the screen. Because of this, various 'dock' programs are nothing more than a 'click the button to launch an app' system-- one cannot click on a button second time to simply activate the app in question. Why should the WM be aware of what is running? It is a Window Manager, not a process manager and never was the developers intentions. The various 'toolkits' available for developping apps don't help the situation-- while they make it easier to develop X apps, they certainly don't make the apps any more impressive. Back to the Mac situation. If you don't like so many different toolkits, then try writing your own toolkit that does everything that you want it to do and then you can try marketing it and make giga-bucks. -OR- You could put your energy into giving to one of the toolkits to make it become the type that you desire, which many others have already done. X completely lacks a decent mail reader [outside of Messages from the Andrew Consortium-- it is awesome... but oncee one decides to use it, it is hard, hard, hard to leave. as well, there is no source available, so porting is out of the question [though a port already exists for x86 linux]]. No, emacs/xemacs is not acceptable. You should *really* research the history of X and the developers intentions. Maybe I'm just spoiled by years of NEXTSTEP-- but, damnit, NEXTSTEP really is the most well-inntegrated user inrface *ever* built. Seriously. OK, then I'm sad to say Where is it?. I too have seen a many good idea get washed away by (some say ignorant) wave of the masses. There are two clear choices; 1). sit with the masses and be happy with what is feed to you. 2). get in the trenches and give others a hand in what form you can. Venting off... [box off] .Bill, == Man's capacity to learn is not fixed in any ordinary sense. It is not fixed in terms of the responses it will produce; it is not fixed in terms of absolute level of knowledge it will achieve. - Engelmann == -- This message was distributed manually by [EMAIL PROTECTED] after the list initially failed to distribute it.
GnuStep Re: X is painful
Jim asked about GnuStep; Well-- a complete set of GnuStep packages have been built by Karl Sackett and are awaiting my work on gcc [an attempt to fix a crasher in the optimizer that causes the base GnuStep library to NOT be built with optimization-- UGH!] before release. Now that I have an answer on the libc front (ie; 1.2 will ship with 5.4.7), I'm going to reboot to Linux and produce 'official' 5.4.7 compliant GCC 2.7.2.1 + GnuStep Threading Patches in short order. BTW: For now, I'm using the built in MIT_POSIX_THREADS. Who is maintaining LinuxThreads-- it seems like a superior package and I would like to move to it as soon as possible... BUT: If I move to using LinuxThreads, gcc will DEPEND on the LinuxThreads package. Does that offend anyone? b.bum -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
