[Gimp-developer] CMYK in GIMP
Hi, first of all have all a happy new year! Professional users regularly ask for CMYK support in GIMP. I know the team's position about it and for time until it is implemented I'd like to point to the [plug-in Separate+]. As it seems there is no Mac version yet. Does anybody have more information about where to find it? Greetings Sven [plug-in Separate+] http://registry.gimp.org/node/471 ___ 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] Stock Windows and OS X builds of GIMP 2.9.2?
Hi, I have to correct myself. There's also a Windows 64 bit installer from Partha at partha.com - thank you, Partha. It uses an installer visually similar to Jernejs release build. Is it based on that installer code so the problem of unifying the nightly and release Windows builds is a bit closer to a solution? Greetings Sven ___ 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] Image viewer for openexr and floating point tiff file formats, and maybe even XCF?
On 31.12.2015 at 4:17 PM Elle Stone wrote: On 12/31/2015 09:55 AM, Alexandre Prokoudine wrote: Doesn't media-gfx in Gentoo have a djv port? There is an overlay, but nothing in portage itself. ___ How about using the downloadable DEB or RPM, convert and install it? Perhaps checking the converted archive where DJV looks for that libpng12 solves the problem for you? Greetings Sven ___ 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] Image viewer for openexr and floating point tiff file formats, and maybe even XCF?
Addition: Photoflow opens the floating point TIFF file, but crashes at OpenEXR and 2.9 XCF. DJV indeed opens FP-TIFF and OpenEXR, but no 2.9 XCF (I guess no other program than GIMP 2.9 will be able to open the latter). Greetings Sven ___ 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] Image viewer for openexr and floating point tiff file formats, and maybe even XCF?
On 31.12.2015 at 2:35 PM Elle Stone wrote: Are there any image viewers for Linux that can display openexr and floating point tiffs? What about GIMP 2.9 XCF files? Just tried XnViewMP, Gwenview, Showfoto and Darktable with images exported from Darktable. XnViewMP only opens the floating point TIFF file, but reduces the colors down to 8 bit/channel and the result looks painful dark. Darktable, Gwenview and Showfoto only open the OpenEXR file. Greetings Sven ___ 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] Testers requested for our new Mac OS X DMG release!,
On 28.12.2015 at 8:54 PM Kristian Rietveld wrote: Hi Sven, Thanks for your feedback! On 28 Dec 2015, at 10:19, scl wrote: 2. Is this build with the latest dependency versions? No, the first step was to reproduce a build using your instructions on my system. Your detailed instructions have been very helpful, thanks for that! Nice to read that my work helped someone :-) The next step is to upgrade dependencies and to build a WebKit-enabled GIMP so we can ship with a working help system. Good idea. IIRC building Webkit was at least not so easy when I tried. I considered making the switch to WebKit2. Perhaps WebkitGTK+ is also an alternative. And the steps after that are to automate the process This reminds me of my attempts to integrate an OS X build slave into the Jenkins continuous build environment. Sam Gleske or Tobias Vogel might be able to tell you more about the current state. and to look into doing regular 2.9.x builds. Yes, that would be nice. How do you think about preponing the 2.9.2 build right after the dependencies are updated? So the GIMP team could offer the awaited 2.9.2 build a bit earlier. I you need somebody to test your OS X build related commits, I can be there. Some more thoughts about the build process, but I leave it up to the GIMP people what to do with them: - Avoiding to git clone babl, gegl and GIMP during the JHBuild process and instead build all into the existing prefix. Thus it would be easier to test local changes, even in local branches, without pushing them untested to the public git repository first. - Splitting the 2.8 and master builds in the modulesets and moving the master builds into the GIMP master branch. - @GIMP team: I remember that at the time I was more active new versions came out of a sudden when Mitch had time to bump a release and the releases were made later. This has the effect that users who read the announcement have to wait again and thus are disappointed after a long period of waiting for a release. How about reorganizing the process of release builds and version announcements by 1. negotiating a release date internally, 2. completing the release docs (NEWS, http://wiki.gimp.org/index.php?title=Special%3APrefixIndex&prefix=Release%3A&namespace=0) 3. bumping the version number, 4. making and testing the builds and 5. as last step announcing the release? Many words, but I hope I could give some useful inspiration. If desired I can try to help. Greetings and have all a happy new year, Sven ___ 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] Testers requested for our new Mac OS X DMG release!,
On Mon, Dec 28, 2015 at 5:16 AM, Alexandre Prokoudine wrote: On Mon, Dec 28, 2015 at 12:19 PM, scl wrote: How about mentioning the patched and extended builds of other eager contributors like Partha and skl or even Gimp Paint Studio and CinePaint in a separate fork section of the Download page? The general agreement in the team is that we don't feel comfortable promoting builds whose packagers do not provide information about changes they introduced (if any). To make this more transparent for the community, we are preparing a document on packaging requirements that we'd like (but don't demand) GIMP packagers to meet. On 28.12.2015 at 2:13 PM Partha Bagchi wrote: > While I am not against your policy, this is first I am hearing about > this agreement. Of course this may have been a verbal agreement within > the team. There was also a similar agreement at the LGM 2014, see http://wiki.gimp.org/wiki/LGM2014Minutes#Malicious_and_reputation-damaging_installers_and_apps, 3): "3) How do we deal with GIMP builds that come with additional plug-ins, such as Simone Karin Lehmann’s or Partha Bagchi’s build? Agreement to 3) 3rd party plug-ins and improvements to OS-integration (OS X, Windows, etc.) are ok. ? Shall they become part of the official build? Changing GIMP’s designed behaviour, like modifications to the Save-Export-behaviour must not become part of the official GIMP builds." Neither your nor skl's builds are considered as malware. The question came up when we discussed public GIMP builds with modifications. I hope this helps a bit. Greetings Sven ___ 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] Testers requested for our new Mac OS X DMG release!,
On 28.12.2015 at 11:01 AM Su V wrote: On 2015-12-28 10:19 (+0100), scl wrote: 1. The GIMP build comes with the G'Mic plug-in. Sadly it is crashing. I suddenly get the message: The official app bundle for GIMP 2.8.16 from wgo does not include the G'Mic plug-in. Thanks for this hint. I checked back and indeed, the G'Mic plug-in was a leftover from a former G'Mic test on my own system. Sorry for the confusion. Sven ___ 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] Testers requested for our new Mac OS X DMG release!,
Hi Kristian, thank you for stepping in and making an OS X build! Especially the DMG creation command and fixing some of the nasty Poppler and DBus problems are impressing me. You asked for testers and here are some of my test results: 1. The GIMP build comes with the G'Mic plug-in. Sadly it is crashing. I suddenly get the message: "Plug-in crashed: "gmic_gimp" (/Users/$my_user_name/Library/Application Support/GIMP/2.8/plug-ins/gmic_gimp) The dying plug-in may have messed up GIMP's internal state. You may want to save your images and restart GIMP to be on the safe side." Including this plug-in is well-meaning but I think it's a pitfall for the GIMP team because users might think it would be part of GIMP and therefore report G'Mic bugs to the GIMP team instead to the G'Mic people. Avoiding this was the reason I made a stock build of GIMP 2.8.14 with no extra plug-ins. 2. Is this build with the latest dependency versions? 3. To be honest and fair it would be good to name Kristian as the creator of the 2.8.16 build on the download page and not me anymore for the older build. How about mentioning the patched and extended builds of other eager contributors like Partha and skl or even Gimp Paint Studio and CinePaint in a separate fork section of the Download page? If I find more I'll try to report to Bugzilla. Anyway, I know how hard it is and how much time it takes to provide a working OS X build - thanks for your work! Greetings Sven ___ 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] Stock Windows and OS X builds of GIMP 2.9.2?
Hi seeing the GIMP team making a 2.9. release was a nice surprise to me - my congratulations for taking this step! I tried to download 2.9.2. builds for Windows and OS X, but however I could not find one. The only thing I found was a master OS X build from partha.com, but with many plugins, so I could not test the vanilla stock build (anyway, thanks Partha!). For Windows I couldn't find no build at all. Is there anything I am missing and if yes, where I can I find 2.9.2 builds? I don't want to start the hassle of building them all again on my own. Thank you in advance, Sven ___ 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] No nightly Windows builds anymore?
Hi, I tried to download Drawoc's Windows nightly builds of GIMP master. Neither 32 nor 64 bit builds are to find at the darkrefraction site anymore. Is there a chance to see them back in the future? Will the Windows nightlies and the official Windows build be unified at some day? Thanks in advance & greetings Sven ___ 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 can't find libmypaint-gegl
Hi, I'm facing the same problem when trying to build GIMP with Sam's portable environment Vagrant VM. Just FYI the issue is already reported to Sam's Github repo. Have all a happy new year ;-) Greetings Sven ___ 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] handle transform tool
> With Peter's departure I don't really have a suggestion how to deal > with this kind of a situation. It's great that people contribute code, > and I'm thankful to them. But do we want to pile underdesigned >features up again? Personally, I wouldn't like to see the project to > go back to pre-2006. +1 Somebody came up with code and it looked cool, therefore it's in the code base. Like Tito and similar to the N-Point-Transformation tool while we have the Cage tool plus some other half-done features. But hey, we dropped the Magic Scissors Tool and the performance of GIMP master is near to unusable! As long as the 'Hack first' principle rules, the team will never reach its own product vision, if anybody remembers that thing :-( Sad to see it go that way. Disillusioned, Sven ___ 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] [Gegl-developer] babl roadmap
Hi, I fully agree with Jehan and think it's essential in a healthy software development process to scrutinize and review things. Especially the whole color management stuff is a topic that is not so clear to many of us and - with all my respect to Pippin - depending on a single expert's opinion is a risk in every project. It's natural for this topic that it is also academic. Academic work is the foundation for many things in the computer world, may the hands-on-people like it or not. Perhaps some other color management experts could join in and share their knowledge? One thing could be improved from my point of view: the discussion is spread over the two lists gimp-developer and gegl-developer. As it is all mainly BABL- and GEGL-related it would be more helpful if the discussion took place on a single list. I propose the GEGL-developer list, because this catches both the GEGL-only devs as well as the GIMP devs. Kind regards Sven ___ 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] Don't make an architectural mistake based on a groundless premise
Hi Pippin, I hope you don't see my lines as picking on your work, but as the constructive criticism as it is meant. GIMP has performance issues, especially with large images and modern camera sensors are just delivering them. On 8.10.2014 at 4:47 PM Øyvind Kolås wrote: On Wed, Oct 8, 2014 at 4:25 PM, scl wrote: 1) Extra conversions every now and then produce overhead -> increase computation time -> decrease performance. One part of GIMP's product vision is [high working speed] and I don't see how extra overhead can speed up things. And I would not claim GIMP and GEGL to be tigers, especially when it comes to large images. Babls conversions are often transparent since they occur where data is copied anyways and memory access is more expensive - the ones doing unpremultiplication of alpha being among the exceptions (as well as when we end up hitting reference paths where we are starting to use new and not even attempted optimized combinations of formats.) What I don't see is not there? - Let's not put the head in the sand. The point is not whether they are transparent or not, but whether they are necessarily done or not. Also, how does memory access instead of converting come in here? For example adjusting brightness and contrast with preview of a 5184x3456 px photo happens immediately in PS CS5 (from 2010). GIMP 2.8.14 takes 7 seconds and the GEGL tool 'brightness-contrast' takes 16 seconds for the same image on the same machine. Performance is a concern, but it is different parts of the architecture that needs improvement for that type speed up... With a GEGL GUI that is not GIMP I've experimented with the new mip-map rendering capabilities recently added to GEGL and previewing of on canvas brightness contrast or gaussian blur/unsharp mask on a 1x5000 image is instant (it processes somewhere between the number of pixels on screen and 4x that, not more). Allowing you to both adjust the op, pan and zoom at will. This is a display trick to give the user immediate control (and a good idea for GIMP, too). However, the whole image has to be processed anyway. Display tricks can hide an underlying problem, but not solve it. I also think that it should be the user's decision whether s/he wants to apply an operation to a coloured image, a grayscale image or a mask. Leaving this decision solely to the developer (who's not necessarily an artist) doesn't satisfy the claim to be a high-end image manipulation program. That decision is not set in stone because of the format asked for by the GEGL operation, it is the task of GIMP on top of GEGLs abstractions to provide the means to do so. ...which ends up in refusing the op or converting the data and the circle closes here. Or is there something else? Therefore I think it's better to let all operations work on the same appropriate colour space (big enough and computable precisely and efficiently) and do conversions only on the interfaces to the outside world: importing and exporting images, displaying, working with ICC profiles etc. IIRC there was a hint on that in one of the former posts to this topic - what where the reasons to not to do so? The we have to juggle a large set of different types of pixel formats already? I thought of the same (=a common) colour space for all ops, leading to a commonly shared pixel format which makes conversions unnecessary. You and Elle are the right people to find that space and fine tune its implementation and I hope you both are open enough to find a good solution together. Kind regards Sven ___ 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] Don't make an architectural mistake based on a groundless premise
On 7.10.2014 at 8:43 PM Øyvind Kolås wrote: On Tue, Oct 7, 2014 at 8:13 PM, scl wrote: On 4.10.2014 at 5:59 PM Øyvind Kolås wrote: Almost, developers decide which pixelformat is appropriate for their operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale formats as well as formats used with digital video with different data types; currently the set of babl formats. perhaps I missed or forgot something: what happens if a GEGL operation is called with a wrong pixel format - will the operation refuse to work or the data be converted to an appropriate format? tl;dr: converted to an appropriate format. I consider this design decision critical for two reasons: 1) Extra conversions every now and then produce overhead -> increase computation time -> decrease performance. One part of GIMP's product vision is [high working speed] and I don't see how extra overhead can speed up things. And I would not claim GIMP and GEGL to be tigers, especially when it comes to large images. For example adjusting brightness and contrast with preview of a 5184x3456 px photo happens immediately in PS CS5 (from 2010). GIMP 2.8.14 takes 7 seconds and the GEGL tool 'brightness-contrast' takes 16 seconds for the same image on the same machine. 2) Extra computation steps can introduce computation and rounding errors and thus cause wrong results. These effects might be very low for each single operation, but will sum up when many operations are combined (which naturally happens when editing an image). I also think that it should be the user's decision whether s/he wants to apply an operation to a coloured image, a grayscale image or a mask. Leaving this decision solely to the developer (who's not necessarily an artist) doesn't satisfy the claim to be a high-end image manipulation program. Therefore I think it's better to let all operations work on the same appropriate colour space (big enough and computable precisely and efficiently) and do conversions only on the interfaces to the outside world: importing and exporting images, displaying, working with ICC profiles etc. IIRC there was a hint on that in one of the former posts to this topic - what where the reasons to not to do so? On 5.10.2014 at 6:49 PM Øyvind Kolås wrote: You've already been invited, and I invite you again to spend some time with the rest of the GIMP team and others with interest in color, photography and graphics in Toronto, end of april next year for the next Libre Graphics Meeting. +1. What can go wrong? Sometimes meeting the people and talk things over at a coffee or beer is better than throwing arguments back and forth. It's also a great chance to meet creatives and color experts from other libre-graphics-projects and hear their opinions. Kind regards Sven [high working speed]: http://gui.gimp.org/index.php/Vision_briefing#value_.2B_traits ___ 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] Don't make an architectural mistake based on a groundless premise
Hi, On 4.10.2014 at 5:59 PM Øyvind Kolås wrote: Almost, developers decide which pixelformat is appropriate for their operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale formats as well as formats used with digital video with different data types; currently the set of babl formats. perhaps I missed or forgot something: what happens if a GEGL operation is called with a wrong pixel format - will the operation refuse to work or the data be converted to an appropriate format? Kind regards Sven ___ 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] OSX - solution
On 21.9.2014 at 2:22 PM Michael Bauer wrote: Ok, good news, between the indomitable Partha and myself (mostly Partha, I was just testing), we managed to identify the problem and Partha was able to fix it and provide a working build. Fault finding eventually got us to running After running $ export LC_ALL="de_DE.UTF-8 $ cd /ApplicationS/Gimp-2.8.app/Contents/MacOS $ ./gimp-bin This means to have to set the language outside GIMP in a terminal window and seems to partially bring back the language black magic we removed from the build because it was unmaintainable. Partha, did you also try commit ef0ef921b8dcb49ee82acba6540b69e6617c65d9 I presented in my message from 14.09.14 at 3:08 P.M.? It works for me in an environment without access to the build prefix. Kind regards Sven ___ 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] OSX
Am 14.09.14 at 11:40 AM scl wrote: On 14.9.2014 at 10:38 AM Simone Karin Lehmann wrote: The language selector only shows system language and en_US. thank you for reporting back. It seems to be a relocation issue. To reproduce the issue tried both - revoking read permissions from the original build prefix and - renaming the original build prefix. In both cases I only see 'System language' and 'English (en_US)' now in the listbox. Reverting these changes brings the other languages back immediately (without restarting GIMP). This would also explain to me why Partha and users of his build have the same issue (see his mail from 11.09.14 12:35 PM). I'm just trying to make the code in https://git.gnome.org/browse/gimp/tree/app/widgets/gimplanguagestore-parser.c?h=gimp-2-8#n124 relocatable. Perhaps that would fix it. Resolved fixed. commit ef0ef921b8dcb49ee82acba6540b69e6617c65d9 Author: Sven Claussner Date: Sun Sep 14 14:43:58 2014 +0200 Bug 721482 - Make language codes relocatable Although all translation files are in the OS X bundle GIMP didn't recognize other languages than the system's language and English (en_US) on OS X on other machines. It searched the language code file from the iso-codes package (iso_639.xml) in the build prefix which is usually not existing on other machines. This commit puts that file into the OS X bundle and makes GIMP search for it there. app/widgets/gimplanguagestore-parser.c | 2 +- build/osx/gimp-2.8-python.bundle | 2 ++ build/osx/gimp-master-python.bundle| 2 ++ 3 files changed, 5 insertions(+), 1 deletion(-) --- I tested under the circumstances as shown above to reproduce the fancy effect and it workes fine here. >> BTW, I’ve never used this part of the code at all and only rely on System Preferences as any other OS X Application does. Well, that's indeed a point why we provide an extra language selector while the user can already set the language in the operating system resp. desktop environment. This is questionable not only on OS X, but on all systems. Especially on OS X we currently have the effect that the language of most of the UI is set in our selector, but the language of system specific menu items from the App menu can only be set in the OS X' system preferences. The convenient way for users to set the language consistently is to use 'System language' in GIMP, set the desired language as primary language in the system's preferences and restart GIMP. From a technical point of view the language information is something that has to be provided by the application framework to make sure all applications based on it behave the same. Kind regards Sven ___ 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] OSX
On 14.9.2014 at 10:38 AM Simone Karin Lehmann wrote: Hi Sven, I’ve downloaded your build and I’m experiencing the exact same issue. The language selector only shows system language and en_US. thank you for reporting back. It seems to be a relocation issue. To reproduce the issue tried both - revoking read permissions from the original build prefix and - renaming the original build prefix. In both cases I only see 'System language' and 'English (en_US)' now in the listbox. Reverting these changes brings the other languages back immediately (without restarting GIMP). This would also explain to me why Partha and users of his build have the same issue (see his mail from 11.09.14 12:35 PM). I'm just trying to make the code in https://git.gnome.org/browse/gimp/tree/app/widgets/gimplanguagestore-parser.c?h=gimp-2-8#n124 relocatable. Perhaps that would fix it. And it seems to me, that your build is picking up languages from OS X System Preferences, and even uses all other languages in System Preferences as fallback, if the primary one is not complete (as for Gaeilge) Oh, where in the code did you see this? Kind regards Sven ___ 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] OSX
Am 11.09.14 um 16:33 schrieb scl: Are more people experiencing this effect? Hello, no answers? Is there anybody else experiencing the effect that the build from http://download.gimp.org/pub/gimp/v2.8/osx/staging/ shows only two languages in the language selector listbox? Kind regards Sven ___ 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] OSX
On 11.9.2014 at 12:50 PM Michael Bauer wrote: The screenshot is from the version Michael S posted the link for but the end result is pretty much the same. To sum up: Mavericks: Partha's dmg: UI in English, only System Language and English offered in dropdown, even with gd selected as OSX locale Michael S's dmg: UI in Gaelic, only System Language and [Gàidhlig (en-US)] offered in dropdown, with gd selected as OSX locale That's strange. I tested my build (= the one Michael Schumacher referred to) on Mavericks and see a long list of languages in the language selector, not only these both. With Partha's build I see indeed only two items. Also, what language is your primary language in the OS X system settings (I mean, what's it's native name so I could reproduce some issues)? Are more people experiencing this effect? Kind regards Sven ___ 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] OSX
On 11.9.2014 at 2:59 AM Michael Schumacher wrote: On September 11, 2014 2:34:25 AM CEST, Michael Bauer wrote: But perhaps I'm wrong and there IS an easy way of changing this... fingers crossed I guess... go on, someone surprise me? We got a preview of a 2.8.14 dmg available at http://download.gimp.org/pub/gimp/v2.8/osx/staging/ Made by Sven Claussner, and could use some testing. As Michael Schumacher wrote, I've made a 2.8.14 build right from the sources, i.e. with no additional tweaks, with just the standard set of plug-ins and with all the languages GIMP usually ships. It requires a 64 bit machine (Mac from 2006 and later, Mac mini from 2007 and later) and at least OS X 10.9 (Mavericks) I'm currently busy with trying to include the user manual and hopefully I can get the build done for older OS X versions, too. In the meantime please be a bit patient and good luck with the preview build. I'd be grateful for feedback if any blocking(!) bugs are found (and of course for positive feedback, too ;-) ). Kind regards Sven ___ 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] ANNOUNCE: GIMP 2.8.12 released
Hi, nice to read that ;-) GIMP up to version 2.8.10 could run on OS X 10.6 (Snow Leopard) and later. I could provide an OS X 10.9 (Mavericks) build from the original sources (i.e. with no extra plug-ins and other patches), but I'm not able to provide support for OS X versions before that. Does anybody volunteer to build from the original, unmodified sources for OS X 10.6 again? If necessary I could support the OS X packager by answering arising questions by email. If nobody did, could we live with not supporting versions prior to OS X 10.9 in this release? Kind regards Sven ___ 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] Does anyone want to administer GIMP's continuous integration server (Jenkins)?
Hi, we have a continuous integration system (Jenkins based) that we use to check that our commits to GIMP, GEGL, babl, etc. build ok and tests run properly. As I'm leaving the project asap it needs a new maintainer. If nobody steps up, then it will have to be abandoned. If anyone with more or less Jenkins experience is willing to step up to the task of maintaining it, please respond on the list. Kind regards, Sven ___ 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] Current maintainers of GIMP
On 6.8.2014 at 11:20 PM Nathan Summers wrote: On Wed, Aug 6, 2014 at 4:47 PM, Michael Schumacher wrote: Not sure if I should be in AUTHORS, as there are no current contributions of design or code by me in GIMP itself. I think we even had some sort of semi-formal requirements for being listed in either of those files at some point - does anyone remember, was it contributions during the latest stable development cycle? Surely not contributing something during a cycle doesn't mean you are no longer the author of the code you contributed before. +1 After querying Sven Neumann I have removed him from the maintainers list in GIMP master and taken him to the authors list. At this point: Sven Neumann, thank you for your work in the past! Kind regards, Sven ___ 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] Current maintainers of GIMP
Hi, due to some [Git infrastructure changes] I decided to check and update the gimp.doap, AUTHORS and MAINTAINERS files and in succession update the maintainers list on our website. I found that Sven Neumann is still referred to as current GIMP maintainer. The last signs I notice of Sven from the history are a post on this list in May 2011 and a commit on 4.12.2012. Sven - with all my honest respect for your work - are you still active in the project and want to be referred to as a GIMP maintainer? The DOAP file already contains Michael Schumacher as GIMP maintainer. Schumaml, would you agree if I also took you as maintainer to AUTHORS, MAINTAINERS and the maintainers list on the website? In our git repository the changes would affect GIMP master, not 2.8. The changes on the website would happen asap. If you have better ideas, then let me know. Kind regards Sven Claussner [Git infrastructure changes]: https://mail.gnome.org/archives/desktop-devel-list/2014-August/msg00025.html ___ 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 to deal with UI string changes?
Hi Marco, On 29.7.2014 at 11:02 AM Marco Ciampa wrote: Which strings and in which language, more specific please... it's about German. I found some strings there that don't comply with the German default dictionary. And then there is this monster dialog to create a path from a selection... (IIRC you had a discussion with Mitch in IRC whether to translate it in 2.8 a while ago. I'm still hesitating whether it's better to translate it to at least provide anything slightly usable or to replace the dialog with something better and translate that). If you found that the strings are wrong and you think you know how to correct those strings then you can either: - correct them right away or - file a bug Ok, thank you. - forgive my bad english No need to apologize, you are understood. Kind regards Sven ___ 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] How to deal with UI string changes?
Hi, I came across some UI strings that are either not or incorrectly translated in 2.8. They range from single strings to a whole dialog. What are we supposed to do with them? Leave them in their wrong state in 2.8 or correct these bugs in 2.8 because nobody knows when 2.10 will be finally out? I personally am for the latter alternative because I consider them as bugs. What do you think? Kind regards Sven ___ 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-user] Gimp 2.8 and OS X Yosemite
Hi Partha, thank you for that information. How do you achieve backward compatibility? I've built on 10.9. and had to find out that even building for 10.8 has become troublesome (mostly due to issues with the JHBuild bootstrapper on OS X, but I think also the older OS X SDKs are involved here). Kind regards Sven ___ 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] [SOLVED] Jenkins: mypaint brush builds are failing
Hi, the mypaint-brush branch builds on Jenkins again. I've updated the configuration to work with the new libmypaint place. Additionally the Mypaint-Brush job page https://build.gimp.org/job/gimp-distcheck-mypaint-brush/ contains a link to the libmypaint repository now. Kind regards Sven ___ 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] Jenkins: mypaint brush builds are failing
On 20.7.2014 at 9:11 AM Martin Renold wrote: I don't know where GIMP gets its libmypaint from. But it's probably just a matter of running "scons" in the libmypaint directory, to update the generated headerfiles. Hi Martin, thank you for your hint. I get our libmypaint version from git://gitorious.org/mypaint/libmypaint.git Where and when is such a scons call required - at every checkout, in our Makefiles? Which parameters does scons need to do this? Kind regards, Sven ___ 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] Jenkins: mypaint brush builds are failing
Hi, since 13.07. the MyPaint brush build has been breaking. Latest changes: https://build.gimp.org/job/gimp-distcheck-mypaint-brush/21/ Console output: https://build.gimp.org/job/gimp-distcheck-mypaint-brush/21/consoleFull Latest committer to that branch, please fix. If it's something that needs configuration changes on Jenkins, then just let me know so I can update the configuration. Kind regards, Sven ___ 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] Bad link in http://www.gimp.org/mail_lists.html
On 12.7.2014 at 8:57 PM Ofnuts wrote: 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 Thank you for reporting. I've just updated it and the wrong Nabble URLs in the website repository's testing branch. Schumaml or Alexandre should be able to tell when the changes appear on the website. Kind regards, Sven ___ 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] XCF file format spec
Hi, I've updated the XCF format spec at https://git.gnome.org/browse/gimp/tree/devel-docs/xcf.txt?h=osx-build It's currently in the OSX-build branch, but on its way into 2.8 and master soon. So, if anybody wants to have a look on it - feedback is welcome (and answers to my open questions, too :-) ) Kind regards, Sven ___ 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 12.7.2014 at 12:26 PM Alexandre Prokoudine wrote: Joseph Bupe wrote: See the attached mock-up. It's missing. It's here: http://gimpchat.com/download/file.php?id=14353&sid=8bb304f394a8db0eaa414f3a4e4def6d BTW: this lets me wonder whether the UI brainstorm is still active or to be revived. I find it a good way to contribute UI ideas and it's still listed as a way to contribute to GIMP. Kind regards, Sven ___ 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] Questions about the XCF file format spec
Hi, On 12.7.2014 at 4:31 AM Ed . wrote: I believe that the smart move is to go with the code if the doc disagrees, given the age of the doc. hmm, this doesn't really help with my questions, as this is what I'm already doing. I would like to open discussion on a format of how to store GIMP images in an Open Document Format of some kind. The ORA format (see 4) has this in mind. See also http://freedesktop.org/wiki/Specifications/OpenRaster/ ? However, thank you for your nice attempt to help. @Mitch, Nomis, Drawoc etc. - can you GIMP old stagers tell me a bit? Kind regards, Sven -Original Message----- From: scl Sent: Friday, July 11, 2014 6:54 PM To: gimp-developer Cc: henn...@makholm.net Subject: [Gimp-developer] Questions about the XCF file format spec Hi, [...] 4) What will happen with the format after the GEGL port? AFAIK the ORA format will play a big role in the GEGL context (correct me if I'm wrong). Will XCF be dropped then or will ORA then be yet another import/export format like PSD etc.? ___ 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] Questions about the XCF file format spec
Hi, I'm just trying to get a better understanding of the XCF file format and to review and update the XCF spec (/devel-docs/xcf.txt). I've got some questions: 1) Some properties are denoted with "essential", "editing state", "not editing state, but not really essential either". I have problems understanding these remarks. What did Henning Makholm mean? 2) I found the property PROP_ITEM_PATH in the code, which is not yet in the spec (I'll add it). The code reads that it is a list of pointers, represented as uint32 integers and somehow in the context of layers. However, I don't get what this is for and what the property values mean. 3) The XCF file holds (for unclear historical reasons) a level-of-detail hierarchy, but we only use the lowest hierarchy level of it and other XCF consumers are told to do the same. For my understanding this looks like a mipmap. Would using it to save an image pyramid or the thumbnail for the File dialogs get us some benefits? 4) What will happen with the format after the GEGL port? AFAIK the ORA format will play a big role in the GEGL context (correct me if I'm wrong). Will XCF be dropped then or will ORA then be yet another import/export format like PSD etc.? 5) The document shows that the layer modes 'Overlay' and 'Soft light' are identical. If this information is still valid - is this state subject to change in GEGL? Should we continue providing two different names for the same thing? Thank you in advance, Sven ___ 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] Eraser Tool default setting (Was [Gimp-user] ERASER TOOL)
On 10.7.2014 at 4:06 PM Przemyslaw Golab wrote: I think that the user didn't know that layers could be stripped of alpha channel, and by default Background layer is no-alpha layer. Hi, when I wrote this I actually asked myself: "Why can't the eraser behave on the background layer behave like on the others?" After some research in this list's archives I found that this topic was already discussed thoroughly so I assume it's just so for good reasons. (Handling the simplest use case "Editing a one layered image with no alpha" most easily, comes to my mind). So it's all fine about it. I didn't want to start a longish painful discussion again. While playing around with the Eraser tool I found out another strange effect: The Anti-Erase option doesn't work well: On layers with no alpha channel: In GIMP 2.8 it simply behaves like the Eraser, i.e. it paints with the background color. In GIMP master nothing happens at all. On layers with alpha channel: The erased pixels are properly restored. However, if I paint on a transparent layer and anti-erase formerly transparent pixels, they become painted in background color. There might be technical reasons for it, but from a user's point of view this is unexpected. After digging in the archives I found that this is an ancient option that started out as quick hack and could be replaced by an undo brush. It seems with the GEGL port this problem could get solved easily and the option be removed. Until then I think at least disabling the Anti-Erase option on layers without alpha channel could be a way to alleviate it. Shall I file a bug for it? Kind regards, Sven ___ 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] Eraser Tool default setting (Was [Gimp-user] ERASER TOOL)
On 9.7.2014 at 3:38 PM Jluc wrote: Le 09/07/2014 15:32, PDG-USER a écrit : Very new to this program with elementary uses for Gimp. Main task is erasing extraneous graphics from pdf. maps and drawings. Currently, the setting for the eraser tool is not removing graphics, but painting on the checkerboard pattern. have you tried, in the layers pane, to select the layer, click right, and remove the alpha channel ? Hi, the default setting for the Eraser Tool is to not erase from the background layer. As the example above shows this is not what users expect and therefore (new) users have problems with it. Is there a reason to have chosen this default? Kind regards, Sven ___ 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] Compile gimp plugins with lazarus
Hi, On 8.7.2014 at 5:31 PM Paco Garcia wrote: Hi, is there any way to develop gimp plugins with lazarus ide? as Lazarus is a Pascal IDE programming GIMP plug-ins with Lazarus would require Pascal bindings to GIMP or its Procedural Database (PDB). I don't know of any. Kind regards, Sven ___ 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] New Themes sharing
Hi RGB4U, first of all thank you for your initiative to share them with us! As far as I can tell from the screenshot and the Youtube video the themes look very nice. I plan to consider them in our work for a new [UI theme] in our wiki and have some questions: 1) They appear to mimic Adobe CS6. What is their concrete goal? Are they meant to visually clone CS6? 2) On the one hand you post them at a public site for GIMP assets and release them under the GPL, on the other hand there is only a nickname and the ZIP archive is password protected. Why so mysterious? Kind regards, Sven [UI theme]: http://wiki.gimp.org/wiki/Specs:UI_Theme ___ 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] Q about gimp 2.8.12
Hi Kungfu07, On 7.7.2014 at 1:22 PM Kungfu07 wrote: Hello GIMP Development Team; it's been years that i'm a GIMP user, First *thank you enormously* for your good work in the creation of this wonderful software. thank you for your positive feedback ;-) Then I want to know when you go to launch the new version 2.8.12 ? From my point of view it looks as follows: I'm just finishing the last parts of the OS X integration that are meant to go into version 2.8.12. This means - reviewing a patch for the critical and urgent [bug 730211], - checking the JHBuild configuration for updates and - cleaning up. Until this is finished I suggest we also take the time for final tests in the gimp-2-8 branch. From my point of view we could release then. BTW: To support the release process I shared a search in Bugzilla to quickly find the fixed bugs in this release. It's named 'GIMP - changes since last release' and GIMP developers find it in the footer of their Bugzilla sites. Currently it finds 65 fixed bugs. I would also have loved to integrate Simone's port to her forked and updated GTK-Mac-Integration project, but as we're already late with 2.8.12 and her changes are sort of fundamental, I tend to start with that right after the 2.8.12 release. So we'll have enough time to test and do justice to it. > and how > close is the release of GIMP 2.10 ? There are some things yet to do whereof the GEGL port is the most important of it. We don't have a date for GIMP 2.10. Help is welcome. Kind regards, Sven [bug 730211] http://bugzilla.gnome.org/show_bug.cgi?id=730211 ___ 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] Move tool
Hi, just for the records we also have a bug filed for this: https://bugzilla.gnome.org/show_bug.cgi?id=664748 Kind regards, Sven ___ 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.6.2014 at 11:19 PM Ofnuts wrote: I'm not convinced that shape bursts still need a complicated UI. +1 Once you have a nice clean black-to-white linear fill you can always use the Levels or Curves (or a gradient map) on it to achieve whatever you want. How would you bend and distort a straight linear fill (i.e. from left to right) to make it fit into an arbitrary shape with the Levels or Curves tool? They are Color tools and all they can do are tonal corrections. In our case they can only shift the gradient a bit more to the left or right or make it wider or slimer. I think in the context of gradient fill these tools a) don't meet the needs (see above), b) they add an extra step. Modifying a linear, circular etc. gradient with handles, but other gradient shapes with the Color tools is simply confusing. Extra steps also impede the users in working fastly. Therefore Color tools can be taken as optional step for fine tuning a gradient, but never be part of the default filling workflow. I also agree that too many options are more confusing than helpful, but let's not drop useful functionality. Kind regards, Sven ___ 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.6.2014 at 5:45 AM Joao S. O. Bueno wrote: However,a "shape fill" tool, which could not only fill an area with a gradient, but also with a pattern (a selection copied from somewhere else) would be great. Are you perhaps looking for the Bucket Fill Tool's fill type 'Pattern fill'? Its first item is a pattern from the clipboard. Or did you mean to distort the fill pattern to make it fit into the selection's shape? Kind regards, Sven ___ 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
Hi, first of all thank you for your efforts and the posting. In general I like the ideas. On 23.6.2014 at 5:31 AM 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. The UI team sits in Berlin and is named Peter Sikking ;-) You might have luck by sending him an e-mail. 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. That's all fine! * 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. I only remember a conversation between you and Mitch in IRC. To get a general consensus this place seems more suitable (thank you Alex). Do you mean all shapes in the tool's options or only those whose name starts with 'Shaped'? Why should they be moved out of the Blend tool? As we are just improving this tool's interaction, there are some evaluation notes as input for our work: http://gui.gimp.org/index.php/Evaluation_Notes_-_Photo_Composing#Blend_-_Gradient_tool http://gui.gimp.org/index.php/Evaluation_Notes_-_Creating_Web_Images#Gradient_tool I could not find any specs nor at a glance any open, influencing bugs. Kind regards, Sven ___ 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] XCF format specification
Hi, in order to fix [bug 730211] I came across the [XCF file format specification]. While the XCF format has been in production use for years the spec is still marked as draft. Which parts of the spec have become mandatory in between? What do we need to clarify that still justifies the draft state? Kind regards, Sven [bug 730211]: https://bugzilla.gnome.org/show_bug.cgi?id=730211 [XCF file format specification]: https://git.gnome.org/browse/gimp/plain/devel-docs/xcf.txt?h=gimp-2-8 ___ 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 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. Kind regards, Sven ___ 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] Getting contributors via OpenHatch: Beginner documentation
On 29.5.2014 at 10:27 PM 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. Let's not reduce our pool of contributors that way! Ed +1 I also found this as a IMHO quite good beginner documentation: https://wiki.videolan.org/Getting_Started_At_Coding/ and https://wiki.videolan.org/Compile_VLC/ Kind regards, Sven ___ 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] Getting contributors via OpenHatch
Hi, lately somebody committed to [OpenHatch] spoke to me in IRC whether we at GIMP want to work with OpenHatch to gain more contributors. OpenHatch defines itself as 'a non-profit organization with the goals of lowering the barriers to entry into open source community and increasing diversity'. They also teach the next generation of students on colleges how to participate in open source communities, so 'Hello, next GSOC students'. I personally think it's a great chance to get some open problems solved: To push the things a bit forward: - Can we mark some more trivial and gnome-love bugs? - Is anybody willing to mentor some students or give a classroom presentation and if yes in which topic/area? - Are there any topics we've been putting off, neglecting or just plain avoiding? - IMHO the GEGL ports and Windows bugs need some care. If we have this, we can update [GIMP's and GEGL's pages there]. I'm cross-posting this message to the GIMP and GEGL developer lists, because I think also GEGL could benefit from it. Kind regards, Sven [OpenHatch]: https://openhatch.org/ [GIMP's and GEGL's pages there]: https://openhatch.org/projects/GIMP https://openhatch.org/projects/Gegl ___ 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 2.8 on OS X fixes
Hi Simone,
an honest thank you for your efforts.
In my build I'm also patching gtk-mac-integration
so this might be of your interest.
The patches are in /build/osx/patches of the build-osx
branch.
0002-Improve-internationalization-of-App-menu-and-other-s.patch:
The current App menu implementation assumes that the application's name
is at the end of the 'Hide' and 'Quit' menu item in all languages. This
is grammatically incorrect for some languages, such as German.
The patch inserts placeholders for the app name and fixes the
translations where necessary.
Fix references to the internationalization table ("GtkOSXApplication")
to ensure these strings are recognized at runtime.
Fix broken encoding in the ro, ru, uk languages.
Add language pt_BR (Brazilian Portuguese).
0003-Keep-separators-between-placeholders.patch:
Keeps menu separators between menu placeholders.
It fixes the issue that some separators got lost in the menus,
for instance the one between File/Send as e-mail and File/Properties
etc.
As you're forking gtk-mac-integration you might want to integrate them,
too.
Kind regards,
Sven
___
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 2.8 on OS X fixes
On 26.5.2014 at 6:40 PM Jehan Pagès wrote: > In other issues, do you have an idea about this: https://bugzilla.gnome.org/show_bug.cgi?id=719723 I tried yesterday with my GIMP 2.8.11 build of the build-osx branch which is based on GIMP 2.8 (commit c4dc168 from 25.05.2014) and uses lcms 1.19. I can confirm that GIMP doesn't crash anymore. It still shows the error message from comment 2 of this bug, but keeps running. For the GIMP users this means that it should work in the next release GIMP 2.8.12. Kind regards, Sven ___ 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] GIMP 2.8 on OS X fixes
Hi, I’ve updated the OS X builder. The changes include: - Bugfix 721482: bring back languages other than English and offer them in the Preferences’ language selection listbox, show a translated GIMP app menu in various languages, - Bugfix 683177: bring back GIMP’s online user help in a web browser, - Bugfix 721449 and other fixes to make GIMP 2.8 build on OS X again, - add a configuration to build GIMP master, - a UI theme with better integration into the OS X look and feel, - an improved build how-to, - updated dependencies and - various fixes. Known remaining issues are: - Stock buttons in plug-in dialogs still read English instead of the users' language, - GIMP opens the user manual still in English when GIMP was started the usual way by clicking the program icon. It shows the proper language when started from a terminal window. If somebody has a clue on how to fix this I'd be grateful. You find the update in GIMP’s osx-build branch and if we find no deal breaker it can go into the next GIMP 2.8 release. Thanks to all who helped me getting the job done. Mac developers, it would be nice if someone of you could build it on a platform other than OS X 10.9. and report back. The updated how to is /build/osx/README and here: https://git.gnome.org/browse/gimp/plain/build/osx/README?h=osx-build Kind regards, Sven ___ 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] What Python binary does GIMP use for its plug-ins on Mac OS X?
Hi, we use Python 2.7. It's built in and you can find it all under GIMP.app/Contents/ ... /MacOS/python /Resources/lib/libpyglib-2.0-python.0.dylib /Resources/lib/libpython2.7.dylib /Resources/lib/pygtk/ /Resources/lib/python2.7/ Kind regards, Sven ___ 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] Wee reminder about Gaelic in 2.10
On 18.5.2014 at 2:06 PM Michael Bauer wrote: I don't know how the plans for 2.8.12 are progressing but I just thought I'd ask someone please make sure Scottish Gaelic (gd) gets added to the UI language menu in the settings? Hi, good news also for the Mac users: I fixed the bug that GIMP only showed 'EN' and 'System language' in the language selector list. It's currently in the 'osx-build' branch which is planned to get merged back into GIMP 2.8 next days. So, the Mac users will have the UI in their preferred language, too, and Scottish Gaelic is among them. Greetings, Sven ___ 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] Question on building with GVFS support
Hi, I'm currently fixing some OS X issues and am trying to fix [bug 683177], see the build-osx branch in our Git repository and the gimp-osx target in gimp.modules. I've build GVFS and removed the --without-gvfs make argument in the GIMP build. However, the message 'Could not open 'http://docs.gimp.org/2.8/en/gimp-help.xml' for reading: Operation not supported. Perhaps you are missing GIO backends and need to install GVFS?' still appears. In Glib's own configure.ac I found nothing to include GVFS explicitly. Can anybody please give me a hint - is there anything particular missing? Thank you, Sven [bug 683177]: https://bugzilla.gnome.org/show_bug.cgi?id=683177 ___ 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] Building GIMP on OSX 10.9
Hi,
I'm building GIMP on OS X 10.9 with an updated version
of Clayton Walker's JHBuild script. The command I use is
JHB=gimp GIMP_SDK=10.9 jhbuild build gimp-osx
Now that I have all my dependencies built, building GIMP
itself fails with the following messages:
Making all in core
make[4]: warning: -jN forced in submake: disabling jobserver mode.
CC gimpmarshal.o
CC gimp-user-install.o
CC gimpbrushpipe.o
CC gimpbrushpipe-load.o
In file included from gimp-user-install.c:40:
In file included from
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:10:
In file included from
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:8:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:371:1:
error:
expected identifier or '('
@class NSString, Protocol;
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:373:19:
error:
unknown type name 'NSString'; did you mean 'GString'?
FOUNDATION_EXPORT NSString *NSStringFromSelector(SEL aSelector);
^
/Users/.../gimp/10.9/inst/include/glib-2.0/glib/gstring.h:39:33: note:
'GString' declared here
typedef struct _GString GString;
^
The following error is repeated many times until the build breaks with
the message 'Too many errors emitted, stopping now [-ferror-limit=]':
In file included from gimp-user-install.c:40:
In file included from
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:10:
In file included from
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:8:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:374:44:
error:
unknown type name 'NSString'; did you mean 'GString'?
FOUNDATION_EXPORT SEL NSSelectorFromString(NSString *aSelectorName);
^
/Users/.../gimp/10.9/inst/include/glib-2.0/glib/gstring.h:39:33: note:
'GString' declared here
typedef struct _GString GString;
I have glib 2.39.1 installed and the sources I build with are
in [GIMP's osx-build branch] plus Simone's and su_v's patches
to treat C files as Objective C files. However, this doesn't
seem to solve the problem.
Does anybody have a clue how to fix these errors?
Thank you in advance,
Sven
[GIMP's osx-build branch]:
https://git.gnome.org/browse/gimp/tree/build/osx?h=osx-build
___
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] GEGL and GIO porting matrices
Hi, now I updated again the GEGL and GIO porting matrices http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL http://wiki.gimp.org/index.php/Hacking:Porting_file_plugins_to_GEGL_and_GIO and found many items that were still marked as work in progress. Which of them are finished and should be marked in green? Alsoif somebody feels lucky to port more filters - any help is welcome. The sooner we finish this work, the sooner we see version 2.10 ;-) Thank you in advance, Sven ___ 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] OS X build/Python failure
Thanks to Daniel Sabo a solution could be found. FYI you find it at https://git.gnome.org/browse/gimp/commit/?h=osx-build&id=ce0c1021d281473b39e0625bf2af3f703cc7c492 Kind regards, Sven ___ 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] OS X build/Python failure
Am 03.05.14 08:33, schrieb scl: > Hi, > > in order to fix the missing translations in the OS X build > I tried to build GIMP 2.8 for OS X on my system, following > Claytons [README]. > However, when it comes to install and build GIMP (the line > JHB=gimp GIMP_SDK=10.6 jhbuild bootstrap ), Python fails > to recognize the existing file $HOME/.jhbuild-gimp. Sorry, a typo. I meant $HOME/.jhbuildrc-gimp. I investigated a bit further and added a line to print that exception. It returned 'MacOSX10.6.sdk not found' After reading http://stackoverflow.com/questions/19555395/python-framework-is-missing-from-os-x-10-9-sdk-why-also-workaround and checking the place where OS X expects the SDK (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/) I saw there are only MacOSX10.8.sdk and MacOSX10.9.sdk. But neither using GIMP_SDK=10.8 nor GIMP_SDK=10.9 worked. I got then returned 'MacOSX10.8.sdk not found' and 'MacOSX10.8.sdk not found'. Then I tried to trick OSX and added a symbolic link to the place where Python was formerly: cd MacOSX10.9.sdk/System/Library/Frameworks/ sudo ln -s /System/Library/Frameworks/Python.framework/ Python.framework but this didn't help either. I get the same error messages as above. Kind regards, Sven ___ 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] OS X build/Python failure
Hi, in order to fix the missing translations in the OS X build I tried to build GIMP 2.8 for OS X on my system, following Claytons [README]. However, when it comes to install and build GIMP (the line JHB=gimp GIMP_SDK=10.6 jhbuild bootstrap ), Python fails to recognize the existing file $HOME/.jhbuild-gimp. Granting execute permissions to that file with chmod +x didn't help. I'm on OS X 10.9 with a fresh XCode and Python 2.7.5. I also removed the former JHBuild artifacts and restarted the process from scratch. Does anybody here have an idea how to solve this? Thank you in advance, Sven [README]: https://git.gnome.org/browse/gimp/plain/build/osx/README?h=gimp-2-8 ___ 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] Updating the website for all the broken download links?
Hi, yesterday I came across http://www.gimp.org/develop/ and clicked the link 'INSTALL'. It refers to https://git.gnome.org/browse/gimp/plain/INSTALL, which doesn't exist anymore in this form. This raised a question: can the link checker also detect dead links that don't result in an HTTP error but in simply nothing or unreadable garbage? Kind regards, Sven ___ 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 and MPO files
Hi Pavel, thank you for your work! I personally think as the progress in photography continues such work is necessary and much appreciated. Indeed, there is a [MPO file loader plug-in] in the GIMP registry. It's just a loader and has no export functionality. I checked your tool and saw that it doesn't implement the GIMP's plug-in interface. Perhaps you want to join your efforts with the author of the original MPO plug-in to extend its functionality with your code? Thank you and kind regards, Sven [MPO file loader plug-in]: http://registry.gimp.org/node/28259 ___ 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] Emails for contributors?
On 2.5.2014 at 4:09 AM Jehan Pagès wrote:> Hi, Haven't we discussed gimp.org emails for contributors during LGM? I remember that the last day, someone asked about this and the conclusions was that it was a good idea. I wouldn't mind one either. :-) I would like one, too. Kind regards, Sven ___ 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-user] Gimp download android
Hi, I had the topic 'GIMP on other platforms' on the LGM team meeting agenda, but we didn't have time to speak about it. (See Schumaml's prepared document 'Meeting minutes'). As the topic raises up more often these days we should clarify soon how to deal with newer platforms. Kind regards, Sven On 28.4.2014 at 3:16 AM Jehan Pagès wrote: Hi Edith, On Sun, Apr 27, 2014 at 5:29 PM, Edith Arnold wrote: Is there a gimp for android? I miss it so,since I lost computer.I have a odd make, my android is a xeilo tablet 4.1.1. Digging into the system it seams to be with a kernel of Linux 2.6.x. files are apex format. There is no official GIMP for Android. I remember that someone said he compiled GIMP for Android. You can find it on the Google play store. But this was "as is", there were apparently no adaptation whatsoever, or very few, to adapt it to small devices (phone, tablets), so usability is likely close to inexisting and frustrating. That means also that the GIMP developers cannot vouch for it. The "normal" GIMP is meant for desktop only. Note that I don't think that anyone is against getting a real GIMP for Android, adapted for tablets and phones or such devices. But simply no contributor ever shown interest into starting the porting work and contributing this upstream. Jehan I hope I gave you efficient information. Thank you Edith ___ 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] Updating the website for all the broken download links?
On 28.4.2014 at 3:59 AM Sam Gleske wrote: As I mentioned in the past the offer is still open for me to QA the GIMP website frontend for dead links and generate a report. I didn't ever get approval from any of the core devs so I didn't run any front end tests. SAM Hi Sam, yes, we lately had this topic and somehow it went out of sight. I'm not the webmaster, but I think it's useful. If we should/can integrate something into our Jenkins job set, then let me know. Greetings, Sven ___ 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] Big problem with Gimp G'MIC with upcoming Gimp 2.10
On 27.4.2014 at 2:05 AM Jehan Pagès wrote: On Sun, Apr 27, 2014 at 4:55 AM, Jon Nordby wrote: One could set up g'mic or another well-maintained C++ plugin for GIMP to build on Jenkins? That way these errors would be quickly (and hopefully fixed). Actually more simply a very simple do-nothing C++ plugin, yet which includes all possible libgimp headers, could be integrated in the tree as a C++ compilation test to be run during `make check`. That would also catch these kind of bugs. Two souls are dwelling in my in my breast: As GIMP is also a platform for programming cutting-edge image processing algorithms by scientists and artists I think it's a good idea to test the exposed GIMP interface for this purpose. G'MIC with its scientific background seems to be a good candidate. I checked G'MIC's sources and at least there is an example to call the G'MIC-GIMP-plug-in from other Scheme plug-ins. They could work as test-drivers. On the other hand G'MIC with its many filters seems to be a quite good candidate to push our GEGL porting progress forward. From an technical- architectural point of view I rather see its place in the filter- processing-component, i.e. in GEGL (as code donation or through a wrapper interface). From this point of view the aforementioned part of GIMP's product vision suits better to GEGL and GIMP could fully focus on the artistic part. Also the G'MIC plug-in with its extra dialog currently looks like a duplication of the Filters menu and could be more integrated (like the FxFoundry for example). As I'm currently doing the Jenkins work almost alone I'd prefer a solution that's easy to maintain. Jehan's proposal looks good for its pureness. Kind regards, Sven ___ 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] About closing feature requests as invalid
Hi, On 19.4.2014 at 6:29 PM Joao S. O. Bueno wrote: So, I for one, feel like such requests in bugzilla should be left in the "New" or "Unconfirmed" state, with a text inviting the person to discuss it either her or on IRC, I think 'Unconfirmed' is exactly the state we can use here: the request is yet to be confirmed - in this case to find out whether there is a real need for it. 'Unconfirmed' also is not offending. From the three alternatives Bugzilla, IRC and mailing list a mailing list has the best visibility to the target audience and should in my opinion be preferred. Currently we use the GIMP developer mailing list but our users are likely not there, but rather on the GIMP users mailing list. At the end we write software for users and it's good practice in open source to listen to the users. On the other hand the developers are on the GIMP users list, too, so we catch them all. Therefore I'm for discussing new features on the GIMP users mailing list. Another point are feature requests that arrive at Peter's GUI brainstorm. I find the GUI brainstorm's intention a great idea that should be kept alive. In my opinion it could also be used to collect UI ideas for later features, but it should not be misunderstood as a letter box for feature requests. My proposal to handle feature requests: 1) a) A request is made in Bugzilla. If it is a duplicate: RESOLVED DUPLICATE. If it is a troll request, like to bring back the 2.6 save behaviour: RESOLVED-WONTFIX or RESOLVED-INVALID. If it is a valid feature request: UNCONFIRMED, forward discussion to the GIMP users mailing list. We set Platform:=all, Importance:=enhancement. If it is unclear whether it is a bug report or feature request: forward discussion to the GIMP users mailing listto clarify its character there. We reply in timely manner with a friendly stock answer. This is not meant to fob somebody off like an arrogant company but to ease our own work. Who likes to use own words is free to do so. b) A request is made to the GUI brainstorm: If it is a valid request, then Peter replies shortly and forwards the request to the mailing list. In the meantime the idea gets the tag 'New feature' on the brainstorm blog and can be referred from the mailing list post to clarify the idea. c) A request is made on a third party website, like Stackoverflow or a forum. If it is a valid request, then the present GIMP team member replies shortly and forwards the request to the mailing list. 2) The topic will be discussed on the GIMP users mailing list. Yet we should find a default action when no discussion comes up. Does it mean 'Yes' or 'No'? 3) When the discussion has finished we take the result in a timely manner to Bugzilla. If the request is accepted, then it goes into state 'NEW' and we add a short summary, links to the ML discussion and the UI brainstorm. If the request is rejected, we close the bug with WONTFIX. In both cases we add the Bugzilla link to the mailing list thread for future investigations. How do you people think about it? Joao, you mentioned some open requests on the mailing list that haven't made it into Bugzilla yet. Do you have them at hand so we can bring them to Bugzilla now? Kind regards, Sven ___ 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] About closing feature requests as invalid
Hi, 1) I think there is some vagueness about the meaning of the fields in Bugzilla (yes, sometimes it also affects me). They are defined here: https://bugzilla.gnome.org/page.cgi?id=fields.html We already have a severity 'Enhancement' for feature requests and also use the milestone 'Future' for things that are currently not meant to be included in one of the next releases. Indeed, the definition of 'Invalid' lacks of clarity: 'This bug is in some way not valid...'. But if we close bugs we will neither fix nor accept patches we clearly use the state='CLOSED-WONTFIX'. Why would we use 'CLOSED-INVALID' for this? 2) Let's also not forget, that the mailing lists have around 1000 subscribers and are mirrored directly to various sites (GMane, Markmail, etc.). After committing a comment to a bug in Bugzilla we all can see the recipients: a handful of interested people. If I do a Google search on 'tito' and constrain the search to bugzilla.gnome.org, gmane.org or markmail.org I get 1 (in words: one) result for bugzilla.gnome.org and lots for the other sites. This confirms that the mailing lists are suited better for broad discussions than Bugzilla. 2) When I closed the bug 'INVALID' I obeyed the projects policy, see for instance http://www.gimp.org/bugs/ in the 2nd paragraph. However, as we see there are doubts and disagreements about its practical use. I think it is a good idea if the people who usually care most about policies joined in: Mitch, Peter, Schumaml - what are your opinions? Greetings and Happy Easter! Sven ___ 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] About closing feature requests as invalid
Hi, yes, it's a bit tricky. One goal is to take care for bugs in a timely manner to let the reporter know that we care as well as to save developers from drowning in open bugs. The other thing is to sound friendly even if we say 'No, not this way'. That's why I did some investigation about the reported issue and posted the request myself here instead of simply saying 'Go to the mailing list'. Thirdly I think Bugzilla is even less visible to the broad audience than the mailing lists, so lengthy discussions in Bugzilla have less chances to solve anything. If we failed to take accepted feature requests on the mailing list to Bugzilla in the past, this should be no reason to do it wrong in another way. However, you have a point in saying ''Invalid' sounds too harsh'. If we found a better solution I would be the last to hamper it. Currently I see the following solutions: - a friendly stock answer we agreed about to guide the reporter the right way, - the policy change you proposed, - feature voting like [uservoice.com]. I saw newer Bugzilla versions should be able to support [voting], but I neither know whether nor when it will become part of GNOME's Bugzilla. Kind regards, Sven [uservoice.com] http://demo.uservoice.com/ [voting] http://www.bugzilla.org/docs/4.2/en/html/voting.html ___ 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] [FEAT-REQUEST] A way to quickly know layer dimensions in Gimp
Hi, lately at Stackoverflow.com a user came up with a [feature request] and filed a [bug] in Bugzilla: ' [...] I add a feature request to display layer dimensions somewhere in the main window or the layers one. May be display only the current layer sizes, but would be great to see all layer dimesions at a glance. Could be an option in user preferences?' As feature requests shall be discussed at the mailing list first, I bring it up here for discussion. I verified that the desired information is indeed missing, this is not a duplicate in Bugzilla and there were no discussions about this topic on the GIMP mailing lists before. To solve this for single layers I can also imagine to let the user include layer width, height or dimensions show in the title or status bar und add variables for them to Preferences/Image Windows/Title and Status. To have this information for all layers together probably a new column needs to be added to the Layers dialog. As Joao already pointed out at Stackoverflow.com, [automatic layer boundary management] is on our roadmap for the far future. Do we consider such a feature useful? Kind regards, Sven [feature request]: http://stackoverflow.com/questions/18042093/how-to-quickly-know-layer-dimensions-in-gimp [bug]: https://bugzilla.gnome.org/show_bug.cgi?id=728493 [automatic layer boundary management]: https://bugzilla.gnome.org/show_bug.cgi?id=93639 ___ 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] Fwd: Gimp Registry Future
On 9.4.2014 at 5:42 PM Ingo Lütkebohle wrote: If anybody could put up a wiki page for that, that'd be great. Does The GIMP have a wiki? Hi, I've just created that page, see http://wiki.gimp.org/index.php/Hacking:Plugin_registry Kind regards, Sven ___ 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] Fwd: Gimp Registry Future
Hi, it's interesting to see what interest such a post can trigger ;-) To be honest, it wasn't me who started the discussion, I just forwarded Ingo's call to the mailing list. 'GIMP is easily user-extendable, by ‘one-click’ installation of plug-ins.' is a part of our product-vision and as far as I remember there have already been many ideas on this topic, dating back to 2003. For both the registry and GIMP the situation changes: Registry: from some or many users who know and use the registry to potentially every user who can access it conveniently from GIMP. These are millions. GIMP: From a standalone application that uses mostly local data to an application with tighter access to an online service. I think before we start losing ourselves prematurely in implementation details like programming language and data formats we should clarify the overall picture first: - What are the concrete requirements: functional and nonfunctional requirements, - user interaction, - overall technical architecture and integration into GIMP, - reuse of existing solutions like package managers, - who will also care in future for the registry and the plug-in manager? - Integration into the Jenkins builds and manpower to handle this. Examples for functional requirements: * installing only plug-ins or also other assets, * curation/quality assurance of provided assets, * metadata of the assets, * search and filter functionality. Examples for nonfunctional requirements: * performance: be fluent, also with a slow internet connection, * security, protection against abuse, * scalability (how many users will access the registry at one time or at maximum), * target platform, * maintainability (even with our given low resources). Perhaps it would - depending on our resources - first be better to cut down the registry to the necessary part we can handle, e.g. to remove the functionality that causes spam and start with a little thing in GIMP, like a clickable link to open the registry in a browser and easy to find assets folders in the Preferences. Kind regards, Sven ___ 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] Fwd: Gimp Registry Future
On 8.4.2014 at 10:44 AM wrote: Gimp Registry Future Dear Registry Users, I have maintained the registry for over 15 years now, and for the last couple of years we have had an excellent team of co-maintainers who took on a lot of the work. However, there are some much needed improvements which are hard to carry out based on the current platform, and the work due to abuse is growing. We cannot continue this on our own, unfortunately. In particular, we really need better search and categorization functionality, and would also like to integrate the registry more tightly with The GIMP, such that downloading and installing plug-ins becomes more straightforward. This new structure should also help combat abuse much more effectively. This is no longer just a web-development issue, but much more a plug-in development task. Therefore, I would like to ask /you/ for some help with that. Specifically, we need a plug-in which could access a back-end database over the Internet, carry out queries, receive data in XML or JSON format, download plug-ins, and install them automatically. Ideally, it should also be able to display and acquire meta-data, such as ratings, permissions required, etc. Any takers? cheers, Ingo ___ 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] [GUI] Screen space usage
users for some poor arguments. If we made this decision now and held on to it, either users could use their screen space better or we had less code to maintain. So or so we wouldn’t have to discuss this anymore then. Greetings, Sven [specification]: http://gui.gimp.org/index.php/No_image_open_specification#drop_zone [image]: https://imageshack.com/i/fvw9sjp [patch]: https://bugzilla.gnome.org/show_bug.cgi?id=726740 [related activities in the UI wiki]: http://gui.gimp.org/index.php/Rethinking_GIMP_Tool_Options, see ‘Layouts: horizontal vs. vertical’ [agreed to this change]: https://mail.gnome.org/archives/gimp-developer-list/2012-May/msg00125.html, talk between guihipster and scl in IRC #gimp on 21.03.2014 [option in the Preferences dialog]: https://imageshack.com/i/n96p1rp ___ 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] Wiki: Problems and Solutions page
Hi! I've updated the 'Problems and Solutions' page in our wiki. It's a growing knowledge base for developers for all kinds of development related questions. You find it at http://wiki.gimp.org/index.php/Hacking:Problems_and_solutions . The update contains new answers to Git and Eclipse questions, a better navigation and lots of links to external support sites. Feel free to add your own findings there! Good luck with it! Sven ___ 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] Adopt a development model similar to Jenkins?
Hi Sam,
thank you for your suggestion! It comes at just the right time, because
speaking on how we can improve our development process to be more
attracting to new contributors is one point on our LGM meeting agenda.
Indeed, the Jenkins project has some points we can learn from, such as
what you wrote and secondly the release process. They manage it to
release two products (the rolling release and an LTS release) regularly.
On 23.3.2014 at 12:04 AM Sam Gleske wrote:
Right now, GIMP has a place for users to dwonload plugins... but there is
no place where the source code of all of the plugins live and be maintained.
... and the GIMP plug-in registry is only one place among others
(forums, private sites, DeviantArt etc.) We're currently reconsidering
possibilities to install plug-ins and assets from within the
application easily. Having the source code at the same registry site
next to binaries for various platforms (at least the most often used)
would IMHO be a win.
I went looking for the GIMP repository on github (it's nice that there is
one!) however it seems sadly buried in the GNOME project repositories.
Because it's a GNOME project ;-)
One trick: finding a particular project in GNOME's Git repository is as
easy as at GitHub: The URL is always
https://git.gnome.org/browse/${project name}
I propose GIMP developer team take the initiative to create an
organizational account at github and form teams similar to Jenkins.
The GNOME project mirrors its repositories to Github. You can find the
GIMP subpage here: https://github.com/GNOME/gimp
However, to attract more contributors and benefit from more
contributions, we should have an eye on the pull requests there.
Leaving the GNOME project and going our own way is IMHO not the right
way as there are many points where we our both projects give and take
to/from each other to our both benefit.
I'm learning C++ in hopes to contributing to GIMP [4] with more than just
recommendations or the mailing list.
That's nice that you take this initiative. GIMP and GEGL are developed
in C with the object orientation of [GObject]. Also the Babl library we
rely on is in C.
If you like it tricky there are also the Autotools and their M4
language. We use them in our build processes but they are hard to
understand and often full of mystery. Having an expert here who can
either give a founded advice on better build tools (CMake, Maven,
etc.?) or can help using the Autotools' potential better would IMHO
be a big help.
For your first steps let me point you to our [developer wiki],
especially the 'Developer information' section. And as always you find
us at #gimp in IRC and here on the mailing list for asking :-)
Kind regards,
Sven
[GObject]:
https://developer.gnome.org/gobject/stable/
[developer wiki]:
http://wiki.gimp.org/index.php/Main_Page
___
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] Jenkins: dependency version information
Hi, to get a better notion of our builds and ease bughunting I've added a new feature to Jenkins: Every babl, GEGL and GIMP build (the main branches) now contains a table with the versions of the libraries and tools they are built with. You find these informations in the console logs and the file dep-versions.log on each job page and in the nightly builds. May it be of use for our developers! I'd be grateful for feedback. Good luck, Sven ___ 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 6.3.2014 at 1:59 PM Alexandre Prokoudine wrote: To reiterate... To the best of my understanding there is no long-term strategy for involvement with Steam whatsoever, other than "it would be cool, eh?" which is no strategy at all. Hence any voting or similar activities, in my opinion, make very little sense, until this conversation is reasonably formalized, with advantages and disadvantages listed to be judged on. I've witnessed at least three IRC discussions on the topic and they never led to any decisions, just a lot of hot air, and man/hours wasted. I fully agree with you. Here are my pros and cons: Pros: - more users, - more creative possible applications for GIMP, - we are early enough on the Steam platform to say we haven't missed that, - automatic update. Cons: - Steam is mainly a gaming platform. Thus in future GIMP will quite probably be considered a toy. This doesn't match to our product vision to be a high-end graphics software. - We have been only a few developers for years and still are. - There are so many other open tasks, like high bit image editing, improving performance and usability, adding useful features etc. Better doing one thing right that starting a thousand things and leaving them unfinished. What we don't miss on the Steam platform will we lose on our current platforms where our target users are. To me none of the Pros is really a Wow!-argument. For the automatic update we can also learn from the Mozilla people and their automatic browser updates. Even our Jenkins offers the possibilities to deliver updates often and with some coding automatically. In my opinion there's more to this than throwing a build over the wall. We should also consider: 1. What's the concrete benefit we offer our target users with this step? 2. Are so many users of our target audience (intensive GIMP users) using the Steam platform to make the efforts worth it? 3. Who will support GIMP on Steam, i.e. implements platform specific features, writes documentation, tests, cares for the bugs, fixes them and cares for the Steam community? Who will deliver further builds when the current volunteer discontinues his/her builds? 4. How will we deal with feature requests to support gamer hardware? Who will care for it? 5. Steam is a commercial platform. When creating an account the users contract a subscription with Valve. Valve is a company and sells/rents software and somewhere the money has to come from. Do we want to offer GIMP for money? If yes, at what price? How will we spend that money? Who will pay the taxes for the revenues? 6. How can we hedge the risk that Valve could start delivering GIMP with adware or similar stuff harming GIMP's reputation? (I remember the recent Sourceforge issue). 7. @Boudewijn: You Krita people brought Krita to Steam and might have asked yourselves similar questions before: What else should we consider? To me personally it is the same whether we deliver GIMP solely on an open or proprietary channel. I consider the other questions more serious. If we don't want to be seen as simpletons, who enthusiastically start one thing and then fail with flying colours, we should think first. To discuss the platform topic as a whole I've put it on Schumaml's LGM meeting's agenda. TL;DR: This is a big step that needs more consideration than throwing a build over the wall. To me it doesn't really offer a benefit. Kind regards, Sven ___ 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] Jenkins infrastructure (Was: Jenkins tutorial)
On Mon, Feb 24, 2014 at 2:09 PM, scl wrote: Also, I'd like to note that if you're not using git hooks now would be a good time to use them. Hi, together with Andrea Veri I've set up the hook based build trigger. Currently it is active for testing purposes on the branches babl/hooktest and GEGL/master. If we encounter no trouble the other branches will follow in one week or two. That's how it works: 1. You push a commit to babl/hooktest or GEGL/master in our public repository. 2. Git's Post-Receive hook notifies Jenkins about changes in the affected repository and branch. 3. Jenkins' Git Plugin will scan all the jobs which check out the specified URL and if they are configured with polling, they'll poll. 4. The polling will usually find something that's worth a build, so a build will be triggered. 5. You get an answer about success or failure of your commit via IRC and RSS (quicker than before) For more information see: https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin http://kohsuke.org/2011/12/01/polling-must-die-triggering-jenkins-builds-from-a-git-hook/ Thanks to Sam Gleske for the advice and Andrea Veri for setting up the Git side. Kind regards, Sven ___ 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] [GUI] Scrollbars for Script-Fu dialogs
Hi, today a contributor addressed the problem of the missing possibility for scrollbars in Script-Fu dialogs, see [bug 725432]. He (or she) thankfully offers a patch. From my point of view the problem lies deeper: if a dialog needs such a scrollbar it is very probably overloaded and not enough user friendly. I'm thinking of these solutions: A) Reduce the number of elements in these dialogs. B) Use tabbed dialogs to organize these elements better. Perhaps better solutions can still be found. How do you think can we solve this? Kind regards, Sven [bug 725432] https://bugzilla.gnome.org/show_bug.cgi?id=725432 ___ 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] Jenkins infrastructure (Was: Jenkins tutorial)
On 27.2.2014 at 10:36 PM Sam Gleske wrote: Also, when do IRC meetings happen and can anyone participate? What server and channel? http://www.gimp.org/irc We're in #gimp at irc.gimp.org, usually in evening hours (UTC). GIMP users' discussions are in #gimp-users and GEGL development discussions in #gegl. Kind regards, Sven ___ 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] HiDPI/Retina display support and gtk3-port branch?
On 27.2.2014 at 5:14 PM Brion Vibber wrote: I'm not sure how much can be done on the gtk2 end (a large icon theme would probably help on Linux), but I am definitely interested in poking at the gtk3 branch for proper hi-dpi support. I've gone ahead and filed a bugzilla entry: https://bugzilla.gnome.org/show_bug.cgi?id=725263 From asking around in IRC, it seems that the gtk3-port branch won't land on master until after Gimp 2.10 ships. Should I assume the branch is going to remain unstable for a while and wait, or is it ok to start doing some experiments & submitting patches for it? From my point of view: please feel free to do so. Especially to solve various problems with state-of-the-art hardware like graphic tablets and HiDPI displays we should switch over to GTK3 as soon as possible. Let's see how we can solve the current build issues, like the one you mentioned and those reported at https://build.gimp.org/job/gimp-distcheck-gtk3-port/ (The latter should be fixed first, otherwise we don't know whether your patches behave well in GIMP's code base). As Mitch pointed out in IRC there are some more hurdles to take for the GTK3 port such as ensuring that the plug-ins don't fail but IMHO this shouldn't keep you back from patches for HiDPI displays. Kind regards, Sven ___ 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] Jenkins infrastructure (Was: Jenkins tutorial)
On 27.2.2014 at 9:18 AM Michael Schumacher wrote: On February 27, 2014 6:03:59 AM CET, scl wrote: The newly generated website could then be fetched the same way like the we currently do with the API docs. Manually, unless this has changed since the last time I updated it? I was under the assumption that it's automatic now, but I might be wrong. To still be able to review the commits we could agree to either use a separate branch (a review branch or feature branch) This is why I recently asked mitch about resurrecting/creating at least > one other virtual host for creative testing. ... for the website or more stuff? or commit patches only via Bugzilla, We need more discussion about some things, at least. Getting a 'Help, what is >this going to achieve?' feeling for a new tutorial like thr most recent one isn't > optimal, especially if it makes us postpone a site update. Indeed. I think for now we can revert the last three blocking commits in gimp-web and take the tutorial to the wiki when it's finished. or we later use a review tool like [Gerrit] (in co-ordination with GNOME). I think we should start to have semi-regular meetings on IRC, logged and those logs published. Yes, it was started once in 2011, but then it came to nothing (see the Developer meetings in our wiki). Did it work in the past? If we can speed up urgent topics and can all be at a given time in IRC, it's at least worth a try. Kind regards, Sven ___ 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] Jenkins infrastructure (Was: Jenkins tutorial)
On 24.2.2014 at 11:27 PM Michael Schumacher wrote:> On 24.02.2014 22:39, Sam Gleske wrote: The advantage of hooks vs polling is that hooks are on demand. ...a commit hook triggers it. With some suitable delay - right now this would better be days, until we finally overcome the laziness and set up a commit-triggered website build on cube again :) Hi, how about building the website on Jenkins, too? This would unfetter us from asking regularly in IRC whether 'somebody is around who can update the website', i.e. streamline our website maintenance process. The newly generated website could then be fetched the same way like the we currently do with the API docs. To still be able to review the commits we could agree to either use a separate branch (a review branch or feature branch) or commit patches only via Bugzilla, or we later use a review tool like [Gerrit] (in co-ordination with GNOME). Kind regards, Sven [Gerrit] https://code.google.com/p/gerrit/ ___ 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] Jenkins infrastructure (Was: Jenkins tutorial)
Forwarded with Sam Gleske's permission: On 24.2.2014 at 3:21 PM Sam Gleske wrote: > On Sun, Feb 23, 2014 at 5:05 AM, scl <mailto:scl.gp...@gmail.com>> wrote: But if you have sth. stable for production use and are willing to contribute it in form of a Jenkins job, I'll be glad to integrate it. I think our both wikis (wiki.gimp.org <http://wiki.gimp.org>, gui.gimp.org <http://gui.gimp.org>) would benefit from such a test, too. Schumaml, Prokoudine etc.: what are your thoughts or requirements about it? I'm not familiar with the shorthand "sth". I can start running tests against www.gimp.org <http://www.gimp.org> and begin to start ironing out bugs which would need to be fixed in my program. I've run into bugs here and there running my crawler against large websites. Right now I've crawled and run against Drexel University IRT website using the crawler which is ~70k links. I'll do it for www.gimp.org <http://www.gimp.org> too and then contribute a Job when I have it ready (and for the other GIMP websites as well). I don't know whether this could cause technical problems for www.gimp.org. The reason why I wrote 'something stable for production use' is that I want to avoid just them ;-) Thus it would be good to hear our website administrators opinion to that. Also, I'd like to note that if you're not using git hooks now would be a good time to use them. Rather than using Jenkins to constantly poll the SCM simply implement a hook to launch a Jenkins job when a certain branch is committed to. Currently we're polling SCM every few minutes. Adding a git hook to the repository would surely need involvement of the GNOME administrators. Is there a good reason to switch over from polling to hooking? Greetings, Sven ___ 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] Jenkins infrastructure (Was: Jenkins tutorial)
Hi, I'm currently considering using Python, Perl or a JVM based scripting language (Groovy etc.) for the buildjobs. The goal are platform independence, performance and easy maintainability. Without wanting to start a silly flamewar about which tool is the greatest: - Where are the experienced benefits and downsides of these languages for the desired task? - Which readings would you recommend for Python and the JVM based language? Thank you in advance, Sven ___ 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] Jenkins tutorial
Hi Sam, thank you for sharing your thoughts! As they are more related to infrastructure I've started a new thread 'Jenkins infrastructure (Was: Jenkins tutorial)'. Let's continue there. Greetings, Sven ___ 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] Jenkins infrastructure (Was: Jenkins tutorial)
On 23.2.2014 at 12:47 AM Sam Gleske wrote: > Also, something you might be interested in is front end web testing > for bad > links, etc. Recently I've been working on a project to facilitate > that testing. > > https://github.com/sag47/frontend_qa > > This can easily be used in a Jenkins job to arbitrarily launch and crawl > gimp.org and test all the links in it checking for dead links, etc. > Currently it's a work in progress but it's a place that one can easily > start for frontend testing the Gimp website. Thank you for your offer. I have such a topic on my todo list and have planned to add it after improving the nightly and continuous builds. Jenkins opens such a bunch of new opportunities for our release process and I think I'll speak about it at our LGM BOF meeting. But if you have sth. stable for production use and are willing to contribute it in form of a Jenkins job, I'll be glad to integrate it. I think our both wikis (wiki.gimp.org, gui.gimp.org) would benefit from such a test, too. Schumaml, Prokoudine etc.: what are your thoughts or requirements about it? On 23.2.2014 at 12:51 AM Sam Gleske wrote: > That being said... would it be useful to have a vagrant instance of > the development environment including Jenkins for Job testing? > With a vagrant file it can be as easy as a single program executing > to pull down virtual box, the image, all of the requirements for gimp > building and testing. > This is something which could also be tweaked. Indeed, that idea has its charm ;-) I'm currently considering to improve the Jenkins infrastructure to support multiple build slaves of various operating systems and other improvements. So the idea of Vagrant and other Devops tools like Puppy or Chef comes to just the right time. Let's see how we can make the best of it. What does GNOME use - Puppy or Chef? Cameron, do you see a possibility to easily start and setup Virtualbox VMs for Jenkins master and build slaves with tools like Vagrant, Chef or Puppy in the Flamingtext infrastructure, that also comes to terms Flamingtext's interests? Also the idea of a standardised development environment for GIMP to get new contributors started quickly has been something I had in mind for long (see below). > Also, Jenkins really isn't > hard. It's pretty intuitive IMO (java -jar jenkins.jar and you have a > local web server) but a turn key dev environment would certainly > lower the barrier to entry. From the experiences I've made since I took over Jenkins administration in the GIMP project this is surely true for the first step of installing Jenkins. The hard work starts when one tries to setup a complex environment for many, interdependent build products or platforms and to integrate it into a bigger infrastructure. Also building GIMP for the first times and/or on other platforms than plain Debian Testing is a hurdle most times, even for new contributors. This is also an argument for a dedicated GIMP developer VM. Kind regards, Sven ___ 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] Jenkins tutorial
Hi Mukund, On 22.2.2014 at 10:40 AM Mukund Sivaraman wrote: > It would be nice to have docs on how to setup such a Jenkins instance > (after the other tutorials are written). Ok, your arguments are convincing. I'll regard this. > * Such docs would enable others to maintain/reconfigure the Jenkins >instance when you are busy and unable to do so. I also thought it would be nice to have a co-admin for these cases. If anybody volunteers, why not. Kind regards, Sven ___ 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] Jenkins tutorial
Hi, now that we have our continuous integration server Jenkins for babl, GEGL and GIMP at an easy memorable address (https://build.gimp.org) I'm going to write a tutorial for developers and testers on how to use it. Are there any particular questions you want to have answered there? Kind regards, Sven (Yes I know, cross-posting is bad. I did it anyway because I think not all GIMP people will be on the GEGL dev. list and vice versa.) ___ 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] Changes in continuous integration server
Hi, our continuous integration server Jenkins has got a new address. You can now access it via https://build.gimp.org. Please update your bookmarks. I'd like to thank Cameron Gregory, Andrea Veri and Mitch for their efforts and contributions. If you face trouble with the new address, feel free to let me know. Greetings, Sven ___ 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] Changes in developer websites
Hi, the last weeks I've spent with changes to our developer websites. I've integrated most of the contents from developer.gimp.org into our [developer wiki]. The main reason is to have all developer related information in one single place to ease finding the right information and let new contributors get started quicklier. In the wiki you find much contributor related information, such as - the roadmap with our plans for the near future, - build tutorials, - a developer FAQ, - the GEGL and GIO porting matrices, - a brand new developer glossary and more... It was collected and written down by many contributors over the time. The glossary I mentioned last shall collect all terms we developers need to know about functional requirements, computer graphics, color science, babl and GEGL. I've come a long way with it, but surely there will be the one or another point missing. So, if you find something missing or in need of correction, feel free to tell us. Elle Stone and and me are looking forward for your input! I'd like to thank all who helped me collecting and writing it down, spread the word and gave feedback. Thirdly from now on you can also report bugs in the wiki (about wrong content etc.) In Bugzilla choose product:=gimp-web and component:=wiki.gimp.org. Last but not least I have some more ideas on how to make the wiki a useful central point of information for all contributors. I've collected them here: http://wiki.gimp.org/index.php/Mindstorm:Rethinking_the_wiki We can discuss them from now on and realize the good parts after the LGM. Thank you in advance for your feedback and ideas. Kind regards, Sven [developer wiki]: http://wiki.gimp.org/index.php/Main_Page ___ 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 does it work?
Hi, I think you find many answers to your questions in the [GEGL code], which is GIMP's backend graphics library. Some other image processing parts are in the [GIMP code]. There the directories 'modules', 'plug-ins', 'libgimp*', 'devel-docs' look like the right places for you to look at. If you have questions about the technical architecture of GIMP: one of the next points on my todo list is the software architecture documentation of GIMP. Questions are welcome, so I'll get a notion what other developers are interested in. Kind regards, Sven [GEGL code]: www.gegl.org https://git.gnome.org/browse/gegl [GIMP code] https://git.gnome.org/browse/gimp/tree/?h=gimp-2-8 ___ 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] Google Summer of Code 2014
Hi, looking at the [timeline] the Google Summer of Code (GSoC) 2014 starts in a week on 03.02.2014. GIMP has often participated in the last years and had a lot of ambitious contributions. Some thoughts pop up to my mind: 1) Do we want to participate this year, again? 2) If yes, which programming tasks do we want to offer? In my opinion, we should stick with the GEGL/OpenCL ports and integration of the results of former GSoC projects. Yes, it might sound boring, but on the other hand the GEGL and OpenCL ports have been our high priority for many years and there's still something to do, see the [GEGL Porting Matrix]. Unfortunately former GSoC contributions haven't made it into the code yet and we would do not only us a big favour if the work got finished. 3) Who is willing and capable to mentor and organize (did I forget a task)? Perhaps we should distribute the workload on more shoulders this year? Speaking for myself I would be overallocated with mentoring, but I think I can do some lightweight supporting jobs i.e. preparing the wiki like in 2013 or answering students questions. Especially the latter could also give us some hints on what new developers need to get started, so the results would last longer than a summer. 4) What can we learn from the former GSoCs: what have we done well, what could be improved? Kind regards, Sven [timeline]: http://www.google-melange.com/gsoc/events/google/gsoc2014 [GEGL Porting Matrix]: http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL ___ 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
Hi people, look what I found in the former Google Summer of Code ideas: http://wiki.gimp.org/index.php/Hacking:GSoC/Future/Ideas#Make_menus_searchable I think it could perhaps shed some light about the Action Search Tools purpose and further treatment, at least it's an attempt. Kind regards, Sven ___ 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 2.8
On 24.1.2014 at 11:06 AM Owen wrote:> Krita has a plug in that uses huggin and in my view easier to use. That's interesting. What does a sketching and painting application as Krita is do with a stitching plug-in? Anyway it would be nice to read more about it but my searches had no success. Where can I find more information about it? For stitching I can recommened Microsoft's [Image Composite Editor]. Although it's not FOSS software it's free of charge and I find it easy to use. In the FOSS department also [Digikam] has stitching capabilities by Hugin. Kind regards, Sven [Image Composite Editor]: https://research.microsoft.com/en-us/um/redmond/groups/ivm/ICE/ [Digikam]: http://www.digikam.org/node/669 ___ 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] Enhancement request for .cur cursor files
On 19.1.2014 at 9:15 PM Joao S. O. Bueno wrote: Are there more bug reports asking for the same thing? (/me shyes away of dealing with bugzilla) - so this would be a duplicate? No, it's no duplicate. Kind regards, Sven ___ 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
Hi, thank you for your replies. I thought by myself it could be of value to summarize the former discussions here and in IRC etc. to give all the people involved the same state of knowledge. But doing this would take some time and require to have less time for other tasks on my todo list (Wiki, Jenkins, techdoc and real life (what was that, again? ;-)). I guess I could get it done by the end of the week. Is there a need on your sides or do you all (at least Peter, Srihari and Jehan) already know it? Kind regards, Sven ___ 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
