[Gimp-developer] Infos Elefant'Om Birthday Party
Elefant'Om Birthday Party Saturday 13th of April - Paris - France Party inside Paris - Partie à Paris Intra-Muros for 1000 happy people ! Meeting Point : Porte de Charenton 22h-3h To see the flyer, line up and for more infos, please visit the website : http://www.chill-out.nu/elefantom.htm ** Catalunya 2002 Festival Psychedelic Festival 15,16 17 of August in Barcelona, Spain More Infos soon in http://www.chill-out.nu Love Lights ** Chill Out Trance online Shop To be removed from our mailing list, Send an e-mail to [EMAIL PROTECTED] within subject line : Remove me from your list ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] beginning
Hi, manjunath s [EMAIL PROTECTED] writes: hi everyone, i'm student who is interested in contributing to the world of gimp. I have the source of gimp 1.2.2 and i'm finding it difficult about where to start from. Can anyone guide to me to a link or some info or documentation. it very much depends on how you would like to contribute. If you want to hack on scripts or plug-ins, you probably want to upgrade to 1.2.3 and start reading the API reference in devel-docs. On the web, you should be able to find a HOWTO on writing plug-ins as well as a gimp-plugin-template. If you intend to contribute to the gimp core, download gimp-1.3.5 or grab the source out of CVS. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] erase-rows.scm patch
On 9 Apr 2002, at 13:21, Sven Neumann wrote: Rory Hunter [EMAIL PROTECTED] writes: (My apologies if this is the wrong forum for this message.) I've edited the Erase every other row script-fu so that the size of the rows can be changed. I can't find a contact address for the original author, so I've attached a patch. could you please file a bug-report with severity set to enhancement on http://bugzilla.gnome.org/ and attach your patch to the bug-report. This will assure that we don't forget your patch. What was wrong with my patch, which implemented the same and more? -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
salut, Le mar 09/04/2002 à 15:42, Sven Neumann a écrit : - Four direction menus to reduce mouse movements necessary to reach a certain menu entry. I'm not sure if I understood this correctly. Someone should draw some Ascii art to illustrate this. I don't like the idea. i suggest you go there : http://catalog.com/hopkins/piemenus/ddj/piemenus.html or just play the Sims ;) - Clicking somewhere into the image and starting to type should create a new text layer the size of the text's bounding box. Clicking and dragging should create a new text layer the size of the dragged rectangle. or, the size of the layer text is completly hidden to the user, and it adapts automagically when you modify the text also, a suggestion, it would be great to be able to group layers, to be able to show/hide a group of layers in one click, this would be relly usefull when you are doing webdesign with dynamic elements. a+, -- Dam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] erase-rows.scm patch
Hi, Branko Collin [EMAIL PROTECTED] writes: I've edited the Erase every other row script-fu so that the size of the rows can be changed. I can't find a contact address for the original author, so I've attached a patch. could you please file a bug-report with severity set to enhancement on http://bugzilla.gnome.org/ and attach your patch to the bug-report. This will assure that we don't forget your patch. What was wrong with my patch, which implemented the same and more? probably nothing... Could you help my leaky brain by pointing me to the respective bugzilla number? Or did we already apply the patch? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
Hi, Damien Genet [EMAIL PROTECTED] writes: - Clicking somewhere into the image and starting to type should create a new text layer the size of the text's bounding box. Clicking and dragging should create a new text layer the size of the dragged rectangle. or, the size of the layer text is completly hidden to the user, and it adapts automagically when you modify the text how can we wrap lines then if there's no given width to fit the text into? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] erase-rows.scm patch
On 9 Apr 2002, at 16:42, Sven Neumann wrote: Branko Collin [EMAIL PROTECTED] writes: I've edited the Erase every other row script-fu so that the size of the rows can be changed. I can't find a contact address for the original author, so I've attached a patch. could you please file a bug-report with severity set to enhancement on http://bugzilla.gnome.org/ and attach your patch to the bug-report. This will assure that we don't forget your patch. What was wrong with my patch, which implemented the same and more? probably nothing... Could you help my leaky brain by pointing me to the respective bugzilla number? Or did we already apply the patch? I did not submit it to Bugzilla, because nobody told me to. Instead I sent it to the list on May 19 last year, in a thread called Gallery Maker. Since nobody told me otherwise, I assumed this was the way to send in patches (and if memory serves me, this is the way people sent in patches back then). -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] erase-rows.scm patch
Hi, Branko Collin [EMAIL PROTECTED] writes: I did not submit it to Bugzilla, because nobody told me to. Instead I sent it to the list on May 19 last year, in a thread called Gallery Maker. Since nobody told me otherwise, I assumed this was the way to send in patches (and if memory serves me, this is the way people sent in patches back then). sure. That's probably the reason why so many patches got lost back then. So, could you please attach your patch to #78180, thanks. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
Le mar 09/04/2002 à 15:42, Sven Neumann a écrit : - Four direction menus to reduce mouse movements necessary to reach a certain menu entry. I'm not sure if I understood this correctly. Someone should draw some Ascii art to illustrate this. I don't like the idea. I've seen this on a number of graphics packages (Maya for example) and it does work quite well. The idea is that when you Right-click in the image to pop up the menu, instead of having just one honking great list of stuff, you split that menu into a number of catagories (4 or 8 typically) and scatter those catagories as little icons or perhaps text labels in a ring around the mouse pointer. Moving the mouse a short distance in the requisite direction pops up either a new (short) menu - or (more likely), drops you into a new ring of catagories. Releasing the mouse activates whatever thing the mouse is over at the time in the usual way. The idea is that a right-click followed by a short (and easily memorized) gesture gets you to the menu item you want in less time than scrolling down that l-o-n-g menu. It's pretty logical actually. Encoding the function you want as a 1 dimensional list requires EITHER tiny fonts and accurate mouse positioning OR large fonts and huge mouse movements. Neither are good for speedy menu item selection. Using (in essence) a 2 dimensional menu allows for larger, clearer fonts with less distance to travel to get to the entry you want. It also seems that people are somehow able to 'learn' the gestures to get to certain items quickly without even reading the menu's. It's like changing gear on a stick-shift car - you don't even have to think about the actual motion. Right-Click then move up then right then up again seems easier to get into muscle memory than Right-Click, move down 1.3cm then move right then move down 2.6cm. I think the DISADVANTAGE of this scheme is that the beginner doesn't see a clearly presented *list* of options - this is perhaps a problem - but it could be a configuration option to select which style of popup menu you want - and in most packages that use these gesture menu's, there is also a standard menu containing all the options in the usual place at the top of the window. I saw a demo of one of these systems where a joystick was used to select the menu item - with the idea that you could mouse with one hand and pick menu's with joystick with the other. Dunno about that - I like my hotkeys. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
salut, Le mar 09/04/2002 à 16:45, Sven Neumann a écrit : how can we wrap lines then if there's no given width to fit the text into? right ;) firt, my main principle was : in fact the user don't want to see a layer, he just want to see text but, this lead to interresting questions they are (at least) two kind of text : * text like a title, where you don't want to have a fixed width (and you can always use enter to write on 2 lines), and just want to see text, this the usual vision of a graphic/vector tools * multi-line text, like a paragraph, where the text wrap when the width is reached, this is the usual vision of publishing tools, and word processors the current version of the gimp use the first one but maybe this should change fot the gimp 1.4 so the question is, which one is the most usefull for a graphic tool ? also if the second is choosen the user would want to see a containing block more than a layer, ie : if he resize the width of the block, he would expect to see the text redisplayed with the new correct wrapping, this is different from a layer, where when you resize it, you just cut the overlapping content. a+, -- Dam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
On Tue, 9 Apr 2002, Stephen J Baker wrote: Le mar 09/04/2002 à 15:42, Sven Neumann a écrit : - Four direction menus to reduce mouse movements necessary to reach a certain menu entry. I'm not sure if I understood this correctly. Someone should draw some Ascii art to illustrate this. I don't like the idea. I've seen this on a number of graphics packages (Maya for example) and it does work quite well. http://www.piemenu.com/ Research, source, examples, etc. Pie menus are used in The Sims and Maya. They work well for some applications (IMO), especially where there is frequent menu navigation, and I wouldn't mind seeing them as an option within the GIMP. But as already pointed out, the familiar list is also a good approach for those learning the features. A toggleable switch would be nice. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] erase-rows.scm patch
On 2002-04-09 at 1705.32 +0200, Branko Collin typed this mail: On 9 Apr 2002, at 16:42, Sven Neumann wrote: probably nothing... Could you help my leaky brain by pointing me to the respective bugzilla number? Or did we already apply the patch? I did not submit it to Bugzilla, because nobody told me to. Instead I sent it to the list on May 19 last year, in a thread called Gallery Maker. Since nobody told me otherwise, I assumed this was the way to send in patches (and if memory serves me, this is the way people sent in patches back then). in defense of this list as a method to introduce patches and plug-ins and such, branko, your mail was very difficult to keep up with last year. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
On 9 Apr 2002, Sven Neumann wrote: Someone wanted a way to a enter zoom value numerically, so we might want to use an entry/spinbutton instead. Seems to me that an entry/spinbutton has all the advantages of the other ui proposal with the extra advantage that you can quickly and easily go to magnifications other than 100%. - A split mode would be handy: --- ||| | Before || || After | ||| --- Alternative setups like top/bottom, diagonal split have been suggested. Difficult to get this integrated into the GUI w/o cluttering it with buttons. Could be in a right-click menu, but it would probably not be found there. It seems to me that the best way would be to have a paned view. Since it doesn't seem useful to have the pane in any other positions, the pane bar would click to the mid-point and to the left edge. I could even make a case for clicking to the right edge (showing the before image). Also, since left-to-right language speaker's eyes tend to move to the upper left and lower right corners of a dialog, it would be a little more usable to have the after (which is looked at more frequently) on the left and the before on the right (assuming the preview is placed on the left top as it is in all of the plugins I can think of). Not a big deal either way, though. - Alternative preview in image window would be nice to have. - Provide an API that allows the plug-in developer to use the same function for manipulating the image as well as the preview. The preview would have to provide a drawable API and pixel-regions etc. in order to achieve this goal. There is a serious problem here: what if two plug-ins are open at the same time and want to draw on the same image? We wouldn't just need tile-level locking but layer or image-level locking as well, and the preview widget would have to gracefully fall back or force the other plugin to give up its hold on the display. You could run into serious UI issues here. [pie menus] It's really hard to design a useful pie menu for a large number of menu items, especially in this case where you can add and remove items by adding and removing plugins. Perhaps a pie-menu enthusiast could give us a mock-up. - Make docks scrollable. Eeek! Bad idea. But several people around here have suggested to me that image windows be dockable. Honestly, I can't see the point in that, but there is no harm either, and they seem to think it's more convienent to have everything in one big window. - Make layers resizable/scalable in by adding handlers to the layer boundaries. Sounds good, but I would make it a separate tool. Otherwise they would get in the way -- you would go to draw in a corner area and resize the image instead. - Effect layers. Hasn't been discussed much, probably not for 1.4. Perhaps more powerful would be to have effect layer _modes_ instead of effect layers. It would integrate with what gimp currently better as well. I don't really think it's a 1.4 thing. - Replace canvas XOR drawing by something nicer. We looked at some commercial apps and found they all get problems if the background color matches the color used to preview lines/beziers etc. GIMP has this problem with gray backgrounds. I suggest the color that is (1-H, 1-S, 1-V) (where HSV are the hue, saturation, and brightness of the pixel on a 0...1 scale). There will always be some pathological case where any algorithm will produce almost invisible lines, but this one should only be a problem if you have ugly high-frequency high-contrast lines in your image and you are selecting parellel to them. (bleck!) It should be very visable in almost all other cases. On second thought it might be better to use (1-H, S, 1-V). We'll have to experement. - Find a better heuristic to place pasted selections/layers. Right now they appear in the center of the image which is often far away from the spot where one needs them. Using the center of the display could be a better choice. Might I suggest we use the same UI that Get It does in the Self IDE? (http://research.sun.com/self/ -- original MacOS and Solaris versions, http://www.gliebe.de/self/download.html -- Linux port) For those who haven't had the unique pleasure of programming in Self, the Get It function is a lot like those window managers that make you place a new window whenever it pops up. But it's not like that in two important ways. It's not annoying. The window manager mouse placement thing is annoying since windows pop-up unexpectedly at time (like netscape errors) and you have to go to all the trouble of placing it before you see what the windows is. This wouldn't be annoying since you don't paste layers unexpectedly, and the layer would be displayed instead of moved in outline form. So, when you press the paste key combo or select it from the
