Re: [Gimp-developer] New schedule for GIMP 2.8
I'd like to suggest time profiling as another task to be done before the release. Once I started to optimize Gimp's startup time (especially scheme interpreter) and I'd like to return to that task in the near future (when I find at last some time for it :) ). What do you think about it? Łukasz On Sun, Apr 3, 2011 at 21:49, Martin Nordholts wrote: > Hi all, > > I have created a schedule for GIMP 2.8 and put it here: > http://tasktaste.com/projects/Enselic/gimp-2-8 > > Please review the list of tasks and let me know if there are other > things than those listed there that you know we need to do before we can > release 2.8. In that case I will add those tasks to the schedule. > > Ideally, all commits pushed to git master should be related to one of > the tasks listed there. Being able to make a reasonable estimate for > when we can make a GIMP 2.8 release is good for many reasons; one of > them is that we need to know when we should enter a string freeze. > > If no tasks are added and if my estimates are correct, we will release > GIMP 2.8 on 2011-10-20. > > As we all know however, making estimates is hard and 2011-10-20 will not > be our release date, but it is the best estimate we have right now. The > nice thing with having our schedule on tasktaste.com is that anyone > interested in when GIMP 2.8 will be released just needs to visit that > web page linked to above to get an overview of how GIMP 2.8 development > is progressing and get an updated estimate for when we can make a GIMP > 2.8 release. > > As a side note, I have developed tasktaste.com from scratch during the > last few months and the source code is available under the Apache > Licence 2.0: https://github.com/Enselic/task-taste > > / 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 mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On Tue, Mar 1, 2011 at 16:16, Alexandre Prokoudine < alexandre.prokoud...@gmail.com> wrote: > On 3/1/11, Michael Grosberg wrote: > > > I also have a couple of suggestions for things to put on the roadmap: > > > > * change the floating selection behavior so that float and un-float can > > be automatic and not need user's explicit input. > > Wasn't it supposed to be done in 2.8 actually? Floating selections got > some attention last year -- that's for sure. > > > * unified transform tool (I remember seeing plans for that last item on > > Peter sikking's Blog) > > http://gui.gimp.org/index.php/Transformation_tool_specification > > You will probably be nicely surprised :) > Wow! That's a great idea of one tool for many actions! +1 for me :) Łukasz Czerwiński ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developer Boot Camp?
2011/1/28 Alexia Death > 2011/1/28 Łukasz Czerwiński : > > I'd like to write a little bit on some of the topics. > > Q&A > > I think that for a start a Wiki with Q&A edited by everyone could be a > good > > solution. If it gets too complicated, it can be split in sections, pages, > > categories and so on. > Such a wiki has been started. Its hosted by me at > http://gimp-wiki.who.ee and has been devised as unformal developer > space. What it lacks is contributors. Joining easy. A request to me > with desired wiki name and email and that's it. If you want to > maintain the developer FAQ, please step up. > Oh, that's great that something already exists :) Some time ago I've posted a list of "silly questions" that maybe raised by newbie developers. Why not place it there as a FAQ? > IDE > The wiki pointed out above already contains a howto for netbeans. > Netbeans is the only ide Ive gotten to actually code-complete for me > and allows me to navigate project in the manner I like. And before > netbeans Ive used pretty much anything:P > Maybe Eclipse then? Anyone uses Eclipse to develop GIMP? > > From time to time I can see emails "Hey, I'd like to help you, but don't > > know where to start". Some people will get this knowledge on their own > (or > > will try to get it from IRC channels), but some won't and aren't brave > > enough to spam all developers on a Gimp list with his/her newbie > questions. > People who do this "Hi, im bored, give me something to hack" usually > lack the commitment it takes to get into a large code base like GIMP. > People who stick around and evolve into developers come to us with an > issue or a plan. something they want to fix. And then they read the > code and slowly get good enough. Thats the only way I know, that > works. Have an idea what you want to change and then do it by asking > questions. We like sensible questions. In fact, not asking questions > is IMHO a good reason to flunk a student at GSoC mid-term :P If you > want answers, join IRC. And stay connected long enough to answer. the > last guy who did that(IRC name Acumen) had so bad connection that in > the 10 minutes it took for me to see the question his link had already > dropped and I had nobody to answer. > Well, I don't agree. There are (many!) people that don't know how developing an open-source program looks like and what can work on at start. So they just ask for some guidance. Maybe there should be a section on Wiki "How to become a developer?" or "Your first steps" or similar. And there: an information about IRC channel, this mailing list, how bug tracking works and that one can find some easy bugs and try to patch them. Łukasz Czerwiński ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developer Boot Camp?
I'd like to write a little bit on some of the topics. *Q&A* * * As a beginner developer, I'd like to know the place where answers to all my "stupid" questions are answered. In one place. E.g.: - How to commit to git tree? - What's the best way to submit a patch? When I asked this question on this list, I got several different answers - post to mailing list, add new bug and post a patch, do both, commit to git tree. Of course some of responders wrote that previous responders are wrong and it should be done in other way and they do it so... and so on. - How to download and compile the source without mixing it with "normal" Gimp installation? - Who is planning Gimp's development? - How do I know what should be done in Gimp? - What are planned deadlines for next edititons of Gimp? Are there any? - an many many many other. I think that for a start a Wiki with Q&A edited by everyone could be a good solution. If it gets too complicated, it can be split in sections, pages, categories and so on. *Scripts* I think that a good idea is also to include in such Wiki scripts for automated downloading sources and dependencies, updating git tree etc. Maybe not one official script, but several alternatives - each of you writing about his own script says that it does something different than others'. I imagine that such a page with scripts could look similar to a Wiki page with scripts to compile your own PHP source on Dreamhost: http://wiki.dreamhost.com/Installing_PHP5. There is one "Main PHP 5 install script <http://wiki.dreamhost.com/Installing_PHP5#Main_PHP_5_install_script>" - just for a newbie, but also several alternative scripts. *IDE* * * Beginner developers that aren't independent and need some support from more experienced developers probably aren't at all used to working on an open source projects, reading through thousands of lines of new code, hundreds of files and directories. Therefore all their experience is working on some projects in Eclipse or other IDEs. I'm one a such person :) And although I tried to use kate, gedit and vim to edit code, it would be much easier for me to setup and use an Eclipse project. If some of you use IDEs, couldn't you just write on the Wiki how to setup a project in a few easy steps? Some of you will write about Eclipse, some about Qt Creator, maybe NetBeans and other. * * *Tutor / supervisor* (an experienced developer) It's a good idea to choose one or two developers responsible for the whole "Newbie Developers Boot Camp". Of course the work on Q&A, submitting scripts, guides for IDEs and maybe some other tips should be done by many developers, but someone should supervise it and make sure that these guides are really helpful for people. >From time to time I can see emails "Hey, I'd like to help you, but don't know where to start". Some people will get this knowledge on their own (or will try to get it from IRC channels), but some won't and aren't brave enough to spam all developers on a Gimp list with his/her newbie questions. Łukasz Czerwiński ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developer Boot Camp?
Maybe just a good documentation for GIMP source is needed? Once I tried to patch TinyScheme interpreter to make it work faster. In files I was working on was almost no comments. Łukasz Czerwiński ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] astronomical use of GIMP
Maybe it's worth taking a look at point 6 a. on http://chandra.harvard.edu/photo/openFITS/casa.html: Another limitation of using GIMP for a 3 color image is that GIMP does not > use what are known in Photoshop as "Adjustment Layers". Adjustment Layers > allow you to make changes to your layers in a non-destructive way. That is > to say that you do not actually change the layer itself, you apply an > additional layer to the original layer to make changes. This preserves the > original layer so you can always go back to its original state at any time. > The changes we'll make here have to be applied to the original layer, and > once the file has been saved and closed, you cannot back out of those > changes. One workaround to this is to duplicate your original layers and do > all of your work on the duplicates so that you can always go back to the > original if need be. How about adding this missing feature to GIMP? Best wishes, Łukasz Czerwiński On Thu, Nov 18, 2010 at 08:36, Marco Ciampa wrote: > With last discover of a little jung black hole by NASA, > I have found this project on the Chandra X-ray observatory site: > > http://chandra.harvard.edu/photo/openFITS/ > > IMHO it can be very effective to spread the use of GIMP having a page > dedicated to the interesting / useful real case of GIMP use. > > Forgive my bad english... > > -- > > > Marco Ciampa > > ++ > | Linux User #78271 | > | FSFE fellow #364 | > ++ > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization & tricks (getting Blender's 2.53 UV layout as path into GIMP).
Hello, The same as Tobias, I'm not in the topic of paths, so maybe I'm wrong, but you wrote that you add each path (x1, x2, y1, y2) to the hash table and look for duplicates. And what if only a part of a path overlaps? Consider paths: (2,4,2,4) and (1,3,1,3) - then the overlapping fragment will be a path (1,2,1,2), won't it? Łukasz Czerwiński 2010/9/12 Mirza Husadzic > Hi all, > > I came up with solution to import and merge Blender's SVG file as path into > GIMP. > This is just quick and dirty solution which I hacked this afternoon. But it > works very well. > I opened bug report yesterday concerning GIMP's invalid path-line drawing ( > https://bugzilla.gnome.org/show_bug.cgi?id=629340). > Then, as Sven marked this ticket as duplicate of > https://bugzilla.gnome.org/show_bug.cgi?id=55364 (dating form 2001) I > realized that > things will change really slow:-). > I was quite depressed yesterday, but in the middle of night I got an idea > :-) > "If GIMP cannot draw overlapped lines, then why should draw them > *overlapped* after all!?" > If duplicates are removed, then XOR drawing will not affect path. Yupiee. > As a side effect, there will be approx. half of lines less to draw (in case > of connected polygons a.k.a mesh) so this is a very good optimization > for poor gdk-powered line drawing in GIMP. > > Here is a SVG file for testing: > http://www.qsoftz.com/mirza/wp-content/data/gekkoman_unwrapp.svg > Here is a screenshot of GIMP with paths on my lovely Ubuntu desktop: > http://www.qsoftz.com/mirza/wp-content/data/Screenshot.png > Here is a patch: > http://www.qsoftz.com/mirza/wp-content/data/0001-cleared-duplicate-lines.patch > > btw. I used slower variant 'g_hash_table_find' instead of > 'g_hash_table_lookup'. I know that this is a flaw. I will try > to fix it. > > And yes, rendering of this kind of optimized path is much better than > without optimization. > I'm able to work and paint (realtime) over this path. I'm very happy! :-) > > About patch: > > The code affects processing only if paths are merged while importing > (checked "Merge imported path"). > I'm not sure that I placed code at right place. > I'm not sure how it will affect importing of other entities from SVG file > (curves, ellipses etc.). > > But, I'm pretty sure that this is a good way in direction of merging paths. > > It is useless if they are not flattened into only one path, without > duplicated points. > > The algorithm: > > As strokes are processed the key for each line in stroke (x1,x2,y1,y2) is > constructed and pushed into hash table. > If key is uniuqe then line in stroke is valid. > If key is duplicated, then line is rejected and current stroke ends (begin > of a new stroke). > That's it. > > This method can be applied even if paths are merged from GUI. I will > further test this approach > with other shapes from SVG (cubic bezier, ellipse etc). > If they are flattened on lines, at this stage, maybe this may work with > them too. > But, I'm not sure about this. I didn't tested it. > > I would like to hear you opinions. > > Cheers, > Mirza. > > www.qsoftz.com > www.qsoftz.com/mirza > > > ___ > 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] Patch shortening GIMP startup time
2010/9/1 Kevin Cozens > Łukasz Czerwiński wrote: > > I have made several optimizations in loading script-fu extension making > the > > loading process a bit faster. > > Thank you for the patches. They will be reviewed son. I can't look at them > for another day or two as I'm finishing up some changes on another project. > > I would ask that you update the patches to address the issues raised by > Sven and then post a bug report against Script-Fu. Attach the patches to > the report instead of pasting them in the body of the report. The bug > report will prevent this issue from getting lost in my e-mail's mail > folders. > > It would help if you could also send some additional information about the > patches to this mailing list to explain the changes. I noticed in the > before and after graphics that your modified version doesn't go through the > usual steps to locate the script files which leaves me wondering how it > finds what scripts need to be loaded. > It seems that you and Sven asked me to make two different actions and it's useless to do both. Sven asked me to commit my patch into git, you have told me to create a bug and add a patch there as an attachment. Whose commands should I obey? :] I'm trying to guess what's the procedure for making changes in code and get them approved by some more experience developers. Could you provide me such information? Maybe there should be a page on the website saying what should be done step by step to patch GIMP and get the patch approved. I'm thinking of a small guide for newbie developers. By now I have submitted a bug report for Script-fu in GIMP, but didn't commit my changes into git. Sven, Kevin, should I do it? As for your request for additional information, a description of my change I have written in a description of my bug report: https://bugzilla.gnome.org/show_bug.cgi?id=628509 Looking forward to your answer, Łukasz Czerwiński ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Patch shortening GIMP startup time
Hello,
W dniu 31 sierpnia 2010 00:39 użytkownik Sven Neumann napisał:
> On Mon, 2010-08-30 at 23:31 +0200, Łukasz Czerwiński wrote:
>
>
> > I have made several optimizations in loading script-fu extension
> > making the loading process a bit faster. It's the first time I change
> > something in an open source program and don't know best way to
> > "announce" it and get it reviewed, so I send a patch in a mail.
> > The major speedup is caused by calling my function load_script_file
> > instead of script_fu_run_command("(load "). Please review my
> > changes and send an answer if the patch is OK.
>
> Thanks for your patch. It definitely needs some work though. First of
> all it is not OK to comment out code. If code should be removed, then
> please remove it.
>
Ok, I will remove.
>
> Passing a string literal directly to g_message() is also not a good
> idea. Please use g_message("%s", message) instead. But I didn't
> understand what this part of your patch is trying to achieve.
>
Why it's not a good idea? What's the difference? Nevertheless, ok, I'll
change it.
> Overall it would help a lot if you could explain what your patch tries
> to achieve and what the purpose of the changes are. I have not been able
> to understand the benefits of your changes just by looking at the patch.
>
The difference is clearly visible on a callgrind's graph. Compare flow
between script_fu_run and Eval_Cycle at
http://students.mimuw.edu.pl/~lc277642/gimp/before.jpg and
http://students.mimuw.edu.pl/~lc277642/gimp/after.jpg.
Full versions of the graphs in jpg and Callgrind formats are available at
http://students.mimuw.edu.pl/~lc277642/gimp/.
A description of an optimization: all script-fu scripts loaded on startup
was loaded using a command "(load ...)" of a TinyScheme language. This means
running several functions escaping a path to a script, interpreting the
string, choping it to tokens, analyzing, unescaping and finally loading the
script. My optimization makes Gimp call directly a function loading a script
without using a slow (comparing to calling one function in native C)
TinyScheme interpreter. Instead I've written two helper functions (
load_script_file and scheme_file_push) responsible for loading scripts.
I have done also a second modification - connected with comparing strings
(stricmp), but I've just spotted an error in it, so I'll fix it and send it
later.
Is my description detailed enough or I should add something?
The corrected patch:
diff -rup
/home/lukasz/OPOS/SOURCE/gimp-git-original/gimp/plug-ins/script-fu/scheme-wrapper.c
gimp/plug-ins/script-fu/scheme-wrapper.c
---
/home/lukasz/OPOS/SOURCE/gimp-git-original/gimp/plug-ins/script-fu/scheme-wrapper.c
2010-08-24
17:49:15.0 +0200
+++ gimp/plug-ins/script-fu/scheme-wrapper.c 2010-08-31 13:49:59.0
+0200
@@ -298,6 +298,10 @@ ts_interpret_stdin (void)
scheme_load_file (&sc, stdin);
}
+int load_script_file(const char *fname) {
+ return scheme_file_push(&sc,fname);
+}
+
gint
ts_interpret_string (const gchar *expr)
{
diff -rup
/home/lukasz/OPOS/SOURCE/gimp-git-original/gimp/plug-ins/script-fu/scheme-wrapper.h
gimp/plug-ins/script-fu/scheme-wrapper.h
---
/home/lukasz/OPOS/SOURCE/gimp-git-original/gimp/plug-ins/script-fu/scheme-wrapper.h
2010-08-24
17:49:15.0 +0200
+++ gimp/plug-ins/script-fu/scheme-wrapper.h 2010-08-31 13:50:17.0
+0200
@@ -32,6 +32,8 @@ const gchar * ts_get_success_msg (v
void ts_interpret_stdin (void);
+int load_script_file(const char *fname);
+
/* if the return value is 0, success. error otherwise. */
gint ts_interpret_string (const gchar *expr);
diff -rup
/home/lukasz/OPOS/SOURCE/gimp-git-original/gimp/plug-ins/script-fu/script-fu-scripts.c
gimp/plug-ins/script-fu/script-fu-scripts.c
---
/home/lukasz/OPOS/SOURCE/gimp-git-original/gimp/plug-ins/script-fu/script-fu-scripts.c
2010-08-24
17:49:15.0 +0200
+++ gimp/plug-ins/script-fu/script-fu-scripts.c 2010-08-31
13:51:33.0 +0200
@@ -602,13 +602,12 @@ script_fu_load_script (const GimpDatafil
command = g_strdup_printf ("(load \"%s\")", escaped);
g_free (escaped);
- if (! script_fu_run_command (command, &error))
+ if (! load_script_file(file_data->filename))
{
gchar *display_name = g_filename_display_name
(file_data->filename);
gchar *message = g_strdup_printf (_("Error while loading
%s:"),
display_name);
-
- g_message ("%s\n\n%s", message, error->message);
+ g_message ("%s", message);
g_clear_error (&error);
g_free (message);
@@ -625,6 +624,7 @@ script_fu_load_script (const GimpDatafil
[Gimp-developer] Patch shortening GIMP startup time
folded);
return sc->NIL;
}
@@ -1415,6 +1433,14 @@ static void finalize_cell(scheme *sc, po
/* == Routines for Reading == */
+/* modified by Lukasz Czerwinski (lc277...@students.mimuw.edu.pl) */
+int scheme_file_push(scheme *sc, const char *fname) {
+ int ret = file_push(sc, fname);
+ file_pop(sc);
+ return ret;
+}
+/* end of modification */
+
static int file_push(scheme *sc, const char *fname) {
FILE *fin = NULL;
if (sc->file_i == MAXFIL-1)
diff -rup
/home/lukasz/OPOS/SOURCE/gimp-git-patched/gimp/plug-ins/script-fu/tinyscheme/scheme.h
gimp/plug-ins/script-fu/tinyscheme/scheme.h
---
/home/lukasz/OPOS/SOURCE/gimp-git-patched/gimp/plug-ins/script-fu/tinyscheme/scheme.h
2010-08-24
17:49:15.0 +0200
+++ gimp/plug-ins/script-fu/tinyscheme/scheme.h 2010-08-24
23:07:28.0 +0200
@@ -152,6 +152,11 @@ SCHEME_EXPORT pointer scheme_eval(scheme
void scheme_set_external_data(scheme *sc, void *p);
SCHEME_EXPORT void scheme_define(scheme *sc, pointer env, pointer symbol,
pointer value);
+/* modified by Lukasz Czerwinski (lc277...@students.mimuw.edu.pl) */
+SCHEME_EXPORT int scheme_file_push(scheme *sc, const char *fname);
+/* end of modification */
+
+
typedef pointer (*foreign_func)(scheme *, pointer);
pointer _cons(scheme *sc, pointer a, pointer b, int immutable);
Looking forward to your answer,
Łukasz Czerwiński
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
