Re: [Gimp-developer] remove layer should not force you to last selected layer
I understood gimp 2.7 will fix this kind of problem, if that´s the case, then I will be waiting for 2.7. About Jerry way of doing things I think it makes more sense (at least) to me. I do not know very well how to use your script but I´ll find a way to give it a shot buddy. Em Sex, 2010-03-05 às 15:16 -0300, Joao S. O. Bueno escreveu: > On Fri, Mar 5, 2010 at 3:05 PM, Akkana Peck wrote: > > Luiz Felipe Moraes Pereira writes: > >> Also I do not mind much about not having a selected layer after > >> the deletion of a layer. But the forced viewer scroll down( or up ), > >> depending of the last selected layer is a problem. > > > > This used to annoy me a lot, because I frequently want to delete, > > say, the top 5 layers. But once I figured out what it was doing, > > I developed a habit of clicking on the layers I want to delete in > > sequence before deleting. For instance, click on the 5th layer from > > the top, then the 4th, and so on until I get to the top; then click > > Delete 5 times. It sounds tedious but it doesn't take long at all -- > > certainly it's a lot faster than scrolling back up each time. > > Try it -- you may find that it solves the problem. > > > yes, I do that as well. > > The new Layer Groups feature in 2.7 will ease this and several other > workflows a whole lot. > (For example, probably all the layers you are deleting, if more than > one, would not be themselves part of the same group - you just have to > delete the group) > > > js > -><- > > >...Akkana > > ___ > > 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init (David Gowers)
On Sat, 2010-03-06 at 08:41 +1030, David Gowers wrote:
> >>> On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote:
> > I agree with Joao S. O. Bueno and disagree with David Bowers.
>
> Well, I'm glad you don't disagree with me, but who is that?
>
Sorry I mangled your name. BTW David Bowers is a famous
environmentalist, Sierra Club etc. Mr. Gowers was a pharmacist in the
movie "Its a Wonderful Life." He boxed Jimmy Stewart up the side of the
head, like you did me. Just kidding.
> >
> > Its better to make plugins meet the normal expectations of Python
> > programmers (you can import any Python file to use pieces of it) than to
> > add new conventions and directories for shared Python plugin code.
> > Simpler is better?
>
> The normal expectations of Python programmers are that the main loop
> will be guarded.
Granted.
> This is exactly the thing that allows you to import otherwise
> executable modules;
> without it, no guarantees can be made that the code you are importing
> will not interfere with global state in a way which causes your plugin
> to crash. You can depend on a specific version of a plugin which has
> known behaviour; In that case you prevent the user from upgrading that
> plugin, and you rely on knowledge of the internals of that plugin,
> which is very likely to get you into trouble if you ever need to
> upgrade it.
>
> The same principle applies to python scripts that are unguarded:
> importing them will, at the least, have significant side effects.
> Often they are entirely incapable of being cooperative.
>
> Hence, it's not practical to import a plugin module unless it
> specifically indicates that it is fit to be imported (by guarding the
> main loop)
But Gimp shouldn't protect programmers from themselves. If they import
a plugin that is not fit, or create dependencies on versions, let them.
>
> >
> > Often, authors don't plan their code will be useful to others. It's
> > just serendipity. If authors don't plan to share code and put it in
> > these new directories, it thwarts serendipitous reuse and
> > experimentation.
> >
> > It is inconsistent for a duplicate call to register() to be harmless
> > with a warning while a duplicate call to main() is fatal.
>
> Currently, the latter is serving the function of preventing the
> previously mentioned possibility of side effects of importing a plugin
> in this way.
>
> If there is another way of preventing that problem, then we could look
> at removing that aspect of main() calls.
> Otherwise, we absolutely must not.
>
> >
> > Also, new conventions and directories does not solve my wish to call
> > pydoc on plugins (which is not very important. I hope to download a
> > prototype Inspect plugin to gimp registry soon.) But it illustrates
> > that you can't always anticipate what people will want to do.
>
> I wanted to do that too.
> Just because you want to do something, doesn't mean it's wise to do so.
>
> Calling pydoc on unguarded python modules is just as unpredictable as
> importing unguarded python modules. Why? Because the way it gets the
> documentation is by first importing the module in question.
> Furthermore, all GIMP plugins' dependency on the 'gimp' (and/or
> gimpfu, etc..) modules mean that even if they are in the module search
> path, pydoc's attempt at importing them will fail (because the gimp
> and gimpfu,etc.. modules are only available to Python scripts that are
> being run by GIMP).Changing the mechanics of main() would not effect
> that.
>
> If you don't believe that, it's easy to check; set PYTHON_PATH to your
> plugins directory (full, absolute path like
> /home/llkk/.gimp-2.7/plugins), start Python, and try to import one of
> those plugins as a module.
>
> David
My Inspect plugin IS run by Gimp. Thus importing pydoc and invoking it
on plugins DOES work, as far as I can tell by my limited testing, with
the patch to Pygimp that I have proposed.
Also, you CAN invoke pydoc on the pygimp modules from an Inspect plugin
run by Gimp. It turns out not to be really useful, since the existing
documentation for pygimp is rather good.
IF you can't invoke pydoc on the command line on a plugin, it's not
because it can't find the pygimp modules (because you can set the path
so it will) but for the reason you described: they need Gimp running. I
really haven't tested it.
But this does seem to work: start Gimp, open the Python console, import
pydoc, and call pydoc.render_doc('gimp'). I believe this works even
without the patch under discussion. But pydoc.render_doc('colorxhtml')
crashes pyconsole lacking the patch under discussion.
My brain hurts.
Lloyd
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init (David Gowers)
>>> On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote: > I agree with Joao S. O. Bueno and disagree with David Bowers. Well, I'm glad you don't disagree with me, but who is that? > > Its better to make plugins meet the normal expectations of Python > programmers (you can import any Python file to use pieces of it) than to > add new conventions and directories for shared Python plugin code. > Simpler is better? The normal expectations of Python programmers are that the main loop will be guarded. This is exactly the thing that allows you to import otherwise executable modules; without it, no guarantees can be made that the code you are importing will not interfere with global state in a way which causes your plugin to crash. You can depend on a specific version of a plugin which has known behaviour; In that case you prevent the user from upgrading that plugin, and you rely on knowledge of the internals of that plugin, which is very likely to get you into trouble if you ever need to upgrade it. The same principle applies to python scripts that are unguarded: importing them will, at the least, have significant side effects. Often they are entirely incapable of being cooperative. Hence, it's not practical to import a plugin module unless it specifically indicates that it is fit to be imported (by guarding the main loop) > > Often, authors don't plan their code will be useful to others. It's > just serendipity. If authors don't plan to share code and put it in > these new directories, it thwarts serendipitous reuse and > experimentation. > > It is inconsistent for a duplicate call to register() to be harmless > with a warning while a duplicate call to main() is fatal. Currently, the latter is serving the function of preventing the previously mentioned possibility of side effects of importing a plugin in this way. If there is another way of preventing that problem, then we could look at removing that aspect of main() calls. Otherwise, we absolutely must not. > > Also, new conventions and directories does not solve my wish to call > pydoc on plugins (which is not very important. I hope to download a > prototype Inspect plugin to gimp registry soon.) But it illustrates > that you can't always anticipate what people will want to do. I wanted to do that too. Just because you want to do something, doesn't mean it's wise to do so. Calling pydoc on unguarded python modules is just as unpredictable as importing unguarded python modules. Why? Because the way it gets the documentation is by first importing the module in question. Furthermore, all GIMP plugins' dependency on the 'gimp' (and/or gimpfu, etc..) modules mean that even if they are in the module search path, pydoc's attempt at importing them will fail (because the gimp and gimpfu,etc.. modules are only available to Python scripts that are being run by GIMP).Changing the mechanics of main() would not effect that. If you don't believe that, it's easy to check; set PYTHON_PATH to your plugins directory (full, absolute path like /home/llkk/.gimp-2.7/plugins), start Python, and try to import one of those plugins as a module. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] remove layer should not force you to last selected layer
I've verified the behaviour is inconsistent, at least which could be considered a bug. I assumed it would go to the last drawable, but that isn't so... Deleting a channel always makes the channel that was below it active (regardless of the active order before), unless it is the last channel, in which case the last layer that was selected becomes active. -Rob A> ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] remove layer should not force you to last selected layer
I've always hated the way that worked, I've got a script that deletes
the active layer, then sets the layer underneath it to active if anyone
wants to use it...
#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# delete-layer.py - Version 1.0
# Copyright (C) 07/11/2008 by Jerry Baker
# www.gimpthoughts.com
#
# Deletes active layer then selects the layer underneath.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.
# --- Imports
from gimpfu import *
gettext.install("gimp20-python", gimp.locale_directory, unicode=True)
def delete_layer(image, drawable):
image.undo_group_start()
layer_index = image.layers.index(image.active_layer)
if layer_index == (len(image.layers)-1):
layer_index -= 1
image.remove_layer(image.active_layer)
if layer_index >= 0:
image.active_layer = image.layers[layer_index]
image.undo_group_end()
register(
"delete-layer",
N_("Deletes active layer then selects the layer underneath."),
"Deletes active layer then selects the layer underneath.",
"Jerry Baker",
"Jerry Baker",
"07/11/2008",
N_("Delete Active Layer"),
"RGB*, GRAY*, INDEXED*",
[
# --- Parameters
(PF_IMAGE, "image", _("Image"), None),
(PF_DRAWABLE, "layer", _("Drawable"), None),
],
[
# --- Results
],
delete_layer,
menu="/_Layer",
domain=("gimp20-python", gimp.locale_directory)
)
main()
On 03/05/2010 02:22 PM, Martin Nordholts wrote:
> On 03/05/2010 03:20 AM, Luiz Felipe Moraes Pereira wrote:
>
>> Hi again, the original discussion is in the link below:
>> https://bugzilla.gnome.org/show_bug.cgi?id=611758
>>
>> I was advised to present this idea here, what do you think?
>>
>> Also I do not mind much about not having a selected layer after
>> the deletion of a layer. But the forced viewer scroll down( or up ),
>> depending of the last selected layer is a problem.
>>
> To me, having the layers dialog scroll to a seemingly random place after
> deleting a layer is a clear usability problem. A user should not have to
> worry about what layer that was previously selected when deleting a layer.
>
>/ Martin
>
>
>
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] remove layer should not force you to last selected layer
On 03/05/2010 03:20 AM, Luiz Felipe Moraes Pereira wrote: > Hi again, the original discussion is in the link below: > https://bugzilla.gnome.org/show_bug.cgi?id=611758 > > I was advised to present this idea here, what do you think? > > Also I do not mind much about not having a selected layer after > the deletion of a layer. But the forced viewer scroll down( or up ), > depending of the last selected layer is a problem. To me, having the layers dialog scroll to a seemingly random place after deleting a layer is a clear usability problem. A user should not have to worry about what layer that was previously selected when deleting a layer. / Martin -- My GIMP Blog: http://www.chromecode.com/ "Multi-column dock windows and 2.8 schedule" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] remove layer should not force you to last selected layer
On Fri, Mar 5, 2010 at 3:05 PM, Akkana Peck wrote: > Luiz Felipe Moraes Pereira writes: >> Also I do not mind much about not having a selected layer after >> the deletion of a layer. But the forced viewer scroll down( or up ), >> depending of the last selected layer is a problem. > > This used to annoy me a lot, because I frequently want to delete, > say, the top 5 layers. But once I figured out what it was doing, > I developed a habit of clicking on the layers I want to delete in > sequence before deleting. For instance, click on the 5th layer from > the top, then the 4th, and so on until I get to the top; then click > Delete 5 times. It sounds tedious but it doesn't take long at all -- > certainly it's a lot faster than scrolling back up each time. > Try it -- you may find that it solves the problem. yes, I do that as well. The new Layer Groups feature in 2.7 will ease this and several other workflows a whole lot. (For example, probably all the layers you are deleting, if more than one, would not be themselves part of the same group - you just have to delete the group) js -><- > ...Akkana > ___ > 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] remove layer should not force you to last selected layer
Luiz Felipe Moraes Pereira writes: > Also I do not mind much about not having a selected layer after > the deletion of a layer. But the forced viewer scroll down( or up ), > depending of the last selected layer is a problem. This used to annoy me a lot, because I frequently want to delete, say, the top 5 layers. But once I figured out what it was doing, I developed a habit of clicking on the layers I want to delete in sequence before deleting. For instance, click on the 5th layer from the top, then the 4th, and so on until I get to the top; then click Delete 5 times. It sounds tedious but it doesn't take long at all -- certainly it's a lot faster than scrolling back up each time. Try it -- you may find that it solves the problem. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init (David Gowers)
> On Tue, Mar 2, 2010 at 2:58 PM, Sven Neumann wrote: >> On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote: >> >> I wonder if importing a plug-in from another plug-in is really something >> that we want to support. If the goal is to share code, then perhaps the >> code that is worth sharing should be factored out into a Python module >> that the plug-ins can import. >> > > Every Python program is also able to be a python module that plug-ins > can import. We should preserve this feature of the language. > > (For example, one can implement an app with a comand line interface, > and then just add a GUI in another file that uses the functions > defined on the stand-alone first file). David Gowers wrote: I've considered this problem a fair bit, and my opinion is that if you want this functionality, you should simply guard your register()s. We cannot safely 'co-opt' python plugins that are not written with this functionality in mind, as they are designed to be run always in an independent process (hence they may do initialization which confuses the calling program, or vice versa); there is no modification to GIMP which could permit that, it is a logistical problem not a technical one. Allowing python plugins to make separate modules available on installation, similar to Sven's suggestion, seems to me the most practical suggestion. This means we would add two items to sys.path -- one the site modules* directory, and the other the modules* directory belonging to the specific user, which the installation of the plugin package could put modules into. We could further postulate that the normal python modules directory should be the destination of modules that do not require GIMP running in order to function, and only GIMP-requiring modules would be installed in it's modules* directory. I make this distinction because there are various good reasons not to install gimp-dependent modules in the global namespace (for example, pydoc and the general help() facility get confused because the imports of gimp modules fail.. so you can look up a specific module, but not search.) * I realize 'modules' is a term already used in the gimp directory structure. This is meant as a placeholder for something else...python-modules? I agree with Joao S. O. Bueno and disagree with David Bowers. Its better to make plugins meet the normal expectations of Python programmers (you can import any Python file to use pieces of it) than to add new conventions and directories for shared Python plugin code. Simpler is better? Often, authors don't plan their code will be useful to others. It's just serendipity. If authors don't plan to share code and put it in these new directories, it thwarts serendipitous reuse and experimentation. It is inconsistent for a duplicate call to register() to be harmless with a warning while a duplicate call to main() is fatal. Also, new conventions and directories does not solve my wish to call pydoc on plugins (which is not very important. I hope to download a prototype Inspect plugin to gimp registry soon.) But it illustrates that you can't always anticipate what people will want to do. Thanks ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
