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

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.

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

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

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

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"

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..

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

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"

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?

Martin Nordholts (enselic@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.

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.

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"

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.

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

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

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

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

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)