Re: [Gimp-developer] 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/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: A fresh pair of eyes.
[EMAIL PROTECTED] (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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A fresh pair of eyes.
On Thu, 31 Jul 2003, Sven Neumann wrote: > Hi, > > Jay Cox <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A fresh pair of eyes.
Hi, Jay Cox <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Giving a try to gimp-perl
On Sat, Jul 26, 2003 at 01:53:30AM +0200, David Gómez <[EMAIL PROTECTED]> wrote: > I'm using gimp 1.3.16 and gimp-perl from cvs, and i got some errors after > running it, mainly in the Net.pm module. I post the output of the script, Most probably there is a problem starting the gimp. Try to run your script with -v to see the gimp's screen output, it will most probably tell you the rpoblem (such as missing DISPLAY, or problems with starting the perl-server). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
