Re: [Gimp-developer] why I can't repeat this command?
On 22/03/15 02:24, Marco Ciampa wrote: On Sat, Mar 21, 2015 at 10:03:42PM +0100, Ofnuts wrote: On 21/03/15 16:17, Marco Ciampa wrote: I am selecting a program window screenshot (just an image). The command includes some pixels around the program window. I select all the image and shrink the selection 1 bit at a time. Why the repeat command is grayed out? I have to repeat the command every time selecting it in the menu. Is there a reason for this behaviour? I don't see a repeat command. I see a FiltersRepeat last which as its location implies repeats the last *filter* (a general repeat would be next to Edit/Redo). Sorry, I was extrapolating from a nationalized run. The command is: Edit-Redo (grayed out) and, to aswer Owen too, since FiltersRepeat last works with filters and Select-shrink is not a filter, it is grayed out too. I am using gimp-2.9, pulled Mon Mar 9 2015. Presumably is a feature that I do not understand... sorry for the noise. Redo is used to replay what you just removed with Undo, in other words it undoes the undo, so it is enabled only if you just did an undo. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] why I can't repeat this command?
On 21/03/15 16:17, Marco Ciampa wrote: I am selecting a program window screenshot (just an image). The command includes some pixels around the program window. I select all the image and shrink the selection 1 bit at a time. Why the repeat command is grayed out? I have to repeat the command every time selecting it in the menu. Is there a reason for this behaviour? I don't see a repeat command. I see a FiltersRepeat last which as its location implies repeats the last *filter* (a general repeat would be next to Edit/Redo). ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Managing layers manually between layer-to-image-size and crop-to-content
On 16/03/15 08:09, Joseph Bupe wrote: Managing layers manually between layer-to-image-size and crop-to-content in order to be able to work with certain tools or filters is, in my opinion, too devious. E.g If I want to use Aligment tool - I have to crop-to-content to remove empty borders, which also works better with transform tools; If I want to add a drop-shadow - I have to convert layer-to-image-size. Is the proposed automatic layer boundary management going to take care of this situation? If not, maybe layers should be in a crop-to-content mode by default and allow the content's bounds expand automatically only when adding effects like drop shadow. At least this is how it's done in Inkscape. As far as I can tell FiltersLight and shadowDrop shadow works on a layer which isn't as big as the image (canonical case: freshly created Text layer). The problem isn't the layer itself but, if you do the drop shadow manually, the boundaries of the layer that receives the shadow. But if it needs to be bigger than the shadowed layer, it doesn't need to be the size of the canvas. Removing empty borders doesn't always work. Imagine that you have two text layers with the same font, one with fill and one with ping. If you remove all empty borders you cannot align them properly above or under a horizontal guide because you'll have auto-cropped different sides... So, what would be needed would be some kind of automatic enlargement to fit altered pixels... About alignment: I agree that sometime it doesn't make much sense to align the layer borders. For instance, being able to align the baseline of text on a guide would be great. Currently when moving layers you can snap the sides or the center; it could be nice to have in addition a top/bottom/left/right inner snap reference (which by default would correspond to the auto-cropped content, or, for text layers, to the baseline). ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Useability enhancement request: unified/expanded file export dialog
On 11/03/15 14:26, Elle Stone wrote: 3. Scaling upon export: When exporting an image for display on the web, the image usually needs to be resized, and sometimes you might want to make some additional edits at the reduced size before the final export. But not always. It would be convenient to have the option to scale the image as part of the file export dialog, leaving the GIMP XCF file at the original size. For current Gimp there is the Save for Web plug-in that lets you crop/scale the image. However it's not uncommon to do a little bit of sharpening after a downscale, or maybe add some watermark... Better take the habit to use ImageDuplicate. This creates an untitled image to there is little risk to overwrite the original image with a scaled down version(*). (*) in the belt-cum-suspenders series, shouldn't Gimp issue a warning when saving an image if it detects that the image has been scaled down/cropped? This is another case of potential accidental loss of data. **ducks for cover** ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Sample points
On 09/03/15 21:50, Michael Schumacher wrote: On 03/08/2015 03:10 PM, Ofnuts wrote: I wondered about that at the time, but the Path technique has several advantages over the sample points: * you are not limited to 4 points You are not limited to 4 sample points. Well, I stand corrected, you can indeed create more than 4. So you can create more that 4 markers, but I couldn't find a way to make the Sample points dialog show more that the first 4 so you would really have only four sample points :) * you can keep points and target layer in synch using the links If this is the goal. Keeping them fixed in relation to the image might be a different goal. * you have sub-pixel accuracy If this is so desired, then it is an advantage for paths. Neither paths nor sample points are what you really want it you need markers in an image, though - the numbering would be really nice, fixing them to either the image, a layer, a path would be useful as well. In that regard, the ingenuity of script writers to use paths for that sort of input plays out as a disadvantage for GIMP, because otherwise someone might have implemented such markers already. ... so we would have sets of points, that can be saved (since creating them can take time), therefore possibly edited, definitely managed (Markers dialog), passed as parameters to scripts (PF_MARKERS), or acted upon from the management list (Markers menu location...). This starts to look a lot like polygonal paths except that you cannot get a selection from them... Now give me a set of points, with call-backs to a plugin when the points are moved, and that could be a very different story... ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Sample points
On 08/03/15 09:42, Kevin Payne wrote: Is is possible to access the position of the sample points from within a script? I can't find any reference to them in the Procedure browser. No way AFAIK. Scripts that require image coordinates usually ask the user to draw a path and use the path anchor coordinates. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Sample points
I wondered about that at the time, but the Path technique has several advantages over the sample points: * you are not limited to 4 points * you can keep points and target layer in synch using the links * you have sub-pixel accuracy On 08/03/15 14:54, Bill Skaggs wrote: It would be straightforward to add that functionality, though. All that would be needed is to add a function gimp_image_get_sample_points_invoker() to app/pdb/image-cmds.c, which would call gimp_image_get_sample_points(), and then glue it to a procedure called gimp-image-get-sample-points. That would be a good exercise for a developer who wants to gain familiarity with the pdb. (It would also be necessary to add documentation, of course.) Bill On Sun, Mar 8, 2015 at 6:56 AM, Ofnuts ofn...@gmx.com wrote: On 08/03/15 09:42, Kevin Payne wrote: Is is possible to access the position of the sample points from within a script? I can't find any reference to them in the Procedure browser. No way AFAIK. Scripts that require image coordinates usually ask the user to draw a path and use the path anchor coordinates. _ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Exporting Keyboard shortcuts (key bindings/accelerators)
On 11/02/15 23:11, Michael Schumacher wrote: On 02/11/2015 10:25 PM, Seldom Needy wrote: On Wed, Feb 11, 2015 at 1:47 PM, Chris Mohler cr33...@gmail.com wrote: On Wed, Feb 11, 2015 at 2:13 PM, Seldom Needy needthist...@gmail.com wrote: I was wondering about the operation of importing and exporting keyboard shortcuts for GIMP. In See the note at the very bottom of this page: http://docs.gimp.org/en/gimp-concepts-shortcuts.html Basically, you should be able to copy the menurc file from one machine to the other. Chris From the linked article: Custom Keyboard shortcuts are stored in one of Gimp's hidden directory (/home/[username]/.gimp-2.8/menurc) under Linux, and C:\Documents and Settings\[Username]\.gimp-2.8\menurc under Windows XP. It is a simple text file that you can transport from one computer to another. As stated, I was looking to port keyboard customizations in Windows 7 and 8, which are not explicitly documented (unlike XP). But, having searched my hard drive with the hint, I found a menurc in the location C:\Program Files\GIMP 2_8\etc\gimp\2.0\menurc I imagine it's the same arrangement, barring that the paths are a bit different. I will go ahead and test that theory tomorrow. No. What the docs try to tell you, but fail - due to changes in the windows user directory locations - is that this file is located in your personal GIMP user profile directly, which is located in your Windows user profile. A better approach for the docs - and other places that try to tell people how to locate their personal GIMP directories - would be to not mention *any* directories, but show users how to find out that location themselves: 1. Go to the Folders section in the GIMP preferences 2. See two folders there (in the default settings) Example: http://docs.gimp.org/2.8/en/gimp-pimping.html#gimp-prefs-folders-data One of them refers to a directory located where GIMP is installed, one refers to the corresponding directory in the users profile folder. Browse them in a file manager - for example Windows Explorer - and have a look at a few of the files in them - for example with a good text editor (*not* Notepad) to get a feel for what is located there. The time spent on this is well invested. An even better approach for both the docs and the applications itself is to have: 1) some place in the Preferences (top of Folders?) that explicitly states where the profile is. 2) maybe even have a button that opens it using the platform's file explorer 3) likewise the user's folders for the various add-ons could be enhanced with an open explorer here button. Then instructions become click button, dragdrop files. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] Avoid saving file to Recently-used list when loading it with gimp-file-load-layer()
The title says it all... I have a script that loads a lot of files with gimp-file-load-layer() and this fills the recently used list with useless entries. Is there a way to avoid this? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Color Tools and Bump Map as Dockable Dialogs
On 11/07/14 15:38, Joseph Bupe wrote: Hello Developers, IMHO, the Color Tools and Bump Map should be turned into dockable dialogs as a way of cleaning up/minimizing the number of po-up dialogs. All color tools could appear under the same tab as icons and clicking the icon should display corresponding details underneath. Changing values/curves should automatically affect the image; therefore, eliminating the need to click the image in order to access a pop-up dialog. See attached mock-up. For me the question is more why some tools have controls split between the Tool options and a floating dialog. I hardly see the logic to have a floating dialog to show me the Shear/Rotation/Scale parameters when the Rectangle/Ellipse/Crop tools use the Tool options to display equivalent information. Clicking on the image is not meant to access the dialog, it actually starts the tool on a given image, the dialog is a side effect... (of course in single-window mode it's a bit less useful). The floating dialog could have a meaning if it were image-oriented, i.e. if there were one instance of the tool for each image. This also raise the question of why we have the Tool-centric view where you cannot have a two different tools active at the same time on two different images. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] Bad link in http://www.gimp.org/mail_lists.html
On http://www.gimp.org/mail_lists.html the link to the gimp-developer list on mail-archive is: http://www.mail-archive.com/gimp-developer@gnome.org and should be: http://www.mail-archive.com/gimp-developer-list@gnome.org ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Important misfunction in gimp scaling tool
On 04/07/14 11:35, brefromjeu wrote: hey guys ? Any news on this missing must-have feature ? or is gimp still gimp ? :P i got the 2.8 and still no way of resizing from center. Today i got 17 map layers to align. they all have various scales and angles. I really don't like the 'USE PS' plugin and would prefer using gimp. regards. Did you try: http://registry.gimp.org/node/18961 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Blend Tool UI
On 29/06/14 21:08, Michael Henning wrote: mitch: The alt shortcut has always worked in my prototype. (You sound like you might not have been aware of this in your email.) I'm also not sure that the handle size should should necessarily be consistent with other tools. Gradients have only two endpoints, while paths or free selections can get significantly more complicated, which I think justifies having larger handles. Ofnuts: If a gradient is modified in any way, the preview will update properly. Simon: Spherical and Dimpled are actually portions of sinusoids, not quarter circles, but that might be what you meant. So, the transformations functions look like this: http://www.wolframalpha.com/input/?i=plot+1.0+-+sin%28x%29%2C+plot+cos%28x%29%2C++from+x+%3D+0+to+pi%2F2 I'm actually in favor of just removing the Spherical and Dimpled versions of the shaped gradients. There's not too much to differentiate between the three right now, and the transformation functions seem a little silly to me. I'd like to add in a euclidean-based shaped gradient though, and give the user a choice between euclidean and manhattan distance metrics. The manhattan ones aren't very useful alone. On Wed, Jun 25, 2014 at 6:53 AM, peter sikking pe...@mmiworks.net wrote: Maybe drawing circles most of the time, and then hiding the circles and switching to crosshairs while dragging the points, would be good? the alignment of the endpoint with the underlying content needs to also be reviewed when not moving the point. Fair enough. - make the control points big (30–50px diameter) and essentially transparent; clearly mark the centre where the co-ordinate is. My first naive implementation looked like this: http://i.imgur.com/ynQTFHi.png Those handles tended to grab your attention away from the image too much. I went back to my original ones briefly, and I have to admit that they are definitely more difficult to grab than the larger ones. So, I tinkered with them and came up with this: http://i.imgur.com/RK0odEE.png The user still has a 40 px grab target (the entire circle), but I now hide the circle whenever the mouse isn't within 60px of the center of the handle. So, they look quite minimal (just the cross) most of the time, and the grabbable area is still large. I'm generally satisfied with them. - you can drop the line because the gradient is there to represent itself; saves on clutter. I did remove the line, but I think I might like to add it back in if nobody's strongly opposed. Here's why: * I feel like the handles are minimal enough, even with the line present. * I'd like to implement mitch's idea of being able to drag the line to move both points at once. * apparently some people would miss the line (see Jason's post) * I'm planning on allowing the user to disable the preview, (which is something that basically all of gimp's tools have, just in case the user is working on a huge image where the preview would be painfully slow to update), so we can't always rely on the user seeing the on screen preview. At the very least, we should show the line whenever the preview is hidden. OK, I should have consulted the manual and now I have done it. I am now completely convinced that the shape burst belongs in the gradient tool. there is nothing contradictory about that. the gradient tool applies a gradient fill (as everything: modified by the selection) and Shape is a fill ‘mode’. and when talking interactive: next move would be to control these funky fill shapes on the canvas with a handle or two. Okay. I think I have a decent idea of how to control the shapebursts with handles. I'm going to focus on getting the other gradients working first though. Ofnuts wrote: good plan. combine it with updating the colours of the endpoints to make it truly adjustable to get it _right_ This would be updating the gradient while using it, but a gradient can be much more complicated than one color at each end. And what do you do with gradient colors that are not explicit but bound to FG/BG colors? well, I imagined straightaway that the endpoints would be highlightable and then modifiable through the regular color selection dialog(s). this point - that (adjusted) color a more complex gradient is defined by ‘waypoints’ on the canvas, while working interactive, the position where these waypoints fall on the gradient can be shown. then each of them can be highlighted and color-adjusted. when the points are there anyway on the canvas, users can move them, in 2 dimensions. and gee, once you got that. users can build a complex gradient out of nothing by: - starting with a begin and end color; - set up a multi-point path (click, click, click, double-click or return; to begin with: a straight-segment path; intermediate colours get interpolated, based on distance along the path) - update the points’ position and colours; - commit (another double-click or return). if this overloads Michael: you can introduce
Re: [Gimp-developer] Blend Tool UI
On 24/06/14 13:49, peter sikking wrote: Michael Henning wrote: Here are my general plans: * I'd like to make the blend tool generally more interactive. By this, I mean that after the user has created a gradient, they will be presented with handles that they can use to modify the endpoints of the gradient before committing their changes. good plan. combine it with updating the colours of the endpoints to make it truly adjustable to get it _right_ This would be updating the gradient while using it, but a gradient can be much more complicated than one color at each end. And what do you do with gradient colors that are not explicit but bound to FG/BG colors? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Blend Tool UI
On 23/06/14 05:31, Michael Henning wrote: I'd like to make some incremental improvements to the blend tool. On IRC, Alexandre suggested to get the UI team involved, so I'm looking for feedback/advice from the UI team. Here are my general plans: * I'd like to make the blend tool generally more interactive. By this, I mean that after the user has created a gradient, they will be presented with handles that they can use to modify the endpoints of the gradient before committing their changes. * I'd also like to add a live preview to the blend tool so users can preview the gradient and experiment with different options, before committing their changes. * I'm also planning to add undo support within the tool. * The general consensus within the dev team seems to be that the shapebursts (all of the gradient types currently marked shaped) should be moved out of the blend tool. They would likely be moved into either a menu item, or (maybe?) within the fill tool. Any thoughts? I like the idea. If you have a live preview, do you really need the handles to change it afterwards? IMHO it would be one or the other, and a live preview would be best (I've long been dreaming of seeing in real time gradients applied to layer masks). Yes, shaped gradients are an oddity, but they would also be a bit out of place in the bucket-fill (unless this can be applied to other fillings). This would also require a new gradient icon in a rather busy Tool options dialog. At least in the Blend tool they are in a tool that deals with gradients. But would we need a tool for this? The UI is minimal since it is just applying the current gradient to the selection. A filter in FiltersRender perhaps? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Python-fu GIMP Layer parent property error
On 20/06/14 03:38, Joao S. O. Bueno wrote: Issue fixed in master and 2.8 branch. (It will be generally available as of gimp 2.8.12) Thanks for spotting that. While we are at it, it there an explanation why there are both layers and children attributes in a gimp.GroupLayer, that return essentially the same thing but with a different class; image=gimp.image_list()[0] g=image.layers[0] print g gimp.GroupLayer 'Group3' g.children [gimp.Layer 'Group 3-2', gimp.Layer 'Group 3-1'] g.layers [gimp.GroupLayer 'Group 3-2', gimp.GroupLayer 'Group 3-1'] In practice, the children method is a bit of a pain when you walk the tree, because the image has layers but no children. But a gimp.Layer has children but no layers... All this is highly confusing... with a single layers attribute that always returns a GroupLayer when possible things would be simpler IMHO. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Getting contributors via OpenHatch
On 02/06/14 03:29, Ed . wrote: Presumably you guys also think GIMP's documentation (contained in comments in the code) is absolutely perfect, and that the only meaningful contributions to GIMP are substantive code changes? You are changing subject here... We are no longer talking about building the code... If so, then the only people who could add value to GIMP are people who can clear your barrier of super technical competence. Seriously, if you think that building Gimp requires superior technical competence... ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Getting contributors via OpenHatch
On 02/06/14 05:13, scl wrote: On 1.6.2014 at 9:49 PM Ofnuts wrote: If you include in it the page from LightningIsMyName that it links to, definitely... Call me cynical, but someone that needs really more detailed instructions will likely not have the programming background to be a useful Gimp developer. Of course I expect potential Gimp contributors to be somewhat already-knowledgeable, at least in the basics of Linux application development. I would not reduce it to only Linux development: We have a big lack of Windows developers or they have not enough time, so Windows developers are very welcome, too. And: contributions are not only coding. For example user support, bug reporting and triaging, documentation, translation, contributing high-quality assets, test and constructive user feedback/domain guidance, website maintenance are also contributions and they don't need knowledge of Linux application development. I totally agree with that, but I'll add that these people don't really need to build their own Gimp either. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Getting contributors via OpenHatch
On 02/06/14 00:41, Gez wrote: El dom, 01-06-2014 a las 21:49 +0200, Ofnuts escribió: If you include in it the page from LightningIsMyName that it links to, definitely... Call me cynical, but someone that needs really more detailed instructions will likely not have the programming background to be a useful Gimp developer. Of course I expect potential Gimp contributors to be somewhat already-knowledgeable, at least in the basics of Linux application development. Lines have to be drawn somewhere... +1 I'm not a coder, just a user and I could manage to build GIMP from git without too much hassle. Some things may be not exactly obvious, but I want to believe that somebody who intends to contribute in a software project will be at least equiped to compile the thing from sources. If that's supposed to be an entry barrier, I think it's a good one. Gez I don't think it's an explicitly laid down barrier. But after all the maintenance manual of my bike assumes that you know how to operate a torque wrench and what SAE 20W50 means. If you don't you better keep your hands off the engine :) ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Getting contributors via OpenHatch
On 29/05/14 22:27, Ed . wrote: There aren't any formal barriers to contributing to GIMP. There are definitely some formidable (ha!) barriers in the practical sense. Until we provide a clear step-by-step guide (on say Debian) to getting GIMP compiled from git, only the most highly-motivated and already-knowledgeable people will be *able* to contribute. http://wiki.gimp.org/index.php/Hacking:Building No? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Gimp on Steam
On 03/06/2014 09:01 PM, Simon Budig wrote: Secondly I believe that we have a certain responsibility towards the privacy of our users. By using Steam we are encouraging people to create an account there, provide download statistics as well as (to an unknown extent) usage data. We let them generate marketing data for Valve, which they can use to targeted offerings to their users, depending on their documented gimp download. If Gimp is the reason why someone creates a steam account: do we want to accept this responsibility? I know that I am preaching to my friends and family about how to use adblock and reducing the data footprint in the net. For myself I am going through a lot of troubles to minimize me being a data source as well as being locked into certain technologies. Your reasoning seems to imply that Steam will become the sole source for Gimp downloads, while as I understand it it will only be an additional source. Making Gimp available on Steam would not be pushing people towards Steam, it would make Gimp more easily visible/available to those people with a Steam account. And let's be modest here, Steam has 65 millions active users, they don't need Gimp to be popular :) ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Enlarge image canvas with gimp_image_resize procedure
On 02/27/2014 10:53 AM, Alessandro Francesconi wrote: I need to enlarge the area of an image using one of the available GIMP’s procedures. So, instead of using the GIMP’s graphical interface and this tool http://docs.gimp.org/en/gimp-image-resize.html, I want to be able to have the same effects on a C code. The function that should be called is this one, right? http://oldhome.schmorp.de/marc/pdb/gimp_image_resize.html But it works when I need to shrink the canvas: on a 640x480 image, if I input smaller values the canvas is actually cut. Instead, if I want to add a 20px transparent border along the area (so I type 680 and 520 px, also with consistent offset values), the function just returns the original image. How does it work? Thanks Don't know about C, but that function works as advertised in a Python script, with a smaller or larger canvas. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] assets in the high bith depth age
On 02/10/2014 03:01 PM, Joao S. O. Bueno wrote: I agree with the file-format, ad I don't think keeping the i18n's in file is a bad thing to do. The idea of having a file as a pill containing all the translations, and such seens much more tasty than having to distribute separated i18n resources when I publish, say, a color palette on my blog. I doubt that you'll ever have all the translations. Do you speak chinese, basque, irish? In my view, the external I18N is easier to handle for the standard resources (resources are not modified by translations...) and allows roll-your-own I18N when the author doesn't speak your language. Distributors of third party files are welcome to accept downstream contributions to the assets they create, or license their works in a way to allow for the creation of new versions, containing more languages. And this quickly becomes a maintenance nightmare :) However, one option does not exclude the other - the use of the localization could be made in a way to use either built-in translations for colors/metadata or look for them in an external location if the former way defaults. (then one could have the best of both Worlds) Amen to that. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Feature Request(if wrong way to ask, sorry)
On 02/10/2014 05:01 PM, Marek Lukáš wrote: I use Gimp for awhile and I simply love it. But I came to idea to repattern something on a picture (change pattern of walls and floor) but as I found out I would need to create pattern as one huge image with right sizes and then use built-in perspective tool to adjust it. Could you please think about adding something like Perspective pattern tool? You would just select area with right perspective and then select fill this area with... . As I said, if this is wrong way to do feature request or it's already doable I want to apologize myself. I was googling as I could but haven't come to any solution. Did you try the perspective clone tool in pattern mode? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
On 01/15/2014 11:18 AM, Chris Mohler wrote: A counter-example: I need the 'Newsprint' filter every 2 months or so, but for some reason can't seem to remember which filter menu it's under. Why is it such a disaster to expose that filter to a search? A follow-up question: (without looking - no cheating) which menu/sub-menu would *you* look under to find 'Newsprint'? Help/Plugin browser To be honest, I sometimes don't remember the menu locations for some of my own scripts... but I don't remember their exact names either. And very often you don't even know what word to search for, or the word you would search for (halftoning) is not the one used (newsprint). ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
On 01/14/2014 11:48 PM, Burnie West wrote: As Peter pointed out - what do you type in on Mint/Cinnamon if you happen to speak Chinese? On 01/14/2014 01:43 PM, Chris Mohler wrote: And yet the desktop menu in Mint/Cinnamon does precisely this and it *is* fast. I type Win-key,c,h,r,Enter and have Chromium running. Easy. Faster than the menu navigation. I go without clicking an item in the system menu for weeks at a time, on a desktop I use daily. I don't think it is applicable here because you can be pretty much mouse-less on a desktop so that you can type everything with two hands. In Gimp you have only one hand (the other one is on the mouse/tablet). Either you lose time going back and forth between mouse and keyboard to use both hands on the keyboard, or your non-mouse hand goes in hunt-and-peck mode on the keyboard half it is not accustomed to. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] how far from 2.10?
On 01/01/2014 03:10 PM, Jon Nordby wrote:
On 31 December 2013 23:26, Ofnuts ofn...@laposte.net wrote:
On 12/31/2013 06:36 PM, Marco Ciampa wrote:
Presumably how far are we to the new 2.10 gimp version?
How many blocking bugs are left and what are these?
thanks and happy GNU year...
Will it really be 2.10? Its internals are different, the file format is
different (will 2.8 be able to load 16/32/FP files saved by the next
version?), and it looks like many plugins won't work anymore and will need
seroius rework...
Which plugins do you expect not to work anymore, and why?
OK, maybe I'm pessimistic here, even if some of my python scripts had to
be reworked between 2.6 and 2.8, which have far less differences than
2.8 and 2.10. Then in the current API there are still many values with
0-255 ranges (gimp-drawable-{get|set}-pixel (),gimp-histogram) for
instance. So either there is absolutely no change in the API and the
script may produce sub-optimal results in images with high bit depth, or
there is some change and the script has to be reworked and may be made
bimodal or forked to support 2.8 and 2.10.
2.8 will not be able files from 2.10 using new features (naturally).
I believe files produced with 2.10 which _does not_ make use of
2.10-only features can be opened in 2.8. Correct me if I am wrong.
2.10 will be able to open all 2.8 files, of course.
In the usual V.R.M numbering, the situation above is typically when you
change the version number (and maybe the file extension)... because my
point here is not the (completely understandable) incompatibilities, it
their understatement by calling the next version 2.10.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] how far from 2.10?
On 12/31/2013 06:36 PM, Marco Ciampa wrote: Presumably how far are we to the new 2.10 gimp version? How many blocking bugs are left and what are these? thanks and happy GNU year... Will it really be 2.10? Its internals are different, the file format is different (will 2.8 be able to load 16/32/FP files saved by the next version?), and it looks like many plugins won't work anymore and will need seroius rework... If it goes public, calling it Gimp 3.0 will makes things a lot easier to explain to newcomers. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] how far from 2.10?
On 12/31/2013 11:35 PM, Alexandre Prokoudine wrote: On Wed, Jan 1, 2014 at 2:26 AM, Ofnuts wrote: Will it really be 2.10? Yes. Bad decision, then... ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Scripting: creating a channel from a layer in another image and other channel-related manoeuvres
On 12/14/2013 12:21 AM, Ofnuts wrote: Then, gimp-layer-create-mask will accept a ADD-CHANNEL-MASK (6) type, but in this case how do I specify the channel? Some googling got me an answer to this (it uses the active channel) so I have that part covered. Now for the other question, any takers? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://gnome.org/archives/gimp-developer-list
[Gimp-developer] Scripting: creating a channel from a layer in another image and other channel-related manoeuvres
I need to create a channel in an image from a layer (or a channel) in another image of the same size. I'm creating the other image so I can possibly copy the layer across the images and then use gimp-channel-new-from component() but is there a more direct method? I can't find a way to obtain a copy of a channel that doesn't remain attached to the same image (the channel equivalent to gimp-layer-new-from-drawable). Then, gimp-layer-create-mask will accept a ADD-CHANNEL-MASK (6) type, but in this case how do I specify the channel? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Bug 719435
On 12/02/2013 01:10 AM, Rick C. Hodgin wrote: On 12/01/2013 12:15 PM, Ofnuts wrote: On 11/30/2013 10:53 PM, Hodgin, Rick C. wrote: I was asked by Michael Natterer to discuss this enhancement on the GIMP developer list. https://bugzilla.gnome.org/show_bug.cgi?id=719435 Basically, I'd like to see the line cue for the Pen tool colorized when either of the two X,Y axis offsets are 0, or when their absolute values are equal (or have it match the existing angles used for snapping, though I personally only use the 45 degree angle setting often). This colorization cue would be visible without activating snapping, and would simply change the line color when those conditions are met. I have no other reason for wanting it except that I think it is difficult to see when the line is at exactly 45 degrees since it uses such a smooth anti-aliasing algorithm, and that it would provide added value, be a nice helpful feature, and something that I've wanted in GIMP for quite some time. :-) How would that be better than the current constrained angles? It would cue automatically without constraining. As the cursor moves around, the colors would indicate alignments. It could be used to examine existing image content, or to help align new. First, unless we introduce some error margin the cue could be rather elusive because you would have to be on the right pixel (and stay there). Second, I don't see the logic of checking if you are at 45° and not draw the line in a paint tool. If you want to check alignments, the right tool would be the Measure tool. Having display changes (color or else, there are color-blind users) on some angles (and perhaps distances) could be useful there (one more Tool option, and with the caveat about elusiveness). And as a reminder, the Measure tool also has constrained angles (so you can move the second measure point along an accurate vertical/horizontal/diagonal), and will let you to position H/V/H+V guides where the cursor is. So using both capabilities together you can easily define some point at 45° from an existing point(*) (*) Note to the devs: Currently using the constrained angles disables snapping to guides and path. Having both together would be useful: draw the perpendicular to a line through a given point, etc... ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bug 719435
On 12/02/2013 06:45 PM, Hodgin, Rick C. wrote: On 2013-12-02 03:36, Ofnuts wrote: On 12/02/2013 01:10 AM, Rick C. Hodgin wrote: On 12/01/2013 12:15 PM, Ofnuts wrote: On 11/30/2013 10:53 PM, Hodgin, Rick C. wrote: I was asked by Michael Natterer to discuss this enhancement on the GIMP developer list. https://bugzilla.gnome.org/show_bug.cgi?id=719435 Basically, I'd like to see the line cue for the Pen tool colorized when either of the two X,Y axis offsets are 0, or when their absolute values are equal (or have it match the existing angles used for snapping, though I personally only use the 45 degree angle setting often). This colorization cue would be visible without activating snapping, and would simply change the line color when those conditions are met. I have no other reason for wanting it except that I think it is difficult to see when the line is at exactly 45 degrees since it uses such a smooth anti-aliasing algorithm, and that it would provide added value, be a nice helpful feature, and something that I've wanted in GIMP for quite some time. :-) How would that be better than the current constrained angles? It would cue automatically without constraining. As the cursor moves around, the colors would indicate alignments. It could be used to examine existing image content, or to help align new. First, unless we introduce some error margin the cue could be rather elusive because you would have to be on the right pixel (and stay there). Second, I don't see the logic of checking if you are at 45° and not draw the line in a paint tool. If you want to check alignments, the right tool would be the Measure tool. Having display changes (color or else, there are color-blind users) on some angles (and perhaps distances) could be useful there (one more Tool option, and with the caveat about elusiveness). And as a reminder, the Measure tool also has constrained angles (so you can move the second measure point along an accurate vertical/horizontal/diagonal), and will let you to position H/V/H+V guides where the cursor is. So using both capabilities together you can easily define some point at 45° from an existing point(*) (*) Note to the devs: Currently using the constrained angles disables snapping to guides and path. Having both together would be useful: draw the perpendicular to a line through a given point, etc... First, ofnuts, if you're the one who decides whether or not a new feature is included, I hereby withdraw my request and will cease all further input into GIMP. I don't decide anything here. Gimp development is an ergocracy. Those who work decide. I can at best voice an opinion. Here, I'm merely answering your call for discussion. I'm sorry I'm the only one to answer that call. And discussion is not automatic approval. Second, it would be while you're on the correct pixel only. If using fractional pixels (floans), then whenever integer rounding places you on that pixel it would highlight. Third, it's for while you're already doing something on the image using that tool. The cue would provide useful information from time to time, for very little additional programming as the line cure must already redraw itself as the mouse moves. A simple test when rendering onto the output window and you're there. The SMOP is in the eye of the feature requester :) I still don't understand what you gain by knowing if your latest mouse movement puts you on a diagonal, versus just asking Gimp to put you there when you need it (constrained angles). And even more so on the paint tools, where the line indicates where the stroke will be. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bug 719435
On 11/30/2013 10:53 PM, Hodgin, Rick C. wrote: I was asked by Michael Natterer to discuss this enhancement on the GIMP developer list. https://bugzilla.gnome.org/show_bug.cgi?id=719435 Basically, I'd like to see the line cue for the Pen tool colorized when either of the two X,Y axis offsets are 0, or when their absolute values are equal (or have it match the existing angles used for snapping, though I personally only use the 45 degree angle setting often). This colorization cue would be visible without activating snapping, and would simply change the line color when those conditions are met. I have no other reason for wanting it except that I think it is difficult to see when the line is at exactly 45 degrees since it uses such a smooth anti-aliasing algorithm, and that it would provide added value, be a nice helpful feature, and something that I've wanted in GIMP for quite some time. :-) How would that be better than the current constrained angles? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Offline help files
It seems that the page at http://www.gimp.org/downloads/ - lists the help files in the source section, which isn't where Joe User would search them, and doesn't make it clear that these are in a directly usable format, - doesn't list at all the Windows installer for said help. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] What is the purpose of the checkerboard pattern in the color history buttons?
In the color history of the FG/BG color selector dialog, the buttons may appear split in two along a diagonal with the color on top left and a checkerboard pattern on the bottom right. This happens when the color is obtained using the color picker button in the same dialog. However I can't figure out what this display is indicating. The checkerboard pattern would normally hint at some alpha/transparency value, but the color displayed has no alpha channel? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Mystery: scaling thin areas makes them partially transparent
I have a layer filled with black 100% opaque. If I select a 3px wide strip only shrink the long side, the final result is not 100% opaque: I get a one-pixel high black line at 100% opacity with a black line at 87% opacity on each side. And is the selected strip is only 1px high, the resulting line is 74% opaque. If thereis no alpha channel I get gray instead. This seems interpolation related since using None doesn't produce this result. Is there an explanation to this? And can it be avoided? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Mystery: scaling thin areas makes them partially transparent
On 10/09/2013 06:59 PM, Nicolas Robidoux wrote: Note: Enlarging or shrinking abnormally small images is not part of the target use case. I also am not 100% sure that the above recommendation is consistent with the target use case. Actually I found this while working on a script that does a non-affine transform by scaling successive lines of the image. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] text-tool 'Font' panel bold/italic simulation for CJK
On 10/05/2013 01:10 AM, Thomas W wrote: Just trying out the Text Tool UI, re: font simulation. There's a bit of a usability problem in 2.8.4 -- if you type text, remove it, change the font-size click in back in the box to type something else -- your size setting is always rejected reverted to the default (18px). Sigetch is exactly right -- these big fonts need the option of bold/italic simulation. Occasional circumstances and customers also prefer the simulated look. I was going to suggest it should be possible to show a small italic sim or simulated indicator in the Font UI.. to indicate when a simulated font has been selected. Would it be worth it? The plain fonts usually have Bold/Italic versions. And the algorithmic bolding doesn't work that well on fancy fonts, while italics is just a shear transform away. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] select by opacity
On 08/20/2013 01:12 PM, Josh Coppersmith-Heaven wrote: hi all, here is a simple idea, which would be very useful in certain situations... on the 'select by colour' or 'select by contiguous region' tool, it would be GREAT if there was a further option to select on the basis of opacity, from 0 - 100, within a given region Isn't that exactly what Layer/Transparency/Alpha to selection is all about? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Need help with Python on GIMP 2.8 for bug fixing
On 08/03/2013 11:04 AM, b...@neeneenee.de wrote: Hi all, thanks for the first hints but no way to get it working. My plugin structure for testing is: from gimpfu import * import os, string, sys import os.path gettext.install(gimp20-python, gimp.locale_directory, unicode=True) def python_fu_cmyk_tiff_2_pdf(active_image, active_layer, this_file1, this_file2, this_compress, this_dpi, delete_files, start_viewer): do_delete = 0 register( python_fu_cmyk_tiff_2_pdf, CMYK Tiff 2 PDF, CMYK Tiff 2 PDF 20130802\nCreating a CMYK PDF for prepress from a CMYK Tiff image., Eckhard M. Jaeger, http://my.opera.com/area42/blog/;, GPL V2 License, 2013, *, *, [ (PF_FILENAME, this_file1, (CMYK Tiff Images), ), (PF_FILENAME, this_file2, ( ), ), (PF_RADIO, this_compress, (Compression), 0, ((JPEG 95% Quality,0), (Zip Full Quality,2), (No Compression,4))), (PF_SPINNER, this_dpi, (Resolution (dpi)), 300, (0,2400,50)),(PF_TOGGLE, delete_files, (Delete Images\nafter PDF creation), False), (PF_TOGGLE, start_viewer, (Start PDF Viewer\nafter export), True), ], [], python_fu_cmyk_tiff_2_pdf, domain=(gimp20-python, gimp.locale_directory), menu=image/Image/Separate/ ) main() I didn't get an eror on the python console nor the plugin showed up at menus or python script listing :( Cheers Eckhard. ___ No way python is going to run this jumbled code... You seem to be missing at least one import gettext... PM me the full thing otherwise... ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Need help with Python on GIMP 2.8 for bug fixing
On 08/02/2013 08:33 PM, b...@neeneenee.de wrote: Dear GIMP devs, i'm the author of CMYK Tiff 2 PDF which is an addon for GIMP and the Seperate+ plugin. My script is part of the plugin registry too. But it seems it doesn't show up in GIMP 2.8./ Ubuntu. I changed the pythin script registration to: register( python-fu-cmyk-tiff-2-pdf, CMYK Tiff 2 PDF, CMYK Tiff 2 PDF 20130802\nCreating a CMYK PDF for prepress from a CMYK Tiff image., Eckhard M. Jaeger, http://my.opera.com/area42/blog/;, GPL V2 License, 2013, *, *, [ (PF_FILENAME,this_file1, _(CMYK Tiff Images), ), (PF_FILENAME,this_file2, _( ), ), (PF_RADIO, this_compress, _(Compression), 0, ((JPEG 95% Quality,0), (Zip Full Quality,2), (No Compression,4))), (PF_SPINNER,this_dpi, _(Resolution (dpi)), 300, (0,2400,50)), (PF_TOGGLE,delete_files, _(Delete Images\nafter PDF creation), False), (PF_TOGGLE,start_viewer, _(Start PDF Viewer\nafter export), True), ], [], python_fu_cmyk_tiff_2_pdf, domain=(gimp20-python, gimp.locale_directory), menu=Image/Image/Separate/ ) main() But i didn't get it running. Any help or idea? ___ File /home/me/.gimp-2.8/plug-ins/testreg.py, line 17, in module (PF_FILENAME,this_file1, _(CMYK Tiff Images), ), NameError: name '_' is not defined ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Good Linux IDE for Gimp?
On 07/20/2013 01:29 AM, Owen wrote: I'd like to a bit more acquainted with Gimp source and that means an IDE (because it's mostly browsing code at the beginning). So, what would be the simplest IDE to setup (ideally, install from Ubuntu's software centre, give it the GIT location, and off we go...)? This could be better than the HATE GIMP threads :-) Vi, gedit, geany(http://www.geany.org/), Kdevelop, Code::Blocks (http://www.codeblocks.org) Vi, Gedit: not really IDEs, kdevelop: tried it first since I use KDE, but only for C++, Python and PHP these days. Code::blocks: still looking for a Git plugin. Currently trying Anjuta ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Good Linux IDE for Gimp?
I'd like to a bit more acquainted with Gimp source and that means an IDE (because it's mostly browsing code at the beginning). So, what would be the simplest IDE to setup (ideally, install from Ubuntu's software centre, give it the GIT location, and off we go...)? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Python source code for the smooth curve through points algorithm I made
The curve doesn't include the two end points and it seems it doesn't even get through one of the points (next before last at top right): http://i.imgur.com/Hmy1DMG.png On 07/17/2013 09:24 AM, Ben Thurston wrote: I made an implementation of the idea I had for the drawing of smooth curves through given points... http://benpaulthurstonblog.blogspot.com/2013/07/smooth-curve-generator-implemented-in.html ___ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Python source code for the smooth curve through points algorithm I made
A Bezier curve will be a lot smoother: http://i.imgur.com/73Lhvhw.png On 07/17/2013 03:47 PM, Ben Thurston wrote: Right I should have made it more clear, I left it as a comment in the code, but the first and last point figure into the calculation and do have some effect but are not directly connected to the rest of the curve. They could be left undrawn or automatically be selected as the top left of the bounding rectangle and the bottom right or as I was saying put anywhere to give the beginning and end of the curve the feel that it was coming from a certain direction before the points that actually are all connected. The second issue is that I was placing the red dots in gimp and reading off their coordinates also with gimp to put in the program, so it wasn't exact, but the coordinates actually put in the program are all plotted as pixels so in the end are drawn as part of the curve... Thanks for the question I'm going to post this in an update with your name if you don't mind? You didn't seem to last time... On Wed, Jul 17, 2013 at 4:18 AM, Ofnuts ofn...@laposte.net mailto:ofn...@laposte.net wrote: The curve doesn't include the two end points and it seems it doesn't even get through one of the points (next before last at top right): http://i.imgur.com/Hmy1DMG.png On 07/17/2013 09:24 AM, Ben Thurston wrote: I made an implementation of the idea I had for the drawing of smooth curves through given points... http://benpaulthurstonblog.blogspot.com/2013/07/smooth-curve-generator-implemented-in.html ___ ___ gimp-developer-list mailing list List address: gimp-developer-list@gnome.org mailto:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Idea for free select tool
On 07/14/2013 08:44 AM, Ben Thurston wrote: I thought it might be interesting if this algorithm I made could be incorporated somehow into the free select tool, it is a way to infer a smooth curve through an ordered set of points, different than polynomial interpolation or Bezier curves. http://benpaulthurstonblog.blogspot.com/2013/07/constructing-smooth-curve-from-set-of.html ___ How do you define smooth? With Bézier splines, it means that the tangents at the anchors points are collinear. By construction, your algorithm makes them not so, and it just strives to reduce the angle by multiple iterations. Do you have an estimation of how many iterations you need before the angles are no longer visible? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Paths need better display of on-canvas transform tools
On 06/26/2013 05:28 PM, Richard Gitschlag wrote: I was using the Perspective Distortion on a path-from-text the other day when I noticed a usability gripe: The tool's on-canvas preview (i.e. the transformation handles and guides) used the entire image canvas size. Although it did display an on-canvas preview of the path being transformed, the particular skew I was looking for required stretching the transformation handles well outside the bounds of the image canvas -- not exactly convenient when the path in question occupies a relatively small portion of the entire image canvas. For comparison, when you use a transform tool on a layer, GIMP uses the bounds of that layer for the preview grid (if a selection is present, GIMP also limits it to the layer's selected area). Likewise, if you use a transformation tool on the selection mask itself, GIMP also uses the rectangular bounds of that selection. But when you use a transform tool on a path, GIMP should grab the rectangular bounds of the path you are modifying and base its preview (transformation handles and guides) on that. Much more intuitive that it's modifying a path, not the whole image. If you have a selection the transform tool handles are on the boundaries of the selection... (the tool will still apply to the whole path) http://i.imgur.com/ApvhjV0.png ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Request] Improve Stroke Path capabilities
On 05/29/2013 02:31 AM, Richard Gitschlag wrote: Date: Tue, 28 May 2013 08:52:04 -0300 From: yafuli...@gmail.com To: gimp-developer-list@gnome.org Subject: [Gimp-developer] [Request] Improve Stroke Path capabilities [...] the ability to use gradients [...] That is already doable if you tell it to stroke using a tool AND you have the necessary dynamics configured to draw colors from the gradient. Not exactly convenient though -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. What is really missing is the ability to specify the fade as a percentage of the path (or strokes) lengths. Currently it has to be entered in pixels, and their is no standard user tool to obtain the length of a path (or of its strokes). ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Registering a plugin in the Dynamics menu
What is the name of the menu in the Dynamics list? There are Brushes/Fonts/Gradients menu locations matching the brushes/fonts/gradients in the user profile, by no Dynamics. Does it exist? Or is it named differently? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] I18N in Python plugin
What is the right/best/officially blessed way to handle I18N in Python plugins? Or asked differently, what can I do in my code so that someone can make the plugin usable in other languages without having to update the code? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Registering a plugin in the Dynamics menu
On 05/08/2013 12:22 AM, Michael Natterer wrote: On Tue, 2013-05-07 at 21:29 +0200, Ofnuts wrote: What is the name of the menu in the Dynamics list? There are Brushes/Fonts/Gradients menu locations matching the brushes/fonts/gradients in the user profile, by no Dynamics. Does it exist? Or is it named differently? It was simply forgotten, please file a bug :) --Mitch Done: https://bugzilla.gnome.org/show_bug.cgi?id=699886 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Changing the size of the open file dialog on Windows
On 04/25/2013 10:49 PM, Jernej Simončič wrote: On Thursday, April 25, 2013, 22:39:25, Ofnuts wrote: But I cannot find the equivalent file (or location for the same file) on Windows. I have tried various GTK-related places in the Gimp installation tree, the Gimp profile directory, and or the user home directory without success. Is this possible at all? Look in %APPDATA%\gtk-2.0 (note: you won't be able to edit the file with Notepad). Must have only LF intead of CRLF or some other pitfall? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Changing the size of the open file dialog on Windows
On 04/25/2013 10:49 PM, Jernej Simončič wrote: On Thursday, April 25, 2013, 22:39:25, Ofnuts wrote: But I cannot find the equivalent file (or location for the same file) on Windows. I have tried various GTK-related places in the Gimp installation tree, the Gimp profile directory, and or the user home directory without success. Is this possible at all? Look in %APPDATA%\gtk-2.0 (note: you won't be able to edit the file with Notepad). Created %APPDATA%\gtk-2.0\gtkfilechooser.ini (ie c:Documents and Settings\Admin\Application Data\gtk-2.0\gtkfilechooser.ini) by copying the one I have under Linux, and checked for LF only, startet Gimp, File/Open.. and still no joy :( ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
On 03/10/2013 05:14 PM, Guillermo Espertino (Gez) wrote: El 10/03/13 11:10, rafał rush escribió: Hi Gradients in gimp are very very painful thing. I love gimp and i used it a lot but gradients are nightmare. I see that you are making new tools and other stuff but the most important thing and the thing that all graphic designers using all the time is gradient. To make simple gradient i must do hundred clicks. Gradient window is weird and difficult for new user. Are you planing make gradient tool more user friendly? A nightmare, a pain? I can agree that editing the endpoints is not as straightforward as it should, but adding stops requires only to drag and drop colors on the gradient editor. This must be part of Gimp's Great Oral Tradition... I can't find the word drop in http://docs.gimp.org/en/gimp-gradient-dialog.html :) This said, after trying it, the gradient editor indeed looks better. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] unified transform tool
On 02/22/2013 01:41 PM, peter sikking wrote: actually next month I am teaching interaction again and will give my students the exercise ‘precision rotate and precision perspective one or two tools?’ including of course redesigning the tools. I will need some essential scenarios for that, beyond the obvious photo horizon correction and getting verticals vertical. it must be more complicated and the tool(s) should not end up as 2-trick pony(s). A frequent use case is aligning two objects on two different layers, which involves simultaneous scale and rotation of one of the objects... And where you discover quickly why scaling and rotation should both have an arbitrary (and identical) center. In current Gimp the only practical way of doing this is to use the exact-aligner script (because every rotation/scaling introduces some blur so you want to do it in one single operation, so step-wise scale/rotate is out of the question). ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Minor enhancements in the export dialog
On 11/27/2012 05:52 PM, Liam R E Quin wrote: On Tue, 2012-11-27 at 09:40 +0200, Alexia Death wrote: [...] different workflows/uses need a different default. I find I want a different default in different projects. Long term I'd really like to see gimp start to acknowledge the idea of people working on multiple projects, both sequentially and in parallel. I'm in the middle of processing photos (raw to JPEG or TIFF) when a client calls and I need to open a scanned greyscale PNG image and work on it. As part of doing that I open my project xcf file with colour swatches, notes and layers to drag into the main image. In this view I'd really like to have multiple windows, one per project, each with remembered file format and folder for import/open and for export. But it's not for today :-) Liam gimp --new-instance ? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Discrepancies in the Python API between 2.6 and 2.8
Warning: first off, due to a rather ancient Ubuntu version, I'm not really testing things with 2.8 but with a home-built 2.7.2 (going beyond that causes a dependencies avalanche)... This said, a script of mine out in the Internet wilderness is reported as failing on 2.8. When I run it on my 2.7.2, I find that; layer=image.layers[0] pdb.gimp_drawable_is_text_layer(layer) elicits a wrong parameter type while pdb.gimp_drawable_is_text_layer(layer.ID) works (gimp_item_is_text_layer() has the same problem). In 2.6 all the PDB procedures take objects and not integer IDs, so is this a voluntary change? Next, if the layer is indeed a text layer; pdb.gimp_text_layer_get_text(layer) returns None despite the layer having text. Are these known problems? Are they already fixed in 2.8? Or should I file a report on Bugzilla? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp choking on python invocation
On 11/19/2012 10:54 PM, Vio wrote:
Hello,
Newcomer on this list but old time python coder with a Gimp itch
someone might have an idea how to scratch.
Task seem simple enough: make Gimp do some back-flips from afar
through snaky incantations ... This imply combining 2 libs: gimpfu and xmlrpc.
Well, after a sleepless night trying to solve this query, I am almost
ready to give up.
so I feel ready to get enlightened. I'm most probably doing something
stupid someplace,
but I need another pair of eyeballs to put me on the right track to
see my error.
My simple test-case below, followed by some simple test output I get.
I'm on ubuntu, my gimp is 2.6.8, python version is ... whatever is
embedded there
---
#! /usr/bin/env python
from gimpfu import *
# xmlrpc
from SimpleXMLRPCServer import SimpleXMLRPCServer
from SimpleXMLRPCServer import SimpleXMLRPCRequestHandler
# Restrict to a particular path.
class RequestHandler(SimpleXMLRPCRequestHandler):
print 'TRACE RequestHandler()'
rpc_paths = ('/RPC2',)
# Create server
server = SimpleXMLRPCServer((localhost, 8000), allow_none=True)
def echo(*args):
print echo:, args
server.register_function(echo, 'myecho')
def farmsg(msg):
return 'farmsg is: %s' % msg
server.register_function(farmsg)
def pixh(*args):
print args:, args
src_path = args[0]
print 'pixh src%s' % (src_path)
img = pdb.file_jpeg_load(src_path, 1)
pdb.gimp_image_undo_disable(img)
h = img.height
print 'pixh result%d' % (h)
return 'pixh result%d' % (h)
server.register_function(pixh)
register(
clientecho, , , , , ,
Toolbox/Xtns/Languages/Python-Fu/Test/_Console Echo, ,
[
(PF_STRING, arg0, argument 0, /tmp/t/default.jpg),
(PF_INT,arg1, argument 1, 100 ),
(PF_FLOAT, arg2, argument 2, 1.2 ),
(PF_COLOR, arg3, argument 3, (0, 0, 0)),
],
[],
# echo
pixh
)
print 'TRACE entering main()'
main()
print 'TRACE entering serve_forever()'
server.serve_forever()
--
Some output I'm getting (or lack of)
STARTING SERVER WITH:
gimp --no-interface --batch '(python-fu-clientecho RUN-NONINTERACTIVE
/tmp/t/rihanna.jpg)'
TALKING TO SERVER WITH (xmlrpc server seem to work Ok, it's the Gimp
which fails below):
import xmlrpclib
s = xmlrpclib.ServerProxy('http://localhost:8000')
TRACE RequestHandler()
TRACE entering main()
TRACE entering serve_forever()
s.myecho('s')
$ echo: ('s',)
s.farmsg('homr')
'farmsg is: homr'
s.pixh('/tmp/t/rihanna.jpg')
pixh src/tmp/t/rihanna.jpg
... then nothing
My understanding is that Gimp chokes on this code for some unknown reason.
Perhaps I am not invoking it correctly?
Killing a Gimp child gaves some error message:
GIMP-Error: Opening '/dd/d/devel.../MY/(gimp-quit 1)' failed: No such
file or directory
So I removed the '(gimp-quit 1)' startup invocation...
That error dissapeared, but so did Gimp's conversational skills...
I know what you're saying: by now I should just start learning Scheme
and use extrans/gimpclient.py
to send Scheme instructions to the embedded Gimp-server. But my question is:
why can't I invoke gimp-python remotely as the scheme crowd can?
Where am I putting my foot in my mouth in this code?
I know others have solved this puzzle, as I see a few web-apps using
gimp as their graphics workhorse.
But can it be solved in python alone (no scheme)?
PS. if this has been answered before elsewhere, a link to that post
would be most appreciated.
But I've googled this topic non-stop for over 24 hours straight now,
with no luck. Not expecting miracles.
Anyway, any suggestion very welcome ;)
Cheers!
zaz
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
To expand on Jon's answer, I believe that what you want to do is doable,
but a bit differently. You have to start Gimp as if running in batch
mode, specifying a Python script to initiate. This script (that doesn't
need to register, and shouldn't do so) should then be able to run your
processing loop.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] About GimpImageType, image and layers
On 10/06/2012 08:30 AM, Jehan Pagès wrote: Hi, I have a question about the GimpImageType of layers. checking several plugins, I see that the GimpImageType (http://developer.gimp.org/api/2.0/libgimpbase/libgimpbase-gimpbaseenums.html#GimpImageType) is queried for each layer. But as a simple user, this is set Image-wide in Gimp, not for each layer. Are there actual cases where the GimpImageType can be different on different layers of the same image? Thanks. You can mix layers with and without alpha. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] using the capabillities of gimp through Java
On 10/03/2012 12:37 PM, Jon Nordby wrote: On 3 October 2012 10:45, Ziyad Mohammad ziyad...@hotmail.com wrote: Hi can i connect java to gimp so that i can do some image processing on a map using java ide the ide that i will use will be either eclipse or netbeans Hi, have you tried http://jgimp.sourceforge.net/? You should also be able to GEGL with gobject introspection bindings using JGIR: https://live.gnome.org/JGIR Last update to JGimp was in 2003... that was before Gimp 2.0. Will it work with 2.8.2? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Shape layers for GIMP?
On 09/09/2012 01:24 PM, yahvuu wrote: It seems that Adobe rather strongly favors to protect their existing user base's learning investments over any rewards to be gained by a simpler, cleaner interface. Not sure what to learn from that regarding GIMP UI development. Well, given the recent brawl around the Save/Export change in Gimp... :) On the other hand it may be important for Gimp to come up first with a clean interface for this, lest it be patented by someone else... ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Important misfunction in gimp scaling tool
On 06/19/2012 06:36 PM, peter sikking wrote: Liam wrote: I don't think you should view it as written in stone no, you just have to take it up with your own, personal Moses™ ;^} work on the unified geometry tool has been kicked into another gear this week. Mikael and I are discussing different aspects and the spec is taking strides again. so yes, ‘from centre’ is gone and now scaling and shearing can be done (optionally) from the rotation axis, which has been relabelled ‘pivot’ for its new, multi-purpose role. Great news! ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Suspending display update
I have a python plugin that does very many bucket-fills (potentially several thousands) on small selections. While it runs I see the selections in the image window (but curiously, not the painting), and the painting on the layer thumbnail in the layers list. I assume theses display update take a significant amount of CPU and the script could run faster without them? Is there some way to suspend these updates or is the only technique to duplicate everything in a display-less image and copy back the result? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Suspending display update
On 06/14/2012 11:11 AM, Rob Antonishen wrote: There are no pdb calls to change the view settings. I've always duplicated the image and worked on the duplicate without it being displayed. Also disable the undo stack of this duplicate to save memory. OK, thanks, will try that... I've got the undo thing covered already. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Gimp-user] Is it possible to access the capabilities of gimp in Java?
On 05/31/2012 03:14 AM, stephen wrote: On 05/31/2012 02:33 AM, stephen wrote: Hello, Does Gimp offer an interface (dll) which will allow me to access it capabilities through java or c++? There is a C interface, and there is a Python interface which is quite powerful. What is the name of the dlls that offer those interfaces. Can you point me to a web page that describes them. Thanks, Stephen For C: http://www.gimp.org/docs/plug-in/plug-in.html For Python: http://www.gimp.org/docs/python/index.html I strongly suggest that you subscribve to the gimp-developer mailing list: https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] JPEG lossless operations?
On 05/30/2012 05:55 PM, Bruce wrote: I've read that Picasa (Google's program) might be able to perform lossless rotations, but I'm just going by what I've read. (Source http://productforums.google.com/forum/#%21topic/picasa/UsZVs63loDM) Apparently there are ways to test if the tool you use makes use of lossless rotation. This page lists some: http://www.impulseadventure.com/photo/lossless-rotation-test.html This page also has a nice explanation of lossless rotation and its finer nuances: http://www.betterjpeg.com/lossless-rotation.htm From what I've learned so far, I think in the end you just have to relax about all this stuff and not worry about it too much, though it does help to know what's happening when you do certain things (such as rotate a jpeg). The best (and fastest) way to rotate a JPEG is to change its orientation flag... ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] JPEG lossless operations?
On 05/27/2012 08:26 PM, gfxuser wrote: Hi, reading some of the JPEG related articles here I wondered whether GIMP or GEGL can do lossless rotation and cropping on JPEG images. Can you tell me more about it? Thanks, grafxuser For rotation, that would only work on images with dimensions that are a multiple of 8. For cropping, that only works if you crop on 8-pixel boundaries from the origin corner. Otherwise, this also assumes that JPEG is an editable format, while the recent kerfuffle around the Export function has demonstrated that it is not, in the current vision. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Merging visible paths via scripts
On 05/24/2012 04:05 PM, Joao S. O. Bueno wrote: Indeed - there are no vectors merging calls whatsoever on the PDB - for the time being, the only way to merge vectors using a script or plug-on is to explictly adding strokes read from other vectors to another vector. (using gimp-vectors-stroke-new-from-points ). Coding an algorithm that loops through an image vectors, cehck which are visible, and for each visible vectors object, read its strokes, and add them to the target vectors is the way to go. Other, higher level languages, can make this task easier than in scheme - like Python. Indeed, this is a piece of cake/SMOP in Python. On the other hand, indeed, there should be some support for that on the PDB - could you open a bug at https://bugzilla.gnome.org/ asking for this feature? Maybe you could even come to do some work on its developement on a nearby future, in order for it to be in gimp 2.10. js -- If the PBD emulates the current manual version (all paths are replaced by a single, merged one) scripts will often have to copy the paths first, so we are back to square one :) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp-win downloads for 2.6
On 05/23/2012 08:44 AM, Cristian Secară wrote: În data de Wed, 23 May 2012 01:48:50 +0200, Ofnuts a scris: Unless I'm overlooking something, the gimp-win download pages on Sourceforge offer either 2.8 (stable version), or 2.4 and older (Previous Gimp versions page), but 2.6 is no longer referenced. Which page dou you refer ? On Sourceforge there is a loong list of all 2.6.x stable releases http://sourceforge.net/projects/gimp-win/files/GIMP%20%2B%20GTK%2B%20(stable%20release)/ I'l referring to that one: http://gimp-win.sourceforge.net/old.html Which is the one pointed to by the Dowload/old versions link on the home page. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On 05/18/2012 02:18 PM, Nicolas Robidoux wrote: Once GEGL becomes the operative system, XCF can be understood as the tree that leads to a specific image. Save tree? project would have my vote. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Is Tito worth merging? What should be done with it?
On 05/01/2012 05:58 PM, gespert...@gmail.com wrote: Oh, forgot to mention but it's important: Ubuntu just released 12.04 with a new feature: HUD. It basically does the same than TITO, but globally, with almost every application (GIMP included). There's a risk of TITO becoming obsolete if distributions follow the same path and implement a global menu search tool. I guess that's something to be considered too. If GIMP includes TITO and next year all the major linux distributions have something like Ubuntu's HUD, then we'll have something redundant that uses resources and increase the size of the application with no benefit at all. According to Sourceforge, 71-73% of the people that get my Gimp python plugins are using Windows (I get these very similar figures on three differents SF projects). The best Linux ratio is 25%. And since it's python, the figure is biased towards Linux. These users can't depend on HUD. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Text layer information in parasite
I would like to use the text information from a text layer (font, spacing...) in a python plugin. I can obtain it from the parasite but only if the file has been saved since the creation of the text layer (I'm using 2.6.8). Is there another way to get at the information, or is the parasite created right away in more recent versions, or can I trigger its creation without saving the image? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Python and vectors
Is there a Pythonic way to add a gimp.Vectors to an image (ie not using pdb.gimp_vectors_new(img,name)). I can create a new vector using: vector=gimp.Vectors(image,name) But if I then use: image.vectors.append(vector) the new path is not even added to image.vectors, and dir(image) doesn't list anything that looks like it would handle new vectors. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Plugin registration question
On 04/03/2012 11:54 AM, Jon Decker wrote:
Hello
The plugin I have been developing doesn't really relate to individual
images (its more of an extension). In my registration call, how do I
make it so that the listing in the menu is never grayed out?
Currently I just open any image to make the entry active, but I'm sure
there is a way to make certain entries always active. I'm using the
gimpplugin module. Thanks
If you define it without parameters is will always be active:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from gimpfu import *
def always():
pdb.gimp_message('Running')
register(
always,Always...,Always...,
X,X,2012,
Always...,
,
[],[],
always,
menu=Image/File,
)
main()
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Screenshot tool: Unify plugin for Windows, Linux and Mac OS X
On 03/03/2012 11:03 AM, grafxuser wrote: Hi, lately I compared the plugins versions for Windows, Linux and Mac OS X for a bug report. Surprisingly the Windows version is totally different from the others. It only offers three options: capture a single window, capture the whole screen and the delay in seconds. All the other useful options are missing, although they would be of use in Windows, too. The Windows' version plugin is Craig Seteras WinSnap v0.70 (07/16/1999). Compared to Linux' and Macs plug-in-screenshot this is a quite old version, which doesn't seem to be maintained by Craig Setera anymore. On the other hand, there are a lot of good or more sophisticated screenshot tools existing. Some of them ship with every Windows 7, Mac OS X, GNOME or KDE distribution. Maybe there a screencapture tools, which give better results for some particular window managers, like Enlightenment. Why reinvent the wheel, even with restricted developing capacities? To provide a good solution while keeping the own development efforts manageable, GIMP could users give the choice between GIMP's own screenshot plugin in its current state (which would be fixed in basic points and frozen then), the operating systems own screenshot tool and third party tools (SnagIt etc). Results from other tools should then be seamlessly reimported into GIMP. I suggest to place a listbox in the settings dialog with the following items: GIMPs screenshot tool, operating systems tool, Other... The second item would be Windows' 'Snipping tool', Mac's screencapture tool, on Linux' KDEs KSnapshot or whatever. The item 'Other...' would let the user choose an third-party executable for screenshots. How do you think about this enhancement? I don't see much purpose in explicitly using external snapshot tools from within Gimp. If the users have these tools installed they know how to use them, and they may have a hotkey that makes them a lot easier to access directly than from Gimp. And I don't see how Gimp is going to keep up with an even growing list... File/Create/from clipboard gives the most bang for the buck if you want to use external snapshot tools. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP Fonts Problem
On 02/19/2012 05:16 AM, William Roberts wrote:
Im having a problem running GIMP. When it loads up it stops responding
when it trys to load the fonts. I just started having this problem
today. I uninstalled and reinstalled serveral times but no progress. I
need help. Im running on a 32 bit Windows 7 pc. PLEASE HELP ME. I need
this program for my school project.
Erase/rename your Gimp profile (C:\users\{your id}\.gimp-2.6 in
Vista/Seven, or c:\pdcuments and settings\{your id}\.gimp-2.6 in XP) and
retry. Re-installing Gimp serves little purpose, since the profile is
left and reused by the reinstalled code.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Channel to Selection in PDB
(gimp-selection-load channel) No? On 01/19/2012 10:26 PM, Chris Mohler wrote: Hi, Am I missing something? How does one convert a spot channel to a selection via the PDB? Thanks, Chris ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] how to modify precisely a guide position ?
On 01/08/2012 11:40 PM, Noel Stoutenburg wrote: But I'd still like to have a keyboard shortcut to create a guide. There are sufficient number of occasions when I know I want a guide at a specific place, and it would be quicker to press a few keys, than move the mouse around. Challenge accepted: Image/Guide/New guide, you can assign a short-cut to it, for instance Ctrl-Shift-G. This gives: - [Ctrl-Shift-G] - [Cursor up] (horizontal) or [Cursor down] (vertical) - [Tab] (switches to position field) - [3]+[8]+[2] (enter new position) - [Enter] Could be a bit more deterministic if H/V shortcuts were usable in the direction selector. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Saving filter options
Is there a PDB routine to save/retrieve filter-specific options? Googling and gimp-console browsing say no, but I could be lucky (and blind)? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Reducing Load Time
On 12/08/2011 02:04 PM, Alexia Death wrote: On Thu, Dec 8, 2011 at 2:37 PM, Srihari Sriramansrihari29...@gmail.com wrote: Is it possible to implement this change before the release of 2.8? or is it too late? The window to get new features into 2.8 closed long ago. Lazy loading has been on the table for as long as I have been with the project, but it has never been important enough or desired enough to attract a developer to actually implement it and its not a trivial change to do so its actually beneficial. One of the main catches is that for most brushes, to get/generate the preview you need to load it at least once. And once you have loaded it whats the point of dropping it again? IMHO the problem is more with the current single-level display of brushes. Gimp will look in subfolders of the declared folders, but it should allow some hierarchical navigation as well. The current interface must have been designed when the designers thought that 100 brushes would be plenty.. They were right on one point: the resulting interface is very hard to use with more than 100 brushes. And once you have a hierarchical navigation, you only need to load the brushes from the current brush folder. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
