Re: [Gimp-developer] New schedule for GIMP 2.8

2011-04-03 Thread Łukasz Czerwiński
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 ense...@gmail.com 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

2011-03-01 Thread Łukasz Czerwiński
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-02-04 Thread Łukasz Czerwiński
2011/1/28 Alexia Death alexiade...@gmail.com

 2011/1/28 Łukasz Czerwiński lc277...@students.mimuw.edu.pl:
  I'd like to write a little bit on some of the topics.
  QA
  I think that for a start a Wiki with QA 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?

2011-01-28 Thread Łukasz Czerwiński
I'd like to write a little bit on some of the topics.

*QA*
*
*
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 QA 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 QA, 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?

2011-01-27 Thread Łukasz Czerwiński
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

2010-11-18 Thread Łukasz Czerwiński
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 ciam...@libero.it 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).

2010-09-13 Thread Łukasz Czerwiński
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 mirza.husad...@gmail.com

 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-09-01 Thread Łukasz Czerwiński
2010/9/1 Kevin Cozens ke...@ve3syb.ca

 Ł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

2010-08-31 Thread Łukasz Czerwiński
Hello,

W dniu 31 sierpnia 2010 00:39 użytkownik Sven Neumann s...@gimp.orgnapisał:

 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
   g_free (command);
 }
 }
+/* end of modifications */

 /*
  *  The following function is a GTraverseFunction.
diff -rup
/home/lukasz/OPOS/SOURCE/gimp-git-original/gimp/plug-ins/script-fu/tinyscheme/scheme.c
gimp/plug-ins/script-fu/tinyscheme/scheme.c
---
/home/lukasz/OPOS/SOURCE/gimp-git-original

[Gimp-developer] Patch shortening GIMP startup time

2010-08-30 Thread Łukasz Czerwiński
 == */

+/* 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