Re: [Gimp-developer] Regarding GSOC project idea
On Sunday 20 March 2011 09:30:04 bhavya agrawal wrote: Hi guys, Yes I was referring to DICOM 3 and I would like to add that there are not many open source software right now which support DICOM and a nice proper software for DICOM costs around 10,000 euros here in Europe. So, it would be nice if we can have a nice open source implementation. I don't know about which versions it supports (and probably only local files, not all the networking stuff), but ImageJ is in the public domain. And OsiriX is LGPL licensed. So both project's code should be free to use for GIMP. Certificates are less of a matter when the purpose does not lie in clinical application, I presume. Cheers, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Possible Future of ScriptFu/TinyFu with R6RS/Racket
On Friday 14 January 2011 21:59:36 Marco Ciampa wrote: On Thu, Apr 08, 2010 at 05:17:45PM +0200, Michael Schumacher wrote: Writing out recorded actions in any language shouldn't be the problem... I think that this is one of the most wanted TODO for GIMP. If it is not a problem, why noone has planned to do it? As far as I (not a GIMP developer) know, it's not writing out actions that is a problem, but recording them. Preferably in a proper, clean, not too hackish way. And also as far as I know, it's not about missing plans, but about implementing it and the prerequisites. Cheers, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] distributing gimp with another program
On Sunday 21 November 2010 08:48:47 ash oakenfold wrote: Hi all, I'm using gimp for some image post-processing (via script-fu and the command line) and I'd like to include it in the distribution of my Flash application. I read the GPL and it says: *Activities other than copying, distribution and modification are not **covered by this License; they are outside its scope.*** And on wikipedia it says: *The mere act of communicating with other programs does not, by itself, require all software to be GPL; nor does distributing GPL software with non-GPL software.* So, just to be clear, can I distribute gimp and use it to make a batch call from my program? Or does this violate the GPL? Hi Ash, I am not a lawyer but I think that distributing GIMP along with other non-free programs should be ok if those other programs just use it through the command line. Of course you will still have to distribute GIMP under the GPL, which means that you will have to inform the recipients about the license and their right, and you will have to make sure (as stated in the GPL) that they can get the source code in an appropriate way. HTH, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement request: better utilization of mouse buttons
On Sunday 25 July 2010 18:37:09 Bill Skaggs wrote: the only question is which one is more important. Or how they can be combined in a clever way ;) UI designers to the rescue, but I'm certain that restricting the future to either possibility is not the optimum. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why doesn't --enable-debug turn off optimization?
On Thursday 15 April 2010 18:56:53 Omari Stephens wrote: It seems like running configure with --enable-debug should also disable optimization; otherwise you end up with a bunch of magically inlined or optimized-out function calls, optimized-out variables, and confusing execution order. Shouldn't whoever says --enable-debug be able to say -O0 as well? Otherwise it might be harder to pin down erratic behaviour to the compiler. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] User Friendly Plug-In Browser
On Saturday 10 April 2010 19:46:44 Avgoustinos Kadis wrote: resize before applying the plugin That's an important point anyway, since many plugins are not scale invariant. So maybe cropping into a relevant region may be more appropriate in some cases. Just my 2¢ worth of thoughts, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP T-shirts in our online store
On Wednesday 04 November 2009, Ismael Barros² wrote: How about a little competition? Better than this list would be the gimp-user list, and I'm sure there are some more lists for this purpose. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ceci n'est pas une selection...
On Saturday 31 October 2009, peter sikking wrote: brainstorm - like a close box [x] on the top-right of the marching ants I like the idea of adding such a selection context menu to the selection, it could have much more than just an [X], maybe stuff like what Alt+... currently does (move selection, move selected content, move duplicate of selected content). Plus a number of other things I can't imagine yet. Think of it as the options that show up for desktop widgets for say KDE4 or Mac's dashboard applets. And it would be nice if these popped up at the side of the selection where the mouse currently is located so that the maximum distance is always size/2. /brainstorm There would have to be a way to free the area occupied by such options, either by moving it to the other side or by disabling it, because there are some scenarios where you might need to do something with that area. Maybe one modifier key that's freed by that additional user interface could be used to switch it off (either while being pressed or to toggle the state)? A lot of design details wait here. As always I'm looking forward for what you invent next, Peter :) Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re branding ....
On Saturday 31 October 2009, vabijou2 wrote: Speaking again as a non-programmer, why would anything have to change internally? Many internal names have gimp in them, and future generations of programmers should not have to ask themselves what that stands for when nobody knows GIMP anymore. So while changing names internally is not strictly required, it would be very very much recommended. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peter's single-window proposal
On Monday 28 September 2009, saulgo...@flashingtwelve.brickfilms.com wrote: It should be noted that many plug-ins and filters provide dialogs in which the user is prompted (via drop-down lists) to select images/layers/channels/paths from amongst those available in currently opened images. It would seem unwieldy for the code to have to open previously closed files to search for these potential images/layers/channels/paths every time such a dialog is presented (and the resulting drop-down lists could contain LOTS of entries in which the user holds no interest). The point when the user can choose the desired other image does not require the full image, a name + thumbnail is all that's shown with the current implementation. If this requirement doesn't change, I don't see a problem. The thumbnails are there for the gallery anyway and the drop-down list could be just another instance/view of the very same gallery, maybe. Real access to the relevant image's content is only done when it's needed. And the gallery's entries would be in roughly chronological order wrt the last showing time anyway, I suppose. Cheers, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Peter's single-window proposal (Was: We should go for a single-window mode in 2.8)
I'm not planning to dive deeply into this discussion, but I feel that Peter's blog deserves its own thread. Now my comment: Peter wrote: I have really to ask what you expect from that float image, and how different that would be from multi-widow mode. I don't know an answer to this, so I'm going to pont to one of the brainstorm images that Peter shows on his blog: The one with the split image window (third in the center column). It still is a single window, with all toolbars, docks, etc. fit closely in. But it has some advantages of multiple windows: You can work on two images simultaneously, as needs to be done when comparing two images, repetitive copypaste between the two, cloning with one image as the source and the other (active) as the target, etc. Draggingdropping from the history would work intuitively as well, closing one view would simply expand the other window to full size again, but I'm happy to leave the details to others. As I said, I don't have that much time at the moment.. Cheers, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Improve brush outline for fuzzy brushes, sample screenshot included
On Sunday 30 August 2009, Martin Nordholts wrote: [1] http://www.chromecode.com/temp/improve-fuzzy-brush-outline.png One more thing that has always irritated me (not related to your change though): The lower-left - upper right lines (/) seem to use a different corner case of the same algorithm (looks like a different algorithm even) as compared to the other side (\). Other than that I think it makes sense to show not the total affected area but only the area which is affected by more than a certain nonzero threshold (say opacity = 20%). My weekend comment, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scrollwheel actions by default?
On Saturday 25 July 2009, Jeremy Morton wrote: I noticed that by default, scrolling up and down with the mouse scrollwheel isn't configured to do anything at all. Especially as it wouldn't even be replacing something else, I propose that the scroll-up and scroll-down actions be configured, by default, to zoom in and zoom out. I just did this manually and it works great. Hello Jeremy, as far as I see, it's configured to scroll up/down and left/right (when scrolling up/down and left right) by default. Plus Ctrl+scroll up/down is configured to zoom in/out. Maybe that's already enough to do what you had in mind without changing any defaults? Regards, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm talk, part 2...
Sorry, I just saw that Guillermo cleared up that misunderstanding already. (Though it was not detected as part of the same thread by my mail client.) Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Toolbar should dock to screen edge
Hello Iain, The toolbar should dock to the screen edge shouldn't that be the window manager's job? Still I'm looking forward to more ideas from Peter (and maybe other UI designers) :) Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please restore removed crop tool functionality
On Saturday 28 March 2009, Sven Neumann wrote: That's the whole point. You don't want to crop the image, you want to enlarge it. That's exactly why we moved this functionality out of the Crop tool. A user who wants to enlarge the image is never going to look for this in the Crop tool. It simply does not belong there. I don't think that was the point. The point was to only modify the canvas size without cropping all the layers. Currently the crop tool only allows to crop either a) all layers plus the canvas or b) just one layer. If I understand Sampo correctly, he would like to see c) crop only the canvas which is what Image Canvas size does already, but not in a very graphical way (or with Simon's workaround). Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
On Friday 06 March 2009, Sven Neumann wrote: So we probably need to add specific actions to save a layer, a channel or a layer mask. If that (plus to save all of a kind, e.g. all layers) could go into the generic save dialog, we would have another 10% questions less on irc :) Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp on a Commercial CD-Rom ?
On Tuesday 10 February 2009, Jackson Tam wrote: 1. Can you tell me what the source code we need to include looks like specifically? If we were to simply include the Gimp installer (the setup.exe file), the source code is already packaged inside, right? Unless someone here can give you a better answer, maybe ask the windows packager at http://gimp-win.sourceforge.net/contact.html . But sinze the ...setup.exe is about the same size as the source code packages themselves, I don't think they can be included already. You can find the sources linked from the gimp-win home page (the link named Releases). There select the release you're interested in and get the source packages (architecture: platform independent, usually just archives in some format), gtk+, babl, gegl and gimp, maybe the libexif there as well. 2. Do you know if this permission applies internationally too? We're interested in distributing to the US, Mexico, and maybe Europe. The GPL is a license that grant you extra rights (beyond use and those rights you have in each country anyway), if you agree to it. Its creators do their best to make it as widely applicable as possible, but, as Chris wrote, have a look at their site for more information. 3. Is the 2007 GPL the most current? There's no 2007 GPL (only versions, like 2 or 3), the relevant one is the one found in the LICENSE and COPYING files in each source package. (AFAIK it's version 2 or later for the current releases.) 4. And lastly, do I need to contact anyone else besides you? (The company I work for is a bit afraid of GPL's since there is no direct contact person. So we want to cover all bases). The GPL is kind of an agreement between all the authors (so there cannot be just one contact in most cases) of a program and its users. The authors offer the users the GPL's conditions. If the users accept, they can redistribute and copy the program (under these conditions). If they don't, they don't gain the right to copy the software and no harm is done to anyone. (You and your company are the users in this case.) It's your choice to either accept the conditions or not. I am not a lawyer, but that's basically how I understand the GPL and explain it to people :) And there's no reason to be afraid of it, the GPL is not there to restrict usage or distribution, but just tries to guarantee this freedom to your customers as well. So as long as you tell them Hey, GIMP is free, just copy it and give it to your friends as well if you want. probably nobody will bite you. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GPS - Gimp Paint Studio
On Tuesday 03 February 2009, jEsuSdA 8) wrote: Hello! Ramón Miranda has published his nice Gimp Paint Studio for Gimp. GPS is a set of brushes, presets and color palettes specifically made for digital painters. You could see information and download the GPS and the GPS Manual from: http://www.jesusda.com/blog/index.php?id=314 I recomend you to see the Ramón Miranda artwork to view the GPS power: http://ramonmirandavisualart.blogspot.com/ Finally I want to ask a question: I is possible to add GPS to Official Gimp Release? Salu2 de jEsuSdA 8) Hola! They look great, and if you want to reach more artists, why not announce this release on the gimp-user mailing list as well? Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] trunk - new status for empty images
On Saturday 31 January 2009, Joao S. O. Bueno wrote: But when trying i I could not help bu tnote it also show upswht the text tool -- text tool should be able to work with an epty image, should'nt it? The move tool, o the other hand, is not displaying the message properly. I t does, however whe n I try to move a path on a 0 layer image - then, instead of moving the path it eels me it is expecing layers. - Not only the move tool, but all other transformation tools should be able to work as well. - The same holds for the align tool. - Probably there's no harm in allowing the crop tool to work (if the Current layer only option is deactivated). - The path tool doesn't react on pressing Ctrl (when there are no layers) as it should (usually this modifier allows to close a path). - At least some of the selection tool could also work. Note that in the quick mask, painting is not possible (the mouse even cannot be moved while pressing its button), but the brush outline is shown. Looks like a good change, but maybe with more work under the hood than expected. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] help to identify the occurence of a string - translation related
On Wednesday 28 January 2009, Cristian Secară wrote: In gimp.gimp-2-6.pot file the string is surrounded by these other strings, perhaps somewhat related: ... Selection mask Item visibility Link/Unlink item Item properties Move item Scale item Resize item Add layer ... I _guess_ it is (was?) a tooltip for the chain icon in the layers dialog where layers can be linked together. And I'm pretty sure that is what it means. I hope this helped, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp2.6.4 for ARM processor
On Tuesday 20 January 2009, sanju More wrote: Hi, Thanks for your input. i downloaded gimp2.6.4, i configured this with some packages like(babl,gegl,glib) and i did make and make install on fedora 10 host machine. This is working fine. But i need gimp2.6.4 to be cross compiled with arm-linux-gcc. For this i need to cross compile all these packages(babl,gegl,glib...) and then gimp2.6.4 or just i need compile gimp2.6.4 -- Sanjeev You'll need to have all the dependencies available on the other platform as well, which probably means you'll have to cross-compile them. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp2.6 Install issue
On Saturday 17 January 2009, sanju More wrote: checking for perl... /usr/local/bin/perl checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool Well, is the Perl xml parser installed? Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp's default screentones, brushes and palettes
On Wednesday 30 July 2008, Theodore Imre wrote: i would suggest this palette: http://gatogirl12345.deviantart.com/art/Copic-Colors-for-The-Gimp-86084821 its a copic markers palette with all the copic markers colors.You know how expensive these are? How much people love buying them exactly because of their colors? =P Hi, IANAL but: The artist on deviantart may be ok now with redistributing the palette, but before this is shipped, some lawyer should have a look at it. While the colour data of a single colour is probably not copyrighted in most countries (The _use_ of certain colors in certain contexts may be protected, under trademark laws, for example. But that doesn't matter here, I think.), the distribution of databases may be seen as original work and thus protected. And if the databases are not gatogirl12345's invention, GIMP might run into trouble. Just my 2¢, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Modifier key to create new layer from floating selection
On Thursday 20 November 2008, David Gowers wrote:
Oops, I see you originally suggested modifier-clicking to create a new
layer. Sorry, I do not agree with that proposition, it seems too fiddly to
me -- esp. because there is no reliably free modifier key. (Alt is only
unused by paint, transform (and color?) tools; All selection tools use
Alt.)
The same holds for no modifier key at the moment (mouse without any keys is
used already... in certain ways), I don't know if that's intentional
behaviour though.
A little demo:
1) Copypaste a selection to create a floating selection ('F').
2a) Single-click outside the float F to anchor it.
- undo to go back one step -
2b) Drag outside the float: A new selection ('S') will be created to define
where the floating layer F shall be applicable.
Now, my proposal to handle the Alt key from this situation on:
3a) Alt+click creates a new real layer (single-click is equivalent to 2a).
3b) Alt+drag performs the selection tool's Alt behvaiour, as is currently
indicated in the status bar: Click-Drag to move the selection mask
(click-drag is equivalent to 2b).
Other key events (like scroll buttons, as you suggested) could be bound to
that as well, of course.
I am aware this would mean further overloading of tools, so more I welcome
more comments and discussion.
Daniel
signature.asc
Description: This is a digitally signed message part.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Modifier key to create new layer from floating selection
On Thursday 20 November 2008, David Gowers wrote: This is usually effectively the same as pasting (ctrl+V for most people, Insert for me). Is creating a floating selection that does not match the clipboard contents a common use case, or do we just need to document this behaviour better? Sorry, I think there's a misunderstanding here: I proposed a mouse-driven way to create a new layer from an existing floating selection. (And not to paste the current (floating) selection into the respective layer.) And yes, that Ctrl-V anchors a copy of the current floating selection was new to me and probably should be better documented. Plus the Edit menu entry still says Paste Ctrl+V while Paste Into (which does the same) does not have a shortcut listed. Btw, http://docs.gimp.org/en/gimp-selection-float.html still seems to be from 2.4 times (or older), I'll crosspost this fact to the gimp-docs mailing list as well. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Modifier key to create new layer from floating selection
Hi, in case it's not too late (meaning a brand-new floating selection replacement is to be implemented soon), I have a small proposal to make the current behaviour a bit more user-friendly: While working on a floating selection, clicking outside the floating selection with a modifier key pressed (Alt seems to be free for that at the moment), a new layer should be created in the same way as pressing the new layer button in the layers dialog. Current status: When the mouse is outside the floating selection, a single click will anchor the floating selection to its current parent layer. This behaviour is also announced in the status bar. Rationale: Creating a new layer from a floating selection is needed about as often as anchoring it (if not more often). Thus a handy way to do this without moving the mouse across the desktop should be provided. There seems to be a default shortcut for this already (Ctrl+Shit+N), but esp. for tablet users a single click would be faster. Alt+click doesn't seem to be used for anything special at the moment yet. What do you think? Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the symbol for inch can be ' ?
On Tuesday 18 November 2008, Cristian Secară wrote: Somewhere in the po-plug-ins file there is this string: The unit's symbol if it has one (e.g. \'\ for inches). The unit's abbreviation is used if doesn't have a symbol. Is this correct ? As far as I know the symbol for inch is , not '. Cristi ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer Indeed, wikipedia says it's the double prime symbol: http://en.wikipedia.org/wiki/Inch http://en.wikipedia.org/wiki/Prime_(symbol) http://www.isthisthingon.org/unicode/index.php?page=02subpage=0glyph=02033 which is different from quotation marks. I don't know if that plays a role here though :) Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
On Wednesday 05 November 2008, David Gowers wrote: I am such a user, and I say: This is a change I do not want, it would reduce my working speed further. This is because of the way recently-accessed lists work -- the most recent is at the top. This means unless I am constantly selecting *the* most recent (instead of eg. 2nd most recent), where I have to click to achieve the same result changes, because my choice reorders the list. How about weighted sorting for some uppermost 2-5 flexible entries? Using a certain layer mode adds weight to that mode, and each mode loses some weight again for each action. I think that that's more or less how desktop environments manage their most used applications. Do you think that would be less annoying? Another problem (imho) would simply be the added length to that list, which is longer than what feels good to me now already. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slo wer than in Gimp 2.4
On Wednesday 29 October 2008, Nicolas Robidoux wrote: Implementation note: If two different methods are used, do the upsampling with the better for enlargements method first (unless you can do them both at once, but this is quite challenging programming wise). This approach is slower, but will give better results. Whatever your final thoughts might be, please keep in mind that there are cases where there's both enlargement and shrinking in the same layer, and where you can't simply decompose them into vertical and horizontal parts (think perspective transform) or where horizontal or vertical distances and areas are conserved (rotating, shearing). Interpolation is necessary in these cases as well. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpg memory allocation - bugreport 555033
On Sunday 05 October 2008, fremobit wrote: In my opinion the needed memory for an image of the dimensions 15000px to 15000px at 8bit depth is 214,57MB but Gimp allocates 1,1 GB. This is an old discussion, but your case seems simpler than the usual discussion/guesses: 8 bit means 8 bit per channel (RGB, and in some cases also alpha) 215MB sound as if you did calculations for an image with only one channel, such as a grayscale image. signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] provide transparent color
On Wednesday 24 September 2008, Chris Moller wrote: Maciej Pilichowski wrote: So there is obstacle, indeed. And till now I have no idea how to solve this. Might be a bit of a wild branch on this topic, but I'm wondering if all the effects described here could be implemented as a /subtractive/ process. I haven't looked at gimp's implementation, but generally speaking colors combine as Cr = Ce * ( 1- o) + Cb * o, where Cr is the resultant color (clamped full saturation of each of it's components), Ce is the existing color, Cb is the brush color, and a is the opacity. What if, instead, you made Cr = Ce * (1 - o) - Cb * o, with Cr clamped at 0? All this doesn't fiddle with the alpha channel at all, but might get the desired effect. Isn't that pretty much what the 'subtract' mode does? And yes, it doesn't involve the alpha channel. http://docs.gimp.org/en/gimp-concepts-layer-modes.html Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] provide transparent color
On Thursday 25 September 2008, Chris Moller wrote: Yeah, I expect it's the same function, but adding a transparent layer, painting it, switching to subtract mode, and merging down, is more cumbersome than just painting in subtract mode would be. The documentation site only refers to those modes as layer modes, whereas you can actually set the mode for any painting tool you use, so it's not really quite as cumbersome. signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] provide transparent color
On Tuesday 23 September 2008, bgw wrote: How does draw with transparency differ from using eraser tool with x% opacity? You could change the color information at the same places (and less importantly in a single step) you change the alpha information. At least that's how I understand it. Imagine painting with a solvent-diluted color, somehow. It might prove useful, although it might also interfere with current workflows. My 2¢, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal new default layout starting 2.6
On Friday 22 August 2008, Alexia Death wrote: Good morning ladies and gentlemen, ... My proposal is basically this: http://a.death.pri.ee/2.6_default_layout_proposal.png personal opinion I like my dialogs to be higher than 1/2 the screen height. And I like similar tool icons next to each other. /personal opinion This does not mean the layout can not be changed, maybe the average user has other feelings about this subject. signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] get mouse feedback within plug-in?
On Friday 11 April 2008, Torsten Neuer wrote: Hi, The current application needs interactive user-input with the mouse. So far I have not found out how gimp could inform a plug-in about mouse-movements (like the current cursor position) in a drawable. Is a plug-in generally suitable for the task or how could I implement such a tool? (I read the little tutorial on developer.gimp.org. More how-tos would be welcome as well.) From what you write and what it looks like on your project page, you should probably write a tool instead of a plugin (you may find fitting examples under gimp-2.4.5/app/tools). Also, you could then use any brush available to the Gimp. Torsten Just have a look at the current foreground selection tool (since GIMP 2.4), probably you can use much of its design or at least user interface. Also make sure that you don't accidentally use the same algorithm ;-) Since the usage seems to be similar, maybe this could even be made an alternative choosable algorithm there? Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
On Tuesday 19 February 2008, Sven Neumann wrote: They're deprecated? It figures that something so useful would be. Well, perhaps not deprecated in the don't use this API sense. Their use is discouraged. And not by the GTK+ developers but by usability experts. Tearoff menus might sometimes be useful for the power-user but for almost all users and almost all use cases they are unnecessary clutter and make the menu more difficult to use. I have to object here, since I have never seen any user unintentionally use tearoff menus. On the other hand I find them very useful, especially with window manager features like window shading and unshade on mouse-over, I use them in my everyday work, not only in GIMP but also in e.g. xmgrace. Benefits I see are easy access to hidden parts of menus that are not used often enough (on the long term average) to deserve a key shortcut (I might need that special sub menu quite a few times only on this very special image) or for trying out several entries, as was discussed enough earlier in this thread. I don't think that the issue of tearoffs should be seen as a field of conflict between power users and normal users. As /gg has pointed out already, the latter probably won't even notice the tearoffs while the former still can deliberately decide for or against them. Just my 2¢, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] $HOME
On Saturday 16 February 2008, Klaus Ethgen wrote: I see no point how to make it more simple. 3 lines vs. one line is not that more complexity. Every dev would have to remember 3 lines instead of only one. Sure, can be done. And might be more abstract. But in that case please define the stuff inline else the overhead for the function call would be to high. I doubt that there'd be any measurable difference, considering a) nowadays' compilers, b) the amount that function would be called (not within loops, constant times, at startup or at maybe by a user action) and c) the time the access to some environment variable (or even /etc/passwd) needs. If it works, the patch is accepted and anyone notices that it is speed critical, _then_ is the time for optimizing. BTW, have you proposed this to the GLIB team/list already? Greetings, Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
