Or even if there's an error that tends to produce invalid ballots, or just slows the voter down so they end up rushing through part of the ballot.
If the electronic machines are not capable of providing a better and more obvious user interface than the paper ballots, then what's the point? We already know how to make paper ballots that are read and verified at the ballot box, using (for example) scantron type cards and a display that the voter can use to make sure their ballot reads the way they think it does. The electronic "voting machine" need not be anything but a convenience for generating and printing the ballot for the voter.
So it sounds like it's usingsomething similar to the callback mechanism I suggested for the MS HTML control, where an object's access is controlled by the calling application rather than inferred from the location and status of the document.
I assume that the ioslaves contrrol access to local as well as remote resources outside the HTML rendering engine. Is that correct?
Oh, I'm sorry, I assumed that when you wrote: "This is why we need CHROOT browsers" you meant "This is why we need CHROOT browsers", rather than "This is an unrelated point, but these other problems are why we need CHROOT browsers" which is what you're discussing now. I apologise for misunderstanding.
Just yesterday we read on Slashdot that 'All browsers but Microsoft Internet Explorer kept crashing on a regular basis[...]
Can you provide an actual link to that message so we can see what you're talking about? Because I'm completely failing my "read your mind" saving roll. If you provided enough context that it wasn't necessary it'd really help you get your point across.
Maybe you should look into another bank, or better yet, a credit union. I know not of these "transaction fees" of which you speak.
Congratulations. We're all in awe of your terrifying banking-fu. But what does that have to do with the way a bad user interface can lead to an error on the user's part that shouldn't be dismissed as "user error"? Nothing, of course, it's background material, it's how the bad design developed.
Getting back to the original issue...
If people using voting machines are tending to make a common kind of error, the response shouldn't be "it's user error, it's not a design problem", it's "let's examine the error, and see if there's a way to modify the design and make it less likely to happen".
I would be more in favor of a tab not opening a dialog or firing any other events until it becomes active again
That would alleviate the real problem slightly, but it wouldn't begin to address the general problem that javascript is given too much detailed control over the user interface. There are other ways to spoof websites, if you can get between the site and the user in any fashion.
Basically, window creation should be under the user's control. It should always be obvious that any browser window, whether it's a dialog box or a pop-up window, is a browser window. It should have enough decorations to make sure you can't confuse it with a local application. Resizable windows and dialog boxes should be optional in all browsers if they're available at all, so that web designers have an incentive to create sites that work completely in a standard window.
OK, I don't know whether you're reading a different Mozilla advisory than me, or you missed the fact that I was comparing the two advisories, or you're mixing up the IE one with the Mozilla one, or if I'm really missing something... but I'd sure appreciate it if you'd explain your comment a bit further. Thanks much.
The point is that current browser installations under Linux are generally very insecure.
Can you elaborate on this? The only browser that I know of that runs on Linux that mightn't use an inherently secure sandbox is Konqueror, and I don't know of any exploits for Konqueror based on its modest level of "desktop integration".
What specifically are you talking about when you say "browser installations under Linux are generally very insecure"? There's nothing in this exploit, for example, related to the security of the browser itself.
Mozilla etc... "If the user explicitly opens a page in a background tab, it may not be possible to tell what webpage a dialog box is associated with". Note that the exploit can not open a page in a background tab, it can only take advantage of that if it happens.
Exposure: If the user can first be tricked into opening a page in another tab, and the exploiter can guess whether the user has "open tabs in background" (or the equivalent option) selected or not, then they may be able to trick them into entering confidential information a little easier. There are other ways to get similar results without having to trick the user twice, using frames or with multi-stage popups.
Internet explorer: The exploit can be used to launch web pages in the local security zone. The hole here is really the fact that there is such a thing as a "local security zone" at all. For seven years now, exploit after exploit has used this design flaw in the HTML control to run arbitary code as the local user. Spyware, viruses, worms, spam bots, over and over again, malicious software has gained its initial foothold through variants of this attack.
Exposure: Visiting a web page can allow an attacker to take over your computer, without any further action on your part.
And you say "The Mozilla etc problem seems equally serious."?
Option 4: Don't allow webpages to open dialog boxes from Javascript. The only time I've seen this as being useful is for optional client-side form validation, and there are other ways to provide the same functionality (for example, using CSS to bring up the message in the same page).
Option 5: Don't allow webpages to open windows without decorations. This is occasionally useful, but it's routinely abused by everything from pop-up ads to control-freaks who just don't want you to see how their site is structured.
It would probably add half as much again to the cost of the machine, plus you would inevitably end up with one or the other readers broken because as long as one reader worked the store would be inclined to leave the machine in service... so you'd have to guess or ask which way worked.
1) verify the price on the LCD. (at this point, adventurous types can add cashback) 2) swipe card if the price is right. [...] If its not a debit card and the user selected cashback, it beeps and tells the user that its not a debit card
I don't think so. Forcing a user into an unnecessary "error" state is a bad design.
The first steps need to be "swipe card" and "select debit/credit/...". The order isn't critical, but swiping the card first is better because that reduces the number of options that need to be presented to the user. Letting them do it in either order is best, because they may be used to another store that does things the other way and if you accept both you're less likely to confuse them.
Present the total and if the user swiped a card that could be used as a debit card THEN you can ask if they want cash back. If there's an option, present it:
Your total is $23.16. How do you want to pay? [credit] [debit]... [cash back (debit only)]
After they select [cash back], or the card is only one type, then:
Your total is $43.16. Is this OK?
Requesting the PIN if the card has a debit option AND the user hasn't explicitly selected credit is OK, but if you do this you need to present a "credit" option at the same time... don't make the user hit "cancel" as part of a normal transaction. If the user has asked for cash back, you don't present that option of course.:)
Please enter your PIN: ____ [credit (no PIN)]
For most cards, the number of actions will be the same, but there's no places the user can be forced into an error state and there's no backtracking.
I can see how most of the issues are user problems [... on credit/debit card machines at grocery stores, customers...] hit 'cancel' instead of 'OK', etc
That's because most debit card machines at grocery stores are deliberately designed to confuse the user into using their card in a way that costs the grocery store less. I started noticing this recently... in the past couple of years... and it started happening first in new machines but gradually older systems have been reprogrammed with the same scheme.
The motivation is obvious: If you use your "credit/debit" card as a credit card, the grocery store pays a credit card fee, you pay the amount on the ticket. If you use your "credit/debit" card as a debit card, the grocery store pays less (if anything), but you pay a transaction fee that can be over $3.00 in some cases.
So, to use it as a credit card: about half have a "credit" or "debit" button you can hit before swiping, so you select "credit" if it's there. Either way, you swipe, then it asks you for a PIN. If you enter the PIN it switches to debit mode, so you have to hit "cancel" at this point. Then it asks you to select "credit" or "debit". Sometimes it asks you to hit "credit/debit" then "credit", if there are other choices (like check-cashing cards). Then, it asks you if the amount is OK. This time you hit "OK" and it goes on to complete the transaction.
I'm not exaggerating, here. Almost every machine does this, and at least half make you go through all these steps.
So, I would NOT classify the problems you're seeing as user error. They're the result of customers being systematically trained to hit "CANCEL" as a necessary part of the transaction. This is a user interface design problem.
And that's just the deliberate design problem... sometimes there are actual bugs in the user interface as well.
For example, the machines at Home Depot in Houston are not all that agressive about the credit/debit card thing, but they will sometimes briefly switch to a screen asking you to swipe your card or hit cancel before bringing up the signature box: this appears to be a programming error, but it looks like there's a problem with the transaction and the first time it happened I hit "CANCEL" at that point, just in case... because I'd gotten charged twice at a pharmacy when it did something similar.
I'm a computer professional: I've been programming computers regularly for over 30 years, using everything from paper tape and punch cards to experimental OpenGL-based 3d user interfaces. I'm not a naive user who isn't used to a variety of user interfaces. Yet I have occasionally hit "CANCEL" at the wrong time. I'm not at all surprised that some people are regularly baffled by grocery store card readers. And these are MUCH simpler than voting machines.
I don't know who this ITAA is, but if they're telling people that voting machine problems are "user error" I wouldn't trust their judgement further than I could spit a Diebold executive.
Having multiple options is of course an advantage, but having multiple options has absolutely nothing to do with the menu style. Tk menus on Windows and UNIX are in-window, but they're also tear-off. Pop-op menus are again independent: the Amiga had several patches that let you use either top-of-screen or under-the-mouse pop-up menus.
Having a menu in a fixed place on the screen is bad, because it means that the movement from where you're working (in the window) to wherever the menu is varies, depending on where the window you're working on is. Having the menu in the window means that the muscle movement to reach the menu is independent of the location of the window.
Pop-up menus, particularly pie-style pop-ups, do that part even better, but they lose the always-visible nature of other menu styles, so they can't act as cues.
Putting menus at the edge of the screen avoids overshoot, but it loses local context, so hitting the menu is marginally easier but getting back to work brings back the overshoot problem in the other direction. It's like putting the scrollbar on the right instead of the left (another common mistake).
There's so many trade-offs that the only rational option is to let the user specify where the menus should be. In-window, at the top of the screen, in a corner, or as contextual menus on the window background or title bar (the equivalent of pop-ups). Any window system that only allows one or two of these options is unnecessarily frustrating some of the users.
if you moved it to the bottom left of the screen, with just the application's name showing and used the left mouse button to bring up the menu wherever your mouse happened to be on the screen(s), it was way way way more convenient then either OS-X or Windows.
Ah, so the real advantage to the Uglymenu is you can get rid of it completely and treat it as a context menu.:)
I do like tear-off windows. I like tear-off toolbars and other panel-like objects as well.
scroll bars should be on the left sice of windows
In the ideal GUI, you would be able to grab the end of a scrollbar and tear it off and reattach it to either side of the content. Or for a side-scrolling panel, drag the scrollbar from the bottom side to the top.
I guess the difference is that the people who designed the class framework for NeXTstep/OpenStep/Cocoa should have spent some time using Smalltalk first.
I had, perhaps rashly, assumed that they had a good reason for the chaos and anarchy in NSthis and NSthat. Now I'm depressed.
But blocks are obligatory in Smalltalk due to its OO-ness, while they are not in Objective-C as you can just reuse C construct (if/while/for..).
Which is why I don't think C or even just C syntax was a good place to start with ObjectiveC any more than it was with C++, Java, or Livescript.
Have you had a look at F-Script? It's the closest thing to Smalltalk+OpenStep that I've seen.
Basically, ObjC is as close to SmallTalk+C as you can possibly get.
True, which is why I don't think C is a good basis for a Smalltalk-like language, and why I think there's more potential in what PARC wrought (potential, alas, wasted... the Smalltalk community makes the Balkans look unified).
All your issues are with the OpenStep APIs.
Almost true, and close enough, and I'm sorry if I didn't make it clear that I'm looking at ObjectiveC in the context of this thread comparing PARC's environment and NeXT's. Is it unreasonable to discuss OpenStep's APIs when talking about NeXTstep/OpenStep? I do think the stringFromString vs stringFromCString mess is hard to avoid in ObjectiveC, but I admit I'm not familiar with other OC frameworks. Is there one you can say (for example) something like ["C string" at: offset]?
I find the space wasted by the horizontal menu on my 19" monitor on my G4 at work very annoying
Heh. You're comparing an annoying design with another only slightly less annoying design.
I find having to move my mouse to the top of the screen or the upper left corner of the screen on Nextstep annoying. I find having big blocks of vertical menus following my focus around on GNUstep annoying. How about horizontal menus attached to the window, or even better: context menus that only show up when requested?
I don't think the issue here should be Objective-C versus SmallTalk, because they really are two variants of the same flavour of OO language
Not quite. ObjectiveC requires the programmer to spend more effort handling memory management and distinguishes between objects and primitives.
Also, the typical Smalltalk class system seems much more orthogonal. ObjectiveC frameworks (including Cocoa, and I assume OpenStep) don't seem to really take advantage of the capabilities of dynamic classes... let's look at NSString, for example:
Why are these four separate methods with separate names? Why is "string" part of the method name? In Smalltalk, these would probably all be "toString" methods on the objects. If ObjectiveC was Smalltalk-like, you'd at least have something like this:
String with: ((File with: "name of file") contents).
This way the bookkeeping doesn't fall on the programmer, and common same idioms can be more widely used. Programming in ObjectiveC reminds me of programming in the OO-equivalent of Bliss, where you have to remember to explicitly dereference all your variables, or BCPL, where you have to use different operators on interger or floating point values.
It's still better than Java or C++, but lord there's a long way to go.
Want to view page 799 of an 800 page document that's PostScript? Guess what, you have to render the first 798 pages
Maybe, maybe not. There are ways to structure Postscript and provide assertions about what part of the code is required. Most modern Postscript generators provide these assertions and there's no reason DPS can't benefit from that kind of provision.
The big problem with Display Postscript is that DPS had all the overhead of a full Postscript interpreter but it doesn't use it for much more than rendering. NeWS used the Postscript interpreter to handle the ebb and flow of minor user-interface operations, allowing the server to handle them without the overhead of a context switch back to the application until something like a menu selection had been completed.
NeXTStep was based on BSD. Mach is not a complete kernel, though it is more extensive than most microkernels and I have some difficulty using that term for it. It's the same kind of Mach+BSD merge as Tru64, Darwin, and Lites. It's much more than just "some BSD code to implement the BSD APIs".
Looks interesting, when I get back to a non-OSX environment I'll check it out. I'd still rather have a Windows/Motif style menu bar, particularly in a mixed environment, but this would be OK.
There seems to have been a lot of open-source *step code that was released over the past decade that has dropped off the face of the earth. Is anyone keeping track of this stuff, mirroring and archiving it? There's some old archives, but the ones I've found have been incomplete.
The vertical menu makes tear-off sub-menus make sense, which allows effortless customization of one's working environment for a given task w/o inscrutable toolbars
The vertical menu, however, is enough to keep me from using any of the GNUstep apps I installed on my computer, before I switched to OS X. I really wanted to like it, but it was just too annoying to use. I've got a Nextstation, had it for a while, and it's annoying there as well.
If anything should have been configurable from the start, it's the menus. Put them in a toolbar, slide them out from behind the title bar, even put them at the top of the screen as Rhapsody did. But the big gray box turned me off completely.
The big problem with the classic NeXT look is the menus. Whether they're in the corner in classic NeXTstep, or hovering next to the active window in GNUstep, they're just plain inconvenient and obtrusive.
Windows-style title bars work better. Apple's "all menus at the top of the screen" are OK, if you have good and consistent context menus (unfortunately Apple doesn't). But the big grey box is obtrusive and needs to change. It shouldn't be too hard... they could be made as configurable as you want without changing the API... but they've been enough to make me shy away from GNUstep apps.
The best alternative, I think, might be to attach them to the title bar of the active window, but in a horizontal menu-bar layout.
Slashdot Mirror
Or even if there's an error that tends to produce invalid ballots, or just slows the voter down so they end up rushing through part of the ballot.
If the electronic machines are not capable of providing a better and more obvious user interface than the paper ballots, then what's the point? We already know how to make paper ballots that are read and verified at the ballot box, using (for example) scantron type cards and a display that the voter can use to make sure their ballot reads the way they think it does. The electronic "voting machine" need not be anything but a convenience for generating and printing the ballot for the voter.
So it sounds like it's usingsomething similar to the callback mechanism I suggested for the MS HTML control, where an object's access is controlled by the calling application rather than inferred from the location and status of the document.
I assume that the ioslaves contrrol access to local as well as remote resources outside the HTML rendering engine. Is that correct?
Oh, I'm sorry, I assumed that when you wrote: "This is why we need CHROOT browsers" you meant "This is why we need CHROOT browsers", rather than "This is an unrelated point, but these other problems are why we need CHROOT browsers" which is what you're discussing now. I apologise for misunderstanding.
Just yesterday we read on Slashdot that 'All browsers but Microsoft Internet Explorer kept crashing on a regular basis[...]
Can you provide an actual link to that message so we can see what you're talking about? Because I'm completely failing my "read your mind" saving roll. If you provided enough context that it wasn't necessary it'd really help you get your point across.
Maybe you should look into another bank, or better yet, a credit union. I know not of these "transaction fees" of which you speak.
Congratulations. We're all in awe of your terrifying banking-fu.
But what does that have to do with the way a bad user interface can lead to an error on the user's part that shouldn't be dismissed as "user error"? Nothing, of course, it's background material, it's how the bad design developed.
Getting back to the original issue...
If people using voting machines are tending to make a common kind of error, the response shouldn't be "it's user error, it's not a design problem", it's "let's examine the error, and see if there's a way to modify the design and make it less likely to happen".
I would be more in favor of a tab not opening a dialog or firing any other events until it becomes active again
That would alleviate the real problem slightly, but it wouldn't begin to address the general problem that javascript is given too much detailed control over the user interface. There are other ways to spoof websites, if you can get between the site and the user in any fashion.
Basically, window creation should be under the user's control. It should always be obvious that any browser window, whether it's a dialog box or a pop-up window, is a browser window. It should have enough decorations to make sure you can't confuse it with a local application. Resizable windows and dialog boxes should be optional in all browsers if they're available at all, so that web designers have an incentive to create sites that work completely in a standard window.
OK, I don't know whether you're reading a different Mozilla advisory than me, or you missed the fact that I was comparing the two advisories, or you're mixing up the IE one with the Mozilla one, or if I'm really missing something... but I'd sure appreciate it if you'd explain your comment a bit further. Thanks much.
The point is that current browser installations under Linux are generally very insecure.
Can you elaborate on this? The only browser that I know of that runs on Linux that mightn't use an inherently secure sandbox is Konqueror, and I don't know of any exploits for Konqueror based on its modest level of "desktop integration".
What specifically are you talking about when you say "browser installations under Linux are generally very insecure"? There's nothing in this exploit, for example, related to the security of the browser itself.
As far as I can tell, the exploit can only work in Safari if you have "Select new tabs as they are created" checked in the tabs preferences.
The Mozilla etc problem seems equally serious.
Mozilla etc... "If the user explicitly opens a page in a background tab, it may not be possible to tell what webpage a dialog box is associated with". Note that the exploit can not open a page in a background tab, it can only take advantage of that if it happens.
Exposure: If the user can first be tricked into opening a page in another tab, and the exploiter can guess whether the user has "open tabs in background" (or the equivalent option) selected or not, then they may be able to trick them into entering confidential information a little easier. There are other ways to get similar results without having to trick the user twice, using frames or with multi-stage popups.
Internet explorer: The exploit can be used to launch web pages in the local security zone. The hole here is really the fact that there is such a thing as a "local security zone" at all. For seven years now, exploit after exploit has used this design flaw in the HTML control to run arbitary code as the local user. Spyware, viruses, worms, spam bots, over and over again, malicious software has gained its initial foothold through variants of this attack.
Exposure: Visiting a web page can allow an attacker to take over your computer, without any further action on your part.
And you say "The Mozilla etc problem seems equally serious."?
Jesus.
Option 4: Don't allow webpages to open dialog boxes from Javascript. The only time I've seen this as being useful is for optional client-side form validation, and there are other ways to provide the same functionality (for example, using CSS to bring up the message in the same page).
Option 5: Don't allow webpages to open windows without decorations. This is occasionally useful, but it's routinely abused by everything from pop-up ads to control-freaks who just don't want you to see how their site is structured.
It would probably add half as much again to the cost of the machine, plus you would inevitably end up with one or the other readers broken because as long as one reader worked the store would be inclined to leave the machine in service... so you'd have to guess or ask which way worked.
1) verify the price on the LCD. (at this point, adventurous types can add cashback) 2) swipe card if the price is right. [...] If its not a debit card and the user selected cashback, it beeps and tells the user that its not a debit card
I don't think so. Forcing a user into an unnecessary "error" state is a bad design.
The first steps need to be "swipe card" and "select debit/credit/...". The order isn't critical, but swiping the card first is better because that reduces the number of options that need to be presented to the user. Letting them do it in either order is best, because they may be used to another store that does things the other way and if you accept both you're less likely to confuse them.Present the total and if the user swiped a card that could be used as a debit card THEN you can ask if they want cash back. If there's an option, present it:After they select [cash back], or the card is only one type, then:Requesting the PIN if the card has a debit option AND the user hasn't explicitly selected credit is OK, but if you do this you need to present a "credit" option at the same time... don't make the user hit "cancel" as part of a normal transaction. If the user has asked for cash back, you don't present that option of course.
I can see how most of the issues are user problems [... on credit/debit card machines at grocery stores, customers...] hit 'cancel' instead of 'OK', etc
That's because most debit card machines at grocery stores are deliberately designed to confuse the user into using their card in a way that costs the grocery store less. I started noticing this recently... in the past couple of years... and it started happening first in new machines but gradually older systems have been reprogrammed with the same scheme.
The motivation is obvious: If you use your "credit/debit" card as a credit card, the grocery store pays a credit card fee, you pay the amount on the ticket. If you use your "credit/debit" card as a debit card, the grocery store pays less (if anything), but you pay a transaction fee that can be over $3.00 in some cases.
So, to use it as a credit card: about half have a "credit" or "debit" button you can hit before swiping, so you select "credit" if it's there. Either way, you swipe, then it asks you for a PIN. If you enter the PIN it switches to debit mode, so you have to hit "cancel" at this point. Then it asks you to select "credit" or "debit". Sometimes it asks you to hit "credit/debit" then "credit", if there are other choices (like check-cashing cards). Then, it asks you if the amount is OK. This time you hit "OK" and it goes on to complete the transaction.
I'm not exaggerating, here. Almost every machine does this, and at least half make you go through all these steps.
So, I would NOT classify the problems you're seeing as user error. They're the result of customers being systematically trained to hit "CANCEL" as a necessary part of the transaction. This is a user interface design problem.
And that's just the deliberate design problem... sometimes there are actual bugs in the user interface as well.
For example, the machines at Home Depot in Houston are not all that agressive about the credit/debit card thing, but they will sometimes briefly switch to a screen asking you to swipe your card or hit cancel before bringing up the signature box: this appears to be a programming error, but it looks like there's a problem with the transaction and the first time it happened I hit "CANCEL" at that point, just in case... because I'd gotten charged twice at a pharmacy when it did something similar.
I'm a computer professional: I've been programming computers regularly for over 30 years, using everything from paper tape and punch cards to experimental OpenGL-based 3d user interfaces. I'm not a naive user who isn't used to a variety of user interfaces. Yet I have occasionally hit "CANCEL" at the wrong time. I'm not at all surprised that some people are regularly baffled by grocery store card readers. And these are MUCH simpler than voting machines.
I don't know who this ITAA is, but if they're telling people that voting machine problems are "user error" I wouldn't trust their judgement further than I could spit a Diebold executive.
Having multiple options is of course an advantage, but having multiple options has absolutely nothing to do with the menu style. Tk menus on Windows and UNIX are in-window, but they're also tear-off. Pop-op menus are again independent: the Amiga had several patches that let you use either top-of-screen or under-the-mouse pop-up menus.
Having a menu in a fixed place on the screen is bad, because it means that the movement from where you're working (in the window) to wherever the menu is varies, depending on where the window you're working on is. Having the menu in the window means that the muscle movement to reach the menu is independent of the location of the window.
Pop-up menus, particularly pie-style pop-ups, do that part even better, but they lose the always-visible nature of other menu styles, so they can't act as cues.
Putting menus at the edge of the screen avoids overshoot, but it loses local context, so hitting the menu is marginally easier but getting back to work brings back the overshoot problem in the other direction. It's like putting the scrollbar on the right instead of the left (another common mistake).
There's so many trade-offs that the only rational option is to let the user specify where the menus should be. In-window, at the top of the screen, in a corner, or as contextual menus on the window background or title bar (the equivalent of pop-ups). Any window system that only allows one or two of these options is unnecessarily frustrating some of the users.
if you moved it to the bottom left of the screen, with just the application's name showing and used the left mouse button to bring up the menu wherever your mouse happened to be on the screen(s), it was way way way more convenient then either OS-X or Windows.
:)
Ah, so the real advantage to the Uglymenu is you can get rid of it completely and treat it as a context menu.
I do like tear-off windows. I like tear-off toolbars and other panel-like objects as well.
scroll bars should be on the left sice of windows
In the ideal GUI, you would be able to grab the end of a scrollbar and tear it off and reattach it to either side of the content. Or for a side-scrolling panel, drag the scrollbar from the bottom side to the top.
I really don't understand your example. How is it different than:in Objective-C ?
Hmmm...
I guess the difference is that the people who designed the class framework for NeXTstep/OpenStep/Cocoa should have spent some time using Smalltalk first.
I had, perhaps rashly, assumed that they had a good reason for the chaos and anarchy in NSthis and NSthat. Now I'm depressed.
But blocks are obligatory in Smalltalk due to its OO-ness, while they are not in Objective-C as you can just reuse C construct (if/while/for
Which is why I don't think C or even just C syntax was a good place to start with ObjectiveC any more than it was with C++, Java, or Livescript.
Have you had a look at F-Script? It's the closest thing to Smalltalk+OpenStep that I've seen.
Basically, ObjC is as close to SmallTalk+C as you can possibly get.
True, which is why I don't think C is a good basis for a Smalltalk-like language, and why I think there's more potential in what PARC wrought (potential, alas, wasted... the Smalltalk community makes the Balkans look unified).
All your issues are with the OpenStep APIs.
Almost true, and close enough, and I'm sorry if I didn't make it clear that I'm looking at ObjectiveC in the context of this thread comparing PARC's environment and NeXT's. Is it unreasonable to discuss OpenStep's APIs when talking about NeXTstep/OpenStep? I do think the stringFromString vs stringFromCString mess is hard to avoid in ObjectiveC, but I admit I'm not familiar with other OC frameworks. Is there one you can say (for example) something like ["C string" at: offset]?
I find the space wasted by the horizontal menu on my 19" monitor on my G4 at work very annoying
Heh. You're comparing an annoying design with another only slightly less annoying design.
I find having to move my mouse to the top of the screen or the upper left corner of the screen on Nextstep annoying. I find having big blocks of vertical menus following my focus around on GNUstep annoying. How about horizontal menus attached to the window, or even better: context menus that only show up when requested?
Not quite. ObjectiveC requires the programmer to spend more effort handling memory management and distinguishes between objects and primitives.
Also, the typical Smalltalk class system seems much more orthogonal. ObjectiveC frameworks (including Cocoa, and I assume OpenStep) don't seem to really take advantage of the capabilities of dynamic classes... let's look at NSString, for example:Why are these four separate methods with separate names? Why is "string" part of the method name? In Smalltalk, these would probably all be "toString" methods on the objects. If ObjectiveC was Smalltalk-like, you'd at least have something like this:eg:This way the bookkeeping doesn't fall on the programmer, and common same idioms can be more widely used. Programming in ObjectiveC reminds me of programming in the OO-equivalent of Bliss, where you have to remember to explicitly dereference all your variables, or BCPL, where you have to use different operators on interger or floating point values.
It's still better than Java or C++, but lord there's a long way to go.
Want to view page 799 of an 800 page document that's PostScript? Guess what, you have to render the first 798 pages
Maybe, maybe not. There are ways to structure Postscript and provide assertions about what part of the code is required. Most modern Postscript generators provide these assertions and there's no reason DPS can't benefit from that kind of provision.
The big problem with Display Postscript is that DPS had all the overhead of a full Postscript interpreter but it doesn't use it for much more than rendering. NeWS used the Postscript interpreter to handle the ebb and flow of minor user-interface operations, allowing the server to handle them without the overhead of a context switch back to the application until something like a menu selection had been completed.
NeXTStep was based on BSD. Mach is not a complete kernel, though it is more extensive than most microkernels and I have some difficulty using that term for it. It's the same kind of Mach+BSD merge as Tru64, Darwin, and Lites. It's much more than just "some BSD code to implement the BSD APIs".
Looks interesting, when I get back to a non-OSX environment I'll check it out. I'd still rather have a Windows/Motif style menu bar, particularly in a mixed environment, but this would be OK.
There seems to have been a lot of open-source *step code that was released over the past decade that has dropped off the face of the earth. Is anyone keeping track of this stuff, mirroring and archiving it? There's some old archives, but the ones I've found have been incomplete.
The vertical menu makes tear-off sub-menus make sense, which allows effortless customization of one's working environment for a given task w/o inscrutable toolbars
The vertical menu, however, is enough to keep me from using any of the GNUstep apps I installed on my computer, before I switched to OS X. I really wanted to like it, but it was just too annoying to use. I've got a Nextstation, had it for a while, and it's annoying there as well.
If anything should have been configurable from the start, it's the menus. Put them in a toolbar, slide them out from behind the title bar, even put them at the top of the screen as Rhapsody did. But the big gray box turned me off completely.
After nearly 20 years of "progress" we need at least a 400mhz processor, with 256mb of RAM to equal it. Why?
High quality rendering and automatic double-buffering. Every window requires megabytes of backing store, and antialiasing slows down the rendering.
The big problem with the classic NeXT look is the menus. Whether they're in the corner in classic NeXTstep, or hovering next to the active window in GNUstep, they're just plain inconvenient and obtrusive.
Windows-style title bars work better. Apple's "all menus at the top of the screen" are OK, if you have good and consistent context menus (unfortunately Apple doesn't). But the big grey box is obtrusive and needs to change. It shouldn't be too hard... they could be made as configurable as you want without changing the API... but they've been enough to make me shy away from GNUstep apps.
The best alternative, I think, might be to attach them to the title bar of the active window, but in a horizontal menu-bar layout.