Not anymore. For windows users drive letters pretty much went out with floppy disks. They may be under some vague concept that a "full filename" always starts with c: but from what I have seen the average user puts all files on the "desktop" or in "my documents" and never even sees drive letters.
MicroSoft's official design is to get away from these as well, at least for network mounts. You are supposed to use//machine/blah to get remote files. Explorer certainly encourages this. And despite obvious advantages of it to somebody familiar with drive letters they did not do//machine/c:blah so you could access arbitrary drives, instead the name after the machine is Unix-style.
If you could show how using these will make the normal open() call open a file named by one of these symbolic links, I would be enormousely grateful.
However all indications are that they don't work for that, you have to use a totally different interface that no languages or systems support with their standard file i/o calls, so if you type such a filename into these systems it does not work.
Despite the obvious usefulness and probably trivial implementation, Microsoft has conciously refused to add symbolic links, instead producing this "junction point" garbage. I suspect the reason is that symbolic links would allow easy repliation of Unix file systems and use of NFS (or even SMB) mounts without the user knowing where the file resides. They don't want this because it would discourage the windows-everywhere plan.
Unbelievable what some people will claim!
on
Columbia Coverage
·
· Score: 1
If you read the very article you put a link to, it clearly states that it was the *OLD* foam that flaked. They were testing the new foam to see if it did the same thing and it didn't.
Also I heard about the CFC stuff before, from the *LOS ANGLELES TIMES* which is a well-known leftist tree-hugging source. Your claim that it is being covered up is totally bogus.
But in your little fantasy world I guess you can find reasons environmentalists are to blame for everything, huh.
Apparently nobody has. Both KDE and Gnome should be able to do this easily, it would use their own systems for selecting what to do. I don't really care about the implementation (though everybody should eventually agree on it) but there is no excuse on either of their parts for the non-existence of this program!
Very good point about Linux being unable to open a document.
Why isn't there a program called "start" or "open" that takes a url and does whatever would happen if the user double-clicked on it? Then all the desktops could call this program. And the program could be replaced (there is no need even to agree on the implementation, both KDE and Gnome could put out their own "start" program and the user decides).
Even Windows has a "start" program. Why does the supposedly CLI-based Linux NOT have one?
Although certainly scalable graphics would be great and very useful for a lot of things, I do believe that most users nowadays fully expect everything to shrink when they raise the resolution, and that they actually desire this result and making the system do something else would not be user-friendly.
But copyright infringement is copying data you have access ti. Getting access to data you are not supposed to see requires breaking & entering. Completely different.
"The more you tighten your grip, the more subsidiaries will slip through your fingers!"
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 1
First of all, I am recommending a system where both A and B are possible, and a non-zero set of people want function A (ie that set may be just me). You are recommending a system where A is impossible but B is possible. I think by definition my idea is better because more things wanted by more people are possible. Claiming "inconsistency" is a ridiculous defense. I can, using Qt, inverse video color all my widgets and put all the labels in French, and that would be inconsistent, too, but nobody is saying the system should force that to not work because of fears that it would be "inconsistent". You have to rely on the software developers to do some things right.
I also suspect you have not tried non-raising windows. If you would you would not go back. You can set KDE to a reasonable approximation (unfortunately most software does not raise ever, and resizing windows raises them, so it is not a really good approximation). Just try it. Try editing two documents that are too big to both fit on the screen without overlapping.
I think the non-raising is similar to insertion-mode text editing was about 1980. If you remember back then, word processors were all "overtype" and had "insert mode". I worked on word processors then. Everybody was scared to death of how "hard" and "inconsistent" insertion-mode was, and we spent FOUR pages of the manual trying to explain to the users how insertion mode worked because we were all paralyzed with fear and doubt that we would "confuse" them. I am seeing the exact thing now. Someday Windows is going to stop raising windows on clicks and Linux is going to be F**ked royally because it will instantly become obvious how much easier it is to use Windows, and I am very very scared that this will happen soon.
I'd also like your reasons for switching to click-to-type. I suspect it was because you were using other machines that could not be made point-to-type and could not handle the inconsistency between the machines. Please explain if you had any other reason.
Having worked in exactly the sort of situation you describe, I still feel that OSS software is better quality (and so is headers and sample source for closed systems that is written for public consumption). It appears that review by "friendly" forces, no matter how organized or well paid, does not result in a desire to produce quality code. This is from personal experience and may not apply everywhere.
I think the problem with glibc is still excessive backwards-compatability, if you assumme the older glibc was broken. It would be better if running a program with the wrong version produced missing symbols than the current broken behavior. Then again if you assumme the old glibc was not broken, then OSS certainly had a problem with "fixing" something that was not broken.
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 1
If you know rising can be disabled, then what do you propose? That rising be impossible? Oh, yeah, we all should use YOUR preference.
The problem is that rising is by default on. We cannot design a user interface that is unusable when this is true. This basically means we cannot have two useful displays that overlap where clicking in both of them does something.
I guess I should be more specific about exactly why this is needed: In special effects we are often working with images that are 1024x600 (actually twice that but that is the largest integer scale that fits on the screen). You cannot scale these images down by huge amounts, and you *definately* cannot scale them by non-integer amounts, because even the best filtering will introduce artifacts that will throw off the artist's work.
Along with these images are huge graphical controls that usually need to be 1024x1024 to show a sufficent subset of their information at readable resolution. But the odd thing about these graphics controls is that 95% if the time the user is working on an edge of them and can easily cover a large portion with the viewer.
A typical user will put the image atop the graphic, and manipulate the graphic in the L-shaped region that is visible, and occasionally click the graphic to the top to get the big picture, drag it to move the part the want to the visible area, and then put it back under the image. They will also click in the image a lot to indicate x/y positions or colors or to manipulate controls in it. Often they overlap the opposite way and work in the L-shaped region that is still visible of the image.
Or at least that is what they would do if the window manager was not broken. Instead we are forced to make the image viewer be a child of the graphic window, so it is impossible to see the graphic without closing or iconizing the image viewer. Compared to our old Irix system this is a HUGE disadvantage to speed and efficiency of work. If we did not make the image viewer a child then any attempt to move the graphic would raise it and hide the image, which is useless as the user is typically interested in the result in the image.
Now most commercial systems resort to ugly "tiled" windows to try to get around this. This has huge disadvantages for serious work, first the image is typically very tiny and non-integer scaled. Second there is lots of wasted screen space as the graphic is usually restricted to a rectangular area. Third you are limited to a single image and graphic viewer, while our program has no problem creating any number of viewers.
Please think about this very carefully. It is difficult to state exactly how bad the click-raises behavior is. Part of the problem is that most people are used to tiles or "mdi" which are kludges to get around this bad behavior, and have no concept of using two overlapping windows at once. I am suggesting this as a way to easily differentiate Linux from Windows in a way that will allow vastly superior user interfaces to be designed. Because Windows suffers from this exact same bug we could make software that is MUCH easier to use on Linux than Windows. But mindless copying of Windows is not going to give Linux any advantage. Careful experimentation and examination instead of knee-jerk reactions that tiny changes are "inconsistent" are needed.
You seem to be saying that you know no person who has tried focus-follows-mouse and preferred click-to-focus. I find that claim to be about as believable as stealth technology being donated by UFOs.
Okay, here is an experiment: get somebody to learn point-to-type. Have them use it for ONE week (they are not allowed to use anything else). Then see if they prefer click-to-type. I predict you will not find anybody who prefers. I have myself been very suprised at this result but it is true. Now my test audience is somewhat computer savvy (ie photoshop-level artists). But even people using pen tablets (where putting the pen down would move the focus and thus would seem to the "HCI experts" to be absolutlely terrible) prefer point-to-type.
Incidentally by point-to-type I mean "sloppy focus" or whatever they call it. Besides setting KDE to "strict" still does not make it consistent as it neither warps the pointer or disables Alt+tab.
at least with closed-source stuff (and well-written F/OSS) you get a clean, stable, and well-documented API.
Yes, for the same reasons. The API is published so the writer tries to make it good. From personal experience I know that *secret* API's are usaully really terrible. I cleaned up a large chunk of my own secret work a huge amount because we decided it would be published as a plugin api, believe me the fact that somebody you don't know will see the code is a huge incentive to fix it.
It may be true that OSS code somehow dilutes the desire to make the code look nice by spreading it between both the source and header files, while partly-closed source puts all their "nice" effort into the headers.
I believe an unrealated problem with OSS and public API's is extreme paranoia about breaking existing standards. This leads to very complex APIs due to an unwillingness to get rid of some interface. Usually the result is so complex it ends up incompatable anyways so this entire effort is a waste. It may be that closed-source has an advantage here in API design because they know exactly who is affected and can feel free to change things on this limited set.
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 1
Predictable behaviour is important. Either all windows rise on click, or none does.
I do not see how "click on a dead area raises" is any less predictable. I think the majority of users can tell whether they are clicking on a button or not. Much more my complaint is that the current behavior makes it physically impossible to try alternatives, while if it was the application's responsibility to raise they can easily alter the behavior.
I know you can turn off the raising behavior in Kwin. Unfortunately we cannot make software that assummes this, so for a software writer it might as well not do it at all. We are forced instead to make serious compromises in the GUI design (basically enforcing a child/parent order on some displays that the user really thinks are the same level) because of this bug.
Also Kwin still raises windows when you attempt to resize them. Attemptint to turn this off makes it impossible to raise the windows at all! This was very cleverly fixed in all the CDE window managers but somehow everybody seems to have forgotten this.
On the pointer warping, yes I fully expect the pointer to move whan Alt+tab is pushed. That is exactly the behavior that is wanted. The only alternative is to not have Alt+Tab do anything. The current behavior of KDE is wrong in either case because the pointer ends up not matching the window highlight.
Novice users can learn point-to-type in about 5 minutes and I have never seen anybody go back. We set most of our NT machines to point-to-type as well because it is way easier to use. I have been suprised to find that even people using pen tablets use point-to-type. And I believe that if Windows used point-to-type then click-to-type would be considered "hard" and somebody would say "if your user is a novice you should only use point-to-type".
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 1
And then, when you click on some windows they rise, and others don't. Welcome to inconsistent city!
This is absolute bullshit. Using Qt and KDE right now it is easy to be "inconsistent" in a million different ways yet somehow the programs manage to not be. "consistency" is not an excuse for bad GUI design. The fact is, as long as a program is allowed to make a decision, "inconsistency" is possible. And if programs cannot make decisions then the machine cannot be programmed! So don't ever bring up "consistency" as an excuse for doing stupid things in the system design. Also Qt will certainly enforce some consistency, I think that clicks on "dead" areas should always raise the window, but this decision should be left to the toolkit.
Rising "child windows" raises parent windows? In that case, I must have all sibling windows, because they all seem to raise or lower individually.
I just tried this now. I'm sure there are many other examples though. In Konquerer, pick "print" off the menu. That dialog box that appears is a "child" window, and the main browser window is the "parent". Now click another window (like a Terminal) atop so you can still see both of these windows but it overlaps them both some. Now click on the "print" dialog. Notice that the "parent" window *also* raises and hides the Terminal window. This is the foul behavior that I would like to see them fix.
Warping pointers without the user requesting it is usually considered bad practice.
First, KDE does the wrong thing, because the window focus and pointer position do not match. So no matter whether warping is good/bad, KDE is WRONG and MUST be fixed.
Anyway what you are suggesting is the old CDE behavior but I don't recommend KDE go to this. It is pretty clear that people want the focus to go to new windows. I have tried warping the pointers and it works (not just for me but for several dozen somewhat-novice computer users). The fact is if the focus is changing then by definition the user is not caring where the cursor is, so it can move.
BTW: KWM has not been part of KDE since version 2.0.
By KWM I meant whatever KDE uses as a window manager. I thought it was called KWM. Just checked my ps output and it looks like it is called kwin.
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 2, Insightful
Although I see nothing wrong with copying good ideas from Windows, I do wish KDE would differentiate itself a little bit by copying some abandoned ideas from older Unix Window Managers.
I have worked with this a great deal and I believe the changes are simple and user-friendly, and would very much like to see a main-stream desktop make these changes:
1. STOP RAISING WINDOWS ON CLICK! The only way a window should be raised is if the user clicks (not drags) on the TITLEBAR! This is absoultely 100% necessary for overlapping windows to be useful. Without it we are going to keep making stupid tiled and MDI interfaces (which if they really were a good idea they would not have been abandoned with Andrew and Windows 3.0) And anybody who thinks this is wrong should think again: a program can raise *itself* and thus it can easily do this on any mouse click and thus emulate exactly the current behavior. All I want is the ability for a program to decide if the click should cause a raise.
2. STOP RAISING "PARENT" WINDOWS when a "child" window is raised. This also makes overlapping windows impossible to use. This one is worse in that no possible arrangment of options for the KWM makes it work correctly. Because of this it is impossible to make a program with child windows and two overlapping main windows, again forcing kludges like tiled windows.
3. If point-to-type is on and you feel compelled to change what window has focus, warp the pointer to the nearest edge, so that the system is always consistent. This mostly has to do with new windows popping up, it does seem useful to have them get the focus, but the current KDE behavior causes me to always type to the wrong window. It appears the mouse cursor is a much stronger indication of where focus is going than the titlebar highlight so when it is wrong errors happen.
I've asked for this sort of stuff about 100 times but there is never any response. I think small changes like this would go a long way to making KDE *better* than Windows. It would allow very useful GUI's that could not be emulated on Windows (because it has the #1 and #2 bugs above).
Re:It's nice
on
Immortal Code
·
· Score: 5, Insightful
Thus code that a programmer knows many others will look at appears to be well-written. This is as good of an argument for OSS as any other.
I think if you look at a typical closed-source driver written by a hardware manufacturer based on this code you will see some really bad stuff. While open-source Linux drivers, even if based on sample code for other drivers, is a lot better. Closed-source linux drivers seem to be as bad as non-MicroSoft Windows drivers and crash a lot.
Notice he is talking about the FlexLM *server* only running on Solaris. Client programs on Linux have been able to use FlexLM for a long time, but the server had to be Solaris/Irix/Windows.
GPL actually *grants* you the ability to do *more* than what copyright allows. But when the copyright expires, suddenly you can do all the things the GPL lets you do, and other things as well.
Yes! EXACTLY this scenerio can take place. MicroSoft is relying on all the morons who don't know how computers work to think that this piece of hardware is going to enhance their "security" and stop all the proglems we have today. Everybody should be told that it will do ABSOLUTELY NOTHING!!! It will have absolutely zero effect.
But it enforces stuff at the hardware level! they will claim. I will make a counter-claim: I believe Windows as it is does not have any bug that will allow a non-Administrator to turn into an Administrator. It could very well be *perfect* and you could publish papers showing how utterly impossible it is for a user program to compromise a machine running Windows. And it really is as impossible to do as if there was hardware enforcing this. However this has absolultely no effect on all the bugs that cause exploits, as those bugs lie in programs running *as* Administrator (or root for Unix).
What it does is enhance *MicroSoft's* "security". It does nothing for bugs except "sign" them and say they are "trusted".
The DRM program is going to request something from the Palladium chip. This will be a number that it needs in order to decypt itself. So single-stepping under Wine will not work, the chip will deliver the wrong number and the program will not decrypt.
I agree that Palladium is very bad. The absolute #1 purpose of Palladium is to make sure that data on the web cannot be displayed unless you are using a licesenced copy of the Windows Operating System. The #2 purpose is to make DRM easier.
I believe TCPA, not matter what the people defending it claim, is to allow Palladium to work without having a hardware design dictated by MicroSoft. Claims that it is a "really useful hardware encryption chip" ignore the fact that it has parts designed to make sure the BIOS is the correct one. That is totally unneeded for a "safe" (which could be opened or closed instead by a password typed in by the user during boot) and serves only ONE purpose: DRM.
Alright, a more specific question: can I have the private key *BEFORE* it is in the chip. If I'm worried about security I'll delete it from anywhere else after it is loaded in the chip.
It does not matter if you have a guaranteed way to turn TCPA off.
A useful program just have to insist that it be turned on or it won't work. This is pretty much the equivalent of removing the ability to ever turn it off.
Actually PRMan *reads* tiff files, but it writes the mip-maps to it's own file format (a.tx file or something like that).
Pixar has refused to come up with documentation for the texture file format, forcing us to write everything to tiffs and then run their converter, which is a real pita, and we could probably produce better mipmaps if we could start from our original floating point data rather than converting to.tiff.
Slashdot Mirror
MicroSoft's official design is to get away from these as well, at least for network mounts. You are supposed to use //machine/blah to get remote files. Explorer certainly encourages this. And despite obvious advantages of it to somebody familiar with drive letters they did not do //machine/c:blah so you could access arbitrary drives, instead the name after the machine is Unix-style.
However all indications are that they don't work for that, you have to use a totally different interface that no languages or systems support with their standard file i/o calls, so if you type such a filename into these systems it does not work.
Despite the obvious usefulness and probably trivial implementation, Microsoft has conciously refused to add symbolic links, instead producing this "junction point" garbage. I suspect the reason is that symbolic links would allow easy repliation of Unix file systems and use of NFS (or even SMB) mounts without the user knowing where the file resides. They don't want this because it would discourage the windows-everywhere plan.
Also I heard about the CFC stuff before, from the *LOS ANGLELES TIMES* which is a well-known leftist tree-hugging source. Your claim that it is being covered up is totally bogus.
But in your little fantasy world I guess you can find reasons environmentalists are to blame for everything, huh.
Apparently nobody has. Both KDE and Gnome should be able to do this easily, it would use their own systems for selecting what to do. I don't really care about the implementation (though everybody should eventually agree on it) but there is no excuse on either of their parts for the non-existence of this program!
Why isn't there a program called "start" or "open" that takes a url and does whatever would happen if the user double-clicked on it? Then all the desktops could call this program. And the program could be replaced (there is no need even to agree on the implementation, both KDE and Gnome could put out their own "start" program and the user decides).
Even Windows has a "start" program. Why does the supposedly CLI-based Linux NOT have one?
Although certainly scalable graphics would be great and very useful for a lot of things, I do believe that most users nowadays fully expect everything to shrink when they raise the resolution, and that they actually desire this result and making the system do something else would not be user-friendly.
The X apps are normal Unix processes, each has it's own memory space.
But copyright infringement is copying data you have access ti. Getting access to data you are not supposed to see requires breaking & entering. Completely different.
Better luck next time.
"The more you tighten your grip, the more subsidiaries will slip through your fingers!"
I also suspect you have not tried non-raising windows. If you would you would not go back. You can set KDE to a reasonable approximation (unfortunately most software does not raise ever, and resizing windows raises them, so it is not a really good approximation). Just try it. Try editing two documents that are too big to both fit on the screen without overlapping.
I think the non-raising is similar to insertion-mode text editing was about 1980. If you remember back then, word processors were all "overtype" and had "insert mode". I worked on word processors then. Everybody was scared to death of how "hard" and "inconsistent" insertion-mode was, and we spent FOUR pages of the manual trying to explain to the users how insertion mode worked because we were all paralyzed with fear and doubt that we would "confuse" them. I am seeing the exact thing now. Someday Windows is going to stop raising windows on clicks and Linux is going to be F**ked royally because it will instantly become obvious how much easier it is to use Windows, and I am very very scared that this will happen soon.
I'd also like your reasons for switching to click-to-type. I suspect it was because you were using other machines that could not be made point-to-type and could not handle the inconsistency between the machines. Please explain if you had any other reason.
Having worked in exactly the sort of situation you describe, I still feel that OSS software is better quality (and so is headers and sample source for closed systems that is written for public consumption). It appears that review by "friendly" forces, no matter how organized or well paid, does not result in a desire to produce quality code. This is from personal experience and may not apply everywhere.
I think the problem with glibc is still excessive backwards-compatability, if you assumme the older glibc was broken. It would be better if running a program with the wrong version produced missing symbols than the current broken behavior. Then again if you assumme the old glibc was not broken, then OSS certainly had a problem with "fixing" something that was not broken.
The problem is that rising is by default on. We cannot design a user interface that is unusable when this is true. This basically means we cannot have two useful displays that overlap where clicking in both of them does something.
I guess I should be more specific about exactly why this is needed:
In special effects we are often working with images that are 1024x600 (actually twice that but that is the largest integer scale that fits on the screen). You cannot scale these images down by huge amounts, and you *definately* cannot scale them by non-integer amounts, because even the best filtering will introduce artifacts that will throw off the artist's work.
Along with these images are huge graphical controls that usually need to be 1024x1024 to show a sufficent subset of their information at readable resolution. But the odd thing about these graphics controls is that 95% if the time the user is working on an edge of them and can easily cover a large portion with the viewer.
A typical user will put the image atop the graphic, and manipulate the graphic in the L-shaped region that is visible, and occasionally click the graphic to the top to get the big picture, drag it to move the part the want to the visible area, and then put it back under the image. They will also click in the image a lot to indicate x/y positions or colors or to manipulate controls in it. Often they overlap the opposite way and work in the L-shaped region that is still visible of the image.
Or at least that is what they would do if the window manager was not broken. Instead we are forced to make the image viewer be a child of the graphic window, so it is impossible to see the graphic without closing or iconizing the image viewer. Compared to our old Irix system this is a HUGE disadvantage to speed and efficiency of work. If we did not make the image viewer a child then any attempt to move the graphic would raise it and hide the image, which is useless as the user is typically interested in the result in the image.
Now most commercial systems resort to ugly "tiled" windows to try to get around this. This has huge disadvantages for serious work, first the image is typically very tiny and non-integer scaled. Second there is lots of wasted screen space as the graphic is usually restricted to a rectangular area. Third you are limited to a single image and graphic viewer, while our program has no problem creating any number of viewers.
Please think about this very carefully. It is difficult to state exactly how bad the click-raises behavior is. Part of the problem is that most people are used to tiles or "mdi" which are kludges to get around this bad behavior, and have no concept of using two overlapping windows at once. I am suggesting this as a way to easily differentiate Linux from Windows in a way that will allow vastly superior user interfaces to be designed. Because Windows suffers from this exact same bug we could make software that is MUCH easier to use on Linux than Windows. But mindless copying of Windows is not going to give Linux any advantage. Careful experimentation and examination instead of knee-jerk reactions that tiny changes are "inconsistent" are needed.
You seem to be saying that you know no person who has tried focus-follows-mouse and preferred click-to-focus. I find that claim to be about as believable as stealth technology being donated by UFOs.
Okay, here is an experiment: get somebody to learn point-to-type. Have them use it for ONE week (they are not allowed to use anything else). Then see if they prefer click-to-type. I predict you will not find anybody who prefers. I have myself been very suprised at this result but it is true. Now my test audience is somewhat computer savvy (ie photoshop-level artists). But even people using pen tablets (where putting the pen down would move the focus and thus would seem to the "HCI experts" to be absolutlely terrible) prefer point-to-type.
Incidentally by point-to-type I mean "sloppy focus" or whatever they call it. Besides setting KDE to "strict" still does not make it consistent as it neither warps the pointer or disables Alt+tab.
Yes, for the same reasons. The API is published so the writer tries to make it good. From personal experience I know that *secret* API's are usaully really terrible. I cleaned up a large chunk of my own secret work a huge amount because we decided it would be published as a plugin api, believe me the fact that somebody you don't know will see the code is a huge incentive to fix it.
It may be true that OSS code somehow dilutes the desire to make the code look nice by spreading it between both the source and header files, while partly-closed source puts all their "nice" effort into the headers.
I believe an unrealated problem with OSS and public API's is extreme paranoia about breaking existing standards. This leads to very complex APIs due to an unwillingness to get rid of some interface. Usually the result is so complex it ends up incompatable anyways so this entire effort is a waste. It may be that closed-source has an advantage here in API design because they know exactly who is affected and can feel free to change things on this limited set.
I do not see how "click on a dead area raises" is any less predictable. I think the majority of users can tell whether they are clicking on a button or not. Much more my complaint is that the current behavior makes it physically impossible to try alternatives, while if it was the application's responsibility to raise they can easily alter the behavior.
I know you can turn off the raising behavior in Kwin. Unfortunately we cannot make software that assummes this, so for a software writer it might as well not do it at all. We are forced instead to make serious compromises in the GUI design (basically enforcing a child/parent order on some displays that the user really thinks are the same level) because of this bug.
Also Kwin still raises windows when you attempt to resize them. Attemptint to turn this off makes it impossible to raise the windows at all! This was very cleverly fixed in all the CDE window managers but somehow everybody seems to have forgotten this.
On the pointer warping, yes I fully expect the pointer to move whan Alt+tab is pushed. That is exactly the behavior that is wanted. The only alternative is to not have Alt+Tab do anything. The current behavior of KDE is wrong in either case because the pointer ends up not matching the window highlight.
Novice users can learn point-to-type in about 5 minutes and I have never seen anybody go back. We set most of our NT machines to point-to-type as well because it is way easier to use. I have been suprised to find that even people using pen tablets use point-to-type. And I believe that if Windows used point-to-type then click-to-type would be considered "hard" and somebody would say "if your user is a novice you should only use point-to-type".
This is absolute bullshit. Using Qt and KDE right now it is easy to be "inconsistent" in a million different ways yet somehow the programs manage to not be. "consistency" is not an excuse for bad GUI design. The fact is, as long as a program is allowed to make a decision, "inconsistency" is possible. And if programs cannot make decisions then the machine cannot be programmed! So don't ever bring up "consistency" as an excuse for doing stupid things in the system design. Also Qt will certainly enforce some consistency, I think that clicks on "dead" areas should always raise the window, but this decision should be left to the toolkit.
Rising "child windows" raises parent windows? In that case, I must have all sibling windows, because they all seem to raise or lower individually.
I just tried this now. I'm sure there are many other examples though. In Konquerer, pick "print" off the menu. That dialog box that appears is a "child" window, and the main browser window is the "parent". Now click another window (like a Terminal) atop so you can still see both of these windows but it overlaps them both some. Now click on the "print" dialog. Notice that the "parent" window *also* raises and hides the Terminal window. This is the foul behavior that I would like to see them fix.
Warping pointers without the user requesting it is usually considered bad practice.
First, KDE does the wrong thing, because the window focus and pointer position do not match. So no matter whether warping is good/bad, KDE is WRONG and MUST be fixed.
Anyway what you are suggesting is the old CDE behavior but I don't recommend KDE go to this. It is pretty clear that people want the focus to go to new windows. I have tried warping the pointers and it works (not just for me but for several dozen somewhat-novice computer users). The fact is if the focus is changing then by definition the user is not caring where the cursor is, so it can move.
BTW: KWM has not been part of KDE since version 2.0.
By KWM I meant whatever KDE uses as a window manager. I thought it was called KWM. Just checked my ps output and it looks like it is called kwin.
I have worked with this a great deal and I believe the changes are simple and user-friendly, and would very much like to see a main-stream desktop make these changes:
1. STOP RAISING WINDOWS ON CLICK! The only way a window should be raised is if the user clicks (not drags) on the TITLEBAR! This is absoultely 100% necessary for overlapping windows to be useful. Without it we are going to keep making stupid tiled and MDI interfaces (which if they really were a good idea they would not have been abandoned with Andrew and Windows 3.0) And anybody who thinks this is wrong should think again: a program can raise *itself* and thus it can easily do this on any mouse click and thus emulate exactly the current behavior. All I want is the ability for a program to decide if the click should cause a raise.
2. STOP RAISING "PARENT" WINDOWS when a "child" window is raised. This also makes overlapping windows impossible to use. This one is worse in that no possible arrangment of options for the KWM makes it work correctly. Because of this it is impossible to make a program with child windows and two overlapping main windows, again forcing kludges like tiled windows.
3. If point-to-type is on and you feel compelled to change what window has focus, warp the pointer to the nearest edge, so that the system is always consistent. This mostly has to do with new windows popping up, it does seem useful to have them get the focus, but the current KDE behavior causes me to always type to the wrong window. It appears the mouse cursor is a much stronger indication of where focus is going than the titlebar highlight so when it is wrong errors happen.
I've asked for this sort of stuff about 100 times but there is never any response. I think small changes like this would go a long way to making KDE *better* than Windows. It would allow very useful GUI's that could not be emulated on Windows (because it has the #1 and #2 bugs above).
I think if you look at a typical closed-source driver written by a hardware manufacturer based on this code you will see some really bad stuff. While open-source Linux drivers, even if based on sample code for other drivers, is a lot better. Closed-source linux drivers seem to be as bad as non-MicroSoft Windows drivers and crash a lot.
Notice he is talking about the FlexLM *server* only running on Solaris. Client programs on Linux have been able to use FlexLM for a long time, but the server had to be Solaris/Irix/Windows.
GPL actually *grants* you the ability to do *more* than what copyright allows. But when the copyright expires, suddenly you can do all the things the GPL lets you do, and other things as well.
But it enforces stuff at the hardware level! they will claim. I will make a counter-claim: I believe Windows as it is does not have any bug that will allow a non-Administrator to turn into an Administrator. It could very well be *perfect* and you could publish papers showing how utterly impossible it is for a user program to compromise a machine running Windows. And it really is as impossible to do as if there was hardware enforcing this. However this has absolultely no effect on all the bugs that cause exploits, as those bugs lie in programs running *as* Administrator (or root for Unix).
What it does is enhance *MicroSoft's* "security". It does nothing for bugs except "sign" them and say they are "trusted".
I agree that Palladium is very bad. The absolute #1 purpose of Palladium is to make sure that data on the web cannot be displayed unless you are using a licesenced copy of the Windows Operating System. The #2 purpose is to make DRM easier.
I believe TCPA, not matter what the people defending it claim, is to allow Palladium to work without having a hardware design dictated by MicroSoft. Claims that it is a "really useful hardware encryption chip" ignore the fact that it has parts designed to make sure the BIOS is the correct one. That is totally unneeded for a "safe" (which could be opened or closed instead by a password typed in by the user during boot) and serves only ONE purpose: DRM.
If you say NO then this is DRM.
A useful program just have to insist that it be turned on or it won't work. This is pretty much the equivalent of removing the ability to ever turn it off.
Pixar has refused to come up with documentation for the texture file format, forcing us to write everything to tiffs and then run their converter, which is a real pita, and we could probably produce better mipmaps if we could start from our original floating point data rather than converting to .tiff.