A whole bunch of people here seem to be confusing "put controls in the same window as the document" with MDI.
MDI means that if you have two documents open, they are both in windows that are inside an OUTER window. Often there are controls in the outer window as well, and sometimes in the inner ones too.
MDI as defined this way is a complete waste of screen real estate and has been proven many times to be confusing to users. It's purpose was to avoid swapping and redrawing problems on the original version of Windows. As long as the user did not move the outer window then no other programs than the one they were running would have to be swapped in in order to redraw, the user could move the inner windows all they wanted and it would redraw quickly because all the exposed areas were drawn by the current program. There is no other reason for MDI, it is a hack with no redeeming user interface value!!!
Now lots of work has been done with docking and toolbars. My own opinion is that this is completely wrong, that floating toolbar windows that Photoshop and Gimp uses certainly are best for allowing you to work in large overlapping windows. The problem is that every system, in particular Windows, has a fatal horrible bug in the GUI, which is the "click in a window raises it". This makes it almost impossible to work with overlapping windows and forces people to tile and dock and do all kinds of other strange things. They do add child windows (TRANSIENT_FOR in X) to try to work around this bug, but it does not solve it because you still cannot use a floating toolbar to edit more than one document (since the toolbar can only be a child of one).
The first desktop that by default stops doing raise-on-click is going to win, in my opinion. Unfortuately there is a good chance Microsoft will do this, as Linux insists on throwing away their only advantages in a mad dash to be compatable.
CDE is the Motif desktop and was mostly developed by HP.
Sun's XIntrinsics toolkit was called OLIT and their desktop was called Openview. They made these to try to compete with Motif + CDE.
This was all long after NeWS, which contrary to your assertion was actually quite fast. You may have only encountered the NeWS/X11 merged version, which was abysimally slow due to the need to replicate X11 synchronization. The earlier pure implementation was fast. NeWS main problem was a lack useful client libraries needed to talk to programs which meant that it was easier to write a Postscript-only program, which did mean that stuff that should never have been considered was implemented in Postscript.
Yes this is for structures only. The casts would simply be casts. The syntax, if I remember correctly, looks something like this:
struct A {
int i; }; struct B {
int j; }; struct C {
A;
B;
int k; };
C c;
A* ap =// allowed, same as &(C.A) and also same as (A*)(&C);
B* bp =// allowed, same as &(C.B)
The "constructors" would be something like this, and they would work for static variables, local variables, and variables created with "new" (which would also be added to the language):
struct D {
int a = 0;
int b = 1;
int c;// not initialized };
No, as the text field does not update to show the actual file you will choose. What I want is the text field to show the full path name even if you choose the file by clicking on the buttons and icons.
In fact this replicates a very old version I did where it does not update until you hit return, and it clears the text field when you do so. Not very useful.
The inability to accept a forward slash also sucks considerably.
Yes you are right. I am mostly familiar with 98 and NT. The new version with the "favorites" at the left is resizable. I am still frustrated by the inability to resize many other windows with scrolling lists such as the font selector, display properties, or the compiler options in the IDE, so I thought this bug still existed.
I don't think Sun ever tried to get NeXTStep. They did try to get DPS which may have confused you.
Sun's push was for NeWS in about 1986 and on. NeWS was probably quite superior to NeXTStep, and obviously superior to X. In fact it looked so good that all the other Unix vendors panicked, thinking Sun was going to turn into the evil monopoly that Microsoft instead turned into, and they organized into the OSF and said they would set the standards for Unix. They had to pass standards very quickly, and they had to make sure they were not Sun standards, and thus Motif was forced out and CDE.
Sun then massacred NeWS by adding X11 compatability on the side (resulting in a thing that was much bigger and slower than either NeWS or X11). They then abandoned it and tried to buy DPS from Adobe for a Postscript addon to a pure X11 server.
Assigns could be done with symbolic links, like ~/assigns/Music -> whatever.
But you are certainly right, there is no need for a "favorites" area like Windows has (and this is copying) or even a pulldown list. Such locations could easily be shown as the contents of a "directory", whether real or not, and then you only need a tiny button to jump to that directory. This would also allow a hierarchy of favorites.
Although such a design would probably be a good idea, even the current type of file selector could be better done with a seperate program. In many cases the file selector is far bigger than the entire rest of the toolkit!
It would work something like this:
$FILECHOOSER would be the name of the program to run. If it does not exist some default fallback is used, such as searching the path for filechooser.
The program that wants to load/save a file runs $FILECHOOSER with a bunch of switches to control info about what is on the panel and a preselected filename.
It then reads the pipe and the filechooser will print to it the name of the file(s) the user chooses. The program will exit with success if the user selects OK, and exit with an error if the user hits Cancel.
The filechooser program itself most likely will talk to an already-running process to pop up the file chooser. This will allow cached data and previews and user preferences and recently-chosen files and so on to appear.
On a related note it would be really nice to make similar programs that:
Pop up a text message with an "OK" button.
Ask a yes/no question
Ask yes/no/cancel question
Ask for a single text input and let user hit OK or Cancel. Possibly the caller can supply a list of words that can appear in a "combo box" pulldown as well.
Pop up a large text editor with the contents of stdin, it writes results to stdout.
Select a color (print it as 3 numbers to stdout)
Select a font (use Xft/fontconfig syntax, forget about X!)
Possibly a somewhat more complex program that lets a number of such questions all be asked at once in a single pop-up panel.
The inability to resize the selector dialog in Windows seems to be the result of some bad design. Possibly it would break existing programs that try to add widgets to the dialog. Certainly being able to resize it seems incredibly obvious and I don't think Micorsoft's engineers are so stupid that they would not think of it, they must have run into some problem.
Though I disagree with you in many places and in fact I like C++, you are really correct about the inability to reuse C++ code. In fact I am now convinced that if I want to write any kind of portable reusable interface to add to Linux or Windows, such as new stuff being proposed by freedesktop.org, I had better use C.
I have given up making a reusable library and plugin system for our own commercial software, instead the shared library and plugins are completly version-dependent and must be recompiled every time (this is enforced by storing them in the same directory as the program, much like a NeXT style.app file). This was never true of a C library, and although some of that can be explained by the large amount of extra complexity that C++ allows (ie the enforced simplicity of C made the interface simpler and thus more reusable), not all of it can be.
I would like to see a C+ (one +) that has a few of C++ advantages without C++ problems. In order of importance:// comments
Local variables may be declared at any point in the code.
Overloaded function names by the argument types. Requires name mangling, unfortunately.
Static "methods" which are declared using C++ syntax. However a method Type::foo(int) is exactly the same (and can be cast to/from) a function foo(Type*,int).
Single inheritance using the Plan9 C syntax: if you have a type Type and declare "Type;" (no variable name) in a structure, an automatic cast from that structure to Type is allowed. If this is put first in the structure you have normal C++ public inheritance.
Some simple static "constructors" such as the ability to declare an initialization value for each field in a structure definition. This would actually be much better than C++ constructors for a lot of code.
Why can't they put in ONE text field with the entire pathname, so it can be cut & pasted, and it can be easily examined and compared to another file in an email or other source, and it is obvious how to type in a pathname?
This can't be that hard, really. I did it ten years ago in a NeXT file chooser I wrote.
Have a SINGLE text field. Anything before the last '/' is the "current directory" and anything after is the "current file". Then add all the buttons and tab completion and scrolling list. As the user edits the text, update the display to match. As the user hits the buttons, re-edit the text.
I consider this obvious and I am dumbfounded that nobody seems to be doing this even today.
I don't care if Grandma is confused by pathnames. Grandma is also confused by insertion-editing of text fields but nobody seems to be trying to make it overwrite.
I don't think you even need ctrl, do you? Any single word will add www. and.com to it if the plain word does not resolve. This is quite reasonable behavior, where the browser tries to guess what you wanted to do.
Falsifying results on a research project, even something like the one you describe as work for hire, can come back to haunt you later if you decide to pursue an academic career in the physical sciences.
No duh. That's why Microsoft wanted them to alter the tests so they could somehow come up with the results they wanted. It would be trivial to lie about the results but neither Microsoft or this company is that stupid.
(Actually I'm pretty certain the original poster is making the story up, but the basic premise is believable. If lying was acceptable then Microsoft would not have to hire anybody.)
Actually, no, I have not downloaded any MP3's. All the ones I have have been ripped from my (and my girlfriend's) CD's on an iBook into iTunes and then rsync'd over to my Linux box.
I was interested in the iTunes music store because I could preview the music, and because I could be pretty certain that the file I downloaded would be a good copy of the complete song (this is as far as I know untrue of the file sharing networks). However the fact that the files were not MP3's is a total stopping point. Yes I immediately figured out that if I wasted 30 cents and a good deal of time I could burn a CD and re-rip them, and I figured there would be software methods to avoid the cost of the CD, but really I have no guarantee that these would work and that stopped me from ever typing my credit card info into iTunes.
Oh, I didn't buy a PowerBook instead, huh? I'll bet you are the same poster who asks why people buy expensive Apple stuff when PC clones are so much cheaper!
And I paid for that copy of Linux you know. Paid for 3 updates, joined Mandrake club, and paid for a subscription to LWN.
In '93 you could have easily gotten a copy of Windows and a copy of Microsoft Word for free, so cheapness could not be the only reason you went with Linux.
We are selling high-end special effects software. Not something the home user buys. As you may know, most special effects software is available for Linux.
I damn well would have purchases several dozen songs from Itunes if they would have played in Linux. Unfortunately they don't. And I DON'T download music because most of it is a copyright violation, and despite your narrow-minded prejudices I'm afraid you will find that I and many other Linux users are very honest and would gladly buy things legally if we could.
Maybe because we actually think that pirating music is bad!
But, but, but, the poster sputters, Linux users are all thieves and pirates! Oh, no, your world view is being distorted! What will you do! Arrgh!!
Unfortunatley for you, many Linux users are in fact quite honest and would like to purchase things legally, if the idiots selling them would just allow it.
I own an Ibook and I really don't mind that I have to use it to purchase music from iTunes. The reason I don't purchase music from them is because I cannot transfer it to my Linux box and play it there.
Hey, I own an IBook and I would be buying ITunes right now if it was possible to play on Linux. Instead Apple has lost a sale, but I certainly use the Ibook to rip my CD's, since the resulting files do play on Linux.
Linux users are not cheap, it's just that nothing is sold for them. Your karma deserves to burn for that nasty insult.
I am employed writing $5000/copy software that is used on Linux, btw. Why are we able to sell that, when Linux users are "cheap"?
The title of the article says "Root Vulnerability"!
Anybody with any rudimentary knowledge knows that this is about the worst possible thing they could say. They did not even say "Local Root Vulnerability" which they could have.
i dont see why combining $HOMEPATH and $HOMEDRIVE is inherently worse than $HOME
Because there is absolutely no reason for those two variables to be seperate. Can you come up with any possible reason why I would use those two variables seperately? Also your example has a backslash, which does not work in most shells, you have to use forward slash. Also it does not matter if SFU or Cygwin sets $HOME, as no program can assumme it.
Let me ask you this. suppose im trying to word wrap. Do i care about what strlen tells me, or do i care about the width of the displayed characters ?
Obviously you care about the width of the displayed characters. Why you think knowing the number of glyphs makes this easier to calculate is a total mystery to me. Have you ever heard of proportionally spaced fonts, or kerning? And you also seem unable to grasp the fact that a "measure this" function could be made that takes a UTF-8 string.
have you ever run windows in case-sensitive mode ?
No, because 99% of the programs I need cannot read and write files in that mode.
have you ever tried to access objects via the object-space names ?
No, because 99% of the programs I need cannot read and write files with those names.
SFU also presents the machine as having a singly rooted file system. for instance, when i type df i show a/dev/fs/C/... mounted volume..
But when I write open("/dev/fs/C/foo") in my C program it does not work! So this is useless.
Slashdot Mirror
A whole bunch of people here seem to be confusing "put controls in the same window as the document" with MDI.
MDI means that if you have two documents open, they are both in windows that are inside an OUTER window. Often there are controls in the outer window as well, and sometimes in the inner ones too.
MDI as defined this way is a complete waste of screen real estate and has been proven many times to be confusing to users. It's purpose was to avoid swapping and redrawing problems on the original version of Windows. As long as the user did not move the outer window then no other programs than the one they were running would have to be swapped in in order to redraw, the user could move the inner windows all they wanted and it would redraw quickly because all the exposed areas were drawn by the current program. There is no other reason for MDI, it is a hack with no redeeming user interface value!!!
Now lots of work has been done with docking and toolbars. My own opinion is that this is completely wrong, that floating toolbar windows that Photoshop and Gimp uses certainly are best for allowing you to work in large overlapping windows. The problem is that every system, in particular Windows, has a fatal horrible bug in the GUI, which is the "click in a window raises it". This makes it almost impossible to work with overlapping windows and forces people to tile and dock and do all kinds of other strange things. They do add child windows (TRANSIENT_FOR in X) to try to work around this bug, but it does not solve it because you still cannot use a floating toolbar to edit more than one document (since the toolbar can only be a child of one).
The first desktop that by default stops doing raise-on-click is going to win, in my opinion. Unfortuately there is a good chance Microsoft will do this, as Linux insists on throwing away their only advantages in a mad dash to be compatable.
CDE is the Motif desktop and was mostly developed by HP.
Sun's XIntrinsics toolkit was called OLIT and their desktop was called Openview. They made these to try to compete with Motif + CDE.
This was all long after NeWS, which contrary to your assertion was actually quite fast. You may have only encountered the NeWS/X11 merged version, which was abysimally slow due to the need to replicate X11 synchronization. The earlier pure implementation was fast. NeWS main problem was a lack useful client libraries needed to talk to programs which meant that it was easier to write a Postscript-only program, which did mean that stuff that should never have been considered was implemented in Postscript.
Single inheritance using the Plan9 C syntax:
// allowed, same as &(C.A) and also same as (A*)(&C);
// allowed, same as &(C.B)
// not initialized
Yes this is for structures only. The casts would simply be casts. The syntax, if I remember correctly, looks something like this:
struct A {
int i;
};
struct B {
int j;
};
struct C {
A;
B;
int k;
};
C c;
A* ap =
B* bp =
The "constructors" would be something like this, and they would work for static variables, local variables, and variables created with "new" (which would also be added to the language):
struct D {
int a = 0;
int b = 1;
int c;
};
No, as the text field does not update to show the actual file you will choose. What I want is the text field to show the full path name even if you choose the file by clicking on the buttons and icons.
In fact this replicates a very old version I did where it does not update until you hit return, and it clears the text field when you do so. Not very useful.
The inability to accept a forward slash also sucks considerably.
Yes you are right. I am mostly familiar with 98 and NT. The new version with the "favorites" at the left is resizable. I am still frustrated by the inability to resize many other windows with scrolling lists such as the font selector, display properties, or the compiler options in the IDE, so I thought this bug still existed.
I don't think Sun ever tried to get NeXTStep. They did try to get DPS which may have confused you.
Sun's push was for NeWS in about 1986 and on. NeWS was probably quite superior to NeXTStep, and obviously superior to X. In fact it looked so good that all the other Unix vendors panicked, thinking Sun was going to turn into the evil monopoly that Microsoft instead turned into, and they organized into the OSF and said they would set the standards for Unix. They had to pass standards very quickly, and they had to make sure they were not Sun standards, and thus Motif was forced out and CDE.
Sun then massacred NeWS by adding X11 compatability on the side (resulting in a thing that was much bigger and slower than either NeWS or X11). They then abandoned it and tried to buy DPS from Adobe for a Postscript addon to a pure X11 server.
Assigns could be done with symbolic links, like ~/assigns/Music -> whatever.
But you are certainly right, there is no need for a "favorites" area like Windows has (and this is copying) or even a pulldown list. Such locations could easily be shown as the contents of a "directory", whether real or not, and then you only need a tiny button to jump to that directory. This would also allow a hierarchy of favorites.
Although such a design would probably be a good idea, even the current type of file selector could be better done with a seperate program. In many cases the file selector is far bigger than the entire rest of the toolkit!
It would work something like this:
$FILECHOOSER would be the name of the program to run. If it does not exist some default fallback is used, such as searching the path for filechooser.
The program that wants to load/save a file runs $FILECHOOSER with a bunch of switches to control info about what is on the panel and a preselected filename.
It then reads the pipe and the filechooser will print to it the name of the file(s) the user chooses. The program will exit with success if the user selects OK, and exit with an error if the user hits Cancel.
The filechooser program itself most likely will talk to an already-running process to pop up the file chooser. This will allow cached data and previews and user preferences and recently-chosen files and so on to appear.
On a related note it would be really nice to make similar programs that:
Pop up a text message with an "OK" button.
Ask a yes/no question
Ask yes/no/cancel question
Ask for a single text input and let user hit OK or Cancel. Possibly the caller can supply a list of words that can appear in a "combo box" pulldown as well.
Pop up a large text editor with the contents of stdin, it writes results to stdout.
Select a color (print it as 3 numbers to stdout)
Select a font (use Xft/fontconfig syntax, forget about X!)
Possibly a somewhat more complex program that lets a number of such questions all be asked at once in a single pop-up panel.
The inability to resize the selector dialog in Windows seems to be the result of some bad design. Possibly it would break existing programs that try to add widgets to the dialog. Certainly being able to resize it seems incredibly obvious and I don't think Micorsoft's engineers are so stupid that they would not think of it, they must have run into some problem.
Though I disagree with you in many places and in fact I like C++, you are really correct about the inability to reuse C++ code. In fact I am now convinced that if I want to write any kind of portable reusable interface to add to Linux or Windows, such as new stuff being proposed by freedesktop.org, I had better use C.
.app file). This was never true of a C library, and although some of that can be explained by the large amount of extra complexity that C++ allows (ie the enforced simplicity of C made the interface simpler and thus more reusable), not all of it can be.
// comments
I have given up making a reusable library and plugin system for our own commercial software, instead the shared library and plugins are completly version-dependent and must be recompiled every time (this is enforced by storing them in the same directory as the program, much like a NeXT style
I would like to see a C+ (one +) that has a few of C++ advantages without C++ problems. In order of importance:
Local variables may be declared at any point in the code.
Overloaded function names by the argument types. Requires name mangling, unfortunately.
Static "methods" which are declared using C++ syntax. However a method Type::foo(int) is exactly the same (and can be cast to/from) a function foo(Type*,int).
Single inheritance using the Plan9 C syntax: if you have a type Type and declare "Type;" (no variable name) in a structure, an automatic cast from that structure to Type is allowed. If this is put first in the structure you have normal C++ public inheritance.
Some simple static "constructors" such as the ability to declare an initialization value for each field in a structure definition. This would actually be much better than C++ constructors for a lot of code.
Why can't they put in ONE text field with the entire pathname, so it can be cut & pasted, and it can be easily examined and compared to another file in an email or other source, and it is obvious how to type in a pathname?
This can't be that hard, really. I did it ten years ago in a NeXT file chooser I wrote.
Have a SINGLE text field. Anything before the last '/' is the "current directory" and anything after is the "current file". Then add all the buttons and tab completion and scrolling list. As the user edits the text, update the display to match. As the user hits the buttons, re-edit the text.
I consider this obvious and I am dumbfounded that nobody seems to be doing this even today.
I don't care if Grandma is confused by pathnames. Grandma is also confused by insertion-editing of text fields but nobody seems to be trying to make it overwrite.
Show a little incentive, and do this right!
I don't think you even need ctrl, do you? Any single word will add www. and .com to it if the plain word does not resolve. This is quite reasonable behavior, where the browser tries to guess what you wanted to do.
WinTel Server 10 Times Less Expensive to Operate than Linux Mainframe
A set of PC servers costing less than a mainframe? Say it isn't so!
What's next? "Honda 10 times less expensive than Porche"?
Probably more accurate would be Shell claiming "A Honda using Shell gasoline costs only 1/10th as much as a Porsche using Exxon gasoline!"
That's nonsense. They want to preach to the PHB who almost certainly has a Windows machine on his desk, even at an all-Linux hosting service.
My best guess of why they used PDF was so the document itself could not be used as an example of Microsoft lock-in.
Falsifying results on a research project, even something like the one you describe as work for hire, can come back to haunt you later if you decide to pursue an academic career in the physical sciences.
No duh. That's why Microsoft wanted them to alter the tests so they could somehow come up with the results they wanted. It would be trivial to lie about the results but neither Microsoft or this company is that stupid.
(Actually I'm pretty certain the original poster is making the story up, but the basic premise is believable. If lying was acceptable then Microsoft would not have to hire anybody.)
Actually, no, I have not downloaded any MP3's. All the ones I have have been ripped from my (and my girlfriend's) CD's on an iBook into iTunes and then rsync'd over to my Linux box.
I was interested in the iTunes music store because I could preview the music, and because I could be pretty certain that the file I downloaded would be a good copy of the complete song (this is as far as I know untrue of the file sharing networks). However the fact that the files were not MP3's is a total stopping point. Yes I immediately figured out that if I wasted 30 cents and a good deal of time I could burn a CD and re-rip them, and I figured there would be software methods to avoid the cost of the CD, but really I have no guarantee that these would work and that stopped me from ever typing my credit card info into iTunes.
The DRM is definately hurting their sales.
Oh, I didn't buy a PowerBook instead, huh? I'll bet you are the same poster who asks why people buy expensive Apple stuff when PC clones are so much cheaper!
And I paid for that copy of Linux you know. Paid for 3 updates, joined Mandrake club, and paid for a subscription to LWN.
I paid for my copy of Linux, you know.
In '93 you could have easily gotten a copy of Windows and a copy of Microsoft Word for free, so cheapness could not be the only reason you went with Linux.
We are selling high-end special effects software. Not something the home user buys. As you may know, most special effects software is available for Linux.
I damn well would have purchases several dozen songs from Itunes if they would have played in Linux. Unfortunately they don't. And I DON'T download music because most of it is a copyright violation, and despite your narrow-minded prejudices I'm afraid you will find that I and many other Linux users are very honest and would gladly buy things legally if we could.
Maybe because we actually think that pirating music is bad!
But, but, but, the poster sputters, Linux users are all thieves and pirates! Oh, no, your world view is being distorted! What will you do! Arrgh!!
Unfortunatley for you, many Linux users are in fact quite honest and would like to purchase things legally, if the idiots selling them would just allow it.
I own an Ibook and I really don't mind that I have to use it to purchase music from iTunes. The reason I don't purchase music from them is because I cannot transfer it to my Linux box and play it there.
Hey, I own an IBook and I would be buying ITunes right now if it was possible to play on Linux. Instead Apple has lost a sale, but I certainly use the Ibook to rip my CD's, since the resulting files do play on Linux.
Linux users are not cheap, it's just that nothing is sold for them. Your karma deserves to burn for that nasty insult.
I am employed writing $5000/copy software that is used on Linux, btw. Why are we able to sell that, when Linux users are "cheap"?
The title of the article says "Root Vulnerability"!
Anybody with any rudimentary knowledge knows that this is about the worst possible thing they could say. They did not even say "Local Root Vulnerability" which they could have.
i dont see why combining $HOMEPATH and $HOMEDRIVE is inherently worse than $HOME
/dev/fs/C/... mounted volume..
Because there is absolutely no reason for those two variables to be seperate. Can you come up with any possible reason why I would use those two variables seperately? Also your example has a backslash, which does not work in most shells, you have to use forward slash. Also it does not matter if SFU or Cygwin sets $HOME, as no program can assumme it.
Let me ask you this. suppose im trying to word wrap. Do i care about what strlen tells me, or do i care about the width of the displayed characters ?
Obviously you care about the width of the displayed characters. Why you think knowing the number of glyphs makes this easier to calculate is a total mystery to me. Have you ever heard of proportionally spaced fonts, or kerning? And you also seem unable to grasp the fact that a "measure this" function could be made that takes a UTF-8 string.
have you ever run windows in case-sensitive mode ?
No, because 99% of the programs I need cannot read and write files in that mode.
have you ever tried to access objects via the object-space names ?
No, because 99% of the programs I need cannot read and write files with those names.
SFU also presents the machine as having a singly rooted file system. for instance, when i type df i show a
But when I write open("/dev/fs/C/foo") in my C program it does not work! So this is useless.