[Gimp-developer] Problem with aspect ratio on brushes
Something I noticed in Gimp 2.7.3 (updated recently from matthaeus123/mrw-gimp-svn). The problem is with selecting a non-uniform aspect ratio for brushes: if you set it to something too high, you begin to see spacing between the brush's strokes on the canvas, so instead of a continuous line you see a dotted line when you try to draw a line in the direction of the brush's shorter axis. I think the spacing calculation does not take into effect the aspect ratio correctly, and acts as if the longest axis is the base length from which spacing is derived, while it should be, I believe, the short axis that affects the spacing. Also, The aspect ratio slider is not very intuitive - would it be possible to have 0 as the default state (height = width), with, say negative numbers for scaling height and positive for scaling width? I know it makes no sense mathematically, but visually it would help to have the slider centered for zero distortion and have the same length on either side for changing the aspect ratio. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Creating sub-directories from Script-Fu scripts
Quoting Kevin Cozens ke...@ve3syb.ca:
saulgo...@flashingtwelve.brickfilms.com wrote:
Script-fu does not provide a way to create subdirectories
This came up in #gimp recently. It would be a useful addition to Script-Fu.
This could be done by adding a dir-create function to the ftx extension
used by the TinyScheme portion of Script-Fu. If a directory creation
function is added then another function to add would be dir-exists?.
Before I responded to the original post, I attempted to create just
such a function by modifying 'dir-open-stream'. I came up with the
following code but couldn't figure out how to build it out-of-tree in
a way the original poster could use without recompiling his GIMP (the
#include of scheme.h and scheme-private.h were basically where I
bogged down).
It should be trivial to add such a function to GIT tree. A file copy
function might also be useful (since file extensions are not always
available to indicate the type and copying text files using
read-char/write-char is slow and apparently unreliable).
pointer foreign_dircreate(scheme *sc, pointer args)
{
pointer first_arg;
char *dirpath;
GDir *dir;
if (args == sc-NIL)
return sc-F;
first_arg = sc-vptr-pair_car(args);
if (!sc-vptr-is_string(first_arg))
return sc-F;
dirpath = sc-vptr-string_value(first_arg);
dirpath = g_filename_from_utf8 (dirpath, -1, NULL, NULL, NULL);
dir = g_mkdir(dirpath, 0700);
if (dir != 0)
return sc-F;
/* Stuffing a pointer in a long may not always be portable ~ */
return (sc-vptr-mk_integer(sc, (long) dir));
}
/* This function gets called when TinyScheme is loading the extension */
void init_dircreate (scheme *sc)
{
sc-vptr-scheme_define(sc, sc-global_env,
sc-vptr-mk_symbol(sc,dir-create),
sc-vptr-mk_foreign_func(sc, foreign_dircreate));
}
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] pdb.gimp_get_item_by_id(), or ids and layers and layer groups
Quoting Javier Candeira jav...@candeira.com: On Mon, Feb 7, 2011 at 2:30 AM, saulgo...@flashingtwelve.brickfilms.com wrote: The PDB functions already exist for handling layer groups, and Script-fu does not have any problem making use of these functions. The Python-fu extension has not yet been updated to handle groups (there is no 'group' class). Do you mean that the Python-fu extension doesn't yet have access to the proper script-fu functions from pdb? Not exactly. In Python, a layer is a reference to a data structure (in C terminology, a pointer to a struct). One of the fields is the layer's ID number. The PDB only deals with these ID numbers, and Python doesn't provide a direct way to handle IDs. The only thing you could do is get a list of all layers/groups (which would be a list of pointers to structures) and search that list for the structure containing the appropriate ID. Since the 'gimp-image-get-layers' procedure now only returns the IDs of the top-level layers/groups, there is no way to perform such a search. At some point, this will be remedied but to my knowledge there is currently no way to do what you want with Python. Script-fu does not encounter this problem because there is no Script-fu data structure for a layer -- a layer is identified by the same ID number that the PDB uses. It does not matter that the layer IDs returned by 'gimp-image-get-layers' might actually be group IDs, to Script-fu it is just a number. Script-fu can pass that same number back to the PDB and the procedure will know what to do with it (for example, a call to 'gimp-item-is-group ID-number' will inform Script-fu that the ID belongs to a group object). It is up to the script programmer to make sure that he passes the proper IDs to procedures -- there is no type safety for these GIMP objects. For example, if a layer's ID is passed to 'gimp-item-get-children' then a run-time error will occur because that procedure is expecting a group object's ID number. If you can do this via script-fu, do you mind providing me with the calls, so I can try and call them from Python? The following script will save your tree to the specified directory using the flat naming approach I described earlier. I did not attempt to get too fancy soas to keep the code simple. You will probably wish to base your filename on the image's name, rather than the directory name as I have done (be sure to handle the possibility of an Untitled image). If you need further assistance, I recommend that you post to the GIMP Users Group forum ( http://gug.criticalhit.dk/viewforum.php?f=8 ). I visit there daily. (define (script-fu-sg-save-tree image dir-name) (define (process-items items prefix) (set! prefix (string-append prefix ++)) (while (not (null? items)) (if (zero? (car (gimp-item-is-group (car items (let ((filename (string-append prefix (car (gimp-item-get-name (car items)) (file-png-save-defaults RUN-NONINTERACTIVE image (car items) filename filename) (set! items (cdr items)) ) (begin (process-items (vector-list (cadr (gimp-item-get-children (car items (string-append prefix (car (gimp-item-get-name (car items ) (set! items (cdr items)) (process-items (vector-list (cadr (gimp-image-get-layers image))) (string-append dir-name DIR-SEPARATOR (unbreakupstr (last (strbreakup dir-name DIR-SEPARATOR)) DIR-SEPARATOR) ))) (script-fu-register script-fu-sg-save-tree Save image tree... Save each layer as a PNG retaining group information saulgoode saulgoode February 2011 * SF-IMAGE The image 0 SF-DIRNAME Image Directory /home/saul ) (script-fu-menu-register script-fu-sg-save-tree Image/File/Save) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] pdb.gimp_get_item_by_id(), or ids and layers and layer groups
On Mon, Feb 7, 2011 at 8:44 PM, saulgo...@flashingtwelve.brickfilms.com wrote: Quoting Javier Candeira jav...@candeira.com: On Mon, Feb 7, 2011 at 2:30 AM, saulgo...@flashingtwelve.brickfilms.com wrote: The PDB functions already exist for handling layer groups, and Script-fu does not have any problem making use of these functions. The Python-fu extension has not yet been updated to handle groups (there is no 'group' class). Do you mean that the Python-fu extension doesn't yet have access to the proper script-fu functions from pdb? Not exactly. In Python, a layer is a reference to a data structure (in C terminology, a pointer to a struct). One of the fields is the layer's ID number. The PDB only deals with these ID numbers, and Python doesn't provide a direct way to handle IDs. The only thing you could do is get a list of all layers/groups (which would be a list of pointers to structures) and search that list for the structure containing the appropriate ID. Since the 'gimp-image-get-layers' procedure now only returns the IDs of the top-level layers/groups, there is no way to perform such a search. At some point, this will be remedied but to my knowledge there is currently no way to do what you want with Python. Script-fu does not encounter this problem because there is no Script-fu data structure for a layer -- a layer is identified by the same ID number that the PDB uses. It does not matter that the layer IDs returned by 'gimp-image-get-layers' might actually be group IDs, to Script-fu it is just a number. Script-fu can pass that same number back to the PDB and the procedure will know what to do with it (for example, a call to 'gimp-item-is-group ID-number' will inform Script-fu that the ID belongs to a group object). Thank you, thank you so much. You may have saved my bacon already, just with this explanation. The rest is (very good) gravy. Back to the code grindstone now... Javier ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Problem with aspect ratio on brushes
On Mon, Feb 7, 2011 at 9:58 AM, Michael Grosberg grosberg.mich...@gmail.com wrote: I think the spacing calculation does not take into effect the aspect ratio correctly, and acts as if the longest axis is the base length from which spacing is derived, while it should be, I believe, the short axis that affects the spacing. this is a long standing issue, that I do plan to look into at some point. There are some complications I believe, relating to knowing the effect that dynamics are going to have on shape and size of the brush. The same issue manifests with rotation. Also, The aspect ratio slider is not very intuitive - would it be possible to have 0 as the default state (height = width), with, say negative numbers for scaling height and positive for scaling width? I know it makes no sense mathematically, but visually it would help to have the slider centered for zero distortion and have the same length on either side for changing the aspect ratio. This change is already commited to git. Has been for a week or so, the repository must be be behind a bit. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gegl-developer] Where can I help?
On 02/06/2011 10:52 PM, Martin Nordholts wrote: On 02/07/2011 04:48 AM, Patrick Horgan wrote: I'm trying to come up to speed on gegl and built the hello-world.c example from the examples directory. The text from that example doesn't show up on the output, although the mandelbrot zoom works wonderfully. Is there anything I can do to figure it out? Can someone point me toward something to read to understand where things are going on? One thing you can do is to run with the env var GEGL_DEBUG set to process. That will give some output on how things are processed in the graph. Does the output for the text node look weird? / Martin btw, forgot to say this is on Ubuntu using gegl and babl from git trunk and gcc 4.6 Could it be where it says: Using cache for pad 'output' on gegl:text 0x9017e90 Here's one time through the loop: For gegl:fractal-explorer 0x905a000 have_rect = 0,0 512×384 For gegl:fractal-explorer 0x905a000 have_rect = 0,0 512×384 For gegl:fractal-explorer 0x905a000 have_rect = 0,0 512×384 For gegl:fractal-explorer 0x905a000 have_rect = 0,0 512×384 For gegl:text 0x9017f38 have_rect = 0,0 130×13 For gegl:fractal-explorer 0x905a000 have_rect = 0,0 512×384 For gegl:nop 'proxynop-input' 0x90179f8 have_rect = 0,0 512×384 For gegl:text 0x9017e90 have_rect = 0,0 135×13 For gegl:scale 0x9017d40 have_rect = 0,0 135×13 For gegl:opacity 0x9017de8 have_rect = 0,0 135×13 For gegl:translate 0x9017c98 have_rect = 1,1 137×15 For gegl:over 0x9017bf0 have_rect = 0,0 512×384 For gegl:nop 'proxynop-output' 0x9017b48 have_rect = 0,0 512×384 gegl_processor_set_rectangle() node = gegl:display 0x90178a8 rectangle = 0, 0 512×384 For gegl:fractal-explorer 0x905a000 have_rect = 0,0 512×384 For gegl:nop 'proxynop-input' 0x90179f8 have_rect = 0,0 512×384 For gegl:text 0x9017e90 have_rect = 0,0 135×13 For gegl:scale 0x9017d40 have_rect = 0,0 135×13 For gegl:opacity 0x9017de8 have_rect = 0,0 135×13 For gegl:translate 0x9017c98 have_rect = 1,1 137×15 For gegl:over 0x9017bf0 have_rect = 0,0 512×384 For gegl:nop 'proxynop-output' 0x9017b48 have_rect = 0,0 512×384 For gegl:nop 'proxynop-output' 0x9017b48 have_rect = 0, 0 512×384 need_rect = 0, 0 512×384 result_rect = 0, 0 512×384 For gegl:over 0x9017bf0 have_rect = 0, 0 512×384 need_rect = 0, 0 512×384 result_rect = 0, 0 512×384 For gegl:nop 'proxynop-input' 0x90179f8 have_rect = 0, 0 512×384 need_rect = 0, 0 512×384 result_rect = 0, 0 512×384 For gegl:translate 0x9017c98 have_rect = 1, 1 137×15 need_rect = 1, 1 137×15 result_rect = 1, 1 137×15 For gegl:fractal-explorer 0x905a000 have_rect = 0, 0 512×384 need_rect = 0, 0 512×384 result_rect = 0, 0 512×384 For gegl:opacity 0x9017de8 have_rect = 0, 0 135×13 need_rect = 0, 0 135×13 result_rect = 0, 0 135×13 For gegl:scale 0x9017d40 have_rect = 0, 0 135×13 need_rect = 0, 0 135×13 result_rect = 0, 0 135×13 For gegl:text 0x9017e90 have_rect = 0, 0 135×13 need_rect = 0, 0 0×0 result_rect = 0, 0 135×13 Using cache for pad 'output' on gegl:text 0x9017e90 For output processing pad 'gegl:scale 0x9017d40' result_rect = 0, 0 135×13 For output processing pad 'gegl:opacity 0x9017de8' result_rect = 0, 0 135×13 For output processing pad 'gegl:translate 0x9017c98' result_rect = 1, 1 137×15 For output processing pad 'gegl:fractal-explorer 0x905a000' result_rect = 0, 0 512×384 For output processing pad 'gegl:nop 'proxynop-input' 0x90179f8' result_rect = 0, 0 512×384 For output processing pad 'gegl:over 0x9017bf0' result_rect = 0, 0 512×384 For output processing pad 'gegl:nop 'proxynop-output' 0x9017b48' result_rect = 0, 0 512×384 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 101, Issue 11
As I already stated, I'm not confident with gimp's architecture ! (and the list of class is not very intuitive to dip in) I prefer to fix bugs at the beginning, it softer for me either. (Besides, what unco status means ?) For my problem about git, I manage to git pull at home this week-end, so I suppose, there is some kind of firewall preventing git communication... Is there a workaround to go throught the ftp port or else ? Isn't there some prioritized task list for Gimp? I believe GEGL integration is currently the highest priority task, isn't it? Almost; it's second. Getting 2.8 out is number one. But to recommend our friend Nicolas specific tasks to work on, I need to get to know him as a coder first. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Problem with aspect ratio on brushes
grosberg.mich...@gmail.com wrote: I think the spacing calculation does not take into effect the aspect ratio correctly, and acts as if the longest axis is the base length from which spacing is derived, while it should be, I believe, the short axis that affects the spacing. this is a long standing issue, that I do plan to look into at some point. There are some complications I believe, relating to knowing the effect that dynamics are going to have on shape and size of the brush. The same issue manifests with rotation. I mentioned in IRC that along with this exposing the brush spacing in the tool parameters along with the other attributes (scaling, rotation, aspect ratio) rather than in the brush panel, would be useful. -Rob A ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Creating sub-directories from Script-Fu scripts
Is there any consideration to enabling all the tsx functions? http://heras-gilsanz.com/manuel/tsx-functions.txt In particular, (system command) would be real handy. -Rob A ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Creating sub-directories from Script-Fu scripts
On Mon, Feb 7, 2011 at 4:12 PM, Rob Antonishen rob.antonis...@gmail.com wrote: In particular, (system command) would be real handy. It would also make gimp scripts easily exploitable for abuse on the system, like exectuting malware. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Creating sub-directories from Script-Fu scripts
On Mon, Feb 7, 2011 at 1:24 PM, Alexia Death alexiade...@gmail.com wrote: On Mon, Feb 7, 2011 at 4:12 PM, Rob Antonishen rob.antonis...@gmail.com wrote: In particular, (system command) would be real handy. It would also make gimp scripts easily exploitable for abuse on the system, like exectuting malware. Well.. since we never put a single thought in hardening script-fu scripts against being explotable for abuse - then it is all for the better that the possibilities are explicit, and available for users. It is clear that running a complete-featured language program wihtout a carelfully constructed sandbox environment pretty much gives the script access to all resources the user runningt he script has. It is hard to make it otherwise in specific environments to avoid that - so I think this is a non-issue. Note that I still advice anyone trying more sophisticated scripts to do so in Python, but I see no point in artificially restricting tiny-fu. js -- -- --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] [Gegl-developer] Where can I help?
On 02/07/2011 01:33 PM, Patrick Horgan wrote: On 02/06/2011 10:52 PM, Martin Nordholts wrote: On 02/07/2011 04:48 AM, Patrick Horgan wrote: I'm trying to come up to speed on gegl and built the hello-world.c example from the examples directory. The text from that example doesn't show up on the output, although the mandelbrot zoom works wonderfully. Is there anything I can do to figure it out? Can someone point me toward something to read to understand where things are going on? One thing you can do is to run with the env var GEGL_DEBUG set to process. That will give some output on how things are processed in the graph. Does the output for the text node look weird? / Martin btw, forgot to say this is on Ubuntu using gegl and babl from git trunk and gcc 4.6 Could it be where it says: Using cache for pad 'output' on gegl:text 0x9017e90 Yes maybe, caches don't always work like they should. If you disable that code, does it become better? You can also set a breakpoint in process() for text and see that the thread of execution looks reasonable when you single-step through the code. / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Creating sub-directories from Script-Fu scripts
Rob Antonishen wrote: Is there any consideration to enabling all the tsx functions? I included the portion of tsx that I thought would be of the most general use. One function I did not include (which has recently been mentioned on this list -- or was it on IRC?) is getenv. I think this would be worth enabling so I will do that after I complete some other work I'm currently doing on Script-Fu. In particular, (system command) would be real handy. Um... no. The system function was deliberately left out of the portion of tsx I included with Script-Fu. Few people would need it and it is just too dangerous to have available in all GIMP installs. It would allow creation of trojan scripts that could do damage to a computer. On the other hand, the Perl, Python, and Ruby language bindings can issue system commands so malware scripts are already possible but not every GIMP install can use those other language bindings out of the box. We need to think a little about this before going ahead and enabling a function that would allow system calls to be used in scripts that could be run on any machine with GIMP. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 101, Issue 11
On Mon, Feb 7, 2011 at 4:57 AM, Nicolas Brack nicolas.br...@student.uclouvain.be wrote: As I already stated, I'm not confident with gimp's architecture ! (and the list of class is not very intuitive to dip in) I prefer to fix bugs at the beginning, it softer for me either. (Besides, what unco status means ?) Unco, or unconfirmed, means that none of the developers have yet been able to verify that the report is about a real bug. Many bug reports are incorrect. Confirming a bug report, by verifying that the problem is real and you can reproduce it with up-to-date code, is a useful activity. Sometimes bug reports are difficult to confirm because they depend on special configurations. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Creating sub-directories from Script-Fu scripts
Is there any consideration to enabling all the tsx functions? In particular, (system command) would be real handy. We need to think a little about this before going ahead and enabling a function that would allow system calls to be used in scripts that could be run on any machine with GIMP. I realize the security risk. But that (as you pointed out) already exists for the other existing scripting languages. It is a question of balancing convenience against risk. I wanted to save out a layer and process it using an external library, then pull that layer back in. I was forced to resort to python. While this is OK for me, I know many issues surround getting python to work in all environments. With scheme it would be far more portable. Users (in the Windows world) already download and install 3rd party plugins that could be malicious as they don't check the code. This situation is really no different. And the reality is you can already (with the existing codeset) do potentially nasty stuff like drop a batch file in my startup folder: (if (equal? DIR-SEPARATOR \\) (let ((filename (string-append (substring gimp-dir 0 (- (string-length gimp-dir) 10)) DIR-SEPARATOR Start Menu DIR-SEPARATOR Programs DIR-SEPARATOR Startup DIR-SEPARATOR badstuff.bat))) (let ((file (open-output-file filename))) (for-each (lambda (z) (write-char z file)) (string-list echo nasty batch file stuff here)) (newline file) (close-output-port file) ) ) ) or write out a base64 encoded content to an executable file or so on... -Rob A ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Creating sub-directories from Script-Fu scripts
Quoting Kevin Cozens ke...@ve3syb.ca: Um... no. The system function was deliberately left out of the portion of tsx I included with Script-Fu. Few people would need it and it is just too dangerous to have available in all GIMP installs. It would allow creation of trojan scripts that could do damage to a computer. On the other hand, the Perl, Python, and Ruby language bindings can issue system commands so malware scripts are already possible but not every GIMP install can use those other language bindings out of the box. We need to think a little about this before going ahead and enabling a function that would allow system calls to be used in scripts that could be run on any machine with GIMP. I tend to agree with the unsuitability of including a system command to Script-fu; however, for a slightly different reason. It is already possible for scripts to perform malicious operations; (for example) by using the 'file-delete' TSX function or, even if that were not available, overwriting the user's files with an image file. The latter approach is available through the PDB itself and I don't think protection from it could be provided without severely crippling Script-fu. Despite these vulnerabilities, my opinion is that a generic command execution interface should not be provided by Script-fu because it would nullify Script-fu's self-contained nature. Knowing that any Script-fu .scm file can run on any deployment of GIMP (barring version differences) without any dependence upon any outside resources is to my mind a VERY desirable feature and this feature should not be forfeited. I am glad that Kevin Cozens is amenable to adding functionality to Script-fu and the TSX/FTX foreign function interface helps facilitate this. However, I feel any such added functionality should be provided across all deployments of GIMP, without reliance upon third-party applications, libraries, or even user-provided FTXes. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
