Re: [Gimp-developer] Example: Vala as code generator
On Sun, 2011-05-01 at 17:15 +0200, ense...@gmail.com wrote: Hi all, We have discussed the possibility to use Vala as a code generator. What follows is a set of patches so we all can see what that would look like. Any objections to me pushing these commits? Yes, and I'm currently on vacation and can't respond in detail, but IIRC I have made myself very clear about vala. I want a helper class in the implementation of single-window mode session management, and this is in my opinion a perfect example of when to use Vala: a small utility class at the bottom of the architecture with only GLib as a dependency. These patches do not add any additional tarball build time dependencies, valac is only required when building from git. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Example: Vala as code generator
The following statement of Mich's unfortunately describes most of nowadays C.S. students [1] 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. One way of viewing the issue is: Do you want to cater to the programmers you want, or the programmers you have? (With the hope of turning the latter into the former.) Nicolas Robidoux [1] research.cs.queensu.ca/~cisc422/2010f/readings/papers/whereAreTheSoftwareEngineersOfTomorrow.pdf ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Example: Vala as code generator
On Mon, May 2, 2011 at 9:15 AM, Nicolas Robidoux nicolas.robid...@gmail.com wrote: One way of viewing the issue is: Do you want to cater to the programmers you want, or the programmers you have? (With the hope of turning the latter into the former.) It's worse than that, even. This is a perpetual argument. People were railing against C in the 70s because people who weren't programming in assembler weren't intimate with the stack, heap, or registers. They hated the subroutine call inefficiency. They hated losing the ability to dynamically change executing code, or freely use instructions as data. Software development - all engineering, really - is about trades. C imposed a base level of inefficiency for a higher level of productivity. Today, C is a hindrance to even greater productivity (GObject itself is evidence of this). It's less useful to know how to write a hash table interface with its own unique API than it is to know how or when to use one. If a hash table is part of the language, then it becomes the One True Implementation and Everybody knows it and uses it, and does so mostly-correctly. FWIW, to me, Vala seems like a reasonable choice for GObject based systems. I don't think it's going to expand the developer base now because Vala prefers an understanding of GObject, which is little used outside OSS systems. The syntax should be familiar to C/C++/C# users, but the trade here is for productivity. While another language (C++, C# or Java) may have more developers, that language would require an object system be built around GObject, which just raises the question: Why not Vala? One would assume that a stable Vala compiler exists or is currently stable enough to use on all target platforms. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] nonlinear revision control system for GIMP
Hi all, Recently we have published a paper on SIGGRAPH 2011 about nonlinear revision control system for images. You can find the abstract and videos at https://sites.google.com/site/httimchen/2011_imagesvn As described in the abstract, the core idea is to record users' actions and transform it into a DAG representation where nodes are actions and edges there dependency. With the DAG, we are able to implement all important revision control functions, including add, branch, diff, merge. Although our prototype is tightly coupled with GIMP, we design our system for easy porting between different image editing systems. There are three main independent components in our system, image editing software (GIMP), revision control system (GIMP plugin) and renderer (GTK+). And ideally, we can replace any of them if necessary. For now, the most messy part is on the image editing software, i.e. GIMP, in this case. To achieve all fancy functions you saw on the video, the image editing software basically does two things: log user actions (action name, selected region and parameters) and replay the actions. The replay part is simple with libgimp, but the log part is missing in current GIMP. In this project, I implement all these stuffs on my own. And to meet the SIGGRAPH submission deadline, I simply hack the GIMP core by inserting functions that would output the corresponding logs in text into corresponding functions (for example, inserting the output function into the color_balance_config_notify() at app/tools/gimpcolorbalancetool.c to record users' action of applying color balance...etc). And obviously, this is an ugly hack. I would really love to put our system upstream so that everyone can enjoy it and the ultimate goal here is to replace the current backend completely with GEGL. But a much simpler and faster way to do so is probably by implementing some sort of macro system in the GIMP first? So, I am wondering 1) is there anyone implementing the macro/script system and 2) can anyone give me a head start on how should I modify my hack so that it is more readable to others? Spreading the log function into tens of files certainly breaks most guideline one should follow when writing object-oriented program :D Regards, -Tim ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] nonlinear revision control system for GIMP
2011/5/2 Tim Chen ht.timc...@gmail.com:
Hi all,
Recently we have published a paper on SIGGRAPH 2011 about nonlinear revision
control system for images. You can find the abstract and videos at
https://sites.google.com/site/httimchen/2011_imagesvn
Hi Tim
That's great stuff.
1) is there anyone implementing the macro/script system
Nope there isn't, so you are more than welcomed to start doing that.
FYI, macro recording is on our roadmap found at
http://wiki.gimp.org/index.php/Roadmap.
2) can anyone give me a head start on how should I modify my hack so that it
is more readable to others? Spreading the log function into tens of files
certainly breaks most guideline one should follow when writing
object-oriented program :D
I'm convinced (others are not) we should use the proven
http://en.wikipedia.org/wiki/Command_pattern and
http://en.wikipedia.org/wiki/Composite_pattern for macro recording and
wrote some patches a while ago that introduced a GimpCommand and a
GimpGroupCommand class. I didn't have time to even turn it into a
working prototype however.
It will be necessary to make some extensions to the above patterns.
For example, you may have noticed that GIMP is quite quick to Undo and
Redo, in particular for time consuming pixel processing operations.
That's because the undo stack contains the tiles with the resulting
pixels, not only parameters used to get that result. When Redoing, the
tiles with the result can quickly be applied.
I'm imagining that we'd have code that would look something like this:
gimp_expensive_command_execute (...)
{
if (gimp_expensive_command_result_cached (...))
gimp_expensive_command_apply_cached_result (...);
else
// Do time-consuming stuff
}
We don't want to start each GimpCommand with that if case though, so
an abstraction will be needed.
This is not a trivial refactoring, but we need to do it eventually.
Best regards,
Martin
--
My GIMP Blog:
http://www.chromecode.com/
GIMP 2.8 schedule on tasktaste.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Example: Vala as code generator
2011/5/2 Michael Natterer mi...@gimp.org: On Sun, 2011-05-01 at 17:15 +0200, ense...@gmail.com wrote: Hi all, We have discussed the possibility to use Vala as a code generator. What follows is a set of patches so we all can see what that would look like. Any objections to me pushing these commits? Yes, and I'm currently on vacation and can't respond in detail, but IIRC I have made myself very clear about vala. Hi Michael, I'm trying hard to find time hacking on GIMP, and not having to waste time on GObject C boiler plate means a lot to me. At first I was thinking what the hell, I'll just come up with the the damn boilerplate code manually then. But right after I began doing that I started to feel like I was wasting my time, and I can't stand that feeling. I find your blunt dismissal of these two patches really discouraging. Can't we at least push them to master and have them in for a while and see if we can discover some real problems? If it really doesn't work out, we can just reformat the generated .h and .c files and discard the .vala file. If you are on vacation and don't have time to properly review or test these patches, please take your time to do so. I'm not going to push these patches without your OK, and if you're busy for a few weeks, then I'll have to wait. I can work on other items on the GIMP 2.8 schedule in the meantime... Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 schedule on tasktaste.com ___ 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
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
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
[Gimp-developer] [GSoC] GimpSizeEntry widget
Hi all, i've come up with the first concept for the rewrite, including a class diagram and sequence diagrams for a few use cases: http://enni.userpage.fu-berlin.de/GimpSizeEntry.pdf Note that it mainly shows how the different components work together, not how each component does its work internally. If I forgot something (and I probably have ;-) ) please tell me. Martin: I planned on integration the keep-aspect-ratio functionality right away, because I don't think it's to much additional work. Additionally I set up a task schedule on http://tasktaste.com/projects/enni/gimpsizeentry and applied for a gnome git account, but it probably takes some time for it to be activated. Also, since I'm using a Mac and tried to not having to use a virtual machine, I built git-gimp natively on osx (without X11) and with a patch that moves the menubar from the main window to the top of the screen (like other mac apps). It really was a horrible experience (took me a whole day), so I thought it would be nice to have a precompiled app-bundle. As far as I know, there are no official mac binaries, right? The only ones I found where using X11, which isn't very good. I could try to provide osx binaries of the current 2.7.2 and then 2.8 including patches for the menu bar and a nice theme. Regards, Enrico ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Example: Vala as code generator
Martin Nordholts (ense...@gmail.com) wrote: I'm trying hard to find time hacking on GIMP, and not having to waste time on GObject C boiler plate means a lot to me. At first I was thinking what the hell, I'll just come up with the the damn boilerplate code manually then. But right after I began doing that I started to feel like I was wasting my time, and I can't stand that feeling. Hm. This paragraphs leaves me a bit perplexed, because it gives the impression that the most important thing about including vala is to make you more comfortable with our codebase. You blame mitch for a blunt dismissal, but this reads a lot like bluntly forcing down something through mitchs throat. Not sure if that is any better. I must say that - while I have my share of frustrations with the gobject boilerplate code - I don't think that adding vala helps the quality of the Gimp codebase. And this is IMHO what should be in our focus. From reading a lot of code in a lot of different free software projects I have to say, that Gimp still is one of the shining examples regarding consistency and quality of the source code. This has a lot to do with mainly Sven and Mitch investing countless hours into refactoring and restructuring the code, enforcing a common code structure and generally fighting against sloppiness. I don't see how mixing this code with code written in a new language will help the quality of the source. Vala code will inherently develop a set of patterns that differs from the C code (and don't underestimate the value of grepping through the code base). Also new contributors will not only have to learn about GObject and GTK+, they have to learn vala as well. And adding vala *is* adding a new entry barrier, vala is by no means a lingua franca. Bye, Simon -- 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
