Re: [Gimp-developer] GIMP Developer Meeting
> > Interaction with new usability team? > Yes, please. ;-) If possible, please kindly consider scheduling the meeting before May 21st or after May 29th. I will be on vacation during that time. ___ 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
On 5/2/11, LightningIsMyName wrote: > 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...) +1 > - 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. +1, the discussion at gimp-web@ so far is a failure > - More? Interaction with new usability team? Alexandre Prokoudine http://libregraphicsworld.org ___ 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,
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]
On Mon, Apr 18, 2011 at 7:01 PM, Alexia Death wrote: > be 18:40GMT for GSoC meeting and 19:00GMT for dev meeting. If there Silly me. 17:40GMT and 18:00 GMT that is. > http://www.timeanddate.com/worldclock/fixedtime.html?msg=GIMP+Developer+Meeting+%234&iso=20110419T18 > > World clock times for the dev meeting. This is correct. -- --Alexia ___ 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]
Hi, During IRC conversation it was decided that moving by 3 hours would run into workday for some key people so the new suggested times would be 18:40GMT for GSoC meeting and 19:00GMT for dev meeting. If there are no major protests on these times, lets consider the meeting moved. http://www.timeanddate.com/worldclock/fixedtime.html?msg=GIMP+Developer+Meeting+%234&iso=20110419T18 World clock times for the dev meeting. -- --Alexia ___ 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]
LightningIsMyName wrote: > 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. 1700 GMT is 1pm local time in the eastern time zone of Canada. I'm ok with that unless I wind up having a late lunch (which happens on occasion). ___ 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 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
Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting]
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
Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting]
- Forwarded message from Mukund Sivaraman - Date: Mon, 18 Apr 2011 07:28:06 +0530 From: Mukund Sivaraman To: LightningIsMyName Cc: gimp-developer Subject: Re: [Gimp-developer] GIMP Developer Meeting #4 + GSoC Mentor/Admin Meeting User-Agent: Mutt/1.5.21 (2010-09-15) Hi LightningIsMyName On Sun, Apr 17, 2011 at 11:39:05PM +0300, LightningIsMyName wrote: > 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+%234&iso=20110419T20 > As usual, the meeting will take place on #gimp-devel 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. :) Mukund - End forwarded message - pgpfZzrbQVBQF.pgp Description: PGP signature ___ 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+%234&iso=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.com&ctz=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
> On 2011-03-29 14:09, LightningIsMyName wrote: >> ** 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. > > So you set the quality slider to 95 to ensure files will be big, but set > sampling to 2x1 to ensure the image quality will be poor? I don't see > the sense in this. > > Also the JPEG export plug-in has had a stored default for years. What > are you trying to add? > > Note that if the source file is JPEG the plug-in offers similar settings > to the originating file by default. You can still click "load defaults" > to override it. I did a couple of quick tests with an image with photos and design elements (type and areas with solid fill) and I got better results both in overall quality and file size using 1x1 and smaller quality factors than using worse subsampling and higher quality factors. In my test the best relationship between quality and filesize was using quality=92, subsampling=1x1 and floating point for the DCT method. The resulting file was smaller than the ones I exported with quality set in 95 and 2x1 or 2x2 for subsampling. with 1x1 subsampling and quality set in 90 the edge artifacts in type and solid fill areas became visible but the edges were sharp as in the original. The photo didn't show any noticeable compression artifacts. That's completely different with 2x1 and 2x2 subsamplings. All the edges became softer and when the quality factor is high enough to avoid compression artifacts the resulting file is larger than when 1x1 was used. So I'd suggest a different default quality setting for jpg: 92 / 1x1 / floating point. If file size matters (the size gain isn't too significative, but still), a quality factor of 90 will still give considerably better quality than the current defaults. >>and add a hack to save defaults (using something >> like the PNG plugin does, or something more elegant) I don't understand what's missing in the current implementation. I could change my defaults and store the new configuration as default through the advanced options of the jpeg export plugin (in 2.6.x) ___ 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
On 3/29/11, Michael Natterer wrote: > On 03/29/2011 06:54 PM, Alexandre Prokoudine wrote: >> On 3/29/11, Michael Natterer wrote: >> >>> As I said before, let's please work on our public interface >> >> Let's try to outline what exactly needs doing, eh? :) > > - Website updates I think I could add recent books, including the one from Packt. > - News > - Wiki Discussed above and below > - Blogs > - Maybe we should have a GIMP blog aggregator? We used to have layers.gimp.org exactly for that, but it's gone. I think we can reuse infrastructure from graphicsplanet.org that Mukund and me maintain. Any suggestions on URL? Maybe simply blogs.gimp.org? > - More frequent developer releases (my fault, I know) Since you insist :D >> The new website is stuck in the middle mostly because AFAIK Jimmac was >> busy all the time with GNOME 3 which is finally soon to be out, so >> maybe Jakub will have more spare time to finish this now. > > I think Jimmac is pretty busy, so maybe somebody should pick up the > work. Also, I don't think we absolutely need a new website, just > a few people who can trigger website updates after something has > been pushed to git, at least as long as auto-updates are broken. > I'll poke Sven about that. Can't this be automated? >> The wiki transition seems to be stuck as well. What exactly has to be >> done? > > I'm in contact with Shawn, and the DNS entry should point to > Alexia's wiki soon. Cool Alexandre Prokoudine http://libregraphicsworld.org ___ 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
On 03/29/2011 06:54 PM, Alexandre Prokoudine wrote: > On 3/29/11, Michael Natterer wrote: > >> As I said before, let's please work on our public interface > > Let's try to outline what exactly needs doing, eh? :) - Website updates - News - Wiki - Blogs - Maybe we should have a GIMP blog aggregator? - More frequent developer releases (my fault, I know) > The new website is stuck in the middle mostly because AFAIK Jimmac was > busy all the time with GNOME 3 which is finally soon to be out, so > maybe Jakub will have more spare time to finish this now. I think Jimmac is pretty busy, so maybe somebody should pick up the work. Also, I don't think we absolutely need a new website, just a few people who can trigger website updates after something has been pushed to git, at least as long as auto-updates are broken. I'll poke Sven about that. > The wiki transition seems to be stuck as well. What exactly has to be done? I'm in contact with Shawn, and the DNS entry should point to Alexia's wiki soon. > The news is what I already take care of. That much appreciated :) > What else has to be done apart from that? Whatever people are capable and wanting to do :) Everybody involved with the project is invited to join the effort. ciao, --Mitch ___ 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
On 3/29/11, Michael Natterer wrote: > As I said before, let's please work on our public interface Let's try to outline what exactly needs doing, eh? :) The new website is stuck in the middle mostly because AFAIK Jimmac was busy all the time with GNOME 3 which is finally soon to be out, so maybe Jakub will have more spare time to finish this now. The wiki transition seems to be stuck as well. What exactly has to be done? The news is what I already take care of. What else has to be done apart from that? Alexandre Prokoudine http://libregraphicsworld.org ___ 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
On 03/29/2011 02:45 PM, Martin Nordholts wrote: > 2011/3/29 LightningIsMyName: >> ** 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). > > Hi, > > Unfortunately I couldn't attend the meeting and affect the outcome of > the discussion, but I still want to comment on it: > > GObject C boilerplate is a general productivity problem not bound to > any specific kind of code, it doesn't make sense to treat core and UI > code differently. Right, it doesn't make sense to make a difference here. And the summary doesn't quite reflect the result of the discussion. Regarding productivity: I don't know how you measure "more productive" on a scale from zero to zero. There is simply not much contribution currently, and blaming GObject for that is lame, and attempting a fix where you earlier put the blame is activism. As I said before, let's please work on our public interface, That maybe has the potential of attracting new developers. I already gave the reasons why I think adding another language won't. > Regarding code generators: that's basically how we will use Vala, I > don't see why e.g. turbine would be better to use for this. Turbine is a comfortable replacement for: - copy existing class with SameNumberOfWords - do s/OldName/NewName/ and s/old_name/new_name/ - remove junk - skeleton done Vala is a programming language and *not* a code generator. You also don't consider gcc a code generator because it has some internal representation in between C and machine code. ciao, --Mitch ___ 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
On 2011-03-29 14:09, LightningIsMyName wrote: > ** 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. So you set the quality slider to 95 to ensure files will be big, but set sampling to 2x1 to ensure the image quality will be poor? I don't see the sense in this. Also the JPEG export plug-in has had a stored default for years. What are you trying to add? Note that if the source file is JPEG the plug-in offers similar settings to the originating file by default. You can still click "load defaults" to override it. ___ 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
2011/3/29 LightningIsMyName : > ** 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). Hi, Unfortunately I couldn't attend the meeting and affect the outcome of the discussion, but I still want to comment on it: GObject C boilerplate is a general productivity problem not bound to any specific kind of code, it doesn't make sense to treat core and UI code differently. Regarding code generators: that's basically how we will use Vala, I don't see why e.g. turbine would be better to use for this. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ "Why GIMP 2.8 is not released yet" ___ 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 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
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
Alexandre Prokoudine wrote: > It has *something* to do with too much gobject boilerplate code. 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. 1. Don't use gObject. Just including this for completeness since it is very unlikely to happen. 2. "Fix" gObject. Update/improve gObject so it doesn't require so much (or any?) boilerplate code. I've been looking at two other OOP languages and haven't seen the need for boilerplate code. If its needed with gObject its either a design issue of gObject or due to the complexity of GIMP objects. 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. 6. Use some other programming language to avoid having to write boilerplate code. This option is really just another way to avoid having to write boilerplate code by hand. If vala (or language x) is used to avoid the need for all the boilerplate code there are still a number of issues: 1. Time to learn gObject vs. time to learn vala 2. Time to change code to be vala based instead of raw gObject. - Need to know both system while migration is taking place 3. How many GIMP developers can write code in vala? 4. How many GIMP developers who know vala are free to work on the migration? 5. How much of GIMP would need to be updated/modified/rewritten in vala? I think throwing another language in to the mix is the wrong way to address the boilerplate issue. ___ 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
Martin Nordholts (ense...@gmail.com) wrote: > 2011/3/27 Michael Natterer : > > And this is *exactly* the problem. We would end up with programmers > > that quickly learnt vala, having no clue about GObject. That's > > absolutely horrible. > > How is it a problem that our code becomes so easy that even "dumb" > programmers can understand and improve it when we are not forced to > include patches from such "dumb" programmers? They're bound to hit problems that out of their scope, leaving them perplexed. My experience with vala is deeply tainted by the (now resolved) bug https://bugzilla.gnome.org/show_bug.cgi?id=587683 Bye, Simon PS: I don't like how you rephrase mitch's argument with offending words. -- si...@budig.de http://simon.budig.de/ ___ 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
On Mon, Mar 28, 2011 at 10:26 AM, Martin Nordholts wrote: > How is it a problem that our code becomes so easy that even "dumb" > programmers can understand and improve it when we are not forced to > include patches from such "dumb" programmers? This not how I understood mitch... I understood it as a valid concern that if basics are hidden way another layer new contributors never learn basics at all. And where that leads I have seen on some java developers first hand. It leads to My personal option is sort of split on this. On one hand less there is boilerplate code, less there are chances of making white-space errors, on the other... I looked into to the pdb recently... The perl generator code there was a huge hindrance to understanding and writing the code plus what mitch talked about. For me personally the GObject boilerplate never was an issue. There was plenty of code to copy-paste from even if I did not understand it completely. Besides, you ever write it once per class and if it changes it's a lot of quick and straightforward fixes. What is an issue is UI maintenance. Having to manually stack GTK containers without any preview is absolute pain. Once I used glade to get my structure right and then translated it into code... So whats wrong with finding away to make use of the GTKBuilder more? -- --Alexia ___ 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
2011/3/27 Michael Natterer : > On 03/27/2011 04:45 PM, Martin Nordholts wrote: >> >> On 03/27/2011 02:12 PM, Michael Natterer wrote: >>> >>> As to the actual iussue of introducing whatever *additional* >>> language in GIMP, I strongly doubt that it would help us in >>> any way. It would increase the complexity of both building and >>> programming because there would be two languages to learn, >>> it would complicate the build system (new contributors >>> would also have to learn to deal with autofoo makefiles dealing >>> with both C and vala code). It would increase the barrier of >>> getting new contributors into the project, not lower it. >> >> It's funny, because I see it the other way around. With infrastructure >> for and knowledge about how to use Vala in GIMP, the barriers of >> getting new contributors is lowered, because they don't need to learn >> GObject C boilerplate before writing code. Assuming of course that >> most of our code is in Vala already... > > And this is *exactly* the problem. We would end up with programmers > that quickly learnt vala, having no clue about GObject. That's > absolutely horrible. Just like the people who only know how > to write java or #C code. They know how to use all the fancy > classes, but they have never implemented a list or anything > lowlevel themselves. I don't want people who know vala, but > don't "had to learn" GObject. Absolutely not. Knowing the > foundations is an absolute prerequisite for any serious > programming. How is it a problem that our code becomes so easy that even "dumb" programmers can understand and improve it when we are not forced to include patches from such "dumb" programmers? Why would an open source project have as a goal to keep its code complex in order to limit the set of people that are able to help out, especially a project that wants more people to contribute? Besides, it is not only "dumb" programmers that uses higher-level languages such as C# and Java. / Martin -- My GIMP Blog: http://www.chromecode.com/ "Why GIMP 2.8 is not released yet" ___ 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
On 03/27/2011 04:45 PM, Martin Nordholts wrote: > On 03/27/2011 02:12 PM, Michael Natterer wrote: >> >> As to the actual iussue of introducing whatever *additional* >> language in GIMP, I strongly doubt that it would help us in >> any way. It would increase the complexity of both building and >> programming because there would be two languages to learn, >> it would complicate the build system (new contributors >> would also have to learn to deal with autofoo makefiles dealing >> with both C and vala code). It would increase the barrier of >> getting new contributors into the project, not lower it. > > It's funny, because I see it the other way around. With infrastructure > for and knowledge about how to use Vala in GIMP, the barriers of > getting new contributors is lowered, because they don't need to learn > GObject C boilerplate before writing code. Assuming of course that > most of our code is in Vala already... And this is *exactly* the problem. We would end up with programmers that quickly learnt vala, having no clue about GObject. That's absolutely horrible. Just like the people who only know how to write java or #C code. They know how to use all the fancy classes, but they have never implemented a list or anything lowlevel themselves. I don't want people who know vala, but don't "had to learn" GObject. Absolutely not. Knowing the foundations is an absolute prerequisite for any serious programming. ciao, --Mitch ___ 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
Hi, On Sun, Mar 27, 2011 at 3:12 PM, Michael Natterer wrote: > So when you write code, how much time do you spend writing the > boilerplate? 10%? I would say it's much much less, because writing > the code is a small fraction of the time actually spent on the code, > the rest is debugging, refactoring, reading and reading it over > and over again. The percentage of writing the actual boilerplate > rapidly drops to a few percent. Isn't debugging, refactoring and code reading (finding references, going to definition, etc etc -- noone reads code like a book, right?) many times faster in Java or C# IDEs ? AFAIK Vala could be integrated into IDEs (Eclipse, Monodevelop, Valide) in a similar way as Java or C# and provide many benefits that most of the developers use for many years already.. ___ 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
On 03/27/2011 02:12 PM, Michael Natterer wrote: > > So when you write code, how much time do you spend writing the > boilerplate? 10%? I would say it's much much less, because writing > the code is a small fraction of the time actually spent on the code, > the rest is debugging, refactoring, reading and reading it over > and over again. The percentage of writing the actual boilerplate > rapidly drops to a few percent. I don't have any exact figures, but it takes enough time to make it annoying. Also don't forget to look at this from the point of view from someone who doesn't know anything about GObject boilerplate code. It is quite an obstacle to climb over, not only to be able to write GObject boiler plate fluently, but also to read it fluently. This becomes especially problematic in the context of "temporary" contributions such as GSoC, where a substantial amount of the initial time in a project is spent on getting students up to speed on how GObject works. > And what are "things that benefit our users" we could do instead? > Thats a complete non-statement. Programming a complex thing > like GIMP is hard, no matter how supposedly "easy" you make > the programming language. I meant that instead writing boilerplate, we and others can write code that adds actual functionality. > The "problem" is not the programming language, or GObject, it's > simply the complexity of GIMP's object system, and that complexity > is unfortunately unavoidable, and is not going to decrease by > adding another layer to it. Vala is not another layer, it's just another way to write GObject code where the boiler plate is taken care of by the valac compiler. And I don't see the GIMP object system as very complex, it is what you'd expect for a program like GIMP. I actually often find myself reluctant to add new classes because of all the extra work the boiler plate requires. This isn't a healthy situation; adding new classes should be effortless. > I often hear how well the GIMP source is structured, and people > point others to GIMP as an example of properly done code. That's > a reputation which is not going to improve by adding another > fringe language. The GIMP code *is* well structured, but I don't see how that is an argument either way. I don't want to add Vala to bring structure into the code, I want to add Vala to get rid of all the boiler plate code. > As to the actual iussue of introducing whatever *additional* > language in GIMP, I strongly doubt that it would help us in > any way. It would increase the complexity of both building and > programming because there would be two languages to learn, > it would complicate the build system (new contributors > would also have to learn to deal with autofoo makefiles dealing > with both C and vala code). It would increase the barrier of > getting new contributors into the project, not lower it. It's funny, because I see it the other way around. With infrastructure for and knowledge about how to use Vala in GIMP, the barriers of getting new contributors is lowered, because they don't need to learn GObject C boilerplate before writing code. Assuming of course that most of our code is in Vala already... / Martin -- My GIMP Blog: http://www.chromecode.com/ "Why GIMP 2.8 is not released yet" ___ 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
On 03/27/2011 11:36 AM, Martin Nordholts wrote: > 2011/3/27 Kevin Cozens: >> LightningIsMyName wrote: >>> *** 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). >> >> Before talking about which new programming language is needed(?) in GIMP we >> should make sure the problem is clearly defined as to *why* we need >> something new. What problem is the new language going to solve? >> >> IIRC, it had something to do with creation of GUI stuff (such as dialog >> boxes?). If that is the case, the language should be irrelavant. There are >> other tools that can be used to more easily make a GUI. One that comes to >> mind is a tool like Glade that can generate a file that can be used with >> with a library (GtkBuilder?) to show the contents of the file. >> >> I may be completely off base here because I haven't heard a clear definition >> of the problem. As I already mentioned before. I am very much against the introduction of another language into the GIMP core. > The problem with using C for everything is that we have to spend time > on managing boilerplate GObject C code, like manually initialize > vtables for example. We could spend this time doing things that > benefits our users instead. So when you write code, how much time do you spend writing the boilerplate? 10%? I would say it's much much less, because writing the code is a small fraction of the time actually spent on the code, the rest is debugging, refactoring, reading and reading it over and over again. The percentage of writing the actual boilerplate rapidly drops to a few percent. And what are "things that benefit our users" we could do instead? Thats a complete non-statement. Programming a complex thing like GIMP is hard, no matter how supposedly "easy" you make the programming language. The "problem" is not the programming language, or GObject, it's simply the complexity of GIMP's object system, and that complexity is unfortunately unavoidable, and is not going to decrease by adding another layer to it. And programming in general is *hard* to do right, and whoever is not capable of doing it should rather stay away from it. Yes, there is an entry barrier due to GObject, but as our experience with the last few years of GSoC, and various new contributors has shown, that was never the problem. They all end up writing more-or-less proper GObject code. The problem in their code is simply the lack of understanding for GIMP's object system, and that lack is *completely*normal* and natural given how complex GIMP is. They all get better if they stick with the project, which is also completely normal. I often hear how well the GIMP source is structured, and people point others to GIMP as an example of properly done code. That's a reputation which is not going to improve by adding another fringe language. As to the actual iussue of introducing whatever *additional* language in GIMP, I strongly doubt that it would help us in any way. It would increase the complexity of both building and programming because there would be two languages to learn, it would complicate the build system (new contributors would also have to learn to deal with autofoo makefiles dealing with both C and vala code). It would increase the barrier of getting new contributors into the project, not lower it. > When I get time, I will port GimpTag to Vala so we can see how the > introduction of Vala affects our codebase, autotools etc. If we bump > into a lot of problems, we can drop the idea of using Vala in GIMP, > but if it turns out we can become more productive by using Vala, we > should start using Vala more. Yes we should get more productive, but adding a new language should acheive that? We should rather work on our public interface, which is the web page, the wiki, the devel web page. All that stuff is not really active. If we have a hard time finding people who are willing to do this (and a lot of people are capable of doing web stuff), how is increasing the complexity of the GIMP core going to help us in any way? Introducing development tools like automated tests, or the build system you set up (did I say thanks for that already?) does indeed help a lot. Adding another language to the core in an attack of activism doesn't. ciao, --Mitch ___ 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
2011/3/27 Kevin Cozens : > LightningIsMyName wrote: >> *** 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). > > Before talking about which new programming language is needed(?) in GIMP we > should make sure the problem is clearly defined as to *why* we need > something new. What problem is the new language going to solve? > > IIRC, it had something to do with creation of GUI stuff (such as dialog > boxes?). If that is the case, the language should be irrelavant. There are > other tools that can be used to more easily make a GUI. One that comes to > mind is a tool like Glade that can generate a file that can be used with > with a library (GtkBuilder?) to show the contents of the file. > > I may be completely off base here because I haven't heard a clear definition > of the problem. The problem with using C for everything is that we have to spend time on managing boilerplate GObject C code, like manually initialize vtables for example. We could spend this time doing things that benefits our users instead. When I get time, I will port GimpTag to Vala so we can see how the introduction of Vala affects our codebase, autotools etc. If we bump into a lot of problems, we can drop the idea of using Vala in GIMP, but if it turns out we can become more productive by using Vala, we should start using Vala more. / Martin -- My GIMP Blog: http://www.chromecode.com/ "Why GIMP 2.8 is not released yet" ___ 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
On 3/27/11, Kevin Cozens wrote: > Before talking about which new programming language is needed(?) in GIMP we > should make sure the problem is clearly defined as to *why* we need > something new. What problem is the new language going to solve? > > IIRC, it had something to do with creation of GUI stuff It has *something* to do with too much gobject boilerplate code. Alexandre Prokoudine http://libregraphicsworld.org ___ 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
LightningIsMyName wrote: > *** 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). Before talking about which new programming language is needed(?) in GIMP we should make sure the problem is clearly defined as to *why* we need something new. What problem is the new language going to solve? IIRC, it had something to do with creation of GUI stuff (such as dialog boxes?). If that is the case, the language should be irrelavant. There are other tools that can be used to more easily make a GUI. One that comes to mind is a tool like Glade that can generate a file that can be used with with a library (GtkBuilder?) to show the contents of the file. I may be completely off base here because I haven't heard a clear definition of the problem. ___ 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
On 03/25/2011 02:31 PM, LightningIsMyName wrote: > *** 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). Hi, What's the status of making wiki.gimp.org resolve to gimp-wiki.who.ee so e.g. the roadmap URL becomes http://wiki.gimp.org/index.php/GIMP_Roadmap rather than the current http://gimp-wiki.who.ee/index.php/GIMP_Roadmap ? Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ "Why GIMP 2.8 is not released yet" ___ 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=3&day=28&year=2011&hour=22&min=0&sec=0&p1=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
[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 developer meeting
Hi, 2011/3/6 Łukasz Czerwiński : > > > On Tue, Mar 1, 2011 at 00:22, LightningIsMyName > 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] 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 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=2&day=28&year=2011&hour=22&min=0&sec=0&p1=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=%23gimp&server=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
On 02/28/2011 07:02 PM, Sven Neumann wrote: > On Mon, 2011-02-28 at 19:38 +0200, Alexia Death wrote: >> Wiki needs an admin that cares, a database and php installed on the >> server. AFAIK there is no gimp host that meets all those requirements, >> specially the admin part. > > Well, the machine that hosts www.gimp.org meets all those requirements. > It has database and PHP installed and if anyone volunteers to become > "the admin that cares", it's no problem to add accounts on the machine. Why don't we migrate gimp-wiki.who.ee to gui.gimp.org and call it wiki.gimp.org instead? Seems unnecessary to administer two wikis. / Martin -- My GIMP Blog: http://www.chromecode.com/ "Why GIMP 2.8 is not released yet" ___ 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
This is happening now in #gimp-development --xsdg Sven Neumann escribió: On Mon, 2011-02-28 at 19:38 +0200, Alexia Death wrote: > On Mon, Feb 28, 2011 at 7:23 PM, Kevin Cozens wrote: > > LightningIsMyName wrote: > >> 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. > > > > We can discuss this more at todays meeting. I would like to know what the > > problem is with having wiki.gimp.org. GIMP has its own website so adding a > > wiki to it should be no problem. Is it a lack of diskspace, lack of someone > > to set it up, or lack of someone who keep an eye on the wiki and maintain it? > > Wiki needs an admin that cares, a database and php installed on the > server. AFAIK there is no gimp host that meets all those requirements, > specially the admin part. Well, the machine that hosts www.gimp.org meets all those requirements. It has database and PHP installed and if anyone volunteers to become "the admin that cares", it's no problem to add accounts on the machine. > I wouldn't put in the same machine as any part of the main gimp site. > Any dynamic site is vulnerable to exploits and hacks. Compromising > such a trivial side thing like the wiki should in no way threaten the > operation of any of the main sites and integrity of a heavily used and > trusted host like gimp.org that could be used to spread malware far > and wide. Well, that's a point. But I guess that one could run such a server in a chroot environment or even a virtual host. Sven_ 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
On Mon, 2011-02-28 at 19:38 +0200, Alexia Death wrote: > On Mon, Feb 28, 2011 at 7:23 PM, Kevin Cozens wrote: > > LightningIsMyName wrote: > >> 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. > > > > We can discuss this more at todays meeting. I would like to know what the > > problem is with having wiki.gimp.org. GIMP has its own website so adding a > > wiki to it should be no problem. Is it a lack of diskspace, lack of someone > > to set it up, or lack of someone who keep an eye on the wiki and maintain > > it? > > Wiki needs an admin that cares, a database and php installed on the > server. AFAIK there is no gimp host that meets all those requirements, > specially the admin part. Well, the machine that hosts www.gimp.org meets all those requirements. It has database and PHP installed and if anyone volunteers to become "the admin that cares", it's no problem to add accounts on the machine. > I wouldn't put in the same machine as any part of the main gimp site. > Any dynamic site is vulnerable to exploits and hacks. Compromising > such a trivial side thing like the wiki should in no way threaten the > operation of any of the main sites and integrity of a heavily used and > trusted host like gimp.org that could be used to spread malware far > and wide. Well, that's a point. But I guess that one could run such a server in a chroot environment or even a virtual host. Sven ___ 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
On Mon, Feb 28, 2011 at 7:23 PM, Kevin Cozens wrote: > LightningIsMyName wrote: >> 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. > > We can discuss this more at todays meeting. I would like to know what the > problem is with having wiki.gimp.org. GIMP has its own website so adding a > wiki to it should be no problem. Is it a lack of diskspace, lack of someone > to set it up, or lack of someone who keep an eye on the wiki and maintain it? Wiki needs an admin that cares, a database and php installed on the server. AFAIK there is no gimp host that meets all those requirements, specially the admin part. Quite aside technical issues that are usually solvable by an install command, there are certain risks to be considered. I wouldn't put in the same machine as any part of the main gimp site. Any dynamic site is vulnerable to exploits and hacks. Compromising such a trivial side thing like the wiki should in no way threaten the operation of any of the main sites and integrity of a heavily used and trusted host like gimp.org that could be used to spread malware far and wide. -- --Alexia ___ 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
LightningIsMyName wrote: > 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. We can discuss this more at todays meeting. I would like to know what the problem is with having wiki.gimp.org. GIMP has its own website so adding a wiki to it should be no problem. Is it a lack of diskspace, lack of someone to set it up, or lack of someone who keep an eye on the wiki and maintain it? ___ 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
On Mon, Feb 28, 2011 at 11:49 AM, LightningIsMyName wrote: > 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. I cant have an extra domain, but redirect(the way bugs.gimp.org points to gnome bugzilla) is free and fine by me and I can afford to host it even if it becomes official I think. I do plan to be traveling also at the time of the meeting, so if all goes well I wont be around for it.However my traveling depends on a person who is notoriously slow so who knows:P -- --Alexia ___ 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 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 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
On 02/28/2011 12:07 AM, LightningIsMyName wrote: > Hello, > > Today (February 28, 2011), at 10pm CET (for time zone conversions, see > http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=28&year=2011&hour=22&min=0&sec=0&p1=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? 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 / Martin -- My GIMP Blog: http://www.chromecode.com/ "Why GIMP 2.8 is not released yet" ___ 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 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
[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=2&day=28&year=2011&hour=22&min=0&sec=0&p1=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=%23gimp&server=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
