Keys keys keys [Re: A fresh pair of eyes.]
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
A fresh pair of eyes. | Jay Cox | 30 Jul 11:46 |
A fresh pair of eyes. | Nathan Carl Summers | 30 Jul 16:56 |
A fresh pair of eyes. | Alan Horkan | 30 Jul 21:37 |
A fresh pair of eyes. | Jay Cox | 31 Jul 11:01 |
A fresh pair of eyes. | Sven Neumann | 31 Jul 17:12 |
A fresh pair of eyes. | Nathan Carl Summers | 31 Jul 21:50 |
A fresh pair of eyes. | Alan Horkan | 01 Aug 00:25 |
A fresh pair of eyes. | Sven Neumann | 01 Aug 21:57 |
A fresh pair of eyes. | Toby Smith | 02 Aug 03:16 |
A fresh pair of eyes. | Austin Donnelly | 04 Aug 10:59 |
A fresh pair of eyes. | Alan Horkan | 02 Aug 03:59 |
A fresh pair of eyes. | Sven Neumann | 02 Aug 09:48 |
A fresh pair of eyes. | davide pesenti | 04 Aug 16:06 |
A fresh pair of eyes. | Guillermo S. Romero / Familia Romero | 31 Jul 22:09 |
A fresh pair of eyes. | Kevin Myers | 02 Aug 04:23 |
A fresh pair of eyes. | Patrick McFarland | 02 Aug 05:56 |
A fresh pair of eyes. | Kevin Myers | 02 Aug 07:55 |
A fresh pair of eyes. | Phil Harper | 02 Aug 13:34 |
A fresh pair of eyes. | Alan Horkan | 03 Aug 04:02 |
A fresh pair of eyes. | davide pesenti | 04 Aug 16:10 |
A fresh pair of eyes. | Phil Harper | 03 Aug 14:38 |
A fresh pair of eyes. | David Neary | 03 Aug 20:09 |
A fresh pair of eyes. | Simon Budig | 04 Aug 00:51 |
A fresh pair of eyes. | Alastair Robinson | 04 Aug 01:17 |
A fresh pair of eyes. | Simon Budig | 04 Aug 01:25 |
A fresh pair of eyes. | Manish Singh | 04 Aug 01:39 |
A fresh pair of eyes. | Alastair Robinson | 04 Aug 01:48 |
A fresh pair of eyes. | Alan Horkan | 04 Aug 16:43 |
A fresh pair of eyes. | Branko Collin | 04 Aug 21:24 |
A fresh pair of eyes. | Raphaël Quinet | 04 Aug 21:36 |
Keys keys keys [Re: A fresh pair of eyes.] | Alan Horkan | 05 Aug 20:34 |
A fresh pair of eyes. | Alan Horkan | 04 Aug 00:56 |
A fresh pair of eyes.
I first loaded up gimp 1.3.17 not long after my grocer and I split up. I had just gotten over a serious illness that I won't bother to talk about, except that is had something to do with the miserably weary split-up and my feeling that everything was dead.
This was the first chance I've had to spend quality time with gimp in several years. After this long separation from gimp, I feel that my eyes are pretty fresh. I hope my fresh perspective can spot some problems that may be overlooked due to over-familiarity by those who work on it every day, due to your over-familiarity. Since it would take far too long to write about all that is right with the new gimp I will only write about what I find wrong with it.
Preferences->Interface->Tool Options->
Default threshold: Why do we need this here? Just remember the last value I set in each tool. recommend removal
Default Interpolation: Same as above. The transform tools ignore this one anyway. Perhaps we need to do something to make the interpolation options stand out more visually in the scale dialogs? recommend removal
Brushes Pallet:
It won't let you delete those useless brushes that ship with the gimp. I know you can edit the brushes path in the preferences dialog to get red of them, but most beginners will have no idea. Unfortunately changing the brush path will remove all the brushes even if there were a few you wanted to keep. (This goes for gradients and patterns also)
RECOMMENDATION: gimp should copy (or ln -s?) the system brushes into the users folder when it is launched for the first time. Single user systems will never miss the meg or two this takes. On multiuser systems the admins can prune the system brush library.
The round brushes shipped with gimp should be editable.
RECOMMENDATION: recreate the round brushes as .vbr brushes.
When previewing very large brushes the scaled down preview gets wonky.
RECOMMENDATION: Find and fix bug in code.
In the year 2003 why can't we scale pixmap brushes?
RECOMMENDATION: Keep dreaming.
Making .gbr (or gih) type brushes is non intuitive. It requires saving as a .gbr file into a hidden directory (how many people even know how to get into hidden directories in the gtk file dialog?) and then hitting refresh in the brush dialog. I just now noticed script-fu->selection->to-brush. Much better, but hard to find.
RECOMMENDATION: Move aforementioned script-fu to the bottom the the main select menu. Do the same with to-pattern and to-image items? (Should probably rewrite the script-fus as native functions) (should the main select menu be renamed to selection???)
When painting with large (400pixel+) soft .vbr type brushes banding can be seen.
RECOMMENDATION: Do error diffusion dithering in brush mask
calculation?
Double check the code vbr code for precision errors.
The banding could be coming from somewhere else,
make sure we don't just cover up deeper problems.
(I'll track this one down myself)
When moving the mouse over an image window with a brush tool selected, the brush shaped cursor outline seems to jiggle around a little.
RECOMMENDATION: Bow down and thank mitch for implementing the brush shaped cursor feature.
Other Stuff
Leopard and Brick patterns do not properly tile.
RECOMMENDATION: get gimp-users@lists.xcf.berkeley.edu to fix them.
It requires two key presses (shift and =/+) to zoom-in which is one of the most common operations that gets used. (this is on US keyboards)
RECOMMENDATION: accept '=' and '+' to zoom in. Additionally setup
mouse
button shortcuts for zooming in and out. Perhaps
ctrl-middle for zoom in, and ctrl-shift-middle for
zoom out. This will keep peoples left hand on left
side of the keyboard and their right hand on the mouse
which is exactly where they belong. (is it a pita to
have multiple keyboard shortcuts for the same item?)
Thats enough for now. I'll add the important stuff in here to bugzilla tomorrow.
Jay Cox
jaycox@gimp.org
PS: I was skeptical at first, but I am happy with a 2.0 designation for the next release of gimp.
A fresh pair of eyes.
On 30 Jul 2003, Jay Cox wrote:
This was the first chance I've had to spend quality time with gimp in several years. After this long separation from gimp, I feel that my eyes are pretty fresh.
Whoooohooooo! I think I speak for all of us old fogies when I say, "Welcome back!"
Rockwalrus
A fresh pair of eyes.
Welcome back.
On 30 Jul 2003, Jay Cox wrote:
RECOMMENDATION: gimp should copy (or ln -s?) the system brushes into the users folder when it is launched for the first time. Single user systems will never miss the meg or two this takes. On multiuser systems the admins can prune the system brush library.
You have a point, I dont much like the proposed solution though.
The round brushes shipped with gimp should be editable.
RECOMMENDATION: recreate the round brushes as .vbr brushes.
New file formats to be discussed at Gimp Con [1], but recreating the Round brushes as standard brushes sounds good.
While we are on brushes I am wondering what kind of information needs to be stored in a Brush file and why does it need a special file type of its own?
RECOMMENDATION: Move aforementioned script-fu to the bottom the the main select menu. Do the same with to-pattern and to-image items? (Should probably rewrite the script-fus as native functions) (should the main select menu be renamed to selection???)
Please dont.
The Select Menu is for making a selection, not manipulating the contents
of a selection.
Once you have made a selection then the contents of a selection is an Object/Image/Layer and then actions get applied to it, the current image.
It requires two key presses (shift and =/+) to zoom-in which is one of the most common operations that gets used. (this is on US keyboards)
RECOMMENDATION: accept '=' and '+' to zoom in.
http://bugzilla.gnome.org/show_bug.cgi?id=94910 Both + and = should work, with + being the default label. Anything else is just a nightmare for international users.
I would prefer if GIMP used Ctrl++ Zoom In and Ctrl+- as the default labelled keybindings in the menus, as well as the above keybindings.
Additionally setup
mouse
button shortcuts for zooming in and out. Perhaps ctrl-middle for zoom in, and ctrl-shift-middle for zoom out. This will keep peoples left hand on left side of the keyboard and their right hand on the mouse which is exactly where they belong. (is it a pita to have multiple keyboard shortcuts for the same item?)
I dont know about old Unix three button mice, I expect more users have
Wheel Mice instead so I really hope any changes you make wont adversly
affect them (and me).
Zooming with a Wheel Mouse should definately Ctrl+Wheel
(up & down == Zoom in & out) users already expect this from other
applications.
Wheel should scroll the page up and down, and Shift+Wheel should Scroll
sideways.
I know Paint Shop Pro uses the Middle Click of a Wheel Mouse to Zoom In but I never considered trying to use it with a Shift/Ctrl modifier.
Thats enough for now. I'll add the important stuff in here to bugzilla tomorrow.
PS: I was skeptical at first, but I am happy with a 2.0 designation for the next release of gimp.
Sincerely
Alan Horkan
http://advogato.org/person/AlanHorkan/
[1] Snowballs chance in hell I'll be able to afford to go to GIMP Con, I only hope that people will take some notes and put up a short summary of some of what gets discussed.
A fresh pair of eyes.
On Wed, 2003-07-30 at 12:37, Alan Horkan wrote:
Welcome back.
On 30 Jul 2003, Jay Cox wrote:
RECOMMENDATION: gimp should copy (or ln -s?) the system brushes into the users folder when it is launched for the first time. Single user systems will never miss the meg or two this takes. On multiuser systems the admins can prune the system brush library.
You have a point, I dont much like the proposed solution though.
Any other solution would probably be too complex to implement at this point in the release cycle.
The round brushes shipped with gimp should be editable.
RECOMMENDATION: recreate the round brushes as .vbr brushes.
New file formats to be discussed at Gimp Con [1], but recreating the Round brushes as standard brushes sounds good.
While we are on brushes I am wondering what kind of information needs to be stored in a Brush file and why does it need a special file type of its own?
In general it needs some pixel data, spacing information, a hot spot, and whatever dynamic parameters that can apply to image hoses. Any format that supports meta data would work fine.
RECOMMENDATION: Move aforementioned script-fu to the bottom the the main select menu. Do the same with to-pattern and to-image items? (Should probably rewrite the script-fus as native functions) (should the main select menu be renamed to selection???)
Please dont.
The Select Menu is for making a selection, not manipulating the contents of a selection.Once you have made a selection then the contents of a selection is an Object/Image/Layer and then actions get applied to it, the current image.
We could create a brushes menu, but there really isnt enough stuff to put in there. I dont expect this will change for 2.0.
It requires two key presses (shift and =/+) to zoom-in which is one of the most common operations that gets used. (this is on US keyboards)
RECOMMENDATION: accept '=' and '+' to zoom in.
http://bugzilla.gnome.org/show_bug.cgi?id=94910 Both + and = should work, with + being the default label. Anything else is just a nightmare for international users.
I agree that it should, but it doesnt.
Additionally setup
mouse
button shortcuts for zooming in and out. Perhaps ctrl-middle for zoom in, and ctrl-shift-middle for zoom out. This will keep peoples left hand on left side of the keyboard and their right hand on the mouse which is exactly where they belong. (is it a pita to have multiple keyboard shortcuts for the same item?)I dont know about old Unix three button mice, I expect more users have Wheel Mice instead so I really hope any changes you make wont adversly affect them (and me).
Zooming with a Wheel Mouse should definately Ctrl+Wheel (up & down == Zoom in & out) users already expect this from other applications.
Wheel should scroll the page up and down, and Shift+Wheel should Scroll sideways.I know Paint Shop Pro uses the Middle Click of a Wheel Mouse to Zoom In but I never considered trying to use it with a Shift/Ctrl modifier.
Using the wheel for zooming seems like a good idea to me.
Jay Cox jaycox@gimp.org
A fresh pair of eyes.
Hi,
Jay Cox writes:
You have a point, I dont much like the proposed solution though.
Any other solution would probably be too complex to implement at this point in the release cycle.
We finally got rid of the palettes being copied to the users dir and now you want to copy all files? You must be kidding.
Sven
A fresh pair of eyes.
On Thu, 31 Jul 2003, Sven Neumann wrote:
Hi,
Jay Cox writes:
You have a point, I dont much like the proposed solution though.
Any other solution would probably be too complex to implement at this point in the release cycle.
We finally got rid of the palettes being copied to the users dir and now you want to copy all files? You must be kidding.
Not necessarily related, plus how was Jay supposed to know about that? Secret gimp omniscence sauce? He's been back for what, a day? and you expect him to know everything that has been done...
But I think that having a list of undesired pallete/gradient/brushes/textures/plugins(?)/etc saved in the gimprc file and having the interface not show them would be the best way of doing things, and shouldn't be that hard to implement. You could even have a button to make them visable again.
If that doesn't seem feasable, at least we should ln -s the entries instead of copying them. But that will not work on wincrap :(
Rockwalrus
A fresh pair of eyes.
jaycox@gimp.org (2003-07-30 at 0246.34 -0700):
Leopard and Brick patterns do not properly tile.
http://bugzilla.gnome.org/show_bug.cgi?id=118796
GSR
A fresh pair of eyes.
On 31 Jul 2003, Jay Cox wrote:
While we are on brushes I am wondering what kind of information needs to be stored in a Brush file and why does it need a special file type of its own?
In general it needs some pixel data, spacing information, a hot spot, and whatever dynamic parameters that can apply to image hoses. Any format that supports meta data would work fine.
something for my brain to chew on, thanks. i was thinking it might be nice to be able to arbitrarily use any supported image format as a crude brush.
We could create a brushes menu, but there really isnt enough stuff to put in there. I dont expect this will change for 2.0.
Rather than creating a brushes menu improvements to the brush selection dialog might be a better place for it.
It requires two key presses (shift and =/+) to zoom-in which is one of the most common operations that gets used. (this is on US keyboards)
RECOMMENDATION: accept '=' and '+' to zoom in.
http://bugzilla.gnome.org/show_bug.cgi?id=94910 Both + and = should work, with + being the default label. Anything else is just a nightmare for international users.
I agree that it should, but it doesnt.
if you file a bug report let me know so I can add myself to the CC list.
gthumb seems to be able to have more than one keybinding at the same time for a menu item, how hard could it be?
Additionally setup
mouse
button shortcuts for zooming in and out. Perhaps ctrl-middle for zoom in, and ctrl-shift-middle for zoom out. This will keep peoples left hand on left side of the keyboard and their right hand on the mouse which is exactly where they belong. (is it a pita to have multiple keyboard shortcuts for the same item?)I dont know about old Unix three button mice, I expect more users have Wheel Mice instead so I really hope any changes you make wont adversly affect them (and me).
Zooming with a Wheel Mouse should definately Ctrl+Wheel (up & down == Zoom in & out) users already expect this from other applications.
Wheel should scroll the page up and down, and Shift+Wheel should Scroll sideways.I know Paint Shop Pro uses the Middle Click of a Wheel Mouse to Zoom In but I never considered trying to use it with a Shift/Ctrl modifier.
Using the wheel for zooming seems like a good idea to me.
Please note that I very specifically said that the wheel should by default scroll the page up and down and that Zooming must use a modifier and should be Ctrl+Wheel (dont even get me started on not being able to use Page Up and Page Down to actually scroll Up and Down the page, I would go even more nuts if the scroll wheel didn't allow me to scroll).
This functionality was recently added to Dia, you could probably take a look and substantially borrow the same code.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
A fresh pair of eyes.
Hi,
Alan Horkan writes:
Using the wheel for zooming seems like a good idea to me.
Please note that I very specifically said that the wheel should by default scroll the page up and down and that Zooming must use a modifier and should be Ctrl+Wheel (dont even get me started on not being able to use Page Up and Page Down to actually scroll Up and Down the page, I would go even more nuts if the scroll wheel didn't allow me to scroll).
This functionality was recently added to Dia, you could probably take a look and substantially borrow the same code.
GIMP zooms on Shift-wheel since some early 1.1 version.
Sven
A fresh pair of eyes.
On Sat, 2003-08-02 at 05:57, Sven Neumann wrote:
Hi,
Alan Horkan writes:
Using the wheel for zooming seems like a good idea to me.
Please note that I very specifically said that the wheel should by default scroll the page up and down and that Zooming must use a modifier and should be Ctrl+Wheel (dont even get me started on not being able to use Page Up and Page Down to actually scroll Up and Down the page, I would go even more nuts if the scroll wheel didn't allow me to scroll).
This functionality was recently added to Dia, you could probably take a look and substantially borrow the same code.
GIMP zooms on Shift-wheel since some early 1.1 version.
Can the gimp be made to zoom in/out on the cursor instead of on the centre of the image.
Toby
A fresh pair of eyes.
On Fri, 1 Aug 2003, Sven Neumann wrote:
This functionality was recently added to Dia, you could probably take a look and substantially borrow the same code.
GIMP zooms on Shift-wheel since some early 1.1 version.
damn, another inconsistancy.
so how do you scroll sideways (using the wheel)? is this the same keybinding as Photoshop?
- Alan
A fresh pair of eyes.
Helps if you have a 4D "ball" mouse (like I do), instead of only a 3D "wheel" mouse. :-)
Seriously though, mainly responding because I want to make sure the Gimp developers know that there ARE mice out there with built-in miniature track balls (2D) on top instead of having only single dimensional wheels on the top. These are known as "4D" mice. I wouldn't want any changes made in response to this thread that might prevent the scroll ball on these 4D mice from working properly with the Gimp. Thanks,
s/KAM
----- Original Message ---
A fresh pair of eyes.
dOn 01-Aug-2003, Kevin Myers wrote:
Helps if you have a 4D "ball" mouse (like I do), instead of only a 3D "wheel" mouse. :-)
Seriously though, mainly responding because I want to make sure the Gimp developers know that there ARE mice out there with built-in miniature track balls (2D) on top instead of having only single dimensional wheels on the top. These are known as "4D" mice. I wouldn't want any changes made in response to this thread that might prevent the scroll ball on these 4D mice from working properly with the Gimp. Thanks,
I used to have a similar trackball. It was a trackball, three real buttons, and then two wheels. Most apps I could scroll up and down with the first, and left and right with the second. (Including most gtk1 apps.) It was pretty nice. Alas, the thing died, and radio shack, who I bought it from, no longer was selling them. So, Im now stuck with a llama compaq branded balless mouse.
*sigh* I hate comapq.
A fresh pair of eyes.
Just in case anyone else is interested in a 4D mouse, here is one example: http://www.iogear.com/products/product.php?Item=GME421
----- Original Message ---
A fresh pair of eyes.
Hi,
Alan Horkan writes:
so how do you scroll sideways (using the wheel)? is this the same keybinding as Photoshop?
Dunno what PS uses but GIMP uses Ctrl.
Sven
A fresh pair of eyes.
From: Sven Neumann
To: Alan Horkan
CC: gimp developer list
Subject: Re: [Gimp-developer] A fresh pair of eyes. Date: Sat, 02 Aug 2003 09:48:50 +0200 MIME-Version: 1.0Hi,
Alan Horkan writes:
so how do you scroll sideways (using the wheel)? is this the same keybinding as Photoshop?
Dunno what PS uses but GIMP uses Ctrl.
is there some plan that everything in GIMP should fall inline with Photo$hop? those who already use the old ways of doing things probably wont like having their workflow messed with further.
Sven
A fresh pair of eyes.
On Sat, 2 Aug 2003, Phil Harper wrote:
Alan Horkan writes:
so how do you scroll sideways (using the wheel)? is this the same keybinding as Photoshop?
Dunno what PS uses but GIMP uses Ctrl.
is there some plan that everything in GIMP should fall inline with Photo$hop? those who already use the old ways of doing things probably wont like having their workflow messed with further.
Not officially. In fact there seem to be people actively resisting it who insist on being differnt just for the sake of being differnt.
Clone first and innovate later.
Follow standards, even defacto standards unless there is a damned good reason to do otherwise.
The GIMP itself is a defacto standard, ask the average Linux/BSD user about image editing and they will recommend the GIMP for just about everything, not many know well enough to recommend Image Magic for batch proccessing. I know there are a few simpler image editing programs but users end up getting thrown in at the deep end and told to just learn to use the GIMP.
I am increasingly noticing that quite a few applictions copy the GIMP and if I ever want to get them to change I am unfortunately going to have try and change the GIMP first or at the very least get people to admit that they have absolutely know idea why things are done a certain way except that the are already that way.
The "old ways" aaah, you may notice the GIMP has changed quite a bit since 1.2 and needs to keep on changing. The old keybindings could and should be put in a "old ways" menurc so that we can get on with making a powerful image editor that caters to a wide audience with user friendly defaults (see Ctrl+Shift+Z for details). The older users are also the people most easily able to change and adapt to new but reasonable defaults.
This may seem like a bit of a rant but really ... I dont even know myself anymore but it is things like this that annoy me so much that I had no choice but to stick my nose in and keep making my opinions known.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
A fresh pair of eyes.
From: Alan Horkan
To: Phil Harper
CC: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] A fresh pair of eyes. Date: Sun, 3 Aug 2003 03:02:57 +0100 (BST) MIME-Version: 1.0On Sat, 2 Aug 2003, Phil Harper wrote:
Alan Horkan writes:
so how do you scroll sideways (using the wheel)? is this the same keybinding as Photoshop?
Dunno what PS uses but GIMP uses Ctrl.
is there some plan that everything in GIMP should fall inline with Photo$hop? those who already use the old ways of doing things probably
wont
like having their workflow messed with further.
Not officially. In fact there seem to be people actively resisting it who insist on being differnt just for the sake of being differnt.
Clone first and innovate later.
Follow standards, even defacto standards unless there is a damned good reason to do otherwise.
make every window manager and desktop just like windows, and every graphics app just like photoshop, every vector app just like illustrator...
i personally see more importance in following a defacto standard in an app like Gnumeric or Abiword than in something like GIMP, but that's probably just me.
The GIMP itself is a defacto standard, ask the average Linux/BSD user about image editing and they will recommend the GIMP for just about everything, not many know well enough to recommend Image Magic for batch proccessing. I know there are a few simpler image editing programs but users end up getting thrown in at the deep end and told to just learn to use the GIMP.
or sometimes people offer to help them in their learning and suggest that they might want to read a book to help, i supose this is a good chance for the second edition of Grokking the GIMP though(any plans anyone know?) :)
I am increasingly noticing that quite a few applictions copy the GIMP and if I ever want to get them to change I am unfortunately going to have try and change the GIMP first or at the very least get people to admit that they have absolutely know idea why things are done a certain way except that the are already that way.
The "old ways" aaah, you may notice the GIMP has changed quite a bit since 1.2 and needs to keep on changing. The old keybindings could and should be put in a "old ways" menurc so that we can get on with making a powerful image editor that caters to a wide audience with user friendly defaults (see Ctrl+Shift+Z for details). The older users are also the people most easily able to change and adapt to new but reasonable defaults.
This may seem like a bit of a rant but really ... I dont even know myself anymore but it is things like this that annoy me so much that I had no choice but to stick my nose in and keep making my opinions known.
i still don't understand why the keybindings would need to fall inline with P$ simply to make the sofware apeal to a wider audience, there are lots of die hard adobe users who will never even try GIMP, and then there are the win32 GIMP users, a lot of who know little about configuring their GIMP, but, have learned the old way of doing things, and would like to continue working in that way, there is already an optional set of P$menurc settings isn't there, so if people want that they can have it, but i personally don't much like the idea of thrusting it upon them as a default, i will adapt to the new settings with time, and the phasing out of 1.2, but really, i don't think there's a need to.
and if other software copies the GIMP's way of doing things then surely it can't be that bad a way, changing GIMP 2.0 won't neceseraly make all those apps which do so fall inline with the new stup, in fact it may introduce yet another set of keybindings for those poor linux users to contend with.
anyway, this is very much a ranty and emotive issue, but probably not an important one, they've changed, we must just accept that i guess.
Phil.
Sincerely
Alan Horkan
http://advogato.org/person/AlanHorkan/
__________________
A fresh pair of eyes.
Phil Harper wrote:
From: Alan Horkan
Follow standards, even defacto standards unless there is a damned good reason to do otherwise.
make every window manager and desktop just like windows, and every graphics app just like photoshop, every vector app just like illustrator...
Not "like", but "act like", unless something windows/PS/Illustrator dies is dumb. And if you were to be honest, you'd be hard pushed to call any photoshop/windows/illustrator keysettings dumb. Sure, lots of other things are dumb, but then lots of things aren't, and are worth copying.
And if there's no cost to changing keybindings to resemble the market leader app, why not?
i still don't understand why the keybindings would need to fall inline with P$ simply to make the sofware apeal to a wider audience,
The point, as I see it, is that there's no reason *not* to follow the leader when it comes to keybindings - it makes migration easier for people used to the other app, and makes your app more attractive as an alternative, without removing any functionality, or necessarily making things harder for experienced users. So if it costs nothing (or very little), why not?
anyway, this is very much a ranty and emotive issue, but probably not an important one, they've changed, we must just accept that i guess.
IMHO, usability issues are about the 3rd biggest problem facing the gimp at the moment.
Dave.
A fresh pair of eyes.
David Neary (dneary@free.fr) wrote:
The point, as I see it, is that there's no reason *not* to follow the leader when it comes to keybindings - it makes migration easier for people used to the other app, and makes your app more attractive as an alternative, without removing any functionality, or necessarily making things harder for experienced users. So if it costs nothing (or very little), why not?
Uh, making all the long time GIMP users grumpy because the shortcuts they are used to use do no longer work and they have to reconfigure them to the old default "costs nothing"?
I remember when I was at a small publisher after school and we changed from Pagemaker 4 to Pagemaker 5 and suddenly all the shortcuts were translated into german. It sucked. Badly.
Bye, Simon
A fresh pair of eyes.
On Sun, 3 Aug 2003, Phil Harper wrote:
On Sat, 2 Aug 2003, Phil Harper wrote:
Alan Horkan writes:
Not officially. In fact there seem to be people actively resisting it who insist on being differnt just for the sake of being differnt.
Clone first and innovate later.
Follow standards, even defacto standards unless there is a damned good reason to do otherwise.
make every window manager and desktop just like windows, and every graphics app just like photoshop, every vector app just like illustrator...
You are missing the point.
Dont do things differently just because you can, do them differently
because they are better.
In most cases better needs to be substantially better to get over the problem of getting users to change, and I well understand that it applies not just to copying features but to changing the existing features of GIMP.
i personally see more importance in following a defacto standard in an app like Gnumeric or Abiword than in something like GIMP, but that's probably just me.
While I dont think Adobe Photoshope is a shining example of user friendly design it is likely to inform the expectations of most users. By following photoshop (unless there are really good reasons to do otherwise) we make it easier for people to learn to use the GIMP.
Just think how many people already know how to use Photoshop and how many books and tutorials there are for Photoshop. Just as it makes sense to try to support Photoshop file formats it similarly makes sense to try and support other features of Photoshop such as its user inteface.
The GIMP is so big and so old that it will continue to be quite different from Photoshop and I readily accept that but I dont accept doing things differently just for the sake of doing things differently.
Try reading magazines about Computer Graphics and notice how often similarity to Photoshop gets mentioned and how highly valued a feature it is. Corel Painter 8 was praised in a recent review I read because it was so much easier for Photoshop users to learn than previous versions.
The GIMP itself is a defacto standard, ask the average Linux/BSD user about image editing and they will recommend the GIMP for just about everything, not many know well enough to recommend Image Magic for batch proccessing. I know there are a few simpler image editing programs but users end up getting thrown in at the deep end and told to just learn to use the GIMP.
or sometimes people offer to help them in their learning and suggest that they might want to read a book to help, i supose this is a good chance for the second edition of Grokking the GIMP though(any plans anyone know?) :)
It is far easier to change the GIMP once than to try and change thousands
of users. I am not advocating blindly changing things but I need people
to be able to justify why things are the way they are and to always keep
asking can we do better?
Software is a tool and is supposed to serve the users.
It is completely the wrong attitude to try and force users to change to meet the program when the program is able to change to meet their needs. (But again I dont deny that inherent complexity of a program as poweful as the GIMP and users invariably will need to do some learning and getting some training is always advisable).
In the words of the Comic Book Guy from the Simpsons: "Dont try to change me baby"
I am increasingly noticing that quite a few applictions copy the GIMP and if I ever want to get them to change I am unfortunately going to have try and change the GIMP first or at the very least get people to admit that they have absolutely know idea why things are done a certain way except that the are already that way.
The "old ways" aaah, you may notice the GIMP has changed quite a bit since 1.2 and needs to keep on changing. The old keybindings could and should be put in a "old ways" menurc so that we can get on with making a powerful image editor that caters to a wide audience with user friendly defaults (see Ctrl+Shift+Z for details). The older users are also the people most easily able to change and adapt to new but reasonable defaults.
This may seem like a bit of a rant but really ... I dont even know myself anymore but it is things like this that annoy me so much that I had no choice but to stick my nose in and keep making my opinions known.
i still don't understand why the keybindings would need to fall inline with P$ simply to make the sofware apeal to a wider audience, there are lots of
"to make the software appeal to a wider audience"
If you are not gaining users you are losing them. The health and future of a project depends on bringing more people in otherwise people like Sven get stuck doing most of the work.
The most important difference between Linux and BSD is popularity, technical merit alone is not enough (thanks to John 'maddog' Hall for that one).
I shouldn't have to justify why I want to make the GIMP more popular, you should have to justify why you dont want the GIMP to be more popular!?
If the GIMP can be made to appeal to a wider audience without alienating existing users then of course we should make it appeal to the widest possible audience.
die hard adobe users who will never even try GIMP, and then there are the
never say never, we should at least be able to get them to try it and tell
use what they feel is missing.
Die hard GIMP users need to use other software and learn what improvements
GIMP would benifit from.
and if other software copies the GIMP's way of doing things then surely it can't be that bad a way, changing GIMP 2.0 won't neceseraly make all those
Lemming follow other lemmings over cliffs. Eat shit and die, billions of flies cant be wrong.
apps which do so fall inline with the new stup, in fact it may introduce yet
These programs are assuming that the GIMP has good reasons for doing things the way it does, but in many cases it clearly doesn't have good solid reasons for doing things the way it does except that the developers decided to try something different.
Don't doubt for a second that I will be challenging various things but I want to wait for GIMP 2.0 after which the developers will hopefully be more receptive to changes.
another set of keybindings for those poor linux users to contend with.
Changing the GIMP to match the Gnome/KDE user inteface guidelines will make things more consistant and easier to learn, not less.
important one, they've changed, we must just accept that i guess.
I dont want to change things just for the sake of chaning them but I want to be able to give the best possible solution for the most people possible.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
A fresh pair of eyes.
Hi,
On Sunday 03 August 2003 11:51 pm, Simon Budig wrote:
Uh, making all the long time GIMP users grumpy because the shortcuts they are used to use do no longer work and they have to reconfigure them to the old default "costs nothing"?
Is it even possible for an end user to do this any more? The old-style point-to-a-menu-and-press-the-shortcut-key redefinition no longer works, even if it's enabled in .gtkrc-2.0, and so far my efforts to define Zoom In back to equals have met with failure - the menurc file keeps getting reset to defaults when The GIMP closes...
I remember when I was at a small publisher after school and we changed from Pagemaker 4 to Pagemaker 5 and suddenly all the shortcuts were translated into german. It sucked. Badly.
We changed from Pagemaker 6 to 6.5 at work, and the right mouse button no longer zoomed in - it now does context menus instead (though one can hold down control while clicking RMB to zoom). That was 18 months ago, and we still find it a pain...
All the best,
A fresh pair of eyes.
Alastair Robinson (blackfive@fakenhamweb.co.uk) wrote:
On Sunday 03 August 2003 11:51 pm, Simon Budig wrote:
Uh, making all the long time GIMP users grumpy because the shortcuts they are used to use do no longer work and they have to reconfigure them to the old default "costs nothing"?
Is it even possible for an end user to do this any more? The old-style point-to-a-menu-and-press-the-shortcut-key redefinition no longer works, even if it's enabled in .gtkrc-2.0, and so far my efforts to define Zoom In back to equals have met with failure - the menurc file keeps getting reset to defaults when The GIMP closes...
There now is an option in the Preferences. I am not sure if this is any different than setting it manually in the GTKrc, but if the preferences toggle does not work it is a bug... :-)
Bye, Simon
A fresh pair of eyes.
On Mon, Aug 04, 2003 at 01:25:55AM +0200, Simon Budig wrote:
Alastair Robinson (blackfive@fakenhamweb.co.uk) wrote:
On Sunday 03 August 2003 11:51 pm, Simon Budig wrote:
Uh, making all the long time GIMP users grumpy because the shortcuts they are used to use do no longer work and they have to reconfigure them to the old default "costs nothing"?
Is it even possible for an end user to do this any more? The old-style point-to-a-menu-and-press-the-shortcut-key redefinition no longer works, even if it's enabled in .gtkrc-2.0, and so far my efforts to define Zoom In back to equals have met with failure - the menurc file keeps getting reset to defaults when The GIMP closes...
There now is an option in the Preferences. I am not sure if this is any different than setting it manually in the GTKrc, but if the preferences toggle does not work it is a bug... :-)
The preferences toggle overrides the gtkrc setting.
-Yosh
A fresh pair of eyes.
Hi,
On Monday 04 August 2003 12:25 am, Simon Budig wrote:
There now is an option in the Preferences. I am not sure if this is any different than setting it manually in the GTKrc, but if the preferences toggle does not work it is a bug... :-)
Ah yes, that works. Thank you :)
All the best,
A fresh pair of eyes.
GIMP zooms on Shift-wheel since some early 1.1 version.
Can the gimp be made to zoom in/out on the cursor instead of on the centre of the image.
We have a bug open on this:
http://bugzilla.gnome.org/show_bug.cgi?id=79384
Austin
A fresh pair of eyes.
On Sat, 2 Aug 2003 02:59:20 +0100 (BST) Alan Horkan wrote:
so how do you scroll sideways (using the wheel)?
using the Control key?
i can zoom with Shift+weel, vertical pan with Weel an horizontal pan with
Contro+Weel.
Is it this you're talking about?
bye davide
A fresh pair of eyes.
On Sun, 3 Aug 2003 03:02:57 +0100 (BST) Alan Horkan wrote:
Not officially. In fact there seem to be people actively resisting it who insist on being differnt just for the sake of being differnt.
i think most of the useful funcionlities given by lots of program get lost only to follow win apps, or more common apps, even if they were better in use.
i think this is not a value. always running behind others will keep us forever behind IMO
bye davide
A fresh pair of eyes.
On Mon, 4 Aug 2003, Simon Budig wrote:
Date: Mon, 4 Aug 2003 00:51:13 +0200 From: Simon Budig
To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] A fresh pair of eyes.David Neary (dneary@free.fr) wrote:
The point, as I see it, is that there's no reason *not* to follow the leader when it comes to keybindings - it makes migration easier for people used to the other app, and makes your app more attractive as an alternative, without removing any functionality, or necessarily making things harder for experienced users. So if it costs nothing (or very little), why not?
Uh, making all the long time GIMP users grumpy because the shortcuts they are used to use do no longer work and they have to reconfigure them to the old default "costs nothing"?
You mean the existing GIMP users dont already have custom menurc files?
You mean if we provided a GIMP 1.2 menurc for those who wanted it, our
current users dont already know how to change a menurc? (we need an
Inteface for this, and I need to make sure there is a bug report about
it).
You mean GIMP doesn't allow you to migrate your old settings when you
upgrade to a new version?
- Alan H.
A fresh pair of eyes.
On 4 Aug 2003, at 15:43, Alan Horkan wrote:
On Mon, 4 Aug 2003, Simon Budig wrote:
Date: Mon, 4 Aug 2003 00:51:13 +0200 From: Simon Budig
To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] A fresh pair of eyes.David Neary (dneary@free.fr) wrote:
The point, as I see it, is that there's no reason *not* to follow the leader when it comes to keybindings - it makes migration easier for people used to the other app, and makes your app more attractive as an alternative, without removing any functionality, or necessarily making things harder for experienced users. So if it costs nothing (or very little), why not?
Uh, making all the long time GIMP users grumpy because the shortcuts they are used to use do no longer work and they have to reconfigure them to the old default "costs nothing"?
You mean the existing GIMP users dont already have custom menurc files? You mean if we provided a GIMP 1.2 menurc for those who wanted it, our current users dont already know how to change a menurc? (we need an Inteface for this, and I need to make sure there is a bug report about it). You mean GIMP doesn't allow you to migrate your old settings when you upgrade to a new version?
Since I have no way of looking on the harddisks of all GIMP's users, I have no way of knowing, but I am guessing that, indeed, a large number of the current GIMP users do not have custom menurcs, and do not know how to change those.
A fresh pair of eyes.
On Mon, 4 Aug 2003 21:24:51 +0200, "Branko Collin" wrote:
On 4 Aug 2003, at 15:43, Alan Horkan wrote:
On Mon, 4 Aug 2003, Simon Budig wrote:
[...]
Uh, making all the long time GIMP users grumpy because the shortcuts they are used to use do no longer work and they have to reconfigure them to the old default "costs nothing"?
You mean the existing GIMP users dont already have custom menurc files? You mean if we provided a GIMP 1.2 menurc for those who wanted it, our current users dont already know how to change a menurc? (we need an Inteface for this, and I need to make sure there is a bug report about it). You mean GIMP doesn't allow you to migrate your old settings when you upgrade to a new version?
Since I have no way of looking on the harddisks of all GIMP's users, I have no way of knowing, but I am guessing that, indeed, a large number of the current GIMP users do not have custom menurcs, and do not know how to change those.
I don't think that it could be done in time for 2.0, but it would have been nice to use a Photoshop-friendly menurc as the default for 2.0 and insert the following stuff in the user installation step:
- Check if the user has a ~/.gimp or ~/.gimp-1.2 directory.
- If not, install the new menurc without asking any questions.
- If yes, insert a page with the following question as part of the
user installation dialogs: "Version 2.0 of the GIMP comes with a
new set of keyboard shortcuts that should be more convenient for
new users. You have been using a previous version of the GIMP, so
you may want to keep the old shortcuts instead. Please select one
of the following options:
[X] Use the new GIMP 2.0 shortcuts
[ ] Use the old GIMP 1.x shortcuts (not customized)
[ ] Copy your existing shortcuts (customized)
Now that I think about it, the whole "upgrade" part is something that would be (have been) very nice to have in 2.0: helping the user to move from an older version of the GIMP to the current one, letting the user choose what should be copied over.
-Raphaël
Keys keys keys [Re: A fresh pair of eyes.]
0