[Gimp-developer] GIMP Developer Meeting
Hello, Due to my very unfortunate series of monday's in which I can't arrange a meeting, and due to the fact that some developers where on vacation, there wasn't any serious developer meeting in the last month except for the one in which GSoC mentors did some stuff regarding that. Since I'm having trouble keeping up with all development to collect topics for a meeting myself (and now I also have a GSoC which eats up more of my free time), and since I want to avoid meetings with no content, I'm emailing the list for a thread to discuss ideas. I will organize a meeting when there are enough ideas / enough time passed with no meeting (enough is a flexible thing). Throwing ideas that should be discussed: - GSoC students - Basic guidance on how to handle branches? When to push, where, etc. More important is getting them all with git access (for me it took 1 month to get, so it should be organized now in order not to stall real work...) - Plans for a new website - I know it was discussed, but I don't remember any decision. Major parts of the site need updating, including the tutorials section. - More? Thanks, LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting]
Hello, Theoretically, it should be possible to move the dev meeting and the gsoc meeting. I took a look at the world clock and the developer map, and it should be possible to move the meeting to 17:00 GMT. The places that will suffer from that decision are Canda and Brazil that will have a meeting starting on the morning, but it seems to be as if indeed most dead hours will be over the ocean. However, since I don't know who should attend the GSoC meeting, I'm not sure if we can move it that quickly. I'm trying to catch people on IRC now (I pinged the relevant people in the last 15 minutes), if anyone can tell me who should attend, I'll try making the arrangements. Regarding the developer meeting, I think that moving it should also be feasible - but again let's try to talk this on IRC in a time in which everyone are awake (such as now!). ~LightningIsMyName On Mon, Apr 18, 2011 at 10:42 AM, Alexia Death alexiade...@gmail.com wrote: On Monday, April 18, 2011 05:05:10 Mukund Sivaraman wrote: Sorry, the scheduled time is not fine for me. I had asked for this to be changed on IRC, but nothing was done for the last meeting's time too. The previous meetings have happened at around 1:30 AM localtime and 2:00 AM localtime. As there's a rather large Pacific ocean, there must certainly be a suitable time for this meeting that doesn't occur during the middle of anyone's sleeping hours. :) CET people can do 3 hours earlyer(17:00 GMT) at most I think, because that would put it at 19:00 - 20:00 CET(with dailight savings) and between 18:00-19:00 a lot of people are moving between their jobs and home. Doing the meeting in the middle of a workday is probably not feasible... For me personally in EET+dailight savings earlier is fine, but its up to CET and GMT people. --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting
Hello, The next GIMP Developer Meeting (#4) was scheduled for this week on tuesday, April 19th 2011 on 20:00 UTC. For time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?msg=GIMP+Developer+Meeting+%234iso=20110419T20 As usual, the meeting will take place on #gimp-devel Developers who mentor at GSoC or any other person who has something to do with GSoC administration, should come 20 minutes earlier (a room for that will be announced on #gimp on that time) to finalize the GSoC applications and finish the process of GSoC student application. This is important! The agenda for this meeting isn't yet well defined - basically it's just discussing 2.8. The meeting page can be found on http://wiki.gimp.org/index.php/Hacking:Dev_Meeting_19_Apr_2011 Finally, due to request of some people, there is now a GIMP Developer Calander. For an online view in gmt/utc time, use the following link: https://www.google.com/calendar/embed?src=gj9trunel7ik41rhev111knfao%40group.calendar.google.comctz=Etc%2FGMT The ICS file for the calendar is available at https://www.google.com/calendar/ical/gj9trunel7ik41rhev111knfao%40group.calendar.google.com/public/basic.ics ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Developer Meeting #4
Hello, The next GIMP Developer Meeting will probably take place in the GIMP IRC on April 11th 2011, 20:00 UTC (For time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?iso=20110411T20). I'm very busy and have no time to set up a meeting page on the wiki and/or arrange it. If some dev wants to take control of this one, I'll more than appriciate it. I'll try to attend the meeting tomorrow, but I can't promise... Sorry for the short alert :( LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
Hello, no organized meeting log this time, for various reasons, however I'm attaching below the list of decided actions in the meeting, along with some other off-topic points that were discussed: ** GSoC Student Applications ** Core developers sign up as mentors (for GSoC) schumaml: Write mail about application is open, and required skills, and required code example ** Re-Discussing GIMP's programming language ** For core (non-UI), continue using GObject, use code generators (such as turbine) and do copy/paste/replace for existing GObject classes (for the rare case where the generator won't be enough). For UI, porting widgets to GtkBuilder is an option (and then we'll use Glade and UI xml files), but any action on the UI is postponed until we get 3.0 out! ** Default JPEG Quality (quickie, not a real topic) ** Change to 95 2x1, and add a hack to save defaults (using something like the PNG plugin does, or something more elegant). Note that a decent system to save plugin defaults, along with other api changes, is not something that will happen for 2.8. ** bringing UI crew to LGM ** Will be discussed with mitch and schumaml on the financial aspect (using gimp funds) when the team is fully assembled (parts of it are already assembled - hurray for guiguru and congrats for the new team memebers!) ** Resource management for 2.8 ** One member of the new UI team (lead by guiguru) will take care of that ** Offtopic ** Seems as if most GIMP team can't attend LGM this year, but there may be a GIMP village in the Chaos Communication Camp (http://events.ccc.de/2010/08/10/chaos-communication-camp-2011/) as most developers want/plan to attend it. UI team members will start hanging on IRC once the team is assembled. Many developers suggested help in setting them up with build environments and every other thing they need. This will happen soon, so be nice to the new guys ;) ~LightningIsMyname ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
Hello On Mon, Mar 28, 2011 at 6:27 PM, Kevin Cozens ke...@ve3syb.ca wrote: It's a good thing I asked that we clarify the problem as I was thinking it was something else entirely. Pointers to a couple of files that show the issue of a lot of boilerplate code would be good so we can all see the extent of the problem. If the problem really is with gObject and the need for a lot of boilerplate code there are several options. ... 3. Create template file(s) with all the typical boilerplate code. If people are copying from existing files it might be easier to just create some template files that can be used as the starting point. 4. Write a program to generate the boilerplate code. If template files could not be made to handle the typical use cases, a program could be made where a person could answer questions or set options and have it generate a file with all the required boilerplate code. 5. Use a chanting system similar to what is used in BABL and GEGL. The chanting system in BABL/GEGL seems to work well in that it makes it easy (or easier) to work with things like the GEGL operation files without the need for a deep understanding of gObject. As one of the supporters for the Vala suggestion, I am willing to give up the vala option, for options 4 and 5 (3 is sort of what many of us already do - copy paste). I don't know how easy is option 5 to write, but option 4 does seem more or less possible. also, the fact is that most work with gobject code is writing it in the first time, so I do think that a generate once tool would solve my problem. Again, I'm speaking just for myself. We have a meeting today, and we can *try* and sort this out then. I do agree that introducing another language isn't such a good idea, and what Simon showed doesn't increase my trust in vala (even if I like that language)... ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
Hello, The next GIMP Developer Meeting will take place in the GIMP IRC on March 28th 2011, 10:00 PM CET (For time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?month=3day=28year=2011hour=22min=0sec=0p1=48). Thee meeting page is up and running on http://gimp-wiki.who.ee/index.php/Hacking:Dev_Meeting_28_Mar_2011 Our agenda is quite small this time, so unless someone has more topics, it will be really short this time :) *** GSoC Student Applications *** Official GSoC applications should start coming in on march 28 19:00 utc - that's 2 hours before the meeting should begin. Also, we already have student applications on the mailing list. Some suggestions were made on putting minimal student requirements (not sure how practical this is) and some suggested creating some quick start guides for new developers. Do we want to do anything to get students started? BTW, such content should be placed on the developer wiki! Also regarding GSoC, not sure really which rating of ideas should happen, by whom and when, but discussing it should be done or decided on. For obvious reason, the writer of these lines (who applies for GSoC himself) will not participate in that part of the discussion. *** Optional topic: Re-Discussing GIMP's programming language *** Some developers that weren't present in the last meeting, highly disagree on the attempt to introduce vala into gimp, claiming that it will scare off developers (more than the simple C GObject code). Discuss! *** Other topics *** Any other suggestions should be suggested by replying to this email, or adding it directly to the wiki (if you have permissions to edit the wiki). See you there, LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
Hi, On Wed, Mar 23, 2011 at 8:32 AM, Alexia Death alexiade...@gmail.com wrote: Kevin, cloning was kicked, because welding pixel manipulation code on old paint core is not a good idea, new pixel manipulation should go in gegl and we simply dont have the infrastructure to use that in paint core yet. The name cloning is misleading - this tool has nothing to do with regular paint tools. if it reminds anything by interaction, it's the cage tool - you select a shape, move it around (hopefully with a live preview of what will happen if you drop it there) and then release when satisfied. Please see the demo video if you want to see what I mean - it's on the article page. I'm restoring this idea to the wiki's recommended list. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSoC application - Adaptive Image Cloning
Hello, My name is Barak Itkin (sometimes known on the web as LightningIsMyName), I'm a third year student for computer science at the Tel-Aviv University (Israel), and I'm a regular visitor of the GIMP irc and mailing lists. I'd like to apply for a GIMP GSoC for the Adaptive Image Cloning (aka Seamless Cloning). Past expirience: - Made several contributions to GIMP already, mainly on the plugin side (script-fu scripts, and wrote the new PDF plugin), but also made several to the core (support for multi-colored text in 2.7 was partially written by me) - Contributed several GEGL operations for existing GIMP plugins - More than two years of practical expirience in C - Good background in image processing and computer graphics - In terms of large code, my biggest projects was a ray tracer (4k lines) Thanks, Barak Itkin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Developer Meeting #2 - March 14th 2011
Hello, The next GIMP developer meeting (users are also welcome!) will take place Monday, March 14th 2011, on 10:00 PM CET (GMT+1). The agenda can be found here: http://gimp-wiki.who.ee/index.php/Hacking:Dev_Meeting_14_Mar_2011 Right now, the main topics are: * Reviewing last meeting's decision * Serious discussion of GIMP's programming language * 2.8 - Get it out! Proposals for more topics to discuss will be accepted by replying to this email. The meeting will be in the same place as the previous time (gathering will be done on the GIMP irc irc://irc.gimp.org/#gimp and the actual meeting will take place in a seperate channel that will be announced on the main channel), at the same good hour :) Logs and summaries of the previous meeting can be found here: http://gimp-wiki.who.ee/index.php/Hacking:Dev_Meeting_28_Feb_2011 ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
Hi, Glad to hear a school is considering using GIMP - when I learned in school they tried only photoshop ad other commercial stuff. *The* reference is the official documentation, which is very very detailed as a reference - http://docs.gimp.org/ The tutorials for image retouching (and other stuff), on the main website, should provide a very good basis - http://www.gimp.org/tutorials/ I know that in the past (before I started using GIMP) Grokking the GIMP was considered a very good book on GIMP, and the good part is that it's available online! http://gimp-savvy.com/BOOK/index.html Many of the screenshots are outdated, and the ui changed a bit, but as a reference for how to do things, it can be great. Now, if we want more modern stuff (since some of the things above are outdated(, that children will consider cool, I'd try any of the many tutorial sites on the web, for tutorials about specific effects. I started with gimpusers - http://www.gimpusers.com/tutorials and GimpTalk http://www.gimptalk.com/forum/ GimpTalk was (and probably is) the biggest GIMP forum on the web, it has more resources than you can imagine. it may require lots of filtering, but it has some high quality tutorials. If you need anything specific, feel free to ask on here (or better, on the the gimp-users mailing list - see http://www.gimp.org/mail_lists.html), or on the GIMP chat (see http://www.gimp.org/irc). Good luck! ~LightningIsMyName On Mon, Mar 7, 2011 at 10:34 PM, Debi Rapson drap...@mansd.org wrote: Our school system appears to be headed for using GIMP as a way of teaching our students about graphics. Can you point me in the direction of where I would go to get GOOD tutorial information about GIMP so that I can properly teach it? Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation. We are trying to give our kids real-world skills and we need to be able to point to real places that are using GIMP for photo retouching and graphics resolution. If I am going to teach using this software I need as much ammunition as possible to make this seem exciting and something that the kids will WANT to learn to use. Thank you. Debi Rapson Memorial High School Art Technology Dept 603-624-6378 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP developer meeting
Hi, 2011/3/6 Łukasz Czerwiński lc277...@students.mimuw.edu.pl: On Tue, Mar 1, 2011 at 00:22, LightningIsMyName lightningismyn...@gmail.com wrote: 1. schumaml and LightningIsMyName fix wgo? Could you explain me what wgo means? See http://lightningismyname.blogspot.com/2011/03/first-gimp-developer-meeting-success.html for a detailed explanations on all the conclusions. Basically, wgo is Wilber GIMP Org, or basically the gimp main website. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
Hello, The nearly finalised project list for GSoC 2011 is available at the wiki: http://gimp-wiki.who.ee/index.php/Hacking:GSoC_2011/Ideas Users who have a comment on the list should raise it now. The ideas list was divided in to two parts, as discussed on IRC. Developers who wish to make small corrections should feel free to do so, but please do not move projects between the lists / add/remove projects or do any other major change without a discussion first. GIMP on! ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP developer meeting
Hi, On Mon, Feb 28, 2011 at 8:40 AM, Akkana Peck akk...@shallowsky.com wrote: Any chance you can keep a log of the meeting? I'd love to know what happens, but I'll be traveling then. Thanks! ...Akkana I'll suggest public logging at the begining of the meeting (since we shouldn't log without general aproovement) - it should indeed benefit many devs. If there will be no public logging, I'll send you a private copy of my logs and/or a summary ;) On Mon, Feb 28, 2011 at 9:53 AM, Martin Nordholts ense...@gmail.com wrote: Good initiative. I'd like to add to the agenda: - Create a roadmap at http://gimp-wiki.who.ee/ - Make http://gimp-wiki.who.ee/ the official wiki, e.g. make wiki.gimp.org point to it Added to the the agenda - mine was just a partial suggestion :) I'll try to update my blog post with a public agenda (http://lightningismyname.blogspot.com/2011/02/gimp-developer-meeting.html), and I'll upload a summary to http://gimp-wiki.who.ee/. Btw, Alexia said on IRC that she can't point a domain at that adress so we really should get wiki.gimp.org running or pay for some web server with the GIMP funds. There is a nice chance that my university will let me host the wiki - I'll meet the system guy later today and see if we can point wiki.gimp.org there. If so, I'll migrate Alexia's wiki to there, and we'll have a wiki running up as long as I'm a student (should be another year, which should be enough to get wiki.gimp.org running). ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP developer meeting
Hello, The first meeting took place and it seems to be a success :) The agenda, decided actions and log can be found on the soon-to-be-official wiki at http://gimp-wiki.who.ee/index.php/Hacking:Dev_Meeting_28_Feb_2011 A summary of the decided actions: 1. schumaml and LightningIsMyName fix wgo? 2. Alexia and mitch take care of redirecting wiki.gimp.org 3. Enselic makes a draft of a GIMP roadmap and sends to gimp-developer 4. everybody subscribe to bug mail and TRIAGE BUGS 5. mitch, make a development release soon 6. LightningIsMyName takes care of next meeting 7. setting pages on the wiki to discuss changes in different topics 8. LightningIsMyName gets a list of projects on the wiki by tomorrow, developers review the ideas by email or by commenting on the wiki. Saturday (February 5th, 2011) is hard dead line for finalizing the project list! (I'll try, it make another day though) 9. all devs PM/Email LightningIsMyName username and email for their wiki account Next meeting shall be on March 14, 10:00 PM, CET (GMT+1). A mail about the agenda for the next meeting will be sent several days before the next meeting. Happy GIMPing and see you next time! ~LightningIsMyName On Mon, Feb 28, 2011 at 1:07 AM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello, After the slow development that I and some other developers feel, because of lack of plans, we decided to try and schedule a planned IRC meeting. Today (February 28, 2011), at 10pm CET (for time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?month=2day=28year=2011hour=22min=0sec=0p1=48 ) a meeting of GIMP developers is scheduled on the GIMP developer IRC. On the list of topics: - GSoC 2011 - ORG Application deadline is in 11 days! - Bug fixing priorities - Future development? If you want to discuss GIMP's future, GSoC this year, and just listen, please come. We will meet on irc://irc.gimp.org/#gimp (Users without IRC client can connect using one of the many online IRC clients (such as this one: http://mibbit.com/?channel=%23gimpserver=irc.gimp.org ) Hope to see you, ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP developer meeting
Hello, After the slow development that I and some other developers feel, because of lack of plans, we decided to try and schedule a planned IRC meeting. Today (February 28, 2011), at 10pm CET (for time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?month=2day=28year=2011hour=22min=0sec=0p1=48 ) a meeting of GIMP developers is scheduled on the GIMP developer IRC. On the list of topics: - GSoC 2011 - ORG Application deadline is in 11 days! - Bug fixing priorities - Future development? If you want to discuss GIMP's future, GSoC this year, and just listen, please come. We will meet on irc://irc.gimp.org/#gimp (Users without IRC client can connect using one of the many online IRC clients (such as this one: http://mibbit.com/?channel=%23gimpserver=irc.gimp.org ) Hope to see you, ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP developer meeting
Hi On Mon, Feb 28, 2011 at 1:16 AM, Joao S. O. Bueno gwid...@mpc.com.br wrote: SOrry pal -- this time table does not list CET time. Can you tell me it in the difference to GMT? The time table shows that hour in many cities, and CET stands for centeral europe timezone :) It's GMT+1 ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIT access no longer working
Hi, On Mon, Feb 21, 2011 at 4:33 PM, Ofnuts ofn...@laposte.net wrote: My local copy of the Gimp code used to be updatable by issuing a git update in the root directory.. This no longer work and I get: ... I'm not too familiar with Git. Am I doing something wrong? Or has something changed elsewhere? I'm not a git wizard myself, but cloning here (using git clone) and updating (using git pull) does work for me. I have no idea what about the config file - it means nothing to me :P You did say you use git update in the root directory to update the sources, and I'm not familiar with such a command. Did you possibly mean git pull? ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
I'm starting this thread to list ideas for Google Summer of Code 2011, for the GIMP project. Since in the last year collecting ideas was done partially by the mailing list, let's try it again this year and keep most ideas here. One should aslo take a look at GEGL's page about contributing (too bad GIMP doesn't have something like that): http://gegl.org/contribute.html Here is a list of ideas from 2010, that are still not implemented, and *may* be relevant. -- -- JavaScript scripting in the core and/or plug-ins - using GNOME Java Script infrastructure (GJS) GIMP scripts and plug-ins can be written in Scheme, Perl, Python and C. Scheme is always available, but limited in its application in regard on image manipulation. Additionally, as a list-processing language, it may appear as weird to most users. Its main purpose is scripting workflows for repetitive work. The Perl binding is currently the least supported one and not available on platforms other than Unix. The Python binding and the C libraries are current the most powerful ones. Javascript could take over Scheme's role as the genreral purpose scripting language for GIMP. [Note]: At least for scheme, there are no debuggers for scripting in GIMP, and only tracing is supported. It would be neat if as a part of this project, a javascript debugger will be integrated so scripts could be debugged in a sane way. Again, this is not a part of the original project suggestion (as suggested last year), but this is something that could be helpful. -- -- Make menus searchable ... i.e. have a textbox, in te menu for example, and anything typed will be matched against all menu items and their blurbs and maybe something more (like procedures not registered in menus). -- -- Implement the free transform tool For exact specifications, see: http://gui.gimp.org/index.php/Transformation_tool_specification (may be offline at the moment) -- -- Replace the GimpSizeEntry widget Right now both the code and the UI is a mess. The unit should for example be in the text entry itself instead of in a combo box -- -- Brush selector wigdet More precisely one that is also capable for brush transform input (size/angle/aspect ratio). -- -- Slicing tool One of the most requested features by web designers and/or interface designers, is the addition of a slice tool. Currently slicing images inside GIMP can only be done in grids (using guides and the guillotine action) and you can't split just one rectangle in the middle. For example, the following slice can not be achieved: --- ||| ||| ||| ||| -|| ||| --- -- -- Porting GIMP plugins to GEGL operations There are many many GIMP plugins that would need eventually to be converted to GEGL operations, if we want to use them in future versions of GIMP. Now, I'll throw in a first idea myself: -- -- Adaptive Image Cloning (aka Semaless Cloning) Direct cloning of parts from one image to another, usually ends in bad results because of different lighting conditions and other settings (such as white-balance) which causes the color of the cloned part not to match the source image and look out of place. There are some techniques to solve this, by using poisson equations and some other methods. It differes from the existing heal tool, since it is meant for taking one area from an image, and paste it smoothly in some other area. The current algorithm implemented by the healing tool allows to remove local irregularities (such as dots, hairs, etc.) very well, but experiments of using it to do adaptive cloning of areas (for example copying a person from one image to the other) do not produce good results. (It should be said that I'm a bit biased torwards this idea, because I want to work on it as a student in GSoC and I already collected papers about it. Still, I'd like a lot to see somthing like this in GIMP, no matter who implements it) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Error compiling GIT version
Hi, I know that there were some changes in gegl lately, changes that as far as I know are only present in git (and I do remember someone with the same error on the gipm chat channel). The build works perfectly for me when using the latest version of gegl from git, try it - it should work :) ~LightningIsMyName On Sun, Nov 7, 2010 at 8:02 PM, Ofnuts ofn...@laposte.net wrote: Fairly new at all this, but managed to - git-clone the repository (should give me the latest and greatest (yes, unstable, but that's understood)?) - run autogen.sh and install the various dependencies - at last, running make But, then after some amount of time and much console activity (that let me assume that my setup is OK) I get: gimpoperationcagecoefcalc.c:23:34: error: gegl-buffer-iterator.h: No such file or directory And this file is indeed not part of the headers I got when I built/installed gegl-0.1.2 (from tjhe gtk.org repository). Do I need an even more recent version of GEGL (but autogen.sh looked happy with 0.1.2), and if so, where do I get it from? -- Ofnuts, in very rainy Paris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] menu back in the toolbox
Hello, I have replied to your bug comment before seeing this email - sorry :P I suggested a solution to your use case there in my comment (please read it first), and I'll add some more detail here: You say that we Enforce the UI changes on the users, and as a matter of fact you are right. BUT, think on the other side: If every program would have an option to get back it's old UI, it will have 3 problems: 1. Users will keep using the old UI they are used to, and they will possibly miss the new features of the new UI that make it better. This will make UI development a waste of time since people will also teach new users to use the old UI... 2. It requires lots of work to keep several UI options available - if we do this for every UI change, it will result in many code that will just be there for compatiability without doing anything more useful. 3. You have to draw the line sometimes. Every program does UI changes as it evolves, as a part of it's vision. Even blender which you mentioned made a massive change between 2.4 and 2.5, and no, they have no option to use the old UI again. Each program has a UI designed for it's special case, so saying Blender has it does not matter since blender is used for a completly different purpose - If you'll show something like this in some 2D app which matches GIMP's product vision (see http://gui.gimp.org/) it may be more relevant. I'm very glad to see the discussion here since we are recieving feedback in the right place - and we need user feedback. But unless you show some clear case, WHICH IS SUITING THE PRODUCT VISION, where the new UI is a problem, I don't see any reason to change back. I'm more than open to see specific cases (which I did not already answer in the bug report) in which the new UI is a problem. If you will find some critical cases in which the new UI is worse than the old - we will consider undoing the change :) But please do note the word critical which I used - just saying I'm used to the old way/it's more comfortable in case XXX (where XXX is a very rare case) is not enough. As far as it may sounds anoying, the program will not be tailor-made to match your useage of it - it will made to be useful to the biggest amount of target users it can, even if it leave some few unfortunate users in a less comfortable situation. For example, I find the new UI very comfortable and more intuitive - and it just shows that not all users agree. So, please find some critical user-case in which the new UI is problomatic, or contribute a patch that allows choosing between the two UI's. If such a patch will be present, and if it is elegant enough, there are higher chances of it being implemented. Happy GIMPing :) ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting the ID of a nested layer on GIMP 2.7.1
Hello, Try gimp_item_is_group to check if a layer is a group layer, Then you can use gimp_item_get_children (on the group layers) to get the children by their order (topmost to bottomost). Finally, you can use gimp_item_get_parent to get the parent layerof a layer inside a layer group. Note - these function are not present in GIMP 2.7.1, you'll need to get the latest source and build it to gain access to these functions (they are documented there like the rest of the PDB functions). ~LightningIsMyName On Fri, Oct 15, 2010 at 1:19 PM, Gino D ginodo...@gmail.com wrote: Hi. Correct me if I'm wrong, but I have seemed to notice that the gimp-image-get-layers procedure, when running on GIMP 2.7.1, doesn't return the identifiers of the layers nested within groups, while yielding the ones of unattached layers and layer groups. So, how may such identifiers be obtained? Is there any procedure/stratagem for this purpose? Thanks in advance. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths.
Hello, On Thu, Sep 9, 2010 at 1:13 PM, Mirza Husadzic mirza.husad...@gmail.com wrote: \ The paths are not imported/merged properly where SVG image is generated correctly (probably by 'librsvg'?). GIMP imports path itself using it's own functions - the reason is that it can only handle bezier/polygonal strokes (so other elements are converted to bezier/poloygons). Pretty sure that it's not related to librsvg... The Blender's 'uv.py' exporter script had generated uv's layout as SVG polygons as follows (note that polygon is a quad): polygon fill=rgb(204, 204, 204) fill-opacity=0.5 stroke=black stroke-width=1px points=67.334,493.895 77.587,494.896 78.033,463.871 67.768,463.723 / This was imported perfectly for me, if it still fails to you, maybe you should filla bug report (Try validation your svg first using the svg validator - http://validator.w3.org/ ). As a result, I got more of the paths lines imported and merged into GIMP, but there is a strange drawback. The path is not so big, i.e. (few hundred points) but the GIMP is really slow at redrawing path (i.e. when painting with brush). I also found that if you copy the same path and show them both, nothing is displayed? Maybe this is a cause of that all paths are not displayed because some of them are overlapping, as the polygons are uv's and they overlaps. GIMP renders path in XOR painting mode for the sake of visibility (XOR mode is usually easily visible on most possible backgrounds). As a result, when drawing two paths one above the other, you won't see any of them since pixel XOR path XOR path = pixel. Getting rid of XOR drawing and find something better is on the todo list =) Why is GIMP so slow at rendering paths. Is it using 'cairo' or 'gdi' to render paths? GIMP uses gdk for drawing (as far as I remember) indeed, but I have no idea about the preformance issues. I do know that drawing paths is indeed a bit slow, but I have no numbers of what should/shouldn't be normal... Don't forget that blender uses OpenGL for it's drawing, and this is obviously faster than software only solutions... This should be targeted again possibly when the canvas drawing will be ported to cairo (on the todo list for 2.8). p.s. I think that SVG parsing should be done by 'librsvg', which should then expose even basic API to get only points of basic primitives, such as lines, polys, curves etc. In such case GIMP will be concentrated only to render them as path into its context. GIMP is not meant for vector graphics, and therefore I believe that importing paths as is from svg is enough. Furthermore, since librsvg is a hard dependancy of GIMP, any plugin can link against librsvg and know that it will be available. If you believe differently, you are more than welcome to describe this idea in more detail with some user-cases (and hopefully with a patch =]) so that it will be considered again. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Wish: A better animation system inside GIMP
Hello, Currently, creating animations in GIMP is not done in a very clean way. To specify the duration of each frame and to specify whether it should stay or be hidden after that period, we abuse the layer names. Until recently we also had a limit of one layer per frame so we couldn't have had a frame composed out of several layers (so maintaining the frames had to be done in other files), but now layer groups can solve this (so the animation process is now a bit better). I'm posting here a small wishlist regarding using GIMP for animations, to get the general approval before posting it as an enhancement request in bugzilla: * More supported frame disposal modes - GIF has 3 frame disposal modes (taken from http://www.webreference.com/content/studio/disposal.html ): 1. Leave - after the period of the frame has ended, the frame's pixels will remain visible and the next frames will be displayed on top of it. This mode IS supported in GIMP. 2. Restore Previous - after the period of the frame has ended, the frame's pixels will become transparent and will allow to see what was in that region before the current frame covered it. This mode IS supported in GIMP. 3. Restore Background - after the period of the frame has ended, the rectangle of that frame will be replaced by a transparent rectangle. It's similar to Restore Previous, except for the fact that after the frame disappears you won't be able to see what was below it. This mode IS NOT supported in GIMP, and this is the mode I want to add. Supporting this mode means modifying the gif load/save plugin, the animation preview plugin and possibly the un/optimize plugins. * A better animation editing modes. Abusing the layer modes is a very bad way to do this (at least in my opinion) - see a similar case in https://bugzilla.gnome.org/show_bug.cgi?id=344910 comment 3. We should remember the animation parameters using parasites, and by having some animation editor plugin (which leads to my next point - an animation editor) * GIMP should have an animation editor which is integrated with a preview of the animation. Editing the animation and then closing the editor just to open the preview plugin is a very bad workflow. You should be able to preview from the same place you edit. Also, the editor should allow to edit the parasites of the layers which include the animation parameter. I have something in mind similar to MS Gif Animator (http://en.wikipedia.org/wiki/Microsoft_GIF_Animator), or anything with a similar simple UI. This is how I imagine the animation workflow with GIMP - I'll appreciate some feedback. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wish: A better animation system inside GIMP
Hello, Forgot to mention that it would also require to change most animation scripts and GAP... On Sun, Aug 29, 2010 at 10:15 AM, Olivier oleca...@gmail.com wrote: You seem to be interested only in animated GIF? Even in this case, are you aware of the GIMP Animation Package? Olivier Lecarme First of all, yes - I am aware of GAP and I used it several times (although I'm still not completely familiar with it). Still, abusing layer names must stop and this is my main request - and in order to stop this we must introduce a very simple animation editor (since we have many animation scripts and it should be possible to edit their result). GAP is very good and complicated, and I'm referring to something much simpler only to edit the frame duration/disposal (instead of the ugly layer name hack) - nothing more. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Another set of feature-wishes regarding Guides
Hello, On Sat, Aug 7, 2010 at 8:07 PM, Tobias Ellinghaus h...@gmx.de wrote: Am Samstag, 7. August 2010 schrub oli...@first.in-berlin.de: it is possible to make guides invisible/visible and to make them magnetic/nonmagnetic. Both features are independent, which is good for some situations. To make them invisible as well as non-magnetic at the same time, two check boxes must be enabled/disabled. The possibility to make both with one click would be fine: visible magnetic / invisible non-magnetic. I don't have an installed GIMP around so I cannot test it: are invisible guides magnetic? If not then your request is void as making them invisible will also make them non-magnetic. If yes then that sounds (at least to me) like a bug/design flaw. I actually use invisible guides quite a lot - especially when designing things like website layouts - I want to snap to the layout's rectangles after I drew them, but I don't won't them to clutter my view (especially since in some situations you can have quite a lot of guides) There are many more cases in which invisible magnetic guides can be useful - usually these situations involve many guides where it's visible directly on the drawing itself where the lines are. The fact that snapping and visibility are independent is very useful, and I do wish to keep it this way. If the two clicks really bother some people, I suggest assigning a short-cut key to both features to do this quickly. But, Since I agree it can be confusing, I suggest that when hiding guides which are still magnetic, a message will be displayed in the status-bar at the bottom of the image saying something like Note that the guides are hidden but still used for snapping. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Unsubcribe my ID from the list
Hello, On Thu, Aug 19, 2010 at 2:08 PM, sanju More sanjee...@inetfi.com wrote: Hi, How to unsubcribe my ID from this mailing list --Sanjeev You can unsubscribe in the mailing list page - https://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ~ LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability of menus (search, gegl ops, ...)
Hello, On Tue, Aug 10, 2010 at 9:27 AM, Martin Nordholts ense...@gmail.com wrote: 2. We need to define a usable plugin browser. One of the features I'm missing the most, is a preview image. Plugins should have an option to register a preview image of their effect (probably by having the image's binary data embedded in them). This also relates to the feature request of having a logo script browser... I don't think registering a fixed preview image is good enough, it Believe me, I really want a dynamic preview on the current image :-) But, it's not practical as some plugins take way too long to operate - trying to create a preview on the current image might take way too long to be any good. On Tue, Aug 10, 2010 at 3:31 AM, David Gowers 00a...@gmail.com wrote: On Tue, Aug 10, 2010 at 6:21 AM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello, I recently re-read all the GSoC suggestions for 2010, and I found this interesting one about making the menus searchable: https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility As far as I know, menus are searchable and the best example is the keyboard shortcuts dialog which has a searchbox to find the GIMP action you'd like to use. However, that action is not immediately activateable. What I personally envision is something like the completion dialog that you can find in GTKTreeViews (for example, typing something in when the file list in a file selection dialog is focused, offers you a choice of the possible items. And upon selection from that sub-list, the file is immediately chosen.) So I asked on #gimp and I was told there was a discussion on IRC about finding a more usable replacement to the plugin browser. The reason I made the description above is that the plugin browser is very limited.. you cannot activate non-plugin menu items (for example, I'd like to be able to access 'scale image' and 'scale layer' via a search -- I don't use them enough to warrant keyboard shortcuts, but enough that some acceleration is warranted. The same thing goes for virtually all GIMP-GAP operations). Sorry for my bad phrasing of the question - let me rephrase it: what is left other than exposing the searchbox from there? The searchbox there allows to find non-plugin actions, and these are very neatly organized under several categories. When you search, the categories are already expanded so you can see all the results, organized, right away. On Tue, Aug 10, 2010 at 3:31 AM, David Gowers 00a...@gmail.com wrote: request of having a logo script browser... Well, if we did what you outline here, how would Script-Fu scripts handle the necessary embedding of binary data (I don't mean to imply that they couldn't, just that I do not know exactly how well they can handle this kind of binary string literal). What I suggest, it is possible to embed binary data in script-fu scripts, but it's not easy/fun/simple. What I suggest is that as a part of the refactoring process of the plugin system, we will allow procedures to register a sample procedure. This procedure will be called once to generate a preview image. But this procedure is probably a bad idea (since generating the preview will take time, and this can be long...) The other option is to ship example images with script-fu scripts and to allow them to return a pointer to that image for their preview. This sounds more reasonable to me. One of the things we should remember is that we should still have some sort of seperation between the plugin/script browser and between the general procedure browser. Because if we want things like preview for every action, it would be rather useless to have previews for internal operations such as raise layer. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Usability of menus (search, gegl ops, ...)
Hello, I recently re-read all the GSoC suggestions for 2010, and I found this interesting one about making the menus searchable: https://sites.google.com/site/gimpwiki/long-term-plans/menu-accesibility As far as I know, menus are searchable and the best example is the keyboard shortcuts dialog which has a searchbox to find the GIMP action you'd like to use. So I asked on #gimp and I was told there was a discussion on IRC about finding a more usable replacement to the plugin browser. So, to get a formal record of this discussion, I'm starting it on the mailing list again. Here are points which should be considered: 0. How do we want the search to work? A user can bring a search dialog up? Will the search be based on a string? A tree? 1. GEGL ops should really be integrated in the GIPM menus. As someone said, it's like the old script-fu menu - it was wrong. We don't have to force the user to remember what's a GEGL op (which will be accessed using the GEGL tool) and what's a regular plugin/script. It's a bit offtopic, but we should find a way to implement gegl plugins with a custom GUI, and register them like regular plugins in the menus. Having a search that will once point to a plugin and once activate the gegl tool, is a very bad idea... 2. We need to define a usable plugin browser. One of the features I'm missing the most, is a preview image. Plugins should have an option to register a preview image of their effect (probably by having the image's binary data embedded in them). This also relates to the feature request of having a logo script browser... 3. Will plugins also have a category (in addition to a menu location)? How should we organize the plugins? On one hand, it's probably a bad idea to continue having plugin authors choose their own category (or as it is now - a menu location). Since then you might find yourself with dozens of categories (like my-site his-site) and typos (artisti and artistic) or redefinitions (art vs. artistic) may create more categories. It's a fact - a bloated category list is good for nothing... So, should we limit the categories for plugins? 4. Another option, instead of categories and sub-categories, is tagging - like the brushes work in 2.7 (unlike categories - there are no sub-levels, and each plugin can be in many places) Menus in GIMP should become more useful and things should become easier to find. But how? Please share your thoughts ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Another set of feature-wishes regarding Guides
On Sat, Aug 7, 2010 at 4:23 PM, oli...@first.in-berlin.de wrote: it is possible to make guides invisible/visible and to make them magnetic/nonmagnetic. Both features are independent, which is good for some situations. To make them invisible as well as non-magnetic at the same time, two check boxes must be enabled/disabled. The possibility to make both with one click would be fine: visible magnetic / invisible non-magnetic. Also it would be fine to have keyboard-shortcuts for all those check-boxes. You can already do this to all the guides at once: View-Show Guides View-Snap to guides an even more advaned usage of Guides would be, to have Guide-layers. One could disable guides on a guide-layer completely, when swictching off the eye for that layer, and enable them again like any other layer, when clicking on the corresponding layers-eye. With that feature one could do very complex graphics easily. Together with layer-groups, one could have layer-group specific guides, which will make it even more powerful. Guides that will not be part of a group would be acting globally, and guides that are part of a layer-group would be activated only together with that group. The layer stack is definetly not the place for putting guides (at least that's my opinion). We can however consider adding groups for guides which indeed sounds more reasonable. Since implementing angular guides (which I tried yesterday) requires rewriting many of the guides code, I can try to add this as part of the re-write. Note however that I think that a flat list of guide groups is enough - implemeting a tree of groups sounds much more than needed. I believe that guide groups shouldn't be added to the layer stack since it's cluttered enough as it is, and since having a dedicated dialog for guide groups sounds much more productive. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what is the meaning of git commit %s ? (translation related)
Hello, 2010/8/5 Cristian Secară li...@secarica.ro: On Thu, 5 Aug 2010 12:01:07 +0300, Cristian Secară wrote: I like to know what is the meaning of this string, I don't know how to translated it: #: ../app/version.c:132 #, c-format msgid git commit %s git is the source control system which is used to store GIMP's source. The act of updating the source is called a commit and each such commit has it's unique identifier. So basically, a commit identifier is like a version number (the %s in the string will be replaced with that identifier) I'm not sure this should be translated though, since git is a name of a tool and commit is a git specific term which should probably be kept untranslated (I saw the term commit in other non-English articles so it's probably best not to translate it). I'll add a comment to the file as soon as I get to a non-public computer. ~ LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] pick color anywhere on the screen ? not quite
Hello, On Thu, Aug 5, 2010 at 4:41 AM, Burnie West w...@ieee.org wrote: On 08/01/2010 01:48 PM, LightningIsMyName wrote: Hello, I discovered that when using windows it will indeed turn to the regular cursor when you leave GIMP's UI, but the pick functionality still works. Click anywhere on the screen - although GIMP's window will when you say loose I think you mean lose, correct? loose focus (in favour of the window you clicked on) the right color would still be picked (at least on my windows XP SP3 32). yes, it's a typo... ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
Hello, On Sat, Jul 31, 2010 at 2:29 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On 7/31/10, LightningIsMyName wrote: I don't see GIMP becoming an HTML editor - not only because there is no one with time to develop this (building an html editor is lots of work), but also because this isn't GIMP's product vision. Really? So GIMP is suddenly not the tool for web developers? :) GIMP is meant to be a high-end image manipulation/creating program, and not an application for designing web interfaces (and coding them). Who said that? I don't say that I agree with that, but that is from the UI redesign wiki: http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision If we follow what's listed there then GIMP isn't a tool for generating/editing html code with graphics and stuff. As peter said: On Sat, Jul 31, 2010 at 2:38 PM, peter sikking pe...@mmiworks.net wrote: I thought immediately of what the GIMP team said during the discussion of the product vision. I brought up 'what about making mock-ups of web pages?' after a serious look at what it means to support that (like pro-grade html generation, support for fluid layouts), the team clearly felt that this is not what they wanted GIMP to be. so there is an explicit 'no' for GIMP as a web design tool. there is an explicit 'yes' for GIMP as a production tool for all graphics that are used on a website. This does mean that there needs to be better support for this, like automated cutting and exporting of all the parts from a working canvas, much more than the hack-ish slicing we have right now. I don't agree with some of the product vision points as stated in the UI redesign wiki and by some developers (for example that GIMP is meant mainly for high end users and less for simple users - as we discussed on IRC yesterday), but I do agree on this point. GIMP is an image editining/authoring tool and not a web tool for coding and designing websites. I don't want overcomplicated interfaces just to get more features What makes you think this would be overcomplicated? Expirience taught me that lots of features *usually* mean more complicated interfaces. Let's hope that I'm wrong and we can keep the interface simple if/when we add this =) ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] small Wishlist regarding Guides
Hello - non-rectangle-bound guides: Guides that can be enabled to have any angle, which means that they do not have to be restricted to be 0 degrees or 90 degrees (being parallel to the window). This feature can be helpful, e.g. when correcting pictures, or for drawing parallels that do not fit the 0/90/180/270/360 degree orientation. It would be good, to enable/disable this behaviour via toggle box, so that normal behaviour will be available and guides can be restricted to classical window-parallel behaviour. I think we have seen this request already several times and I definitely agree it could be useful. Your request made me take a look at the code (app/display/gimpdisplayshell-draw.c, app/core/gimpimage-guides.c, /app/core/gimpguide.c) and it actually seems possible. I'll add it to my to-try list for when I have some more time. - boundary guides, instead of middle.guides: Guides, where the outer boundary of a drawing tool snaps to the guide (instead the middle of the drawing tool snapping to the guide). This would be helpful for drawing in general, and correcting pictures: the color will not pass this line of the guide, which means, you can be sure no color enters a certain region. This does not seem trivial to code - in fact with how I remember the paint core works, this is going to be one very hard hack... Also, I think that if the purpose is just to stay inside of the lines you can use a selection (create it using the guides and freeform selection) and stroke it on a new layer with a mask which is exactly the selection - I do this all the time. Stroking a selection is usually faster than me painting it by hand, and it's probably more accurate. - Adding Multiple Guides (there is a Script for this on www.meetthegimp.org, but native would be nice) This feature is good for some repetitive tasks, where a lot of Guides will be needed, something like a guide-grid. Can you give a direct link to the script? I definitely agree this sounds useful - it's worth checking if we can simply include this script with GIMP (or at least if you give us a link to it, we'll be able to write something similar with extra features if needed). ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
Hello On Sun, Aug 1, 2010 at 7:15 PM, Christopher Curtis ccurt...@gmail.com wrote: What format does it save the per-character formatting in? Would HTML be an option? Understanding even a subset of the basic HTML1 tags plus font could likely be a good 80% solution. That's not to say that it's easy (font style= the most obvious problem), but HTML is a decent way to store stylized text. GIMP supports some of the features described in the pango markup - see http://library.gnome.org/devel/pango/stable/PangoMarkupFormat.html. Currently, this includes the following per-character control: Font, Size, Spacing, bold, italic, underline, strikethrough, baseline (raising/lowring the caracter) and when I'll have more time it will also include color. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] pick color anywhere on the screen ? not quite
Hello, I discovered that when using windows it will indeed turn to the regular cursor when you leave GIMP's UI, but the pick functionality still works. Click anywhere on the screen - although GIMP's window will loose focus (in favour of the window you clicked on) the right color would still be picked (at least on my windows XP SP3 32). On linux it works perfectly - the GIMP window doesn't even loose the focus. If colour picking still doesn't work (check that if you click out of the window and go back to GIMP, if the foreground color was set to the right color) you are welcome to open a bug report at the GIMP bugzilla https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
Hello, Smashing magazine linked to an interesting blog entry, where John Nack discusses the possibility of HTML layers in photoshop. I'll add to what Tobias said: I don't think that HTML rendering is necessary. Let's look for a moment on what HTML can do: 1. Render images in specific locations with/without borders - GIMP can obviously render images in certain places, abd borders can be added manually for now (or automatically when GEGL will be fully integrated and will allow what you may know from photoshop as layer effects) 2. Render containers of different colors - We are waiting for vector layers in GIMP. The code for creating vector layers exists in fact, but we need someone that will integrate it with the current source 3. Render text in very special ways - Have you looked at the text engine of GIMP 2.7.1? It can do almost all of the text effects you can do in HTML. The only missing thing is multicolored text and this is a patch I'll finish when I have time (should probably be this month). If I understand the gist of his proposition/fantasy, the idea is the ultimately his image editor would have a feature that can import, present and edit html elements as components of a layer. I don't see GIMP becoming an HTML editor - not only because there is no one with time to develop this (building an html editor is lots of work), but also because this isn't GIMP's product vision. GIMP is meant to be a high-end image manipulation/creating program, and not an application for designing web interfaces (and coding them). I don't see anything wrong with the current workflow of designing a web interface graphically in GIMP, slicing it to small images and then coding it. Adding HTML editing abilities to GIMP will make it overloaded with features, and at least for me - I love the fact that unlike photoshop, GIMP is simple. I don't want overcomplicated interfaces just to get more features - I want a program which I can use quickly and easily. ~ LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script debugging
Hello, Debugging Script-Fu scripts is only slightly less painful than stabbing yourself in the eye with a dull spoon. indeed debugging gimp scripts is a pain and I encountered it several times. There are several ways to make it easier to follow the execution (defining some functions which will print all the arguments passed to other functions) but I'm unaware of any interactive debugging utility. As a more long term fantasy, has there been any discussion of an RPC portal to the Procedure Database. This would allow add-ons to be written in any language with a relatively small investment in each. The big plus for the developers of add-on would be the ability to use existing IDEs with a DEBUGGER. As far as I know, there are some plans to introduce javascript as the new scripting language for GIMP. It was suggested for this year's summmer of code, but eventually other projects were taken. If the suggestion to move to javascript is likely to happen anywhere in the near future, I'm not sure if it's worth it to try write a scheme debugger. Also, a note from the manual of tinyscheme (the scheme implementation GIMP currently uses): Decent debugging facilities are missing. Only tracing is supported natively. So basically, I don't see any trivial way to implement debugging into GIMP's scheme withou a serious re-write of GIMP's scheme. I have only two solutions which are a quick and ugly but they'll work: 1. On my first programming course in the university we learned scheme, and we wrote a scheme interpeter in scheme for learning purposes. I think I can hack it and add debugging features to it as I still remember it's code - then in order to debug a script, you would simply pass the script as a to a function called mc-eval. I'll need to ask permission from my professor to distribute the code, but I'm pretty sure he'll agree. 2. We can connect an external scheme implementation which supports debugging (I have one which I wrote in java, and there are probably more better existing ones) and allow it to run the script itself. When it doesn't find a function, then it will invoke the aproppriate procedure from GIMP using a call to the PDB (since if a script uses a function which is not defined in it, it's probably a gimp procedure) So, I see no way of implementing a scheme debugger in GIMP nativly, but there are two tools which we can connect externally to provide debugging options. Back to javascript - I think that a debugger should be included on the project's todo. These are my thoughts - tell me if any of them seem interesting enough to try. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Brush dynamics are confusing at their current state
Hello, After a bug report like this https://bugzilla.gnome.org/show_bug.cgi?id=623980 and some more discussion on IRC, it was pointed out that brush dynamics are now confusing for users who don't know them. Some example problems are: - Brush resizing because the default dynamics maps the velocity to the brush size, will make regular users wonder why their brush resizes (like the bug report above) - Users that used the basic dynamics in 2.6 possibly won't find them in 2.8 and will complain about missing features - Finding where to choose brush dynamics is simply not intuitive Suggestions: 1. Change the default brush dynamics to mimic the default settings in 2.6 (Pressure mapped to Opacity, and disabling all the other inputs). Simply disabling all the dynamics by default (or more precisely, setting them to Dynamics Off) will cause bug reports about missing pressure support... 2. Adding a widget in the tool options window, to select the brush dynamics. This sounds logical if we already allow to select the brush and gradient from the tool options window. We need feedback for both suggestions - what should the default dynamics be (maybe we should enable things like tilt which don't affect users that use a mouse), and whether to add or not to add a widget to select the dynamics from the tool options window. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotation-Tool: center point and grid
Hello Oliver, On Mon, Jun 28, 2010 at 4:40 PM, oli...@first.in-berlin.de wrote: when using the rotate tool, I can enable a grid that is shown. I also can move the center point. What I want to have, is, that the center point's center also is at one crossover of grid lines. Where (which file) can I change that? I'm not sure I understood correctly what do you wish to do. If I understood correctly, when you rotate a drawable, you can use the option Preview: Image + Grid. Now, you would like to move the center of the rotation so that it will snap to this grid. If this indeed what you mean, then you'll have to modify (at least) the following files: app/tools/gimptransformtool.c - The base class for the transformation tools in GIMP (rotate, shear, transform, scale). The code of the grid for the transformation tool is there, and this is where you should look for information about the grid points (try looking at the function which actually draws the preview grid - it shows how to find and access the grid points themselves) app/tools/gimprotatetool.c - The code of the rotate tool An interesting note which you should probably consider during your implementation, is that it's weird to snap the center of the rotation after you started rotating. Why? Because moving the center point will move the drawable (and the grid itself) and so after you move the center to some other location which was supposedly a crossover of the lines, the crossover would also move and it will probably not be there... (Try it - move the center of the rotation after you already rotated in some big angle) Hope this helps =) LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] hello, I want to ask how to use the api to get the color from the screen with a pen.
Hello, On Fri, Jun 25, 2010 at 8:59 AM, Eva eva...@foxmail.com wrote: hello, I'm a beginner of GIMP. I'm developing a plug-in for GIMP. Now I'm facing a problem, that is, I want to pick a color for a picture and use it as an input to process the picture, but I don't know which api can fulfill my task. Can you help me? Thank you very much. You are looking for the procedure gimp-image-pick-color. You can see it's documentation here: http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpimage.html#gimp-image-pick-color On Fri, Jun 25, 2010 at 8:59 AM, Eva eva...@foxmail.com wrote: By the way, is there any good advice for a beginner to quickly get into the stuff? Any efficient way to use the API reference? Thank you again. You are probably looking for this page: http://developer.gimp.org/api/2.0/index.html Note that the top links in that page are the ones relevant for development of plugins. The bottom link (titled Gimp Application) is a documentation of the GIMP's core and is usually not relevant unless you want to contribute code to GIMP itself. Good luck with your plugin =) LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling Gimp on Ubuntu 9.10
Hello On Sat, Jun 5, 2010 at 1:34 PM, Markus Ilmola markus.ilm...@pp.inet.fi wrote: I am trying to compile the latest git version of Gimp on Ubuntu 9.10 (Karmic Koala). I got it compile, but it crashes when ever I try to create a new image. Does not matter how (File-new, paste from clipboard, take a screen shot, etz). Here are the debug messages to are printed: ... /home/markus/Projects/gimp/app/.libs/lt-gimp-2.7: symbol lookup error: /home/markus/Projects/gimp/app/.libs/lt-gimp-2.7: undefined symbol: gimp_pixels_to_units I don't know about the canberra-gtk-module error, but errors about missing symbols usually mean that the wrong version of the Dynamic libaray (.so) was loaded. Try running ldd /path/to/your/gimp/executable to see which versions of libraries are loaded. If you have an old GIMP installation (2.6.X or older) this is likely to happen, since gimp_pixels_to_units() is a new function that was added after the 2.6 series, and if the old libraries of GIMP 2.6 are still in the path, they will be loaded instead of the new ones. Check that indeed the versions of libraries which are loaded (the ones that ldd shows) are the new versions which you compiled. Anyway, if this is indeed the problem, try doing this in a console (bash) window: export COMPILE_DIR=/the/prefix/directory/in/which/you/compiled/stuff export PATH=$COMPILE_DIR/bin:$PATH export PKG_CONFIG_PATH=$COMPILE_DIR/lib/pkgconfig:$PKG_CONFIG_PATH export LD_LIBRARY_PATH=$COMPILE_DIR/lib:$LD_LIBRARY_PATH And then run your compiled version of gimp from the same console window. If this doesn't work, you may have to set these variables and then recompile your git version of GIMP (with these variables set). Hope this helps =) ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Could new version of gimp building swf?
Hello Hadas, 2010/6/1 Hades ppm10...@163.com: Could new version of gimp building swf? SWF is a very large file-format. It can do anything from showing simple pictures, to running advanced web applications (using actionscript). You'll need to be a bit more specific about what you want to do with the SWF. I don't know of any existing plugin to export SWF (static images in SWF) from GIMP images. In linux env,is there any good swf builder project ? If you want to work with SWF on linux, you should probably try libming - http://www.libming.org/ It has many tools and utilities for working with SWF files. You should be able to find a way to use libming to convert static images to SWFs. -- LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Palettes should be translated ?
Hello Cristi, 2010/5/31 Cristian Secară or...@secarica.ro This string should be fully translated, or Palettes is some code variable ? #: ../plug-ins/script-fu/scripts/palette-export.scm.h:1 msgid Palettes/Export as I wrote that script, and the Palettes part should not be translated. Palettes means that this script will be located in the menu of the palette dialog. The rest of the string (the Export As) should be translated, as this is the actual menu name of the script. Thanks for translating my script =) LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Include resynthesizer plugin in Gimp distribution?
Hello lloyd, On Wed, May 19, 2010 at 5:03 PM, lloyd konneker boo...@nc.rr.com wrote: The Resynthesizer package includes: the engine written in C++, with its own GUI of settings several plugins written in Scheme that call the engine: Smart enlarge Smart remove selection (now called Heal selection) I don'nt believe the developers will accept it since it's written in C++. I would be happy to see this plugin as a part of GIMP, but believe that it will have to be re-written in C (if you need objects, use GObject instead which is the the object library for C that gimp uses) in order for it to be included. There is nothing against including new plugins. Hoever, the fact that it's in C++ (and the fact that it's not in the gnu coding style - although this is minor) will make it hard to maintain for people who don't know C++. I just gave a look at the source - it's not too big (only 980 lines and less than half of them are the algorithm) and the usage of C++ is very minor. It shouldn't be too hard to port the plugin to C (al least, this is the impression I got). I would really like to see resynthesizer included with GIMP - I do hope it will be accepted, even if it will require a bit of rewriting some small parts of the code. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] who is interesting in writing java api to gimp
Hello, I actually had an intention to create a java api for GIMP, and I even started to write this api. BUT, I don't really have any time to work on it since I have other duties to do. I can think of many places where GIMP and java's AWT package can benefit one from another, but I simply don't have time to do it. I know that it may sound like a long time from now, but I intend to purpose this for GSoC for 2011 (if GIMP is accepted). I'm also willing to work on it in GSoC if it will be chosen (but there is more than a year untill then so we'll have to wait and see). Right now there is no active java api for GIMP that I know of (There is http://jgimp.sourceforge.net/ but it is very very old and un-maintained) ~LightningIsMyName 2010/5/9 Hades ppm10...@163.com: Is there anyone who likes writing an java api to gimp?so the J2EE can use the GIMP JAVA API perform graphic 祝 万事如意 Hades 2010-05-09 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Windows snapshot of 2.7 - possible?
Hello Sven, The modification was to one of the ./configure scripts (I changed the path to the perl location in order for the script to find my perl that was installed in some irregular directory - perl was needed for intltool). I haven't changed the source code of any of the programs themselves. Sorry again for the mess... LightningIsMyName On Mon, Apr 12, 2010 at 8:49 AM, Sven Neumann s...@gimp.org wrote: Please, by all means, do never ever distribute a binary based on a modified copy of the source code. If you absolutely need to do so, then please make a very prominent notice about this. It sucks a lot if we get bug reports and later find out that there were changes to the source code that we didn't know about. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Windows snapshot of 2.7 - possible?
Hello, On Sun, Apr 11, 2010 at 5:30 PM, Alchemie foto\grafiche fotocom...@yahoo.it wrote: LIMN the file you uploaded is set to private so is impossible the download my file was set to private since it has modifications in the source code which I'm not sure I can reproduce (I don't remember them exactly, and my code was delted because the shared server I use at university cleaned the temporary space which I have used). My guide for compiling GIMP is almost ready (it will be available this weekend! :D) and then you'll be able to build GIMP yourself. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Windows snapshot of 2.7 - possible?
Hello Tor, I forgot to include the actual sources with my build (they were way to big and I forgot I had to do this), so I removed my build. Thanks for reminding me =) However, I will post the instructions on compiling GIMP on windows soon at the link above. LightningIsMyName On Fri, Apr 9, 2010 at 10:09 AM, Tor Lillqvist t...@iki.fi wrote: Nothing personal, just a friendly reminder to people who distribute personal builds like this: Please note that even if you do it just temporarily on a small scale, you still need to follow the licenses, i.e.offer the sources for all GPL or LGPL code you distribute. You don't want to give anybody the opportunity to start flaming you about breaking the license. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Windows snapshot of 2.7 - possible?
Hello, I compiled GIMP from git this week, on windows using msys and mingw (and without cygwin). You can find my build here: http://www.mediafire.com/file/hjwqw1kym4g/gimp-win-08-04-2010.7z Read the README_FIRST!!!.txt file before using this build (seriously, read it!). This is .7z archive (you'll need 7-zip to extract it). It contains a lot of junk (since it contains all the traces of my failed attempts to compile GIMP) which you probably don't need in order to run GIMP, and there is a lot of mess in the lib directory so I'm not sure you can actually link against anything in there. It contains some general instruction to compile GIMP on windows inside the HACKING.txt file. As it says in the file, I'll provide a complete guide for compiling gimp on windows later on this month (hopefully it will be finished this month) on http://lightningismyname.blogspot.com/p/gimp-stuff.html Again, this is a messy build and it's not intended for every day usage since it was compiled without many of the extra dependencies (for example, it was compiled without jpeg support). It does have export to PNG and obviously for XCF, but many of the other formats are missing. My next build will be much more organized and will contain much less mess. Hope this helps =) LightningIsMyName On Fri, Apr 2, 2010 at 1:38 AM, photocomix for...@gimpusers.com wrote: thank for sharing your build As Rob i will really appreciate some guidance on compiling from git I already compiled (thank to a detailed guide on the gimp wiki) the stable but i failed to adapt the steps to compile from git Did you cross compile this, or compile it under windows? If under windows, can you provide any guidance on compiling from git under windows? I have tried under MSYS but not had luck, mainly due to the many dependencies, not being able to locate compiled binaries. Thanks in advance if you can help, -Rob A -- photocomix (via www.gimpusers.com) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Mouse icons
Hello Nery, You can get custom cursors using GDK. Take a look at this link: http://library.gnome.org/devel/gdk/stable/gdk-Cursors.html#id615496 In the same way they create a cursor from bitmap data in that example, you can create a cursor from a pixbuf (using gdk_cursor_new_from_pixbuf ()), and the pixbuf will be create from a file (using gdk_pixbuf_new_from_file () on an image file) All the information you need is located in the GDK documentation: GDK Pixbuf documentation - http://library.gnome.org/devel/gdk-pixbuf/stable/index.html GDK documentation - http://library.gnome.org/devel/gdk/stable/index.html Hope this helps =) LightningIsMyName On Thu, Apr 1, 2010 at 6:23 AM, Nery Chucuy idesisn...@gmail.com wrote: Hello guys, I've seen that Gimp has very colorful and nice mouse icons. I wonder what do you use to make that possible? also, would you point me into the right direction where that code is placed at your tree? Thanks in advance, -idesisnery ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] incomprehensible behavior with the git version
On Wed, Mar 31, 2010 at 12:12 PM, Olivier oleca...@gmail.com wrote: Since the problem finally occurs on the same machine, but with two different users, it must be a matter of personal GIMP environment. I'm searching in this direction. I had once very interesting bugs that only happened to me because of my personal settings - and this was because of the enviroment variables such as the PATH and LD_LIBRARY_PATH. Apparantly, in my case the problem was that because of these variables, the wrong versions of some of the libraries where loaded since I had two installations of Gtk in different places, and I wanted to load the one which was newer and was in a differet location. Try checking what Omari suggested - maybe you are indeed loading different versions of the libraries in the different users, because of some enviroment variables. -- LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Text layer changes?
Hello, I took a look on the commit logs, and I haven't seen any update to the text tool which should affect exporting it's markup, in the last 3 weeks. So now it's time at least discuss which kind of export do we want for the markup: - Do we want an export which exports pango's markup directly? Although this should be the easiest technique, it might be a burden if for some reason we change to a different text-rendering library in the future (This shouldn't happen, right? If so, this is probably OK) - Do we want an export which exports to some HTML and CSS combination? Right now pango does something very close to this, however it includes some attributes which should be inside a style attribute in valid CSS. This is less pango-dependant and it is probably a better idea to use valid HTML/CSS if we want to allow other uses of the exported text (instead of just usage with Pango as in the PDF plugin). Note however that in this case, there are some elements that it's unclear how to export since Pango's markup supports several attributes (such as fallback) which HTML and CSS don't support. - Other export format? I obviously tend to like the first option more (Pango-style markup) since it requires no writing of convertors for the markup from our current internal represenation, and as far as I know Pango is here to stay. If this option is indeed the way to go, I have a fixed code ready that I can create the patch from. I'll continue working on the PDF plugin as soon as we are done with this =) LightningIsMyName On Thu, Mar 4, 2010 at 12:49 AM, Sven Neumann s...@gimp.org wrote: On Wed, 2010-03-03 at 22:35 +0200, LightningIsMyName wrote: On Wed, Mar 3, 2010 at 9:17 PM, Sven Neumann s...@gimp.org wrote: Is there any way in which I can acces the style of the text?= Such a way will have to be added of course. We usually add the core functionality first, then expose it to plug-ins. It's easier this way around. It should be unproblematic to add a procedure that exposes the new markup property of the text object. OK, I found the markup property you are mentioned - It shouldn't be too problomatic to extract it (I'll probably be able to add the patch myself). However, before I continue working on the plugin, are there any other upcoming changes in the text-engine which will affect the plugin? Almost certainly. The feature is brand-new, you should give it some time to settle. And another thing - with al the late discussions about color profiles, It made me wonder: exporting a PDF via cairo does not support color profiles. Do we need to warn the user if the image has some specific color profile, that the PDF will be exported in the default RGB profile? Or do we continue to stick to the fact that this is an extra feature (andnot a complete feature with CMYK and other PDF related features) in gimp and therfor we don't need to warn about such errors that don't bother most of the users? Almost all our file plug-ins are missing color profile support and we don't warn users in any of them. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] segmentation fault in current git version
Hello, I can confirm this bug on Ubuntu 64bits. I also managed to get a stack trace: #0 0x7f9f47f8abbf in waitpid () from /lib/libpthread.so.0 #1 0x7f9f47aa4fd2 in IA__g_on_error_stack_trace ( #2 0x7f9f47aa51c3 in IA__g_on_error_query (prg_name=0xbfe8d0 gimp-2.7) #3 0x00481da4 in gimp_eek (reason=0x76d281 fatal error, #4 0x00481e16 in gimp_fatal_error (message=value optimized out) #5 0x00482586 in gimp_sigfatal_handler (sig_num=value optimized out) #6 signal handler called #7 0x7f9f4bf9ecb8 in gtk_tree_view_button_press (widget=0x7f9f3da74310, #8 0x7f9f4bea2858 in _gtk_marshal_BOOLEAN__BOXED (closure=0xc054f0, #9 0x7f9f483a95ed in IA__g_closure_invoke (closure=0xc054f0, #10 0x7f9f483beffe in signal_emit_unlocked_R (node=0xc46260, detail=0, #11 0x7f9f483c079d in IA__g_signal_emit_valist (instance=0x7f9f3da74310, #12 0x7f9f483c0e33 in IA__g_signal_emit (instance=0x1e97230, #13 0x7f9f4bfae8de in gtk_widget_event_internal (widget=0x7f9f3da74310, #14 0x7f9f4be9ad93 in IA__gtk_propagate_event (widget=0x7f9f3da74310, #15 0x7f9f4be9bebb in IA__gtk_main_do_event (event=0x24a2d70) #16 0x7f9f4bb0eb8c in gdk_event_dispatch (source=value optimized out, #17 0x7f9f47ac88aa in IA__g_main_context_dispatch (context=0xbfc5a0) #18 0x7f9f47acc238 in g_main_context_iterate (context=0xbfc5a0, block=1, #19 0x7f9f47acc72d in IA__g_main_loop_run (loop=0x119b490) at gmain.c:2799 #20 0x0048172d in app_run (full_prog_name=value optimized out, #21 0x00483636 in main (argc=1, argv=0x7fff54ac1098) at main.c:397 -- LightningIsMyName On Mon, Mar 8, 2010 at 4:53 PM, Olivier oleca...@gmail.com wrote: Version compiled today. If I change the current gradient in the Gradients dialog, all works well. If I try changing it in the Blewnding tool options, I get the following: This is a development version of GIMP. Debug messages may appear here. (gimp-2.7:22938): GLib-GObject-WARNING **: value -2147483648 of type `gint' is invalid or out of range for property `cache-size' of type `gint' /opt/gimp-2.7/bin/gimp-2.7: fatal error: Segmentation fault /opt/gimp-2.7/bin/gimp-2.7 (pid:22938): [E]xit, [H]alt, show [S]tack trace or [P]roceed: e (script-fu:22949): LibGimpBase-WARNING **: script-fu: gimp_wire_read(): error Trying to show trace does not produce any result. Debian testing on a Dell Inspiron 530. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developerhttps://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Text layer changes?
Hello, I have seen in my latest GIMP build that the new text layer allows us to style different parts of the text in different styles. This is an amazing feature (I waited for it for a long time), but it's a pain in the neck for my PDF export plugin (see here https://bugzilla.gnome.org/show_bug.cgi?id=382688 ) Is there any way in which I can acces the style of the text? I can easily add a PDB procedure (to the GIMP's source) to export the PangoTextLayout object to plugins for using, but I doubt that it's a good idea (Since exposing the internal structure will be a big problem in backwards comptiablility if we ever change from pango). The other option which I can think off, is something that will work but will not be ideal. This is to expose a function that renders a text layer to a cairo surface. This way, for vector surfaces It will still be a vector instead of bitmap, and it won't be any trouble for the programmer. However, this method also has many problems... Can anyone give me any hint on what should I do? Thanks, LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Text layer changes?
Hello Sven, On Wed, Mar 3, 2010 at 9:17 PM, Sven Neumann s...@gimp.org wrote: Is there any way in which I can acces the style of the text?= Such a way will have to be added of course. We usually add the core functionality first, then expose it to plug-ins. It's easier this way around. It should be unproblematic to add a procedure that exposes the new markup property of the text object. OK, I found the markup property you are mentioned - It shouldn't be too problomatic to extract it (I'll probably be able to add the patch myself). However, before I continue working on the plugin, are there any other upcoming changes in the text-engine which will affect the plugin? And another thing - with al the late discussions about color profiles, It made me wonder: exporting a PDF via cairo does not support color profiles. Do we need to warn the user if the image has some specific color profile, that the PDF will be exported in the default RGB profile? Or do we continue to stick to the fact that this is an extra feature (andnot a complete feature with CMYK and other PDF related features) in gimp and therfor we don't need to warn about such errors that don't bother most of the users? Thanks for your help, ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] dynamic plugin menu
Hello Gena, I tried to browse the source of the script-fu plugin to answer your question, and this is what I came up with: A temporary procedure is a procedure which is only available while one of your plug-in's real procedures is running. That is correct - If you will look at line 107 http://git.gnome.org/browse/gimp/tree/plug-ins/script-fu/script-fu.c#n107, you will see that the plugin is registerd as an extension and not as a regular GIMP plugin. On line 217 and 221, the plugin registers itself as an extension, and this way it allows itself to run from the moment gimp starts up, untill GIMP is exited. When registering an extension instead of a normal GIMP plugin, the run procedure will be called during GIMP's start-up, and the plugin will then be able to register temporary procedures (exactly like the Script-Fu scripts) that will be available untill GIMP exits. Just to show you how the script-fu extension continues to run after it was intialized, look at the list of all the running procedures on your computer and you should see that as long as gimp is open, there is also a procedure called script-fu running. After creating the temporary procedures with your extension, you can unregister them using gimp_uninstall_temp_proc, and the register them again inside another menu. What I suggested is probably not the best way in the world, but it's the only way I can think of. Hope this helps, ~ LightningIsMyName On Tue, Feb 16, 2010 at 10:27 AM, Gena Batsyan gbat...@gmail.com wrote: Hi! I've been trying to find a way for a plugin to update menu entries it has initially registered from query() via gimp_install_procedure() When the plugin is being run it wishes to update the menu entries, for instance putting some named presets previously selected in the plugin interface to be easily and directly accessible from the gimp menu without opening plugin interface again. Is there a way to affect menu entries generated by a plugin after it's query() has been called? I thought maybe using gimp_install_temp_proc instead of gimp_install_procedure would do the trick, but documentation says: A temporary procedure is a procedure which is only available while one of your plug-in's real procedures is running. What exactly does it mean while my 'real' procedure is RUNNING? gimp_install_temp_proc does also accept the menu spec, so the procedure should also be available in menu, but at which times? Kind regards ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paint dynamics
Hello, On Tue, Feb 16, 2010 at 4:40 PM, Alexia Death alexiade...@gmail.com wrote: Curves don't exist in UI yet, because I personally suck at getting GTK to do what I want... If you know somebody with good GTK bending skills willing to help out, direct him/her to us. I could really use some help... Can you give some explanations of what is needed? It suprises me that there is a problem with a curves widget, when we can steal most of the code from the existing curves dialog of the curve tool... I would like to know some more about this, maybe this is something that I can do (I probably won't be able to do it since my GTK programming skills aren't so great, but let's give it a try). ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paint dynamics
Hello On Tue, Feb 16, 2010 at 10:45 PM, Alexia Death alexiade...@gmail.com wrote: Curves widget is not a problem. Problem is the general making of Peter's spec[1] so that developers who do know gtk, dont faint in disgust at the sight of the code. for example, one dock needs to hold 2.5 distinct views. the check gird and two very similar variants of curves views switched by the drop down. I cant even imagine a solution for this in gtk terms. [1] http://gui.gimp.org/index.php/Paint_dynamics_specification Wow! This seems to be an amazing idea, and probably extremly long to implement... So let's do some analyzing: 1. We need to implement a check grid. This seems to be pretty simple using a GtkTable (if we pick the simple way), or if we use a GtkTreeView (which can actually show a table) with GtkCellRendererToggle. 2. The painting of the matrix as showed in the specifications seems very hard, and I doubt it worths it. We can easily implement different colors for each row, and users will have to settle for a little border between the columns. If we agree to give up the proposed matrix painting and choose what I suggested, it can be done with GtkTreeView without any special changes, but it will leave the simpler GtkTable our of the question (which is fine with me). 3. Adding the images with the link's color should be a bit tricky, but I assume that it can be done dynamically (by drawing those images after acquiring the link's color, instead of embedding ready bitmaps). 4. Popup window: Part 1 - the curves widget. This can definetly be stolen from the curves tool, no need to work twice. The only needed modification is that we can show some other curves at the background, and that we add min and max arrows. 5. Popup window: Part 2 - switching the tabs. This doesn't seem to bad, especially since we already have similar functionality in the curves tool. only two things seem problomatic: A treeview widget can't have a bitmap in it's header, And adding the bitmaps as the first row is ugly and probably not the right way to do this. The guys on the GTK mailing list will probably be able to help us out here. And another questions is, why do we have the same header images at the bottom? Adding a footer to a GtkTreeView isn't possible. Do we really need that? Here i'm defintly sure it's not worth the coding amount that it will require, and I personally find it confusing. I haven't seen anything that scary in here, but I doubt that I'll have time to touch it in this month. If I implement something like this on a dummy GtkWindow (instead of hacking GIMP's source code, which I don't excel at) as a stand-alone Gtk application, will it help? If so, I'll try to give it a shot. If you want to see how to use the TreeView and the CellRenderer, the gtk-demo program (which comes with GTK) has a nice example under Tree View/List Store. The code is very simple and in one of the columns you'll see the Toggle renderer. for example, one dock needs to hold 2.5 distinct views I haven't understood that sentence. Can you please explain (or, have I referred to it already)? Just one offtopic comment: Some of the icons seem very unintuitive - even as an old GIMP user I'm still confused by the fifth one from the left. What does it stand for? ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hello World !
Hello Emmanuel, The first place to begin with is probably the developer website: http://developer.gimp.org/ It's FAQ page should have answers for most of your questions (although some of the info is a bit outdated :P) I would suggest you to start by trying to the plugin tutorial on the GIMP website - it will teach you at least some of the bascs. ~LightningIsMyName On Sun, Jan 24, 2010 at 4:00 PM, Emmanuel Gontcho gont...@gmail.com wrote: Hi, New to the Gimp developer list, I want to help to the core development of the Gimp. Having a average knowledge of C, I think that I can help to improve this software that I am using every day, since I started a new job last month in a photo lab. But I would be considered as a newbie, since I don't ever used any kind of software like a CVS or other... Tell me please how is organised the team, how source code is edited, if developer documentation is ready for offline consulting. Yours, Emmanuel -- Emmanuel Mbenga Gontcho ! Gem ! gontcho.wordpress.com N'utilisez pas Windows 7. Pour savoir pourquoi : http://windows7sins.org/ Don't use Windows 7. To know why : http://windows7sins.org/ Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org Rejoignez maintenant plus de 2 500 personnes, associations, entreprises et collectivités qui soutiennent notre action ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Need feedback for the new PDF plugin
Hello, I tried the new GIMP 2.7 and now I saw what the export feature behaves like. After some thought I reached the conclusion that we should probably merge both procedures (single and multi page) into one procedure for exporting everything. However I also have 2 new additions: 1. The export parameters (aka the pages and optimization) should be saved for each image individually. If the export is automatically suggested for the same file as last time, we should save the parameters for each file - which means saving the parameters for each image. 2. We should warn the user when he wants to re-export the PDF if one of the images that was a part of the PDF was closed, so he won't overwrite his PDF and loose pages. For feature 1, we need to make sure the parameters are saved per image but are only relevant for the current session (since the pages are the open images, not images from files). I need some help here on how to do this... Should I save the parameters to some file instead of adding the to the image? Then I can probabbly use the quit() procedure of the plugin to delete this file. This is the only solution I could think off, and then, should I use the .gimpX.X/tmp/ dir for saving the file? Waiting for feedback =) ~ Barak On Fri, Aug 21, 2009 at 10:59 PM, Martin Nordholtsense...@gmail.com wrote: We can't predict what a user wants to do. We can only give sane defaults, such as the previous export options, and allow the user to change them if they are not right. A more sophisticated solution would be to have per-image export options. Not sure if that is a good idea or not. The problem is that the multipage procedure should be non-related to the single-page save procedure since these are different tasks. I don't see these two as conceptually different tasks. In both cases the user wants to export a PDF. I have only one solution which can solve our problem but I want to hear your opinion about it: 1. Merge the gui both procedures, and make the view of the multipage procedure hidden inside a GtkExpander. 2. Behaviour will be configure like this: a. When the expander is not expanded, only the options for the single page export will be visible, and it will behave as a single page export. b.When the expander is expanded, it will behave as the multipage export and will export the all the images in the GtkIconView. What d you mean w ith all images in the GtkIconView? Can't we simply let the user pick the images for the multi-page PDF? 3. In case of GIMP_RUN_WITH_LAST_VALS it will be assumed that the expander is hidden and it's a single page export. Wouldn't it make more sense to simply run with last vals? That is, if the user previously exported image 1 2 and 3, invoking 'File-Export to file.pdf' would re-export this multi-page PDF. 4. We should make sure that if the multipage procedure was used the image will still be marked as unsaved somehow (Does the new export api causes images to still be marked as unsaved when using the Export function? If so, this solves our problem :D) In git master, exported dirtiness is separate from saved dirtiness. You should try it out :) BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.7.0 Text Tool Crashes (built using MinGW/windows)
Hello, I think that the right place to report this would be in the GIMP bugzilla. http://bugzilla.gnome.org/ and I can confirm this bug - I saw people complaining about it on youtube. ~LightningIsMyName On Tue, Aug 25, 2009 at 1:00 AM, BugByteManbugbyte...@yahoo.com wrote: Hello, Has anybody tried the text tool in Gimp 2.7.0 on windows? The program crashes with the following error: Pango:ERROR:pangowin32.c:###:pango_win32_font_finalize: assertion failed: (win32font-fontmap != NULL) Steps to reproduce: 1. Run gimp-2.7.0 2. Create new image (Ctrl+N) 3. Select Text Tool (T) 4. Click on canvas Thanks, BugByteMan ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Compiling gimp without intltool?
Hello, I'm trying to compile gimp on a computer without intltool (I don't have admin rights so I can't install it). Is there any way to still compile GIMP? I don't need any internationalization, I just want to build GIMP... Alternativly, Is it possible to install it in a local directory (or in my home directory?) Thanks, ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling gimp without intltool?
Hello, nevermind, I built intltool from source inside a local dir and added it to the PATH - solved my problem =) ~LightningIsMyName On Tue, Aug 25, 2009 at 11:15 AM, LightningIsMyNamelightningismyn...@gmail.com wrote: Hello, I'm trying to compile gimp on a computer without intltool (I don't have admin rights so I can't install it). Is there any way to still compile GIMP? I don't need any internationalization, I just want to build GIMP... Alternativly, Is it possible to install it in a local directory (or in my home directory?) Thanks, ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Need feedback for the new PDF plugin
Hello, I have succesfully compiled GIMP 2.7 (from tarball) on linux, using a terminal access =) I'll be able to test GIMP itself and the new PDF plugin on Sunday, when I get to the labs to run GIMP with a GUI. ~ Barak ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Need feedback for the new PDF plugin
Hello Etienne, Thanks - I haven't known that. I tried it, but I got an error saying that it's not allowed... =( Thanks anyway, I learned something new =) ~ Barak On Tue, Aug 25, 2009 at 4:30 PM, Etienne lepercqe.gu...@gmail.com wrote: Notice that if your terminal access is made through ssh, and your ssh-server allows redirecting X, you can launch gui softwares through ssh : ssh -Y -C lo...@server then launch your app. If it can help... Etienne Lepercq -- Sincerily ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Need feedback for the new PDF plugin
Hello Martin On Fri, Aug 21, 2009 at 10:59 PM, Martin Nordholtsense...@gmail.com wrote: A more sophisticated solution would be to have per-image export options. Not sure if that is a good idea or not. I also don't think it's smart - If we do say that the PDF export is a global task (In both cases the user wants to export a PDF) then it shouldn't be associated with any image. What d you mean w ith all images in the GtkIconView? Can't we simply let the user pick the images for the multi-page PDF? The only point is that if we have both procedures merged to one procedure, then the user will have some trouble when handling 2 different PDFs. If the user works on 2 PDFs at the same time, one of images 1 and 2, and another of images 3 and 4 he will be annoyed to set the pages again for every PDF. It shouldn't be a problem with 2 pages but if a user wants to export 50 pages as PDF, it starts to become a problem... However, now that I think of it, GIMP's product vision doesn't say that it's a page layout program, so maybe we shouldn't really worry about this :-) In git master, exported dirtiness is separate from saved dirtiness. You should try it out :) I wish I could try the new branch, however I don't have a computer to test it on with administrator rights... I need someone to package GIMP 2.7 as a zip so I can extract and run it (The windows installer requires administrator rights, and installing a package on linux also requires this). If anyone can package a windows (32 bit)/linux (64 bit) build as a single archive and not as an installer, I'll be very thankful =) Then I'll also be able to test my plugin on GIMP 2.7 (right now, most of my coding for feature releases of GIMP is done blind - I test everything I can on the stable version, and when I want to use the new api I read it, write some code and hope for good :D) ~Barak ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Need feedback for the new PDF plugin
Hello martin, You don't need administrator rights to try GIMP git master, just install into a prefix in your home dir git clone git://git.gnome.org/gimp cd gimp ./autogen.sh --prefix=/home/barak/gimp-2-7 make make install the problem is that the linux system I use on the computer labs at doesn't have autogen (and some other tools required for the compilation) installed, and in order to install it to the main directory I need administrator rights. Is there any way to specify other directories for tools such as autogen? I tried extracting it to /vol/scratch (The scratch disk, since the home-folders are very limited in disk space) and then to add it to the PATH but it didn't work. (I'll try it again next time). If the compilation can be done on /vol/scratch I have enough space to install all the missing scripts (such as autogen) on my homefolder. The problem is that I don't know how to do that. Any tips/help? ~Barak ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Need feedback for the new PDF plugin
Hello, I forgot that there is a tarball (2.7 means a tarball - Yey!) - I'll try it as soon as I can. Back on topic, I'll submit the modified plugin today (I'll merge both procedures and use 2.8 api) so you can see it. ~Barak ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Need feedback for the new PDF plugin
Hello martin, Where should I register the procedure for creating multiple paged PDFs? I switched the plugin to use the gimp_export_dialog as part of the new export api, but I don't know what is the correct place to register a file saver from the menu The problem is that I doubt it's right to have the user choose one of two procedures when saving with a .pdf suffix. The multiple paged PDF is some sort of a wizard since the user can configure which images to save and how - and it doesn't relate to just one specific image... Thank, ~ LightningIsMyName On Thu, Aug 20, 2009 at 10:47 PM, Martin Nordholtsense...@gmail.com wrote: On 08/20/2009 06:09 PM, LightningIsMyName wrote: Hello, As requested in http://bugzilla.gnome.org/show_bug.cgi?id=382688 I have created a PDF export plugin for GIMP. I need some feedback on it (mainly on it's GUI) so I'm asking for it here. The plugin can be accessed through File-Create-PDF (Both multipage and singlepage options) or through the normal save dialog (single page, simply add the .pdf suffix). The first thing to do would be to port it to File - Export... in git master using gimp_export_dialog_new() and gimp_export_dialog_get_content_area(). Look at how the other file plug-ins does it. BR, Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Need feedback for the new PDF plugin
Hello Martin, The problem is that if I add the multiple paged PDF as an option to the normal sace procedure we will have a problem when running the plugin using GIMP_RUN_WITH_LAST_VALS. Imagine the following Scenario: * User has images 1 2 3 open * While image 1 is active, the user now uses the procedure for creating multipage PDFs on images 2 and 3 * The user modifies image 1 again, and wants to export it as a single paged PDF. However he will now have image 2 and 3 and he will have to remove them in order to add image 1. * The user modified image 2 and now we wants to export image 2 and 3 again as a PDF. He will have to add them again. The problem is that the multipage procedure should be non-related to the single-page save procedure since these are different tasks. I have only one solution which can solve our problem but I want to hear your opinion about it: 1. Merge the gui both procedures, and make the view of the multipage procedure hidden inside a GtkExpander. 2. Behaviour will be configure like this: a. When the expander is not expanded, only the options for the single page export will be visible, and it will behave as a single page export. b.When the expander is expanded, it will behave as the multipage export and will export the all the images in the GtkIconView. 3. In case of GIMP_RUN_WITH_LAST_VALS it will be assumed that the expander is hidden and it's a single page export. 4. We should make sure that if the multipage procedure was used the image will still be marked as unsaved somehow (Does the new export api causes images to still be marked as unsaved when using the Export function? If so, this solves our problem :D) ~Barak On Fri, Aug 21, 2009 at 7:29 PM, Martin Nordholtsense...@gmail.com wrote: Can't the multi-page variant simply be an option in the File - Export... dialog somehow? Like, you would specify what additional images to put in the multi-page PDF ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Need feedback for the new PDF plugin
Hello, As requested in http://bugzilla.gnome.org/show_bug.cgi?id=382688 I have created a PDF export plugin for GIMP. I need some feedback on it (mainly on it's GUI) so I'm asking for it here. The plugin can be accessed through File-Create-PDF (Both multipage and singlepage options) or through the normal save dialog (single page, simply add the .pdf suffix). The plugin uses cairo to output the PDF so only features that are available in cairo can be used by the plugin. It builds on my GIMP 2.6.4 so it should work on later versions, The source can be found on the bug report. To get the compiler flags, use 'pkg-config --cflags --libs gtk+-2.0 cairo-pdf gimp-2.0 gimpui-2.0 gimpthumb-2.0'. The plugin is only one file, so it should be easy to compile. Known Issues: 1. Grayscale layers are inverted (although layer masks which are not grayscale,are not inverted) 2. Exporting some fonts doesn't work since gimp_text_layer_get_font Returns a font which is sometimes incompatible with pango_font_description_from_string (gimp_text_layer_get_font sometimes returns suffixes such as semi-expanded to the font's name although the GIMP's font selection dialog shows the name normally - This should be checked again in GIMP 2.7) 3. Indexed layers can't be optimized yet (Since gimp_histogram won't work on indexed layers) Thanks, ~ LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where is the code which is called when mask is selected?
Hello, I do believe that the code is here: http://git.gnome.org/cgit/gimp/tree/app/widgets/gimplayertreeview.c#n1375 It's the gimp_layer_tree_view_mask_clicked function inside app/widgets/gimplayertreeview.c You can see it's signal connected here http://git.gnome.org/cgit/gimp/tree/app/widgets/gimplayertreeview.c#n398 On Wed, Aug 19, 2009 at 10:33 PM, Christopher Howardchow...@indicium.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I wanted to fix trivial bug #563770. I won't bore you with all the details, but I suspect the problem lies somewhere in the code that is called when the user selects the layer mask rectangle inside the layers dialog. In other words, after the user adds a mask to a layer, a small layer mask preview box (icon?) appears to the right of the visibility icon and the small layer preview box, and I think the bug is being caused by something that occurs when the user presses this layer mask preview box. However, I am having trouble finding that code. I have been tracing function calls in gimplayertreeview.c, layers-actions.c, layer-add-mask-dialog.c, gimplayer.c, and elsewhere trying to find the right signal-slot connection or the relevant function but I somehow keep missing it or failing to recognize it. Could someone point me in the right direction? - -- Christopher Howard http://indicium.us http://theologia.indicium.us I digitally sign /all/ my e-mails via PGP. If you receive any e-mail supposedly from me without my valid PGP digital signature, please take additional steps to verify the authenticity of the message. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqMU6QACgkQQ5FLNdi0BcWQmwCffWYBV2HPdzDXcGyv0XvlrQSg QRYAoJfAm/PHz31X2H2cAjATOJW+jbxB =yMMy -END PGP SIGNATURE- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP plugin for windows
Hello, I can try to compile this tomrrow, since the page you gave says it shouldn't be a problem if you can build other gimp plugins (and I can build other plugins). However, can you please tell us what were the errors you encountered during compilation? If so, We might be able to help you in compiling the plugin. LightningIsMyName 2009/8/17 Matthias Röttger mat...@gmail.com: Hello folks, One of my colleagues needs the “DBP” (David’s Batch Processor) for GIMP. http://members.ozemail.com.au/~hodsond/dbp.html I was not able to compile the source on windows XP professional. Has someone of you the capability to compile the DBP source for windows. Thank in advance! Kind Regards Matthias ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Renaming scripts/plugins in a standard way
Hello, I have seen the question of how to give a name for a script/plugin in many places, and most recently here: http://bugzilla.gnome.org/show_bug.cgi?id=588755#c10 Although there are no standard naming rules, I suggest that we styart to use strict naming rules. For example - script-fu-3dtruchet. Without reading the exact description, you would have no idea whether it works on an image, a layer, whether ir creates something new, etc. Another example plug-in-spheredesigner. It is unclear from the name whether it works on an active layer, or whether it creates a new image/layer. Now, if we decide that this is obvious and that all plugins do work on the same layer unless it was specified otherwise, then plug-in-film for example, does not match with this standard (since it creates a new image). most gimp plug-ins should be renamed, to be plug-in-render-XXX, plug-in-distort-XXX, script-fu-ctreate-XXX, etc. I know that this will probably break hundreds of scripts and plugins, so it would be hard to do. My suggestion (which is the only way in which I can see how no API uses will be broken) is to allow from now on for each script/pattern to register in two ways 1. The normal usual way 2. A suuport old usage way, which registers a script/plugin so it won't be viewed in the procedure browser, but it would still be there. A script which wasn't updated (or doesn't need updating) will continue to show in the procedure browser, and scripts/plugins that use method 2. will be able to register procedures for depreceated usage by registering to a depreceated procedure browser (the database of procedures will be shared between the two procedure browsers, however from now on the gui of the procedure browser will show only non-depreceated functions unless specified to show both). gimp_install_procedure will continue to work in the usual way, and gimp_install_depreceated_procedure (this is the new suggested function) will register a depreceated procedure. This way, we don't brake anything and it will make new plugin/script writers start using the new procedures since they will see only the new procedures. Thoughts/Comments? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Uncomitted patches
Hello, I have posted several patches for GIMP which only need to be applied, However I see that they haven't recieved a response for about 2 months. I know that the developers are busy, but I at least want to know that someone noticed these and that they are somewhere on the list of things to be done. A palettte export script to close a four year old feature request (Souce is attached) - http://bugzilla.gnome.org/show_bug.cgi?id=304399 A fix for the bug in the sphere designer plugin (patch is attached) - http://bugzilla.gnome.org/show_bug.cgi?id=582821 Note that for the sphere designer, the patch is in gnu diff since I couldn't create a working git repository of gimp (I had issues with git) If any changes need to be done for the patches and this is the cause for the delay, or if there is any way I can apply the patches myself to the source please tell me and I'll do so. Thanks, ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Uncomitted patches
Hi Martin, Thanks for your response. I'll be on a computer with git somewhere in the next week, and then I'll resubmit the patches. And about the palette script, I do believe it should be included since if we have a palette import built in (for CSS, and for adobe .aco files) there is nothing wrong in having the palette export script included as well. Thanks for your help, On Wed, Jul 15, 2009 at 12:25 PM, Martin Nordholtsense...@gmail.com wrote: On 07/15/2009 11:04 AM, LightningIsMyName wrote: Hello, I have posted several patches for GIMP which only need to be applied, However I see that they haven't recieved a response for about 2 months. I know that the developers are busy, but I at least want to know that someone noticed these and that they are somewhere on the list of things to be done. A palettte export script to close a four year old feature request (Souce is attached) - http://bugzilla.gnome.org/show_bug.cgi?id=304399 A fix for the bug in the sphere designer plugin (patch is attached) - http://bugzilla.gnome.org/show_bug.cgi?id=582821 Note that for the sphere designer, the patch is in gnu diff since I couldn't create a working git repository of gimp (I had issues with git) If any changes need to be done for the patches and this is the cause for the delay, or if there is any way I can apply the patches myself to the source please tell me and I'll do so. Hi, The sphere designer patch looks trivial. With risk of coming across as lazy, could you reattach that patch as a git commit with git-format-patch please? Having patches as git commits makes them about twice as convenient for maintainers to apply. The same goes for the palette export script. The palette export script looks like good code to me after a quick look. I just wonder if that script shouldn't be offered as a third-party plug-in. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Should we add the option to use brush dynamics from the PDB?
Hello, Gimp 2.6 allows to use brush dynamics to control opacity, size, hard and color. These features greatly increase the drawing capabilities of gimp, and many users find them very useful. However, we don't have any way to access these from inside the PDB... I think that it would be nice to be able to access these using the PDB, however I'm not sure about the right method: Do we want to allow the user to specify velocity, and pressure for each coord, or should we use the emulate brush dynamics feature (the same one we have in the libart stroking)? Personally, I believe that the emulate brush dynamics is the right method. I'm willing to try to write a patch to add this for gimp-paintbrush, gimp-airbrush, etc. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should we add the option to use brush dynamics from the PDB?
Hello, On Sun, Apr 26, 2009 at 1:43 PM, David Gowers 00a...@gmail.com wrote: I'm willing to try to write a patch to add this for gimp-paintbrush, gimp-airbrush, etc. Do you understand that you must not change the api of gimp-paintbrush, gimp-airbrush, etc? Because that would break a lot of scripts and plugins. This is part of the problem with the current PDB interface to tools; supporting new options must be done through additional PDB functions. David I understand that, we obviously mustn't change the old API. What I meant was to create something like gimp-paintbrush-wtih-dynamics. The question is, when and how do we want to do this? Do we want to give some sort of option now, and we will replace it when we move to GEGL painting, or should we wait? I would like to see it implemented before 2.8 if possible, however If we need to wait with this, i'll wait. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
Hello again, On Sat, Mar 21, 2009 at 11:15 AM, Sven Neumann s...@gimp.org wrote: Hi, On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote: 1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of). Why would we want to allow the user to create multi-paged PDF files? Perhaps, before anything else, we need to clearly define what the purpose of PDF export is. We certainly don't want to provide a tool to create an illustrated book. That's what page layout applications are used for. I believe that we should have the option to export multi-paged PDFs, since we have the option to import them, and to me it makes sense that we should be able to export what we can import. Gimp may not be a page-layout program, yet doing multi-paged PDFs isn't too hard, and won't hurt anyone... And about what you said on page layout tools, there is some sense in what you said. Therfore, I think it would be indeed simpler to ignore paths untill gimp has vector layers, since these aren't the main point of the PDF plugin. The only feature I believe that is necessary, is to draw single-colored rectangles as drawing and not as bitmap-images (Imagine a background layer for a large scale image - a bitmap image can be a big waist of memory). However, this can be solved easily by finding all the layers in the image which have only 1 color (same RGBA values everywhere). I still need to figure out how to do this (probably using gimp_histogram in some way). -- LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: GIMP PDF export plugin
Hello, On Fri, Mar 20, 2009 at 7:53 PM, Sven Neumann s...@gimp.org wrote: Hi, On Fri, 2009-03-20 at 19:15 +0200, Lightning LIMN wrote: Why so complex? You can have a look at the Print plug-in to see how to transfer the image projection to a Cairo surface without the need to save as PNG. Thanks Sven, I haven't known that. I found what I needed in print-preview.c, and I'll try this code out soon. I should be able to build a small demo that does default printing for layers and text as one image, however there are several questions we should consider: 1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of). 2. PDFs don't have anything such as transperent backgrounds for the pages. Should we ask the user for a background color for each page, or should we get the background color from the current gimp context? (Or mayber we should simply make it white) 3. When drawing paths, how should we ask the user where to draw each path? Also, how will he tell us how to fill/stroke it? Abusing the layer names doesn't sound right, and it won't be user-friendly if he would need to manually relocate his paths inside the plugin's preview... The only solution I can see for handling this would be to wait for vector layers in GIMP, however I haven't heard of any recent progress in this direction. -- LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
