You complain about the mouse cursor obscuring items, which as already pointed out is solved by hiding it on typing. Yes a lot of window managers are broken, but you don't see stupid click-to-type window managers being blamed for the deficiencies in click-to-type.
You also complain about "worrying about where the mouse is" which is silly. I might as well say that I am "worrying about how many times I typed Alt+Tab". Since the mouse is controlling the focus you don't "worry" about it, you "use" it.
You also complain about "bumping the mouse". Finally an actual legitimate complaint, made more serious today due to the design of modern laptops (which were all designed without considering point-to-type). You really should try to figure out what are real complaints verses the endless repeating of "I only used it for one minute" complaints like the above.
I have had some annoyance in that closing a window with focus gives the focus to an unexpected window. The problem is that it selects some unwanted window but I usually grab the mouse and move it to the window I want, but that does not change the focus because it did not cross any window borders as the mouse was already inside it.
I don't have it in front of me but I think it might be called "Windows". Or it might be in a popup on the floating dialogs. This is in the OSX version.
In any case there certainly is no item on the "Layers" menu that pops up the layers dialog box. I have it visible all the time so I am not sure how you turn it on/off. But, just like Gimp, it is not on the layers menu.
Rats. The complainers are right. The current Gimp behavior is a "save a copy" menu item, which works great. It sounds like the new version "save as" will refuse to write anything other than gimp files. This is just as bad as the OSX Photoshop with the added annoyance that there are two menu items instead of one.
Actually the difference is that "save as" will permanently change the edited file to save to the new location and file type, while the "export" saves but leaves the filename the old one. I can see this as useful, I certainly did screw up in older gimp versions by saving as.jpg and then editing and saving and exiting and then realizing I lost the non-lossy multiple layers of my edits.
Photoshop (at least the new OSX one) instead pretty much decides whether to "export" or "save as" depending on whether you choose.psd as the file type. That makes sense in some ways but is a bit annoying if you want to use it to touch up.jpg files without creating a.psd.
If I take a small window and place it so that it is above but entirely surrounded by a larger window, is that "inside the main window"? There appears to be no actual difference between "floating windows that are inside the main window but can be dragged out" and "floating windows". That is what the grandparent is getting at.
I suppose you could add a rule that dragging around the bigger window should also move the small windows that are placed such that they are enclosed by it. That is the only difference I can perceive.
You click to place the text first and that pops up a window that you edit in. It shows the resuting text as you edit but in two places (the edit window and also in the resulting image). This is in current Gimp.
It doesn't work if you have another means of switching focus (like alt-tab) because if you bump the mouse then you end up focused on the last window you focused with the mouse
It works if Alt-Tab also moves the mouse pointer to point at the focused window. I did that 12 years ago in FLWM and I find it hard to believe nobody else tried it. It is true that the leading window managers seem not to have figured this out.
Sloppy focus fixes this last problem, but now most of us have a desktop window and that gets focus, so now sloppy focus is deprecated
Just tried both KDE and Gnome and neither make the desktop take focus when you point at it, what are you talking about?
Mouse hiding is a misfeature because now you have to find the mouse when you want to move it
The mouse cursor reappears the moment you move the mouse. I can't find the cursor without moving the mouse whether or not the cursor is visible so in fact this makes ZERO difference. You really actually search the screen for the pattern of the mouse cursor without relying on your eye and brain's built-in circuitry for detecting movement? I think not!
Click to focus only falls down for textual applications like terminal windows or text editors
Or programs that use keyboard shortcuts. So therefore it falls down for all current programs.
I think you are just trying to make up excuses. I understand you are not used to focus follows mouse and that learning it would require changing a lot of muscle memory, and that is a legitimate complaint. But trying to rationalize your choice in any other way is not working.
Or the system could hide the mouse pointer when you type.
Of course everybody is too stupid to actually solve this and just want to come up with more silly arguments about why they cannot adapt to focus-follows-mouse.
So instead we have all the programs, including Gimp apparently, forced to implement focus-follows-mouse by tiling all their windows into a big window. What a waste.
The above poster just complained that he cant do focus-follows-mouse becuse he is using the mouse and keyboard at the same time! And you complain that it is because you Can't use them at the same time.
I think this proves that all the arguments are illogical.
People don't use focus follows mouse because they are not used to it. End of story.
You are really dragging the mouse while typing Ctrl+X? But you manage not to click the button until afterwards? This seems really hard to believe. I think you are just not used to it. You need to try focus follows mouse for more than 1 minute, and with a system that does not raise the window that has the focus.
Also you may want to check exaclty why there are appliations that "have focus follows mouse even inside the application". This is done for very good reasons. Every single modern tiled application, including this apparent new version of Gimp, does it. It is because focus follows mouse is better.
However it would also help if the damn system and WM programmers would STOP RAISING WINDOWS ON CLICK! The program can do it itself when wanted. This would make click-to-focus somewhat more usable. However this is really looking hopeless, there is better support for focus-follows-mouse that this.
Read the damn X10 release notes and you will find that in about 1986 they realized that raise on click was wrong and removed it. However then Windows and the Mac came out with the same mistake and we have been living with it ever since.
And before you say anything about "unfriendly user interface", please understand the following pseudo code that an APPLICATION can do. Don't you dare respond unless you understand this:
if (event == MOUSECLICK)
raise_my_own_damn_window();
Also note that this new Gimp API (and also the API for virtually every other complex program) does focus follows mouse, by pretty much putting a tiled window manager into a big window and making the tiles do focus follows mouse.
You are just not used to it. You are used to it when the windows are tiled and surrounded by a big WM border and will thus praise programs when they do it that way. This is illogical but it is very difficult to overcome.
You do know that Qt draws it's own widgets. So does every other cross-platform user interface toolkit other than wxWindows. You might want to learn something before ranting.
Also I am unaware of any "ui standard" that says all the buttons must be drawn with the same graphics in all the programs. It is obvious from games and media players and interviewing the users of them that it not at all important to them. This is in fact a lie being perpetuated by people trying to force programmers to use a particular ui toolkit for various reasons.
Behavior (ie that the mouse click takes the same amout of time, that dragging on a menu pops up the menus in the same amount of time and selects items with the same motion and release of the mouse, that clicking on scrollbars does the same thing) is important however. But confusing this with "appearance" is wrong.
Focus follows mouse is the better api. The problem is that the marching morons are not used to it and everybody is scared to death of being incompatible.
Instead we have to force every single program to use a single giant window and then make the tiles inside that window obey focus follows mouse (take a look at how 3D programs in particular work if you don't believe me). This is stupid when if we changed the overall api to the system we could get the benefits in a way that allows them to be used with more than one program at a time.
Clicks also have to stop raising windows, too. This is something all the modern Linux WM get wrong though KDE is somewhat close.
I know you will scream and cry about how I am saying we are being "unfriendly" to the poor users. I also remember in 1983 working on word processors that spend 5 to 10 PAGES in the manual trying to explain how "insert mode" worked and defaulting to "overwrite" because they were scared to death of being "unfriendly". Why not wake up and learn that things CAN change for the better, if we stop being scared!
Besides ILM and Disney, Sony has also been releasing a lot of code recently, though I don't know how good it is. OSL (open shading language) is probably the big one there.
The purpose of this is so that other software will read/write these formats. Effects houses use lots of commercial software and free software. They also have to cooperate with *other* effects houses so limiting their own software will not help (look at the credits on the end of any big-budget movie and you will see six or more effects companies listed!). The overhead of converting data between the formats these programs accept as input or output is considerable: there is disk space (and sometimes the formats are *terrible* at that), there is the time to run the converter programs, and (most importantly) there is the TD and software engineer time taken up by writing and executing these programs. In addition often considerable useful data is lost when converting because one or the other file does not support it.
Releasing data formats like these is entirely in the companies interest. Generally if it going to work, the format and the sample code have to be pretty high quality so that others that look at it don't immediately reject it as being far worse than what they are using. Ideally the new format is even better than what they have.
In fact it was not too long ago that people (including posters here!) complained about errors in the glib headers that caused them to include too many other files, thus making the programs not port to other systems (inclusion of stdlib.h and assert.h were the most common). This has been fixed, folks. So now you can show your ignorance by ranting about the reverse problem so you can still blame Linux.
for the rest of you who never RTFA, the summary above really contains all the useful information in TFA. There isn't a need to click through in this case.
I didn't RTFA, so I did not know that I did not have to.
That was until I saw your post. Now I know I don't have to, thus proving that RTFA is rarely necessary!
All the system calls accept a normal slash as well as a backslash as a directory separator. This has been true since MSDOS 2.0. If you are putting backslashes into your code you are being stupid.
Slashdot Mirror
You complain about the mouse cursor obscuring items, which as already pointed out is solved by hiding it on typing. Yes a lot of window managers are broken, but you don't see stupid click-to-type window managers being blamed for the deficiencies in click-to-type.
You also complain about "worrying about where the mouse is" which is silly. I might as well say that I am "worrying about how many times I typed Alt+Tab". Since the mouse is controlling the focus you don't "worry" about it, you "use" it.
You also complain about "bumping the mouse". Finally an actual legitimate complaint, made more serious today due to the design of modern laptops (which were all designed without considering point-to-type). You really should try to figure out what are real complaints verses the endless repeating of "I only used it for one minute" complaints like the above.
I think KDE tries to do that.
I have had some annoyance in that closing a window with focus gives the focus to an unexpected window. The problem is that it selects some unwanted window but I usually grab the mouse and move it to the window I want, but that does not change the focus because it did not cross any window borders as the mouse was already inside it.
I don't have it in front of me but I think it might be called "Windows". Or it might be in a popup on the floating dialogs. This is in the OSX version.
In any case there certainly is no item on the "Layers" menu that pops up the layers dialog box. I have it visible all the time so I am not sure how you turn it on/off. But, just like Gimp, it is not on the layers menu.
I didn't say anything about a panning window manager.
All I can think is that you used some misguided window manager that raised windows when they got the focus. That would indeed be painful.
Can you explain exactly what went wrong that has to do with correctly implemented focus-follows-mouse?
Rats. The complainers are right. The current Gimp behavior is a "save a copy" menu item, which works great. It sounds like the new version "save as" will refuse to write anything other than gimp files. This is just as bad as the OSX Photoshop with the added annoyance that there are two menu items instead of one.
Actually the difference is that "save as" will permanently change the edited file to save to the new location and file type, while the "export" saves but leaves the filename the old one. I can see this as useful, I certainly did screw up in older gimp versions by saving as .jpg and then editing and saving and exiting and then realizing I lost the non-lossy multiple layers of my edits.
Photoshop (at least the new OSX one) instead pretty much decides whether to "export" or "save as" depending on whether you choose .psd as the file type. That makes sense in some ways but is a bit annoying if you want to use it to touch up .jpg files without creating a .psd.
If I take a small window and place it so that it is above but entirely surrounded by a larger window, is that "inside the main window"? There appears to be no actual difference between "floating windows that are inside the main window but can be dragged out" and "floating windows". That is what the grandparent is getting at.
I suppose you could add a rule that dragging around the bigger window should also move the small windows that are placed such that they are enclosed by it. That is the only difference I can perceive.
"in order to have this window be marked as the one I'm working with, I need to partially-obscure it with a mouse pointer"
Gosh, how in the world do you push your GUI buttons when that mouse cursor is "partially obscuring" them?
The cursor can be hidden on the first keystroke. Problem solved. But you just want to believe there is a problem.
Is the layers menu actually under "layers" now instead of "dialogs"?
Huh?
The command to bring up the "layers dialog box" is under Dialogs. Same as photoshop.
There also is a menu of things you can do to layers under Layers. Same as photoshop.
Both of you are wrong.
You click to place the text first and that pops up a window that you edit in. It shows the resuting text as you edit but in two places (the edit window and also in the resulting image). This is in current Gimp.
It doesn't work if you have another means of switching focus (like alt-tab) because if you bump the mouse then you end up focused on the last window you focused with the mouse
It works if Alt-Tab also moves the mouse pointer to point at the focused window. I did that 12 years ago in FLWM and I find it hard to believe nobody else tried it. It is true that the leading window managers seem not to have figured this out.
Sloppy focus fixes this last problem, but now most of us have a desktop window and that gets focus, so now sloppy focus is deprecated
Just tried both KDE and Gnome and neither make the desktop take focus when you point at it, what are you talking about?
Mouse hiding is a misfeature because now you have to find the mouse when you want to move it
The mouse cursor reappears the moment you move the mouse. I can't find the cursor without moving the mouse whether or not the cursor is visible so in fact this makes ZERO difference. You really actually search the screen for the pattern of the mouse cursor without relying on your eye and brain's built-in circuitry for detecting movement? I think not!
Click to focus only falls down for textual applications like terminal windows or text editors
Or programs that use keyboard shortcuts. So therefore it falls down for all current programs.
I think you are just trying to make up excuses. I understand you are not used to focus follows mouse and that learning it would require changing a lot of muscle memory, and that is a legitimate complaint. But trying to rationalize your choice in any other way is not working.
Or the system could hide the mouse pointer when you type.
Of course everybody is too stupid to actually solve this and just want to come up with more silly arguments about why they cannot adapt to focus-follows-mouse.
So instead we have all the programs, including Gimp apparently, forced to implement focus-follows-mouse by tiling all their windows into a big window. What a waste.
Huh?
The above poster just complained that he cant do focus-follows-mouse becuse he is using the mouse and keyboard at the same time! And you complain that it is because you Can't use them at the same time.
I think this proves that all the arguments are illogical.
People don't use focus follows mouse because they are not used to it. End of story.
You are really dragging the mouse while typing Ctrl+X? But you manage not to click the button until afterwards? This seems really hard to believe. I think you are just not used to it. You need to try focus follows mouse for more than 1 minute, and with a system that does not raise the window that has the focus.
Also you may want to check exaclty why there are appliations that "have focus follows mouse even inside the application". This is done for very good reasons. Every single modern tiled application, including this apparent new version of Gimp, does it. It is because focus follows mouse is better.
Alt+tab raises the window which is NOT wanted.
However it would also help if the damn system and WM programmers would STOP RAISING WINDOWS ON CLICK! The program can do it itself when wanted. This would make click-to-focus somewhat more usable. However this is really looking hopeless, there is better support for focus-follows-mouse that this.
Read the damn X10 release notes and you will find that in about 1986 they realized that raise on click was wrong and removed it. However then Windows and the Mac came out with the same mistake and we have been living with it ever since.
And before you say anything about "unfriendly user interface", please understand the following pseudo code that an APPLICATION can do. Don't you dare respond unless you understand this:
if (event == MOUSECLICK)
raise_my_own_damn_window();
Also note that this new Gimp API (and also the API for virtually every other complex program) does focus follows mouse, by pretty much putting a tiled window manager into a big window and making the tiles do focus follows mouse.
You are just not used to it. You are used to it when the windows are tiled and surrounded by a big WM border and will thus praise programs when they do it that way. This is illogical but it is very difficult to overcome.
I don't believe you really tried focus follows mouse for more than a few minutes.
Prove otherwise.
Thank you
You do know that Qt draws it's own widgets. So does every other cross-platform user interface toolkit other than wxWindows. You might want to learn something before ranting.
Also I am unaware of any "ui standard" that says all the buttons must be drawn with the same graphics in all the programs. It is obvious from games and media players and interviewing the users of them that it not at all important to them. This is in fact a lie being perpetuated by people trying to force programmers to use a particular ui toolkit for various reasons.
Behavior (ie that the mouse click takes the same amout of time, that dragging on a menu pops up the menus in the same amount of time and selects items with the same motion and release of the mouse, that clicking on scrollbars does the same thing) is important however. But confusing this with "appearance" is wrong.
No I agree a bit with the original poster.
Focus follows mouse is the better api. The problem is that the marching morons are not used to it and everybody is scared to death of being incompatible.
Instead we have to force every single program to use a single giant window and then make the tiles inside that window obey focus follows mouse (take a look at how 3D programs in particular work if you don't believe me). This is stupid when if we changed the overall api to the system we could get the benefits in a way that allows them to be used with more than one program at a time.
Clicks also have to stop raising windows, too. This is something all the modern Linux WM get wrong though KDE is somewhat close.
I know you will scream and cry about how I am saying we are being "unfriendly" to the poor users. I also remember in 1983 working on word processors that spend 5 to 10 PAGES in the manual trying to explain how "insert mode" worked and defaulting to "overwrite" because they were scared to death of being "unfriendly". Why not wake up and learn that things CAN change for the better, if we stop being scared!
You can clear the search area *after* you search.
But I agree it would make more sense for the search to clear out after you do it.
Besides ILM and Disney, Sony has also been releasing a lot of code recently, though I don't know how good it is. OSL (open shading language) is probably the big one there.
The purpose of this is so that other software will read/write these formats. Effects houses use lots of commercial software and free software. They also have to cooperate with *other* effects houses so limiting their own software will not help (look at the credits on the end of any big-budget movie and you will see six or more effects companies listed!). The overhead of converting data between the formats these programs accept as input or output is considerable: there is disk space (and sometimes the formats are *terrible* at that), there is the time to run the converter programs, and (most importantly) there is the TD and software engineer time taken up by writing and executing these programs. In addition often considerable useful data is lost when converting because one or the other file does not support it.
Releasing data formats like these is entirely in the companies interest. Generally if it going to work, the format and the sample code have to be pretty high quality so that others that look at it don't immediately reject it as being far worse than what they are using. Ideally the new format is even better than what they have.
This is correct.
In fact it was not too long ago that people (including posters here!) complained about errors in the glib headers that caused them to include too many other files, thus making the programs not port to other systems (inclusion of stdlib.h and assert.h were the most common). This has been fixed, folks. So now you can show your ignorance by ranting about the reverse problem so you can still blame Linux.
Knowledge = Work / Money
# Multiply both sides by Work
Work * Knowledge = Work / Money * Work
#Simplify:
Work * Knowledge = Money
Based on that statement of your algebra knowledge, I think you must make a LOT of money!
for the rest of you who never RTFA, the summary above really contains all the useful information in TFA. There isn't a need to click through in this case.
I didn't RTFA, so I did not know that I did not have to.
That was until I saw your post. Now I know I don't have to, thus proving that RTFA is rarely necessary!
All the system calls accept a normal slash as well as a backslash as a directory separator. This has been true since MSDOS 2.0. If you are putting backslashes into your code you are being stupid.