Posted
by
Cliff
from the save-an-affordable-display-for-me dept.
ike6116 asks: "According to Apple the 15" Apple Studio Display is still available, but when one clicks on Store and tries to select it with a system it is nowhere to be found. I ask you: Where have they gone to? Why have they left? Will they be back?"
This discussion has been archived.
No new comments can be posted.
Well Karma is no longer measured in visible points for a start and the lst time it was mine was up at 50 - this highest it displays, and I never posted at 3.
This highest anyone posts at without moderation is, I believe, 2.
maybe it's how i have my slashdot prefs setup, but both you and i are posting at 3. i think you might get an extra +1 tacked on to your next post after recieving a mod point, which is how i post at 3.... not really sure, but that's how it comes up on my screen.
I was looking on the Mac site and it like said there were displays available but I clicked on the link and it went beep beep beep andlike ate my display. Bummer.
I'll bet all the 15" displays have been removed from the warehouses because Hillary Rosen's crack team of technologists and lint-pickers have discovered that these sized displays are actually *perfect* for view movies on in proper aspect ratio, and thus are a violation of the DMCA.
Or maybe these screens are featured in the next Star Wars movie and Lucas' has had Jobs' over for dinner again to remind him about that whole 'clone wars' argument.
Oh, oh wait, I know... *TERRORISTS* are stockpiling them to make a Beowoulf out of the LCD controller chips in a canny attempt at foiling the FBI, who aren't sure about anything that doesn't run on the federally approved standard MS INtel chips.
Aliens? Okay, no, that's weak. How about Bill Clinton?!! I'm sure he has something to do with it...
actually the 17inch iMac LCDs are perfect for wide screen movies...... the size upgrade is somewhat subtle if you see them side by side, but makes movies look a lot nicer. the 17inch (if i remember right) are the same height as the 15inch models, just the 17inch models are a bit wider.....
if you want to fuel the rumors more, they sites have claimed the iMac will go to 17inch and 19inch *soon*.
they also say the next revision of stand alone LCDs will be 17inch (maybe) and 19inch both in widescreen aspect... and then the surrent bigger way expensive models (possibly bigger than 23inch even).
personally i would love a 19inch wide.... i use a 19inch and 15inch CRT right now and think one nice wide screen would eliminate the need for both screens. the thing i really like about 2 is keeping toolbars on there when doing graphics or layout work.... plus most widescreen ratios are right for 2 pages side by side (or an 11x17 layout).
Considering that this is a weak Apple thread and the editors refuse to post my Ask Slashdot: post, I'll hijack this article and post it here....
If Apple where to add native X11 support to OS X (don't ask), and wanted to show off this new capability, what would you recommend as the top ten X11 apps? I know there's things like the GIMP, but beyond things like desktop managers, what does the Linux community run under X11 (or X on X, or XFree86) that gives them a smug feeling of superiority? I can't think of 10, can you?
If Apple where to add native X11 support to OS X (don't ask), and wanted to show off this new capability, what would you recommend as the top ten X11 apps?
Gee, sorry Adobe, Macromedia, Microsoft, Every other developer benevolent enough to continue support for our platform through times of dwindling market share... We've decided to allow users to run GNU alternatives to your apps right out of the box - yeah we know! "Human interface guidelines, shmuman shminterface shmidelines!" We've decided that having both screen-perimeter affixed menu bars and window-nested menu bars is BETTER...
I think the "smug feeling of superiority" comes from paying $12.47 for hardware and running a free suite of software, not the X11 environment...
We've decided that having both screen-perimeter affixed menu bars and window-nested menu bars is BETTER.
Your main point about interface guidelines is correct. Your example however is not.
For X apps the positioning of the menu bar is controlled by the window manager. So it is not only possible but quite east to have perimeter affixed menu bars for X apps by choosing / configuring the window manager to use this setup. Oroborus is a window manager which actually uses this scheme.
feh [linuxbrit.co.uk] gtk-gnutella [sourceforge.net] lopster [sourceforge.net] dc_gui w/ dctc [tzo.com] mtr [bitwizard.nl] gkrellm [wt.net] (Not sure how well this would work...do OS X systems have a compatible/proc?) xmms [xmms.org]
You ever notice how moderating useful posts Offtopic has little or no point? For Chrissake, if you want to call Offtopic on someone, go after the "SOVIET RUSSIA" guy or someone who's detracting from the forum, not helpful posts.
There's at least one user now whose.sig reads "I metamoderate all Offtopic moderations Unfair", which I'm starting to agree with. Go blow your mod points on trolls, not on helpful discussion.
If Apple where to add native X11 support to OS X (don't ask),
and wanted to show off this new capability, what would you
recommend as the top ten X11 apps?
xterm. Terminal.app is useless as a terminal emulator.
It does not allow you to map your meta key to the place where it belongs (instead, it grabs the meta key for the completely useless keybindings it has). In order to modify your keybindings to switch alt and command, you have to use a third party kernel module which would indicate a low-level architectural problem. You cannot use emacs with Terminal.app (not a big deal for me since I use vi, but it's annoying for using bash and zsh where I use the emacs editing keystrokes - and yes, I know zsh has a "vi-mode", but that's besides the point).
Terminal.app continues to insist on the inane "copy/paste" paradigm, even if I have a perfectly good three-button mouse. Hint: if I highlight something in a terminal, I'm going to copy it to the clipboard - there's absolutely nothing else you can do with a selection in a terminal emulator. If I have a three-button mouse, the middle mouse button isn't doing anything useful, so why not allow it do paste, as is traditional in unix environments?
NB that Terminal.app actually emulates xterm escape sequences. However, it sends "vt100" as the terminal type. What the hell is the logic behind that? Are they trying to pander to the clueless newbs who can't figure out how to set their terminal type when they telnet into an older Sun box, or what?
Terminal.app steals the page up/page down keys for scrolling, instead of using shift page up/shift page down, as is the norm. If you actually need to send page up/page down to a program, you're SOL, and a number of terminal programs expect these keys for some function because no other terminal emulator that I know of has stolen them.
If Apple adds native X support, I'll finally be able to use a Macintosh as a terminal. I'll open up Terminal.app, ssh into a normal *nix box and launch xterm remotely. NB: I don't care about fink or any other third-party X server. The only time I'll use a Macintosh is if I'm in the field and I have nothing else available (so I'm not going to install third-party software on someone else's machine).
I believe it would be far more useful if Apple coded up their apps to be proper X clients instead of adding X server support to OS X. If you try to run OS X Server, the only way you can configure the various services is via their little gui application (or, you can figure out the undocumented netinfo strings they modify, but then you're in the exact same boat as with figuring out what registry keys MS Windows software modifies and uses). These applications are supposedly "network-aware" - you can run them on some other machine and connect to your server remotely. However, they're still completely useless, as you need to install the applications on the other machine, and you need to have a Macintosh as your currently-available machine in order to do it in the first place. If some machine is misbehaving, you have to find an OS X machine whose owner will allow you to install software, or you need to physically get to the box - more often than not, you end up physically going to the box, whereas I don't even remember what the cases on my FreeBSD servers look like.
As for your original question, xterm is the only thing I can think of. I spend 80% of my time in xterm and the other 20% in a web browser. If OS X had a decent terminal emulator and some decent window management (don't get me started on that), I would be able to use it as a workstation. I really can't think of many X applications that I would miss, except perhaps xdvi (fast startup, controlled from command line) and xfig (does things I can't find in any other application, saves to plain text.fig files which can be edited). Might also be useful for the occasional X-based third-party installation program (like sybase and a number of less well-known programs). Would also be useful for running things like matlab or mathematica - you can run them on some remote box via X11, which means you don't need 100 licenses for 100 different machines, just one license for one machine (albeit the *nix licenses are usually more expensive than the Windows or Mac licneses because the vendors expect you to do this sort of thing).
A few thoughts -- there *have* to be existing ssh clients -- I remember BetterTelnet and similar for classic Mac OS.
Is it possible to set up an ssh server, then set up an SSH client that's scripted to ssh into the local machine? A bit of a hack, but as long as you aren't opening tons of terminals, it should provide you with a more reasonable environment without a tremendous amount of work on your part.
Your point about xdvi is well-taken too. Why is xdvi so much faster than gv? Is it *that* much easier to render DVIs than postscript files? Second, I'd suggest rxvt over xterm. Rxvt is the end-all be-all of terminals. It's extremely fast (try catting 50 megs of text in a couple terminals and time it -- it'll win), very lightweight (less RAM usage than any other terminal I know of) and has all the features anyone could possibly use. Oh, and it lets you compile out features that you definitely aren't going to use during runtime. Nice bit of software.
Why is xdvi so much faster than gv? Is it *that* much easier to render DVIs than postscript files?
Short answer, yes.
Long answer
TeX does positioning, Metafont does contents. An almost joined document is stored as xdvi. DVI was designed from the start for quick, easy and predictable rendering. dvips takes the dvi document and maps it into a somewhat different paradigm, for example postscript supports external information for rendering and postscript documents support all sorts of external modifications and redefinitions that dvi does not. In many ways postscript is much more like TeX code than it is like dvi code.
The resulting postscript code is not easy to render.
One way to see the speed difference is to erase metafonts font cache. Then load you dvi document. That is make metafont actually recompute the fonts which is a similar (though slightly more complex process to what postscript has to do every time for every charactor). You will notice a pretty huge drop in dvi rendering speeds.
That brings me to one of the things that really pisses me off about *nixen, and that is that I can't paste text on top of text! Frequently applications feel they must highlight the content of an entry field for me when the field receives focus, and by doing so eliminate what I'd intended to paste within that field.
If all X apps worked correctly and consistently, this wouldn't be a problem. However, since applications are so inconsistent, most people don't figure out that there's supposed to be a method that satisfies both of our requirements.
This is how it's supposed to work (as I understand it): when you (or a program) highlights text, that text is supposed to goe into the SELECTION. Highlighting some other text replaces the SELECTION. Middle-clicking is supposed to insert the SELECTION.
In addition to the SELECTION, there are BUFFERS. When you choose the edit->copy command, it's supposed to replace the first BUFFER with the SELECTION, but only if the program owns the SELECTION (otherwise, edit->copy is disabled). When you do edit->paste, that's supposed to insert the first BUFFER, not the SELECTION.
So, you can highlight something in app1, and middle-click in app2 to insert what's highlighted. If you need to highlight something in app2 to replace instead of just inserting into an empty area, you highlight in app1, copy in app1, and paste in app2. You'll note that if you know nothing about middle-clicking, you'll never have to deal with SELECTIONS - you just use copy and paste like in Windows and MacOS and it works the same.
Things are actually a little more flexible than this because there are multiple BUFFERS, so you always have a history of copies accross all programs. BUFFERS are shared between all programs (they are kept on the X server), but the SELECTION is "owned" by a program (so when you middle-click, the application that accepts the click asks the application that owns the selection to fork over the contents). This is really quite elegant, since it avoids unecessary copies between the clients and server (since X was designed from the start to run over a network): you only copy something to the server when you do a "copy" command in a program, but you never transfer something to the server by just highlighting text.
The problem is that xterm (and a number of other X programs) does not supply a "copy" command that transfers the SELECTION to the first buffer (or a paste command that inserts the first BUFFER). Emacs does all sorts of confusing, crazy things. Lots of apps just do what they feel like doing, since everyone else does contrary things and plenty of X programmers haven't figured out that there's supposed to be a system here.
So it's not the design of X that's the problem, it's the applications that don't stick to standards (and perhaps standards documents that are extremely confusing like the ICCCM).
Try this: use only the latest KDE applications, and not any applications like xterm, netscape, emacs, etc. You'll find that you can use copy and paste in the exact same way as in MacOS since the latest KDE applications get it right. You can treat the middle-click as an added "bonus" to those who understand what's going on underneath.
Hope someone finds this useful - it's rather late in the life of this article.
This is nothing new - the 15" Studio LCD has not been available for quite some time. Three comments come to mind: - maybe they need them for the G4 iMac - maybe they need them for a new tablet Mac - this is just one more nail in the coffin of the CRT
I work at the campus computer store at UC Berkeley and we haven't been able to order 15" displays from Apple for a while now, maybe 3 months. They're no longer selling them. You may be able to find something left over in the distribution channels but I doubt it since its been so long since they stopped selling them.
That maybe just maybe, since Apple is due to be releasing a new lineup of machines (remember the announcment that nothing after january would start into OS 9) than they stopped buying more to clear out their stock. perhaps price drops all arround and the 15inch just is being phased out.
Re:Hummm (Score:1, Offtopic)
This highest anyone posts at without moderation is, I believe, 2.
Re:Hummm (Score:1, Offtopic)
Re:Wow. (Score:1)
WHERE??? (Score:5, Funny)
Re:WHERE??? (Score:4, Funny)
Re:WHERE??? (Score:2)
Evolution Does Exist! (Score:3, Informative)
They've been saying this for months Apple 15" LCD No Longer Available [macrumors.com].
Geeze... maybe it's some sort of conspiracy... (Score:4, Funny)
Or maybe these screens are featured in the next Star Wars movie and Lucas' has had Jobs' over for dinner again to remind him about that whole 'clone wars' argument.
Oh, oh wait, I know
Aliens? Okay, no, that's weak. How about Bill Clinton?!! I'm sure he has something to do with it
Re:Geeze... maybe it's some sort of conspiracy... (Score:2)
if you want to fuel the rumors more, they sites have claimed the iMac will go to 17inch and 19inch *soon*.
they also say the next revision of stand alone LCDs will be 17inch (maybe) and 19inch both in widescreen aspect... and then the surrent bigger way expensive models (possibly bigger than 23inch even).
personally i would love a 19inch wide.... i use a 19inch and 15inch CRT right now and think one nice wide screen would eliminate the need for both screens. the thing i really like about 2 is keeping toolbars on there when doing graphics or layout work.... plus most widescreen ratios are right for 2 pages side by side (or an 11x17 layout).
It's a trick, get an axe. (Score:1, Redundant)
Re:It's a trick, get an axe. (Score:1)
Who buys 15" displays anymore?!
I remember way back when, you could get 9" and 13" displays...
Technology PROGRESSES!
17" is about the smallest screen you'd want to use anyway, especially for web browsing and word processing.
Re:It's a trick, get an axe. (Score:1)
Here's an idea: (Score:4, Insightful)
Ask Apple.
Try asking questions we can answer... (Score:1)
May be available in existing inventory (Score:2)
Honestly, however, the 17" display is a very pleasant display that's worth the extra dough, if you can afford the means.
Stay calm, this is a thread hijack. X11 on OS X (Score:1, Offtopic)
my Ask Slashdot: post, I'll hijack this article and post it here....
If Apple where to add native X11 support to OS X (don't ask),
and wanted to show off this new capability, what would you
recommend as the top ten X11 apps? I know there's things
like the GIMP, but beyond things like desktop managers,
what does the Linux community run under X11 (or X on X,
or XFree86) that gives them a smug feeling of superiority?
I can't think of 10, can you?
Re:Stay calm, this is a thread hijack. X11 on OS X (Score:1, Offtopic)
2. xChat (unless u know a better native.app, I couldn't)
3. PAN
4. Gimp
5. oOffice.org
well, halfway there
Re:Stay calm, this is a thread hijack. X11 on OS X (Score:1, Offtopic)
7.) GQView
8.) ABIWord
9.) Emacs
10.) NmapFE
And there's more, much more...
Re:Stay calm, this is a thread hijack. X11 on OS X (Score:2)
I believe there's already a MacOS-native emacs -- you don't need X for it.
Re:Stay calm, this is a thread hijack. X11 on OS X (Score:1, Offtopic)
I think the "smug feeling of superiority" comes from paying $12.47 for hardware and running a free suite of software, not the X11 environment...
Re:Stay calm, this is a thread hijack. X11 on OS X (Score:2)
Your main point about interface guidelines is correct. Your example however is not.
For X apps the positioning of the menu bar is controlled by the window manager. So it is not only possible but quite east to have perimeter affixed menu bars for X apps by choosing / configuring the window manager to use this setup. Oroborus is a window manager which actually uses this scheme.
Re:Stay calm, this is a thread hijack. X11 on OS X (Score:3, Offtopic)
gtk-gnutella [sourceforge.net]
lopster [sourceforge.net]
dc_gui w/ dctc [tzo.com]
mtr [bitwizard.nl]
gkrellm [wt.net] (Not sure how well this would work...do OS X systems have a compatible
xmms [xmms.org]
Offtopic moderations suck (Score:2)
There's at least one user now whose
Re:Stay calm, this is a thread hijack. X11 on OS X (Score:2, Offtopic)
xterm. Terminal.app is useless as a terminal emulator.
It does not allow you to map your meta key to the place where it belongs (instead, it grabs the meta key for the completely useless keybindings it has). In order to modify your keybindings to switch alt and command, you have to use a third party kernel module which would indicate a low-level architectural problem. You cannot use emacs with Terminal.app (not a big deal for me since I use vi, but it's annoying for using bash and zsh where I use the emacs editing keystrokes - and yes, I know zsh has a "vi-mode", but that's besides the point).
Terminal.app continues to insist on the inane "copy/paste" paradigm, even if I have a perfectly good three-button mouse. Hint: if I highlight something in a terminal, I'm going to copy it to the clipboard - there's absolutely nothing else you can do with a selection in a terminal emulator. If I have a three-button mouse, the middle mouse button isn't doing anything useful, so why not allow it do paste, as is traditional in unix environments?
NB that Terminal.app actually emulates xterm escape sequences. However, it sends "vt100" as the terminal type. What the hell is the logic behind that? Are they trying to pander to the clueless newbs who can't figure out how to set their terminal type when they telnet into an older Sun box, or what?
Terminal.app steals the page up/page down keys for scrolling, instead of using shift page up/shift page down, as is the norm. If you actually need to send page up/page down to a program, you're SOL, and a number of terminal programs expect these keys for some function because no other terminal emulator that I know of has stolen them.
If Apple adds native X support, I'll finally be able to use a Macintosh as a terminal. I'll open up Terminal.app, ssh into a normal *nix box and launch xterm remotely. NB: I don't care about fink or any other third-party X server. The only time I'll use a Macintosh is if I'm in the field and I have nothing else available (so I'm not going to install third-party software on someone else's machine).
I believe it would be far more useful if Apple coded up their apps to be proper X clients instead of adding X server support to OS X. If you try to run OS X Server, the only way you can configure the various services is via their little gui application (or, you can figure out the undocumented netinfo strings they modify, but then you're in the exact same boat as with figuring out what registry keys MS Windows software modifies and uses). These applications are supposedly "network-aware" - you can run them on some other machine and connect to your server remotely. However, they're still completely useless, as you need to install the applications on the other machine, and you need to have a Macintosh as your currently-available machine in order to do it in the first place. If some machine is misbehaving, you have to find an OS X machine whose owner will allow you to install software, or you need to physically get to the box - more often than not, you end up physically going to the box, whereas I don't even remember what the cases on my FreeBSD servers look like.
As for your original question, xterm is the only thing I can think of. I spend 80% of my time in xterm and the other 20% in a web browser. If OS X had a decent terminal emulator and some decent window management (don't get me started on that), I would be able to use it as a workstation. I really can't think of many X applications that I would miss, except perhaps xdvi (fast startup, controlled from command line) and xfig (does things I can't find in any other application, saves to plain text .fig files which can be edited). Might also be useful for the occasional X-based third-party installation program (like sybase and a number of less well-known programs). Would also be useful for running things like matlab or mathematica - you can run them on some remote box via X11, which means you don't need 100 licenses for 100 different machines, just one license for one machine (albeit the *nix licenses are usually more expensive than the Windows or Mac licneses because the vendors expect you to do this sort of thing).
xterm solutions (Score:3, Informative)
Is it possible to set up an ssh server, then set up an SSH client that's scripted to ssh into the local machine? A bit of a hack, but as long as you aren't opening tons of terminals, it should provide you with a more reasonable environment without a tremendous amount of work on your part.
Your point about xdvi is well-taken too. Why is xdvi so much faster than gv? Is it *that* much easier to render DVIs than postscript files?
Second, I'd suggest rxvt over xterm. Rxvt is the end-all be-all of terminals. It's extremely fast (try catting 50 megs of text in a couple terminals and time it -- it'll win), very lightweight (less RAM usage than any other terminal I know of) and has all the features anyone could possibly use. Oh, and it lets you compile out features that you definitely aren't going to use during runtime. Nice bit of software.
Re:xterm solutions (Score:2)
Short answer, yes.
Long answer
TeX does positioning, Metafont does contents. An almost joined document is stored as xdvi. DVI was designed from the start for quick, easy and predictable rendering. dvips takes the dvi document and maps it into a somewhat different paradigm, for example postscript supports external information for rendering and postscript documents support all sorts of external modifications and redefinitions that dvi does not. In many ways postscript is much more like TeX code than it is like dvi code.
The resulting postscript code is not easy to render.
One way to see the speed difference is to erase metafonts font cache. Then load you dvi document. That is make metafont actually recompute the fonts which is a similar (though slightly more complex process to what postscript has to do every time for every charactor). You will notice a pretty huge drop in dvi rendering speeds.
Re:Stay calm, this is a thread hijack. X11 on OS X (Score:2)
If all X apps worked correctly and consistently, this wouldn't be a problem. However, since applications are so inconsistent, most people don't figure out that there's supposed to be a method that satisfies both of our requirements.
This is how it's supposed to work (as I understand it): when you (or a program) highlights text, that text is supposed to goe into the SELECTION. Highlighting some other text replaces the SELECTION. Middle-clicking is supposed to insert the SELECTION.
In addition to the SELECTION, there are BUFFERS. When you choose the edit->copy command, it's supposed to replace the first BUFFER with the SELECTION, but only if the program owns the SELECTION (otherwise, edit->copy is disabled). When you do edit->paste, that's supposed to insert the first BUFFER, not the SELECTION.
So, you can highlight something in app1, and middle-click in app2 to insert what's highlighted. If you need to highlight something in app2 to replace instead of just inserting into an empty area, you highlight in app1, copy in app1, and paste in app2. You'll note that if you know nothing about middle-clicking, you'll never have to deal with SELECTIONS - you just use copy and paste like in Windows and MacOS and it works the same.
Things are actually a little more flexible than this because there are multiple BUFFERS, so you always have a history of copies accross all programs. BUFFERS are shared between all programs (they are kept on the X server), but the SELECTION is "owned" by a program (so when you middle-click, the application that accepts the click asks the application that owns the selection to fork over the contents). This is really quite elegant, since it avoids unecessary copies between the clients and server (since X was designed from the start to run over a network): you only copy something to the server when you do a "copy" command in a program, but you never transfer something to the server by just highlighting text.
The problem is that xterm (and a number of other X programs) does not supply a "copy" command that transfers the SELECTION to the first buffer (or a paste command that inserts the first BUFFER). Emacs does all sorts of confusing, crazy things. Lots of apps just do what they feel like doing, since everyone else does contrary things and plenty of X programmers haven't figured out that there's supposed to be a system here.
So it's not the design of X that's the problem, it's the applications that don't stick to standards (and perhaps standards documents that are extremely confusing like the ICCCM).
Try this: use only the latest KDE applications, and not any applications like xterm, netscape, emacs, etc. You'll find that you can use copy and paste in the exact same way as in MacOS since the latest KDE applications get it right. You can treat the middle-click as an added "bonus" to those who understand what's going on underneath.
Hope someone finds this useful - it's rather late in the life of this article.
Rampant rumor thread (Score:2)
Where 15-inchers have gone (Score:1)
Since it apparently costs no more to make a 17-inch CRT monitor than a 15, that would make Apple's 15s the same price as a mid-line LCD 15.
Umh, which do you think would sell better?
It's not available! (Score:3, Insightful)
- maybe they need them for the G4 iMac
- maybe they need them for a new tablet Mac
- this is just one more nail in the coffin of the CRT
Availability to resellers (Score:2, Informative)
Bought by young nerds, every one (Score:2)
When will they ever learn?
When will they ever learn?
Possible (Score:2)