Re: [Gimp-developer] GIMP 2.99.12 Python User Script's Localization

[Ofnuts via gimp-developer-list]

PS: of course your Gimp should be working in Japanese (which it will be 
if these environment variables are set when you start Gimp)


On 31/08/2022 14:45, Ofnuts via gimp-developer-list wrote:

Just re-checked, works for me. What are the environment values in the
Python console?

>>> os.environ['LANG']
'fr_FR.UTF-8'
>>> os.environ['LANGUAGE']
'fr_FR'

'fr_FR' should be 'ja_JP' for you (and possibly only one of these is
necessary)


On 31/08/2022 10:58, ShiroYuki Mot wrote:

Not localized!
Am I doing something wrong?

(I've tried replacing '_' with '-' or renaming the .mo file, but the
result was the same.)

cmd.exe Tree View

Microsoft Windows [Version 10.0.19044.1889]
(c) Microsoft Corporation. All rights reserved.

C:\Users\UserA>tree C:\Users\UserA\AppData\Roaming\GIMP\2.99\plug-ins /F

C:\USERS\USERA\APPDATA\ROAMING\GIMP\2.99\PLUG-INS
└─Shiro_Dialog_Args6_Test_API3
    │  Shiro_Dialog_Args6_Test_API3.py
    │
    ├─locale
    │  └─ja
    │      └─LC_MESSAGES
    │              Shiro_Dialog_Args6_Test_API3.mo
    │
    └─work
            Shiro_Dialog_Args6_Test_API3.mo
            Shiro_Dialog_Args6_Test_API3.po
            Test.pot

 Notice: .pot = Shift-JIS(cp932) ANSI / .po = UTF-8 / UTF-8 (NoBOM)
       : OS = Windows 10 Japanese Edition

Code

    ## GimpPlugIn virtual methods ##
    def do_set_i18n(self, procname):
        return True, 'Shiro_Dialog_Args6_Test_API3', None
    def do_query_procedures(self):
        return [ 'python-fu-shiro-dialog-args6-test-api3' ]

Zipped File  Shiro_Dialog_Args6_Test_API3.zip

2022年8月30日(火) 19:37 ShiroYuki Mot :

    Dear Ofnuts.

    Thanks for presenting the solution.
    It was detailed and easy to understand.
    I'm glad that this clears up my questions. :)
    I'll try this tonight.

    2022年8月30日(火) 18:40 Ofnuts via gimp-developer-list
:

    My own plugin does:

     def do_set_i18n(self, *args):
     print(f'do_set_i18n({args})')
     return True, 'ofn-guides-presets',None

    (where 'ofn-guides-presets' is the same same as the plugin
    python file
    itself, and as I understand it, if the I18N domain is the same
    name as the plugin file, you don't even need to define this
    method,
    because it's the default behavior.

    Then you create the .mo file(s)  and put them in a
    locale/{language
    code}/LC_MESSAGES subdirectory of your plugin directory.
    ofn-guides-presets/
    ├── locale
    │   └── fr
    │   └── LC_MESSAGES
    │   └── ofn-guides-presets.mo # messages for French
    └── ofn-guides-presets.py   # plugin code

    And yes, using 'gimp30-python' in your own scripts doesn't
    make much
    sense (it does for scripts delivered with Gimp, that share the
    message
    base with other code).


    On 29/08/2022 10:20, ShiroYuki Mot via gimp-developer-list 
wrote:

    > In the official page at
    > https://www.gimp.org/news/2022/08/27/gimp-2-99-12-released/,
    > You say that "with all gettext catalogs under the locale/
    folder of the
    > plug-in directory, and named the same way as the plug-in
    itself".
    >
    > Please teach me 'How TO do that'.
    >
    > On OS, Windows, If I placed my script file
    > (Shiro_Dialog_Args6_Test_API3.py) at
    >
C:\Users\UserA\AppData\Roaming\GIMP\2.99\plug-ins\Shiro_Dialog_Args6_Test_API3,
    > Where do I deploy .mo file?
    > Is it at
    >
'C:\Users\UserA\AppData\Roaming\GIMP\2.99\plug-ins\Shiro_Dialog_Args6_Test_API3\locale'?
    > Or at
'C:\Users\UserA\AppData\Roaming\GIMP\2.99\plug-ins\locale'?
    > And one more question.
    > How do I write the following parts?
    > def do_set_i18n(self, procname):
    >     return True, 'gimp30-python', None
    > (Maybe, That code means calling the official 
gimp30-python.mo.)

    > ___
    > gimp-developer-list mailing list
    > List address:gimp-developer-list@gnome.org
<mailto:address%3agimp-developer-l...@gnome.org>
    > List
membership:https://mail.gnome.org/mailman/listinfo/gimp-developer-list
    > List
archives:https://mail.gnome.org/archives/gimp-developer-list

    ___
    gimp-developer-list mailing list
    List address: gimp-developer-list@gnome.org
    List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
    List archives: 
https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org
List membership: 
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

List archives: https://mail.gnome.org/archives/gimp-developer-

Re: [Gimp-developer] GIMP 2.99.12 Python User Script's Localization

[Ofnuts via gimp-developer-list]

Just re-checked, works for me. What are the environment values in the
Python console?

>>> os.environ['LANG']
'fr_FR.UTF-8'
>>> os.environ['LANGUAGE']
'fr_FR'

'fr_FR' should be 'ja_JP' for you (and possibly only one of these is
necessary)


On 31/08/2022 10:58, ShiroYuki Mot wrote:

Not localized!
Am I doing something wrong?

(I've tried replacing '_' with '-' or renaming the .mo file, but the
result was the same.)

cmd.exe Tree View

Microsoft Windows [Version 10.0.19044.1889]
(c) Microsoft Corporation. All rights reserved.

C:\Users\UserA>tree C:\Users\UserA\AppData\Roaming\GIMP\2.99\plug-ins /F

C:\USERS\USERA\APPDATA\ROAMING\GIMP\2.99\PLUG-INS
└─Shiro_Dialog_Args6_Test_API3
    │  Shiro_Dialog_Args6_Test_API3.py
    │
    ├─locale
    │  └─ja
    │      └─LC_MESSAGES
    │              Shiro_Dialog_Args6_Test_API3.mo
    │
    └─work
            Shiro_Dialog_Args6_Test_API3.mo
            Shiro_Dialog_Args6_Test_API3.po
            Test.pot

 Notice: .pot = Shift-JIS(cp932) ANSI / .po = UTF-8 / UTF-8 (NoBOM)
       : OS = Windows 10 Japanese Edition

Code

    ## GimpPlugIn virtual methods ##
    def do_set_i18n(self, procname):
        return True, 'Shiro_Dialog_Args6_Test_API3', None
    def do_query_procedures(self):
        return [ 'python-fu-shiro-dialog-args6-test-api3' ]

Zipped File  Shiro_Dialog_Args6_Test_API3.zip

2022年8月30日(火) 19:37 ShiroYuki Mot :

Dear Ofnuts.

Thanks for presenting the solution.
It was detailed and easy to understand.
I'm glad that this clears up my questions. :)
I'll try this tonight.

    2022年8月30日(火) 18:40 Ofnuts via gimp-developer-list
:

My own plugin does:

 def do_set_i18n(self, *args):
 print(f'do_set_i18n({args})')
 return True, 'ofn-guides-presets',None

(where 'ofn-guides-presets' is the same same as the plugin
python file
itself, and as I understand it, if the I18N domain is the same
name as the plugin file, you don't even need to define this
method,
because it's the default behavior.

Then you create the .mo file(s)  and put them in a
locale/{language
code}/LC_MESSAGES subdirectory of your plugin directory.
ofn-guides-presets/
├── locale
│   └── fr
│   └── LC_MESSAGES
│   └── ofn-guides-presets.mo # messages for French
└── ofn-guides-presets.py   # plugin code

And yes, using 'gimp30-python' in your own scripts doesn't
make much
sense (it does for scripts delivered with Gimp, that share the
message
base with other code).


On 29/08/2022 10:20, ShiroYuki Mot via gimp-developer-list wrote:
> In the official page at
> https://www.gimp.org/news/2022/08/27/gimp-2-99-12-released/,
> You say that "with all gettext catalogs under the locale/
folder of the
> plug-in directory, and named the same way as the plug-in
itself".
>
> Please teach me 'How TO do that'.
>
> On OS, Windows, If I placed my script file
> (Shiro_Dialog_Args6_Test_API3.py) at
>

C:\Users\UserA\AppData\Roaming\GIMP\2.99\plug-ins\Shiro_Dialog_Args6_Test_API3,
> Where do I deploy .mo file?
> Is it at
>

'C:\Users\UserA\AppData\Roaming\GIMP\2.99\plug-ins\Shiro_Dialog_Args6_Test_API3\locale'?
> Or at
'C:\Users\UserA\AppData\Roaming\GIMP\2.99\plug-ins\locale'?
> And one more question.
> How do I write the following parts?
> def do_set_i18n(self, procname):
>     return True, 'gimp30-python', None
> (Maybe, That code means calling the official gimp30-python.mo.)
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
<mailto:address%3agimp-developer-l...@gnome.org>
> List
membership:https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List
archives:https://mail.gnome.org/archives/gimp-developer-list

___
gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org
List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.99.12 Python User Script's Localization

[Ofnuts via gimp-developer-list]

My own plugin does:

    def do_set_i18n(self, *args):
    print(f'do_set_i18n({args})')
    return True, 'ofn-guides-presets',None

(where 'ofn-guides-presets' is the same same as the plugin python file
itself, and as I understand it, if the I18N domain is the same
name as the plugin file, you don't even need to define this method,
because it's the default behavior.

Then you create the .mo file(s)  and put them in a locale/{language
code}/LC_MESSAGES subdirectory of your plugin directory.
ofn-guides-presets/
├── locale
│   └── fr
│   └── LC_MESSAGES
│   └── ofn-guides-presets.mo # messages for French
└── ofn-guides-presets.py   # plugin code

And yes, using 'gimp30-python' in your own scripts doesn't make much
sense (it does for scripts delivered with Gimp, that share the message
base with other code).


On 29/08/2022 10:20, ShiroYuki Mot via gimp-developer-list wrote:

In the official page at
https://www.gimp.org/news/2022/08/27/gimp-2-99-12-released/,
You say that "with all gettext catalogs under the locale/ folder of the
plug-in directory, and named the same way as the plug-in itself".

Please teach me 'How TO do that'.

On OS, Windows, If I placed my script file
(Shiro_Dialog_Args6_Test_API3.py) at
C:\Users\UserA\AppData\Roaming\GIMP\2.99\plug-ins\Shiro_Dialog_Args6_Test_API3,
Where do I deploy .mo file?
Is it at
'C:\Users\UserA\AppData\Roaming\GIMP\2.99\plug-ins\Shiro_Dialog_Args6_Test_API3\locale'?
Or at 'C:\Users\UserA\AppData\Roaming\GIMP\2.99\plug-ins\locale'?
And one more question.
How do I write the following parts?
def do_set_i18n(self, procname):
return True, 'gimp30-python', None
(Maybe, That code means calling the official gimp30-python.mo.)
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership:https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:https://mail.gnome.org/archives/gimp-developer-list


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Windows Photodraw MIX files

[Ofnuts via gimp-developer-list]

If this ever happens, it will be in Gimp 2.10.34 at best, so coming to
your Gimp 2.8.8  which is about 9 years old, be prepared for a culture
shock. Why don't you upgrade? 2.10 is so much better...

On 18/08/2022 15:34, TheotroniX . via gimp-developer-list wrote:

Hi Gimp developers,

I use your GIMP 2.8.8 with full satisfaction, but:
Is there a way to open the good old Microsoft Photodraw .MIX files in Gimp?
And is it possible for your developers to include the .mix extension in Gimp?
Or is that a difficult operation?
Is there perhaps another way to import these files into Gimp?

In any way Gimp is a great program!

Regards Theo


[cid:104f93e4-e08d-48fc-a7c5-d6440f80d2c9]
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership:https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:https://mail.gnome.org/archives/gimp-developer-list


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] PF_ENUM, SF_ENUM, dynamically defined enums for plugins

[Ofnuts via gimp-developer-list]

Not really. With the current interface, I manage it that way:

I have these two functions:

def createOpts(name,pairs):
    optsclass=namedtuple(name+'Type',[symbol for symbol,label in 
pairs]+['labels','labelTuples'])

    opts=optsclass(*(
    range(len(pairs))
    +[[label for symbol,label in pairs]]
    +[[(label,i) for i,(symbol,label) in enumerate(pairs)]]
    ))
    return opts

def createValuedOpts(name,triplets):
    optsclass=namedtuple(name+'Type',[symbol for symbol,_,_ in 
triplets]+['labels','labelTuples','values'])

    opts=optsclass(*(
    range(len(triplets))
    +[[label for _,label,_ in triplets]]
    +[[(label,i) for i,(_,label,_) in enumerate(triplets)]]
    +[[value for _,_,value in triplets]]
    ))
    return opts

"createOpts" lets one define a namedtuple where members have the proper 
values, so for instance, after


GuidesShow=createOpts('GuidesShow',[('NO','No'),('YES','Yes')])

I can use "GuidesShow.NO" in the code and I don't really care if it was 
defined as 1 or 0.


"createValuedOpts" adds a "values" array which is indexed by the other 
members. "values" elements can be anything: integer/float constants,  
strings, but also functions/lambdas  so for instance I can define a 
bunch of conversions:


Units=createValuedOpts('Units',[
    ('MM',"Millimetres",lambda x: x/25.4),
    ('CM',"Centimetres",lambda x: x/2.54),
    ('INCH',"Inches",lambda x: x),
    ])

So later in the code, assuming "units" is the value of the corresponding 
parameter, converting whatever values to inches is just


inches=Units.values[units](input)

The "labels" member is also generated to be used in the registration:

optionsUnits=(PF_OPTION,'unit','Units', Units.MM, Units.labels)

Here also, I never have to worry about some behind-the-scenes integer 
value.




On 15/08/2022 02:52, Nathan Summers wrote:


Sounds like a nightmare for scripting if I'm understanding correctly.

Rockwalrus


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] PF_ENUM, SF_ENUM, dynamically defined enums for plugins

[Ofnuts via gimp-developer-list]

I'm not convinced this needs to be an enum. The basic problem it to
show  a list of strings, and return the index of the selected one.  The
contents of the list can be quite dynamic. As far as I can tell, in 2.10
they aren't cached in pluginrc. In 3.0, the query/init methods of the
plugin suggest that things can be dynamic and a list of URLs/devices
could be created during registration (this could also change if the user
changes the UI language, and only the plugin would know how to retrieve
the translations...).  How the returned integer is used is left to the
imagination of the author.

So, IMHO, this is more like a variant of regular integer, instead of
showing a slider you display  a list of labels.

On 08/08/2022 14:42, Lloyd Konneker via gimp-developer-list wrote:

This is a continuation of a thread on this list:
https://mail.gnome.org/archives/gimp-developer-list/2022-July/msg00016.html.
The thread diverged to a discussion about future PF_OPTION implementation
in GIMP 3.

Here are my preliminary thoughts.

A PF_OPTION, in the old PyGimp, or a SF_OPTION, in ScriptFu,
is a declaration of a dynamic enum type.
The enum is created by the plugin.
Only the plugin knows the enum.
GIMP has no knowledge of the enum, until at runtime the plugin informs it.

Suppose that for PF_OPTION we can implement so that a GIMP plugin
dynamically defines an enum type
(in the GType system)
Then when registering an arg of the plugin declared using PF_OPTION,
the plugin uses a g_param_spec_enum, passing the GType of the dynamic enum
type.
Then GIMP can use that g_param_spec to add a  property to the GimpProcedure
for the plugin,
and to create a GimpConfig for that property,
and show a dialog with a combo-box widget for the enum type.
All the latter stuff seems to work already.
That is, PF_ENUM and SF_ENUM seem to work,
for a plugin to declare an argument of a GEnum subtype that GIMP has
defined.
The problem is to implement the dynamic creation of an enum type.

GLib appears to be able to create enum types dynamically.
Its complicated and arcane, not something I understand.
So what I suggest may not be possible.

If you grep the GIMP repo, you find G_DEFINE_DYNAMIC_TYPE used in the
modules directory.
That is a GLib macro that seems pertinent, it seems to hide many of the
arcane details.
Anyway, there seems to be some history of dynamically defined types in GIMP.
The word "modules" is a GLib term for dynamically loaded code.

One problem is that GLib documentation often uses the word "static" for the
array of GEnumValues
that are in a GEnum type.
I don't think that  means the key value pairs in the enum must be defined
as static vars in some C code.
I think you can still have an interpreted plugin that allocates an array of
key value pairs and creates a dynamic GEnum type from it.

Another issue that concerns me is the "wire".
If a plugin creates a dynamic GEnum subtype,
does the type have to cross the wire, or only values of the GEnum?
I hope I am worrying too much.

As Ofnuts pointed out, PF_ENUM is heavily used.
It  deserves some attention.
In the thread reference above, Jehan has said he has an idea for
implementation and realizes it needs attention.
Here I am offering an alternative high-level view of what the technical
problem is.

If the technical problem is to create a dynamic GType,
then a pragmatic problem is that few developers deeply understand GType.
(Its a slog for me.)
Maybe Neils could look at it, or maybe we could get some mentorship from
GNOME?
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership:https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:https://mail.gnome.org/archives/gimp-developer-list


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] How to distribute translated/translatable python plugins in 2.99

[Ofnuts via gimp-developer-list]

Thanks. Eventually made it to work.


I am planning to make tutorials for all the GIMP 3.0 API for plug-in
creation, and more generally extension creation. This will include
localization.
We are currently also in the process of reviving
https://developer.gimp.org/ (which is very outdated right now).


Since I just finished migrating my first V2 plugin to V3 I think I can
help there, with firsthand experience.  Recently retired, so plenty of
time. PM me you needs (En or FR). This will  give you more time to
finish GimpUi.ProcedureDialog which is still missing a replacement for
PF_OPTION, which is a major impairment for my migration efforts(*). Some
preference for the Wiki on Gitlab, though, unless markdown can be used
for developer.gimp.org/


That's actually one of the things I still have to review and make
decisions or changes about. Look at my little checkbox at the bottom
of this comment:
https://gitlab.gnome.org/GNOME/gimp/-/issues/8124#note_1493804
The one box still unchecked says "Menu paths" which I believe is what
you are asking about.


This is comment bait, and I won't resist...

(*) usage stats in my Python plugins:

  1 PF_GRADIENT
  1 PF_TEXT
  2 PF_LAYER
  2 PF_PALETTE
  3 PF_FONT
  6 PF_COLOR
 12 PF_INT
 13 PF_DIRNAME
 19 PF_TOGGLE
 30 PF_STRING
 37 PF_FLOAT
 38 PF_DRAWABLE
 48 PF_VECTORS
 52 PF_SLIDER
 82 PF_SPINNER
    109 PF_IMAGE
    153 PF_OPTION



On 26/07/2022 16:48, Jehan Pagès wrote:

Hi!

On Mon, Jul 25, 2022 at 11:38 PM Ofnuts via gimp-developer-list
 wrote:

What is necessary to distribute a translation-enabled python
plugin for
2.99?

I assume that the plugin distribution should be self-sufficient  since
it cannot assume that translations will be available in some general
repository.

What should the plugin directory look like (it seems it needs a
"locale"
subdirectory)?

Indeed.

But adding and "fr.po" file there with some msgid/msgstr
doesn't seem enough.


It must be "compiled" too. `.po` files are source for `.mo` (or
`.gmo`) files.
Also it must be in subdirectories (standard translation
organizations). So if your plug-in is called "my-plug-in", then the
.mo file for French would likely be in locale/fr/LC_MESSAGES/my-plug-in.mo

Are there examples available (outside of Gimp's
source code since these use the general repo).


Anyway that's a lot of work being done right now. We can't give ETA,
but it will happen. :-)


And do menu locations need to be translated as well?


That's actually one of the things I still have to review and make
decisions or changes about. Look at my little checkbox at the bottom
of this comment:
https://gitlab.gnome.org/GNOME/gimp/-/issues/8124#note_1493804
The one box still unchecked says "Menu paths" which I believe is what
you are asking about.

Again, it's on my TODO, but I can't give an ETA. My hope is that I can
make time to finish this one for the next dev release. We'll see.

Jehan


--

Ofnuts




___
gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org
List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list



--
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] How to distribute translated/translatable python plugins in 2.99

[Ofnuts via gimp-developer-list]

What is necessary to distribute a translation-enabled python plugin for
2.99?

I assume that the plugin distribution should be self-sufficient  since
it cannot assume that translations will be available in some general
repository.

What should the plugin directory look like (it seems it needs a "locale"
subdirectory)? But adding and "fr.po" file there with some msgid/msgstr
doesn't seem enough. Are there examples available (outside of Gimp's
source code since these use the general repo).

And do menu locations need to be translated as well?

--

Ofnuts




___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] wiki.gimp.org

[Ofnuts via gimp-developer-list]

Is wiki.gimp.org still active? My bookmarks to it no longer work.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Adjustments on dynamics

[Ofnuts via gimp-developer-list]

IMHO one of the main issues with Dynamics is the rotation origin/range.
Currently it is difficult to have a brush that just wiggles a bit
because +5° and -5° are at opposite ends of the 0-360 curve. You have to
create an upside-down brush for exactly this purpose (and give it a
175-185 range)

Using brushes directly would be possible with a -180°<->+180° curve.


On 13/02/2022 23:46, Joao S. O. Bueno via gimp-developer-list wrote:


On 13/02/2022 23:46, Joao S. O. Bueno via gimp-developer-list wrote:

Hi folks -

This is just to let it in written here that last Monday me, Ayreom, Jehan
and Americo
had a meeting concerning the current behavior of dynamics (both up to 2.10
and on 2.99) -
and asserted some incorrect behaviors -

These included but are not limited to the "spacings"
dynamic output, which is mostly not usefull at all since the dynamics curve
has its lower value corresponding to the current "spacing" setting on the
tool options. A most useful functionality would be to be able, for example,
to have the minimum corresponding to spacing "1%" and maximum corresponding
to the tool options setting.  In that way it would be possible to set the
curve so that spacing would vary from 3% to 15% - which can enforce some
visuals on brushes intending to imitate natural painting. Americo is the
authority on this - but I fully agree, and it should be easily verifiable,
that the current behavior yields no visually intesting results.

Another broken dynamics is the "aspect ratio X direction": it just yields
maximum aspect ratio (20:1 or 1:20) disregarding any intermediate values -

I had to leave the meeting early, and I think the three of them had
asserted more behaviors that are currently of no use but as a toy.

Before I left, though, one of Jehan's sugestions was that we should find a
way to implement a version number to the dynamics files, so that as these
things get fixed, GIMP can auto-convert old, bad behaviors to a new, fixed
scale (if possible at all, after the fix is in effect)..

I think most of the issues discussed have proper issues open on gitlab -
but I proposed sending this in written form to get more engagement to these
(and certainly other)  relatively small fixes that are in need.

Best regards,

joao
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership:https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:https://mail.gnome.org/archives/gimp-developer-list


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Fwd: Making enabling dynamics a checkbox (Issue #4333)

[Ofnuts via gimp-developer-list]

Also all in favor of a special status for the "Off" dynamics. We
definitely need a way to identify them independently of the UI language.

On 29/12/2021 17:19, Asalle via gimp-developer-list wrote:

Forgot to include the mailing list :(

-- Forwarded message -
From: Asalle 
Date: Wed, 29 Dec 2021 at 17:18
Subject: Re: [Gimp-developer] Making enabling dynamics a checkbox (Issue
#4333)
To: 


Hi Joao and all,

I think it's a valid argument, even more so because Jehan and David Z were
discussing it some time ago. From what I can see they concluded on the
checkbox, among other reasons because this way you can assign a shortcut
(which is my initial reason for trying to get this done). See here:
https://gitlab.gnome.org/GNOME/gimp/-/issues/6220#note_998836.

Best regards,
Asa

On Wed, 29 Dec 2021 at 17:01, Joao S. O. Bueno  wrote:


Maybe, instead of a redundant control to the already cluttered tool
options,
we could step back and try to get an easier way to find and select a
desired
dynamics (including the "Dynamics Off"). meanwhile, maybe just
making it special so that it shows first on the dynamics list would
be a nicer workaround than adding still another control there.

On Wed, 29 Dec 2021 at 12:42, Asalle via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:


Hi all,

I'm fairly new to gimp, so any advice is welcome. I'm attempting to
implement this feature request:
https://gitlab.gnome.org/GNOME/gimp/-/issues/4333#note_1211607.
In short: instead of changing from e. g. "Basic dynamics" to "Dynamics
Off"
and vice versa, there should be just a checkbox that allows to turn the
dynamics off and on.

So far I've implemented the checkbox and a "use-dynamics" property in
PaintOptions. But I'm not sure how to actually enable it when drawing. I'm
also not sure if I'm on the right path, so if you could nudge me in the
right direction, I would appreciate it!

Here is my patch:

https://gitlab.gnome.org/Asalle/gimp/-/commit/1928d1edd71286ce7b185fbf24eda91aa5b504b3
.


--
Best regards,
Asa
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Allow simple warping/curving of text

[Ofnuts via gimp-developer-list]

Curve how?

https://www.gimp-forum.net/Thread-ofn-bend-path
https://www.gimp-forum.net/Thread-ofn-text-along-path


On 09/10/2021 08:08, Jarrod T via gimp-developer-list wrote:

  Make an easy tool to curve text please, such as other editors have or
photoshop has
I find it really frustrating on how difficult it is in gimp, and after
googling is a sentiment by many. Please add this! <3

Example in PS:
[image: image.png]
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Gimp export to function

[Ofnuts via gimp-developer-list]

What OS/Version? It is possibly some security setting that prevents
unrecognized apps from accessing external drives.

On 02/10/2021 20:04, Ken Masters via gimp-developer-list wrote:

I downloaded GIMP and so far I think most everything is fine except “when I use 
the export function it won’t show the external drive in the list of possible 
functions.


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] About The Python Script writing

[Ofnuts via gimp-developer-list]

Wouldn't it be more natural to write the migration program in Python
itself (plus this needs Python2->Python3 migration)? Why add a
dependency on yet another language? Is there a decent C# runtime on Linux?

On 24/08/2021 17:31, ShiroYuki Mot via gimp-developer-list wrote:

I wrote the Script File Migration Program.
It was used by MS Visual Studio C#.
The target is to migrate the simple and basic scripts to the new API 3 in
GIMP 2.99 (GIMP 3).
Yes, Scheme and Python, both.
It is still Draft level yet.
Scheme file was almost done, but, Python file is not complete yet.
(No workable Python code has been generated yet. Need manual editings.)

Holding Items for Python. Can it be run on L
1. class - Parameters (__gproperties__ = {)
2. class - def do_create_procedure - procedure.add_argument_from_property
3. pdb calling conversion ... not set out. Maybe, I know how to write.
   4. old procedure arguments migration

On Python,
The formatted/migration-based  sources are created from the official
'foggify.py' .
The qualified phrases using "<>" replace by a value obtained from the
old code.

Here is Questions.
1. Can write PF_COLOR/PF_SPINNER/etc. block like a 'str/float' style in
'__gproperties__ = {' at class ?
2. Is the Class name the Camel-style except "_" ?
ex. python-fu-shiro-migration-test-210 > ShiroMigrationTest210
3. Can the procedure definition name include "_"?
(4th arg at 'procedure = Gimp.ImageProcedure.new' of 'def
do_create_procedure(self, name)')
ex. def shiromigrationtest210 > ? def shiro_migration_test_210 OK?



Initially, the development language was VB.net.
As a possibility in the future, if I publish the source code (or
project/solution) and expect other people to participate, I thought that C#
was more versatile, so I wrote it by C#, which I am not used to.



We, the beginner level GIMP scripting users, are referring to the Procedure
Browser.
So, I think there are many cases that there are a lot of pdb.xxx calling
sentences in the file.
In this case, I feel that visibility deteriorates because there are the new
multiple lines per the old syntax line by the migration.

Maybe, it is better that using not pdb calling but Gimp command (Gimp class
?).
But currently there does not exist the comparison table/list for these.
I think it would be very useful if that will be provided.


.zip Inf.
FileName : GIMPscriptMigSupport_API2to3.v.0.8.1.15.zip
FileDate : 2021/08/24 23:09:04 ( or * Downloaded Date * )
FileSize : 193099(189KB)
MD5 : 318f7a7002a44550188d630c9cd48cfa
   SHA1 : 2e6390231b13f39b4d20f81e70003641cbadf499

FileName : API_Inf/RemovedFunctions_Replacement_GIMP3.txt   <- in zip
FileName : GIMPscriptMigSupport_API2to3.exe   <- in zip
FileName : GIMPscriptMigSupport_API2to3.exe.config   <- in zip
FileName : Ref_Inf/GIMP_Enums.txt   <- in zip
FileName : Ref_Inf/Py3_Import.txt   <- in zip
FileName : Ref_Inf/Py3_Registration.txt   <- in zip

  GIMPscriptMigSupport_API2to3.v.0.8.1.15.zip

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] The problem of compile gimp

[Ofnuts via gimp-developer-list]

You also need to build Babl (like you did for GEGL, these packages work
together).

On 22/07/2021 14:41,  via gimp-developer-list wrote:

Hello??
   Recently, I was learning to compile gimp from source code, 
and I encountered a problem. I'm following the rules 
https://wiki.gimp.org/wiki/Hacking:Building To compile GIMP.
   My problem is that I successfully carried out these 
commands:
  cd babl
  meson _build \
--prefix=${GIMP_PREFIX} 
\
--buildtype=release \
-Db_lto=true
 cd _build
 ninja
 ninja install

   But when I built gegl and gimp, ubuntu said I didn't find 
babl??I hope you can help me. Thank you??
   My operating system is Ubuntu 19.10
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Trouble compiling 2.99

[Ofnuts via gimp-developer-list]

On 30/04/2021 21:08, Liam R E Quin wrote:

On Fri, 2021-04-30 at 14:31 -0400, Liam R E Quin wrote:

On Fri, 2021-04-30 at 17:18 +0200, Ofnuts via gimp-developer-list
wrote:

     GIMP requires the GEGL operation "gegl:introspect".

I seem to remember this requiers "dot" (from GraphViz) be in your path.



In case it helps, for compiling babl gegl & gimp i use,

export PREFIX=$HOME/opt
export LD_LIBRARY_PATH=${PREFIX}/lib
export PKG_CONFIG_PATH=${PREFIX}/lib/pkgconfig/
export PATH=$PREFIX/bin:$PATH
export XDG_DATA_DIRS="$PREFIX/share:$XDG_DATA_DIRS"
export GI_TYPELIB_PATH="${PREFIX}/lib/girepository-
1.0:${PREFIX}/lib/${arch}/girepository-1.0:$GI_TYPELIB_PATH"

# enable sqrt() in TinyScheme:
export USE_MATH=1

# https://wiki.gimp.org/wiki/Hacking:Building

and then in each of babl, gegl, gimp in turn,
git pull
rm -rf obj-x86_64/; SRC_DIR=$(pwd); BUILD_DIR=${SRC_DIR}/obj-$(arch);
mkdir -p $BUILD_DIR && cd $BUILD_DIR && meson -Dprefix=$PREFIX -
Dworkshop=true -Dcairo=enabled -Dumfpack=enabled -Dopenexr=enabled
$SRC_DIR && ninja && ninja install


This assumes you have graphviz, and that you have libmypaint 1.
installed in the same $PREFIX



I have about the same, and it used to work (I did successful builds last
summer).

I didn't see any build complaining about a missing graphviz despite it
not being installed on my system.

So, I installed it, rebuild GEGL and lo and behold, it works. So thanks,
and don't hesitate to claim your beer if you come near Paris.

Now, grep'ing my build tree, I see graphviz mentioned in the Pango
files...  I'll try a  full rebuild tomorrow.

Thanks again




___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Trouble compiling 2.99

[Ofnuts via gimp-developer-list]

On 30/04/2021 19:58, Liam R. E. Quin wrote:

On Fri, 2021-04-30 at 09:46 +0200, Ofnuts via gimp-developer-list
wrote:

/Gimp-dev/2.99/build/gimp/_build/libgimp/Gimp-3.0.gir
HarfBuzz-0.0.gir:135.5-135.79: error: `hb_.language_t' not
supported as
type for constants

Searching with Google for this message finds
https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/515
which suggests you had an old pango release.

Here (Mageia 8) i have harfbuzz 2.8 and pango 1.48, for what it's
worth. but the error seems more about mismatched versions of pango and
harfbuzz to me.



Thanks.

Upped Pango to 1.4.8 to no avail. Will try HarfBuzz next.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Trouble compiling 2.99

[Ofnuts via gimp-developer-list]

Thanks, disabling that makes the build successful. However, when I start
Gimp, I get a dialog with:

   GEGL operation missing!

   GIMP requires the GEGL operation "gegl:introspect".
   This operation cannot be found. Check your
   GEGL install and ensure it has been compiled
   with any dependencies required for GIMP.

I'm compiling a freshly pulled GEGL. The build config says:
gegl 0.4.31

  Directories
    prefix  : /Gimp-dev/2.99/run
    libdir  : lib/x86_64-linux-gnu

  GEGL docs
    Reference   : False
    Docs    : True

  Optional features
    Build workshop  : False
    Introspection   : True
    Vala support    : True

  Optional build utilities
    asciidoc    : True
    dot : False
    pygobject   : True
    source-highlight: False
    w3m : True

  Optional dependencies
    avlibs  : True
    Cairo   : True
    GDKPixbuf   : True
    gexiv2  : True
    Jasper  : False
    lcms    : True
    libnsgif    : True
    libraw  : True
    Luajit  : False
    maxflow : False
    mrg : False
    Pango   : True
    pangocairo  : True
    poly2tri-c  : True
    poppler : True
    OpenEXR : True
    rsvg    : True
    SDL1    : False
    SDL2    : True
    spiro   : False
    TIFF    : True
    umfpack : False
    V4L : True
    V4L2    : True
    webp    : True

  Subprojects
    libnsgif    : YES
    poly2tri-c  : YES

Option buildtype is: release [default: debugoptimized]
Found ninja-1.9.0 at /usr/bin/ninja

During the compilation, this shows up (but then these compiles have
always issued a lot of warnings):

[330/812] Compiling C object
operations/common/gegl-common.so.p/introspect.c.o
../operations/common/introspect.c: In function ‘gegl_introspect_load_cache’:
../operations/common/introspect.c:61:3: warning: ignoring return value
of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
   61 |   write (fd, dot_string, strlen (dot_string));
  |   ^~~

And later I see (removed all the lines marked "ok"):

[643/812] Generating gegl-0.4.vapi with a custom command
Gegl-0.4.gir:7866.7-7866.60: warning: Signal `Gegl.Node.progress'
conflicts with method of the same name
[809/812] Generating doc-operations-img with a custom command
not ok   2 - gegl:warp (no ref) # TODO hash =
f1b3ab0f1e84ec5882f23aee0a0c68f6
not ok  11 - gegl:transform (noop) # TODO hash is noop
not ok  12 - gegl:reset-origin (no ref) # TODO hash =
2e11acd5a417e1e9c6894e9a8f974e14
not ok  15 - gegl:path (unstable) # TODO reference is not reproducible
not ok  16 - gegl:npd (noop) # TODO hash is noop
not ok  23 - gegl:emboss 806a50f6b8e3128d346480c23ce02359 !=
af0c6c39428853e1010fa4c51ee67c7d
not ok  37 - gegl:c2g (unstable) # TODO reference is not reproducible
not ok  39 - gegl:edge-sobel ed3220367a420f5844316a11d11d9eae !=
d75a32d401a11b715bd28277a5962882
not ok  50 - gegl:stress (unstable) # TODO reference is not reproducible
not ok  87 - gegl:svg-huerotate (noop) # TODO hash is noop
not ok  89 - gegl:svg-matrix (noop) # TODO hash is noop
not ok  90 - gegl:svg-saturate (noop) # TODO hash is noop
not ok  94 - gegl:displace (noop) # TODO hash is noop
not ok 102 - gegl:whirl-pinch 5f9e422396aca096dd0d3a551696b2f8 !=
e24f6a5ec8c1c7faead1dbeeae34e386
not ok 126 - gegl:json:dropshadow2 (noop) # TODO hash is noop
not ok 127 - gegl:json:grey2 (no ref) # TODO hash =
43ddd80572ab34095298ac7c36368b0c
not ok 128 - gegl:seamless-clone-compose (unstable) # TODO reference is
not reproducible
not ok 129 - gegl:shadows-highlights (noop) # TODO hash is noop
not ok 137 - gegl:pack (noop) # TODO hash is noop
not ok 139 - gegl:recursive-transform (no ref) # TODO hash =
4fb51936e6cb594c1d79462280f21440
not ok 177 - gegl:cast-space (noop) # TODO hash is noop
not ok 178 - gegl:convert-space (noop) # TODO hash is noop
not ok 180 - gegl:seamless-clone (no ref) # TODO hash =
c138747b74936fecff15497280fd251d
not ok 183 - gegl:map-absolute (no ref) # TODO hash =
f1b3ab0f1e84ec5882f23aee0a0c68f6
not ok 185 - gegl:matting-global (no ref) # TODO hash =
72e111a28f07e2236d6378c3f64eaec3
not ok 186 - gegl:piecewise-blend (no ref) # TODO hash =
f1b3ab0f1e84ec5882f23aee0a0c68f6
not ok 187 - gegl:text 74a9c303192ab2b7763d6808ae892b92 !=
a6612efdac71654360b19ccc424ff130
not ok 205 - gegl:remap (no ref) # TODO hash =
4a011700f93903b4b8fc92be8f3d7ec3
1..205

# without opencl acceleration
# Maybe see bug https://bugzilla.gnome.org/show_bug.cgi?id=780226
# 4 operations producing unexpected hashes:
#  gegl:emboss 806a50f6b8e3128d346480c23ce02359 !=
af0c6c39428853e1010fa4c51ee67c7d
#  gegl:edge-sobel ed3220367a420f5844316a11d11d9eae !=
d75a32d401a11b715bd28277a5962882
#  gegl:whirl-pinch 5f9e422396aca096dd0d3a551696b2f8 !=
e24f6a5ec8c1c7faead1dbeeae34e386
#  gegl:text 

Re: [Gimp-developer] Trouble compiling 2.99

[Ofnuts via gimp-developer-list]

Thanks but no change

Digging into this a bit more, it appears that the
"HarfBuzz-0.0.gir:135.5-135.79"  would be a reference to
/usr/share/gir-1.0/HarfBuzz-0.0.gir and starting at line
#135 this file is:

    
  
  
    

And my /usr/include/harfbuzz/hb-common.h a line #168 is indeed:

    #define HB_LANGUAGE_INVALID ((hb_language_t) 0)

But all these are "hb_language_t" and not "hb_.language_t"

My primary suspect would be my pango install (my Ubuntu 19.10 only has
Pango 1.44 so I have added my own self-compiled 1.47),
but still "hb_.language_t" would have shown up in the uncountable grep's
I have done in my build & source directories and in /usr.

On 29/04/2021 20:13, Jacob Boerema wrote:

If your build dir was not empty before starting then you could try:

meson configure --clearcache

Meson and/or library updates sometimes get meson/ninja confused.

--

Jacob Boerema


On 29 Apr 2021 at 19:40, Ofnuts via gimp-developer-lis wrote:


I'm trying to compile 2.99. It used to work, but my last successful
attempt was in June 2020.

Compiling on Ubuntu 19.10 but I upgraded meson and pango to required
versions.

When I use the meson build:


meson _build --prefix=${GIMP_PREFIX} --buildtype=release
-Djavascript=always -Dlua=always -Dpython=always

cd _build && ninja

It stops with:

[450/1967] Generating gimp-3.0.vapi with a custom command
FAILED: libgimp/gimp-3.0.vapi
/usr/bin/vapigen --quiet --library=gimp-3.0
--directory=/Gimp-dev/2.99/build/gimp/_build/libgimp --pkg=babl-0.1
--pkg=cairo-1.0 --pkg=gdk-pixbuf-2.0 --pkg=gegl-0.4 --pkg=gio-2.0
--pkg=glib-2.0 --pkg=gobject-2.0 --pkg=gtk+-3.0
--metadatadir=/Gimp-dev/2.99/build/gimp/libgimp
/Gimp-dev/2.99/build/gimp/_build/libgimp/Gimp-3.0.gir
HarfBuzz-0.0.gir:135.5-135.79: error: `hb_.language_t' not supported as
type for constants
[459/1967] Generating GimpUi-3.0.gir with a custom command
ninja: build stopped: subcommand failed.

My harfbuzz installation:

ii  gir1.2-harfbuzz-0.0:amd64  2.6.1-3  amd64    OpenType text
shaping engine (GObject introspec
ii  libharfbuzz-dev:amd64  2.6.1-3  amd64 Development files for
OpenType text shaping eng
ii  libharfbuzz-gobject0:amd64 2.6.1-3  amd64    OpenType text
shaping engine ICU backend (GObje
ii  libharfbuzz-icu0:amd64 2.6.1-3  amd64    OpenType text
shaping engine ICU backend
un  libharfbuzz0       (no description
available)
un  libharfbuzz0a      (no description
available)
ii  libharfbuzz0b:amd64    2.6.1-3  amd64    OpenType text
shaping engine (shared library)

Am I missing something?





___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list




___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Trouble compiling 2.99

[Ofnuts via gimp-developer-list]

I'm trying to compile 2.99. It used to work, but my last successful
attempt was in June 2020.

Compiling on Ubuntu 19.10 but I upgraded meson and pango to required
versions.

When I use the meson build:


meson _build --prefix=${GIMP_PREFIX} --buildtype=release
-Djavascript=always -Dlua=always -Dpython=always

cd _build && ninja

It stops with:

[450/1967] Generating gimp-3.0.vapi with a custom command
FAILED: libgimp/gimp-3.0.vapi
/usr/bin/vapigen --quiet --library=gimp-3.0
--directory=/Gimp-dev/2.99/build/gimp/_build/libgimp --pkg=babl-0.1
--pkg=cairo-1.0 --pkg=gdk-pixbuf-2.0 --pkg=gegl-0.4 --pkg=gio-2.0
--pkg=glib-2.0 --pkg=gobject-2.0 --pkg=gtk+-3.0
--metadatadir=/Gimp-dev/2.99/build/gimp/libgimp
/Gimp-dev/2.99/build/gimp/_build/libgimp/Gimp-3.0.gir
HarfBuzz-0.0.gir:135.5-135.79: error: `hb_.language_t' not supported as
type for constants
[459/1967] Generating GimpUi-3.0.gir with a custom command
ninja: build stopped: subcommand failed.

My harfbuzz installation:

ii  gir1.2-harfbuzz-0.0:amd64  2.6.1-3  amd64    OpenType text
shaping engine (GObject introspec
ii  libharfbuzz-dev:amd64  2.6.1-3  amd64 Development files for
OpenType text shaping eng
ii  libharfbuzz-gobject0:amd64 2.6.1-3  amd64    OpenType text
shaping engine ICU backend (GObje
ii  libharfbuzz-icu0:amd64 2.6.1-3  amd64    OpenType text
shaping engine ICU backend
un  libharfbuzz0       (no description
available)
un  libharfbuzz0a      (no description
available)
ii  libharfbuzz0b:amd64    2.6.1-3  amd64    OpenType text
shaping engine (shared library)

Am I missing something?





___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Plug-In Golden ratio on Github/Youtube

[Ofnuts via gimp-developer-list]

Search a research paper widely available in the net as a PDF:

 "Piecewise Circular Approximation of Spirals and Polar Polynomials"

It describes how you can approximate a linear spiral using circle arcs.
You can then use Gimp paths to create the arcs. There is a well known
approximation
or a circle arc with a Bezier spline (Gimp paths are actually Bezier
splines)(search "Bezier kappa"), so you just string the circle arcs into
a path, that you render. You can describe your spiral with 4 control
points (12 if you include tangents) per turn.

If you are not too familiar with Paths, see:
https://www.gimp-forum.net/Thread-Paths-Basics

If you want examples of scripts that use Gimp's vectors/paths, see:
http://sourceforge.net/projects/gimp-path-tools/files/scripts/
In particular see: golden-spiral-0.0.py

On 22/02/2021 18:31, José E Uzcategui via gimp-developer-list wrote:

Hello:
I have developed a plug-in to add layers of golden ratio circles, squares
and a spiral .
I create spiral by writing each point, it seems to be slow but accurate.
Would you advise any method alternative?

https://youtu.be/CC1l9RPhpJM
https://github.com/JoelHz/goldenratioGimpPython.git

thanks in advance.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Translating Gimp into arabic

[Ofnuts via gimp-developer-list]

Gimp already has Arabic translations. Do you have something specific in
mind?

On 03/02/2021 09:41, Abdullah OLABI wrote:

Hi,

Hope you are all fine.

I would like please to talk to someone in your organisation about
translating Gimp into Arabic language.

With kind regards

Abdullah Olabi

___
gimp-developer-list mailing list
List address:    gimp-developer-list@gnome.org
List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] App background query

[Ofnuts via gimp-developer-list]

You can change the theme:

Edit>Preferences>Interface>Theme

You may also want to change the Icon theme:

Edit>Preferences>Interface>Icon Theme)


On 31/01/2021 15:02, Melvill's wrote:

When I open GIMP it comes up with a black background. Can I change it
to another color as I have problems reading white on back

Thanks for your help

Johann

___
gimp-developer-list mailing list
List address:    gimp-developer-list@gnome.org
List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Does it pay to be Open-Source?

[Ofnuts]

On 26/09/2020 21:47, Anthony Beaulé via gimp-developer-list wrote:

Hello GIMP developers,

One of the things I've been enjoying is trying to use less and less proprietary 
software, and I've been thinking of becoming a developer for quite some time 
now.

I really love the passion and effort that's put in these projects, yours 
included, and I enjoy using them, but I can't say the same about creating my 
own Open-Source software; at least financially.

I want to ask you people out of curiosity because this project has existed for 
almost 25 years, and still going strong! Thus, I assume that you developers 
would have a lot of experience working with at least this Open-Source project.

So here goes:
Question 1:
What do I need to get started on making a project Open-Source? My guess is just 
my source code, a list of all the dependencies my program uses, and an account 
on a Git website (GitHub, or SourceForge are the two I know).


Readable and reliable code, some documentation, as well as implementing
nicely some non-trivial functionality. Otherwise it will take less time
for other folks to write their own.


Question 2:
Can I still control or direct the program after I've posted it on a Git 
website? I don't mind other using my code for other projects, as long as I'm 
credited somewhere. I also don't mind it when people point-out flaws in my 
programs either, I or my team (if I have one) just want to be the one to fix it.


You keep control if you demonstrate some ability and competence (or at
least more ability and competence than other project members). Linus
Torvalds has been in control of Linux for ages...


Question 3:
How do you make money off of Free software, and can you live off of it? I'm 
also wondering how money is split in large groups like yours. As much as I'd 
like to code Open-Source Software, I can't do it for free all the time as I'm 
on a tight budget.


If your software has a business use, you can sell support for it. Big
companies hate free software, they want someone to be accountable for
maintenance. Another solution is to have FOSS "Community" edition, and a
commercial "Pro" version with more features.  Otherwise, donations
(Patreon or else). I don't think there is so much money in the Gimp
project that the developers can split it between themselves. At best it
allows them to meet from time to time without paying all the  travel
expenses.


Question 4:
How can you get your program recognised? It's one thing to code a cool program, 
but if no one knows about it then it won't stand a chance. I'm guessing the 
best thing is just advertise it on social media like everything else nowadays.


Possibly. But not everyone is on social media (unless GitHub counts as
such :)


In conclusion, I'd love to be more educated in this topic as being Open-Source 
is something that I find beautiful in a way, as even if a project withers it's 
truly never dead and can bloom again in someone else's project. I'd also love 
to make Open-Source projects, but I fear that it may be a waste of time 
financially.


It will likely be so. People do FOSS because they want to write a good
program. Sometime things get out of hand and they eventually make money
from it... but it's not a frequent occurrence.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Suggestd enhancement

[Ofnuts]

On 23/07/2020 16:54, Shlomi Fish wrote:


Furthermore, GIMP will need to query the clipboard before displaying the
menubar or menu which will likely also be time consuming on your end.


Worse that that. Large data such as images are not always put in the
clipboard, the source application merely posts the equivalent of an
availability notice in the clipboard, and the pasting application
negotiates what the source application will eventually share (actual
data format, etc...).


https://en.wikipedia.org/wiki/Klipper  can do it here, and there may be other
clipboard managers which can as well.


I would also recommend Klipper, but the version in my Kubuntu 19.10
(5.16.5) makes Gimp crash when it copies image to the clipboard (if I
set Klipper to watch for images).

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] No Lua or Python in Gimp 2.99

[Ofnuts]

On 15/06/2020 23:25, Lloyd Konneker via gimp-developer-list wrote:

I would hope that in the future the Gimp install would define that variable
in the environment of Gimp so that plugins spawned by Gimp would have the
same environment.  But since 2.99 is still in development, there is no
installer so you must temporarily do it yourself.


When Gimp is installed as part of the system the typelibs are put in
directories that are already in the GI_TYPELIB_PATH (or in default
locations).

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] No Lua or Python in Gimp 2.99

[Ofnuts]

On 14/06/2020 20:20, Lloyd Konneker via gimp-developer-list wrote:

Try package lua-lgi

I think I had this same issue, and documented it at
https://wiki.gimp.org/wiki/Hacking:Problems_and_solutions#luajit:_...mp.2F2.99.2Fplug-ins.2Fgoat-exercise-lua.2Fgoat-exercise-lua.lua:22:_module_.27lgi.27_not_found


Ok, this fixes the lua part of the problem.

Then after that install I restarted Gimp, and Lua also had namespace
issues, but then looking closer I saw that JavaScript also had namespace
issues... But the Wiki page you pointed to had a similar question and
its answer helped me figure out that somehow the GI_TYPELIB_PATH wasn't
defined. After setting it to:

export
GI_TYPELIB_PATH="${GIMP_PREFIX}/lib/girepository-1.0:${GIMP_PREFIX}/lib/${arch}/girepository-1.0:$GI_TYPELIB_PATH"

... everything looks fine and dandy.

But this raises another question: I have three well-populated
"girepository-1.0" directories in /usr, how comes nothing seems to
define a GI_TYPELIB_PATH variable in the user environment?


Thanks to all.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] No Lua or Python in Gimp 2.99

[Ofnuts]

On 14/06/2020 13:34, Michael Schumacher wrote:


On 6/14/20 1:16 PM, Ofnuts wrote:


This looks more like an environment problem (path?)

Any hints?

What environment variables do you have set for your prefix?



My environment looks like this, where `build` contains the sources and
`run` is where things get installed (I have a similar set up for 2.10):

/Gimp-dev/2.99
├── build
│   ├── babl
│   ├── gegl
│   ├── gimp
│   ├── libmypaint
│   └── mypaint-brushes
└── run
    ├── bin
    ├── etc
    ├── include
    ├── lib
    ├── libexec
    └── share

The whole thing runs quite smoothly except for these two problems. Gimp
prefix and possibly other relevant variables:

PWD=/Gimp-dev/2.99

GIMP_PREFIX=/Gimp-dev/2.99/run

PKG_CONFIG_PATH=/Gimp-dev/2.99/run/lib/x86_64-linux-gnu/pkgconfig:/Gimp-dev/2.99/run/share/x86_64-linux-gnu/pkgconfig:/Gimp-dev/2.99/run/lib/pkgconfig:/Gimp-dev/2.99/run/share/pkgconfig

ACLOCAL_FLAGS=-I /Gimp-dev/2.99/run/share/aclocal -I /usr/share/aclocal

LD_LIBRARY_PATH=/Gimp-dev/2.99/run/lib/x86_64-linux-gnu:/Gimp-dev/2.99/run/lib:/Gimp-dev/2.99/run/lib/x86_64-linux-gnu:/Gimp-dev/2.99/run/lib:

XDG_DATA_DIRS=/Gimp-dev/2.99/run/share:/usr/share:/Gimp-dev/2.99/run/share:/usr/share:/usr/share/plasma:/usr/local/share:/usr/share:/var/lib/snapd/desktop

PATH=/Gimp-dev/2.99/run/bin:/Gimp-dev/2.99/run/bin:/home/me/.local/bin:/home/me/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

In case it matters too, the python files in the "run" tree:

./run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/spyro-plus/spyro-plus.py
./run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/palette-to-gradient/palette-to-gradient.py
./run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/foggify/foggify.py
./run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/python-console/python-console.py
./run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/python-console/pyconsole.py
./run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/palette-offset/palette-offset.py
./run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/py-slice/py-slice.py
./run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/file-openraster/file-openraster.py
./run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/gradients-save-as-css/gradients-save-as-css.py
./run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/goat-exercise-py3/goat-exercise-py3.py
./run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/colorxhtml/colorxhtml.py
./run/lib/gimp/2.99/plug-ins/spyro-plus/spyro-plus.py
./run/lib/gimp/2.99/plug-ins/palette-to-gradient/palette-to-gradient.py
./run/lib/gimp/2.99/plug-ins/foggify/foggify.py
./run/lib/gimp/2.99/plug-ins/python-console/python-console.py
./run/lib/gimp/2.99/plug-ins/python-console/pyconsole.py
./run/lib/gimp/2.99/plug-ins/palette-offset/palette-offset.py
./run/lib/gimp/2.99/plug-ins/py-slice/py-slice.py
./run/lib/gimp/2.99/plug-ins/file-openraster/file-openraster.py
./run/lib/gimp/2.99/plug-ins/gradients-save-as-css/gradients-save-as-css.py
./run/lib/gimp/2.99/plug-ins/colorxhtml/colorxhtml.py

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] No Lua or Python in Gimp 2.99

[Ofnuts]

When I start a freshy pulled/compiled 2.99 on my Ubuntu 19.10, I get:

For Lua:

    luajit:
...mp/2.99/plug-ins/goat-exercise-lua/goat-exercise-lua.lua:22: module
'lgi' not found:
    no field package.preload['lgi']
    no file './lgi.lua'
    no file '/usr/share/luajit-2.1.0-beta3/lgi.lua'
    no file '/usr/local/share/lua/5.1/lgi.lua'
    no file '/usr/local/share/lua/5.1/lgi/init.lua'
    no file '/usr/share/lua/5.1/lgi.lua'
    no file '/usr/share/lua/5.1/lgi/init.lua'
    no file './lgi.so'
    no file '/usr/local/lib/lua/5.1/lgi.so'
    no file '/usr/lib/x86_64-linux-gnu/lua/5.1/lgi.so'
    no file '/usr/local/lib/lua/5.1/loadall.so'
    stack traceback:
    [C]: in function 'require'
...mp/2.99/plug-ins/goat-exercise-lua/goat-exercise-lua.lua:22: in main
chunk
    [C]: at 0x55864ba6d1d0
    GIMP-WARNING: gimp-2.99: gimp_wire_read(): error

As far as I can tell, I have lua5.1, liblua5.2-0:amd64, libluajit-5.1-2,
libluajit-5.1-common, lua5.1,luajit. I maybe missing lgi, but I cannot
find a  likely installation candidate for it?

For Python:

    Traceback (most recent call last):
    File
"/Gimp-dev/2.99/run/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/goat-exercise-py3/goat-exercise-py3.py",
line 17, in 
    gi.require_version('Gimp', '3.0')
    File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in
require_version
    raise ValueError('Namespace %s not available' % namespace)
    ValueError: Namespace Gimp not available

This looks more like an environment problem (path?)

Any hints?




___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Logon to gitlab.gnome.org broken?

[Ofnuts]

On 25/05/2020 00:43, Kevin Cozens wrote:

On 2020-05-24 5:20 p.m., Ofnuts wrote:

While trying to report a bug, I try to sign in,ￜ but on the logon
page:

- the "standard" option seems disabled, only the LDAP version is enabled
(but I have no account for that)


It is a little confusing at first glance. The "Standard" option may
appear to be disabled because the text is in grey. That is because it
isn't the active tab. Just click the Standard tab and you can use a
username and password to login to gitlab.


I'm used to that login page... but eventually figured out my problem:
Javascript was disabled in my browser (I have an add-on for this with a
button a bit too easy to click by mistake it seems). ** blushes **

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Logon to gitlab.gnome.org broken?

[Ofnuts]

While trying to report a bug, I try to sign in,  but on the logon page:

- the "standard" option seems disabled, only the LDAP version is enabled
(but I have no account for that)

- the "3rd party login" links all elicit an error 404.

So, how can mere mortals report bugs? Or is it temporary?

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Selection fill on channel bug

[Ofnuts]

I just hit a bug on 2.10.14 where filling a selection on a channel fills
the selection bounding box and not the selection itself (both using the
GUI and the gimp-edit-fill function).

This problem appears fixed in 2.10.18. Does anyone know what the bug
really was, in which version it appeared and in which it disappeared? I
couldn't find it in the Gitlab issues.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Why does it take so long until Gimp finds out that no image is on the clipboard

[Ofnuts]

On 04/05/2020 12:29, Adalbert Hanßen wrote:

I am running Krusader under Xubuntu 18.04.4 LTS.

I can click and Ctl-c on a file to paste the complete path to the file into an 
editor window, I can paste the whole file if I Strg-v it in a file manager. I 
can copy pictures from one application to another by copy/paste.

I have never heard before about clipboard managers and just googled for that 
keyword to look if any of the names associated with one of the findings is 
installed on my computer:

clipit, copyq, diodon, gpaste, glipper, klipper, qlipper, parcellite, 
xfce4-clipman, xclip and xsel are not installed on my computer.

there is no sequence "clip" in the output of dpkg -l.


Liam mentioned clipboard managers not as a cause of your problem, but as
a possible investigation tool.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Why does it take so long until Gimp finds out that no image is on the clipboard

[Ofnuts]

On 03/05/2020 20:07, Liam R E Quin wrote:

On Sun, 2020-05-03 at 19:17 +0200, Adalbert Hanßen wrote:

Whatreally annoys me isthat it takes almost a minute for Gimp to tell
me that there is no image on the clipboard.

Is this under GNOME 3? or KDE/plasma? Do you have a clipboard manager
running?



* Why does it take that long?

It doesn't, here.


* What can developers do to speed up the error message in such a
situation?

Fix the bug, but that involves understanding whenand why it happens and
what is causing it.


* By the way: Is there a method such that one can see what type of
data is on the clipboard: text/image/file designation/spreadsheet
data, ...?

Again, depends on desktop enviroment and whether wayland or X11, but
yes, there are clipboard managers that can show it. KDE has one running
all the time i think.


Yes, Klipper in KDE can display images in the clipboard. However,
clipboard operations are not that simple under the hood. For large data
such as image, the source app doesn't really copy the data but some kind
of announcement, so during the paste the pasting app retrieves the data
from the source app and this source app may misbehave.





___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Asking for help/collaboration in nonprofit mini-project around covid-19

[Ofnuts]

On 01/05/2020 22:40, P. Cáliz wrote:

Hi all

I am trying to launch a social (non-profit) mini-project based on the
hashtag #EstasEnMisPensamientos / #YouAreOnMyMind.
I am going to publicly share a selection of my photos (a few hundred, I
suppose there will be some good ones ;-) ) labeled with that hastag and
with the URL of the collection, so that anyone can freely send them to
family, friends, ... Also I will try to involve professional photographers,
and entities that have their own collections (botanical gardens, museums,
conservation societies of monuments such as La Alhambra de Granada or the
Topkapi palace, etc), to contribute with material from their collections.
I do not know what success I can have, but being optimistic I must
expect a volume of contributions that I will not be able to handle by
myself, by hand. And it is for this that I request your help, perhaps
someone can make a Script-fu that automates the treatment of the photos. I
have only used Gimp sporadically to correct the color or contrast of my
photos, but I have an absolute ignorance beyond this.

Ideally the script should run in a loop with the following actions:

- Take a photo from the originals directory A
- Adjust the photo to a maximum size (~ 2048 pix vertical or horizontal)
preserving the aspect ratio
- Add a frame around the image with the bottom side wider than the
others (similar to Polaroid photos), and write the hastag (english and
spanish), and the collection URL in this bottom border. This is just an
idea, I'm open to your artistic suggestions
- Export as .jpeg in the modified photos directory B
- If possible, move the original photo from A directory to the C
directory so that it is not treated again

Maybe it is necessary to define some additional detail, please feel free
to ask me anything.

I will exclusively dedicate a Raspberry Pi 3 for Gimp to fly.
Every day I will try to download in the original directory "A" all the
photos received at youareonmym...@scrive.org (by the way, if someone knows
how to automate this, I would be s grateful). And also every day I will
upload all the taged photos in directory "B" to the public album (I'm still
not sure of the URL, I will probably host it in google photos).

Any volunteer? Hope yes.


Typically done with ImageMagick: https://imagemagick.org/index.php

Some features:

https://imagemagick.org/Usage/resize/

https://imagemagick.org/Usage/text/

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Watching gui commands with console

[Ofnuts]

On 28/04/2020 12:48, Metin Barış via gimp-developer-list wrote:

Hello Dear all,

I have a question to experienced developers here, i am new on using
script-fu

Is there any way of console log or watch the commands running from GUI side
of the program ?

For example whenever i run a crop for an image on GIMP side i would like to
tail such command "(gimp-image-cropped image)" from console or log it
somewhere else.
or whenever i open an image i would like to watch (gimp-load-image
imagepath name)

Any kind of suggestion would be greatly appreciated


Recurring question... I wonder how many unfinished Gimp Universal
Macro-Recorders there are out there.

AFAIK there is no such capability, and furthermore there is not a
one-to-one mapping between GUI actions and API calls.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Ubuntu PPA still on 2.10.14

[Ofnuts]

It seems the 2.10.18 build failed, from the build log:


The following packages have unmet dependencies:
  sbuild-build-depends-gmic-dummy : Depends: libgimp2.0-dev but it is not going 
to be installed
E: Unable to correct problems, you have held broken packages.


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Missing dependencies when building Gimp with meson on Ubuntu 19.10

[Ofnuts]

Trying my hand at: https://wiki.gimp.org/wiki/Hacking:Building

Installed all the prereqs listed in 
https://wiki.gimp.org/wiki/Hacking:Building/Linux


Things went quite smoothly for all other packages: babl, gegl, mypaint.

Now trying the meson build for Gimp, it fails with two missing 
dependencies (quotes added by me):


Library "socket" found: NO
Run-time dependency "xmu" found: NO (tried pkgconfig and cmake)

I do have these installed:

    >dpkg -l 'libsocket*'
    Desired=Unknown/Install/Remove/Purge/Hold
    | 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

    |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
    ||/ Name   Version  Architecture Description
+++-==---===
    ii  libsocket++1:amd64 1.12.13-10   amd64    lightweight 
convenience library to handle low level BSD sockets


    >dpkg -l 'libxmu*'
    Desired=Unknown/Install/Remove/Purge/Hold
    | 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

    |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
    ||/ Name   Version  Architecture Description
+++-==---===
    ii  libxmu6:amd64  2:1.1.3-0ubuntu1 amd64    X11 miscellaneous 
utility library
    ii  libxmuu1:amd64 2:1.1.3-0ubuntu1 amd64    X11 miscellaneous 
micro-utility library


Can't find any related ".pc" file. Are these the right packages?

OTOH the "classic" build worked well...





___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Building babl & gegl with meson

[Ofnuts]

On 06/03/2020 05:43, Owen wrote:

Try

https://wiki.gimp.org/wiki/Hacking:Building



Owen


Looks like it, thanks.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Building babl & gegl with meson

[Ofnuts]

On 06/03/2020 00:34, Partha Bagchi wrote:

Ofnut,

You are pretty well versed in this stuff. :)


I used to be...



This should get you started:


Exactly what the doctor ordered, thanks.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Building babl & gegl with meson

[Ofnuts]

Is there a write-up somewhere indicating how to build Babl & Gegl? They
seem to be using meson/ninja and all the indications I can find look
fairly old and assume that they are built using autoconf+make.

Cheers


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Invalid input arguments of file-raw-save2

[Ofnuts]

Looking at the source code; RAW_PLANAR would be 6 (the plugin defines
many images types, but only accepts RAW_RBG and RAW_PLANAR when saving).



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] How to create a GimpFloatArray in Python plugin?

[Ofnuts]

On 2/19/20 9:17 PM, Lloyd Konneker via gimp-developer-list wrote:

Specifically, to pass as third arg to Gimp.PDB.gimp_pencil(layer, 4 line).
Said argument should be GimpFloatArray according to PDBBrowser.

I create a GimpValueArray to pass args to the pdb.  To create a GValue for
the third arg, I tried:

GObject.Value(Gimp.FloatArray.__gtype__, (1.0, 1.0, 1.0, 1.0)

which throws exception  Expected: Boxed.
Thrown by pygobject/gi/pygi-value.c about line 556.
At line 537, it seems like it should work if G_VALUE_HOLDS(value,
G_TYPE_ARRAY) for GimpFloatArray gtype.
My understanding is that PyGObject would then create a GArray from the
Python list of floats for the value of the GValue.

My best guess is Gimp is missing GI annotations or implementation for
GimpFloatArray.

Using Gimp 2.99, I am porting GimpFu.

There might be a related problem receiving GimpInt32Array *from* Gimp (not
*to* Gimp as above.)


You don't need to do complicated things like that in Python, just use a
Python array of floats.

 pdb.gimp_pencil(layer,6,[0.,0.,100.,100.,0.,200.])


(draws a '>')

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2,.8 Bug for function cancel - control+z

[Ofnuts]

On 2/8/20 3:06 PM, aertx0--- via gimp-developer-list wrote:

Does GIMP have a bug for version 2.8, with the button control  + z not
working?
Platform: Win7 64 bit


Never heard of that one. Go to "Edit>Keyboard shortcuts", and enter
"undo" in the search bar. Is Ctrl-Z mapped to "edit-undo"?



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Deleting on images with alpha channel does not delete

[Ofnuts]

On 2/5/20 2:55 PM, Hanno Böck wrote:

Hello,

I've been asked to bring this discussion to this mailinglist.

There's an issue with GIMP that can lead to unexpected disclosure of
private information if one tries to use GIMP to remove private data
from images.
The problem is that when someone "deletes" something with GIMP in an
image with an alpha channel it's not actually deleted, the content is
just set to be fully transparent. This can of course trivially be
reversed.

A typical situation where this might become problematic is when somene
makes a screenshot for e.g. a social media post and wants to remove
something that is private, e.g. a name/address/creditcard number etc.

Will Dormann who works for CERT/CC has reported this as an issue[1],
however it was closed arguing that this is expected behavior.

FWIW I agree with Will Dormann here that this is very surprising
behavior, and thus it should be considered dangerous and should be
changed. He also told me he tested multiple other popular graphics
editors and GIMP is the only one with this behavior.

(Also FYI I am planning to write an article about this for Golem.de.)

[1] https://gitlab.gnome.org/GNOME/gimp/issues/4487


And why should this mailing list make any difference?

I'll even go further in the reasoning. If it makes sense for
PNG/WEBP/GIF, why wouldn't it make sense for the XCF format itself?
After all some poor souls could send someone an XCF where their credit
cars number has been erased in a layer (as a Gimp forum owner, I see
people routinely upload their XCF files fro all to see...). So we would
have to also clear these data in XCF layers, making the whole editor
unusable?

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New asset / extension manager

[Ofnuts]

On 1/8/20 11:00 AM, Jehan Pagès via gimp-developer-list wrote:

Unless by priority you mean throwing my family, friends and life under the
bus to get it done yesterday, because yeah I don't have any of these and
won't ever have.


And you haven't even got a bus right now :)

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Copying a layer mask between images

[Ofnuts]

It's easy to copy a layer to another image:

    pdb.gimp_layer_new_from_drawable(sourceLayer,targetImage)

But I cannot find an equivalent call for a Mask/Channel:

    - gimp_create_mask() won't take an existing mask, just an existing
Channel (and since it's another image I cannot even use the selection)

    - gimp_channel_new() creates n empty channel

    - gim_channel_new_from_component() only tales an image component

As far as I can tell the only way would be create an empty mask and
copy/paste? Am I missing something ? Is there a smarter way?


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] marking a document/image as dirty/changed in a plugin

[Ofnuts]

On 11/10/19 5:23 AM, Dan Hitt via gimp-developer-list wrote:

The other hole is that i find that so far i cannot read and write a
pixel.



From my experiments:

- start an "undo group": this marks the image "dirty"

- attach an "undoable" parasite

- end the undo group and exit

At that point if you list the parasites you find the one that was added

If you then Ctrl-Z and list the parasites the added  parasite is gone.



Actual Python code used in the Pyhon console:

>>> # Assumes you have only a single image loaded

>>> image=gimp.image_list()[0]

>>> # when you enter the line below, the title bar gets an '*'
indicating a dirty image

>>> image.undo_group_start()

>>> Check dirtiness with API

>>> image.dirty
True
>>> p=gimp.Parasite('foo',PARASITE_UNDOABLE,'bar')
>>> image.parasite_attach(p)
>>> image.undo_group_end()
>>> image.parasite_list()
('gimp-comment', 'jpeg-settings', 'foo')

>>> Now undo with Ctrl-Z in the image window, and retest the parasites:

>>> image.parasite_list()
('gimp-comment', 'jpeg-settings')

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Accessing stdin from a Python based GIMP Plugin.

[Ofnuts]

On 9/4/19 6:48 AM, Craig Sanders via gimp-developer-list wrote:

Hello all.

Are there any gotchas that one should be aware of when accessing stdin from
a Python based GIMP Plugin?

The reason I ask, is because I am implementing a Plugin which seems to be
working fine - until such time as I insert the following code into it;



 for line in stdin :



Works fine for me on Linux (assuming you mean 'sys.stdin' and not
'stdin'). This is of course the very stdin stream of the Gimp process.
Just tested with file, pipe, and terminal and all three work.

Can't say the same for Windows, the standard streams for windowed
applications do not have a regular behavior (for instance IIRC you will
hang your plugin if you print more than 8K to sys.stdout).


Not sure it is a good idea anyway to use stdin, you have to restart Gimp
if you want a second run. Why not use a plain file?



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Is there any kind of documentation on the new layer blend modes?

[Ofnuts]

Thanks for the thorough explanations... The "probabilistic" point of
view is interesting.

Your write-up makes a load of sense but some more time is required for
this to completely sink in:)


On 8/18/19 9:35 AM, Ell via gimp-developer-list wrote:


There's indeed no organized documentation for all the new layer modes
yet, unfortunately.

For Pass Through mode, see:

   https://docs.gimp.org/2.10/en/glossary.html#glossary-pass-through

Merge and Split are complementary modes, as their names suggest.  They
are similar to Normal and Erase modes, respectively, but they handle
alpha values differently.  The short version is that (when using their
default composite modes) Merge adds the alpha values of the input
layers, while Split subtracts them.  In other words, if the alpha values
of the bottom and top layers are A and B, respectively, the resulting
alpha values for Merge and Split are `min (A + B, 100%)`
and `max (A - B, 0%)`, respectively.

--- Wall-of-text warning.  Skip to the end for practical examples. ---

[.. snip ..]


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Is there any kind of documentation on the new layer blend modes?

[Ofnuts]

Specifically, I'm wondering about the "Split", "Merge", and the group
"Passthrough" modes.

The only relevant Google answer is a paying video tutorial.

Of course I have checked the online doc...

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Gimp Background Removal App

[Ofnuts]

On 6/9/19 6:05 AM, Sarey Savy via gimp-developer-list wrote:

Hello there!

I absolutely love the Gimp background removal app but I noticed it scales the 
image drastically to a smaller size...

Is there a way to remove the back ground but keep the original size width and 
height of the image?

Looking forward to hearing back soon,

Sarey



Uh? You mean the foreground selector? It doesn't scale things, normally.
Can you provide a sample image?

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] When writing a GIMP Plugin using Python, how can the Plugin determine and/or set the Colour Profile of any image that it operates on?

[Ofnuts]

On 5/21/19 3:43 AM, Craig Sanders via gimp-developer-list wrote:

Hello.

I am writing a GIMP Plugin using Python, and I would like to know how my
Plugin can determine and/or set the Colour Profile of any image that it
operates on.

The reason I ask this, is because I have some PNG files which have been
generated from a PDF file by the ImageMagick convert utility. If I didn't
know better, I would say that this ImageMagick utility is embedding the
following Colour Profile into the images which it generates and stores in
the resulting PNG files;

 Artifex Software sRGB ICC Profile

I also have some PNG files which have been generated by the gnuplot
utility. The images in these files have the following Colour Profile
embedded within them;

 sRGB

When I copy and paste a gnuplot generated image into one of the other
images, the colours of the plots in the gnuplot generated image get altered
upon pasting. If I didn't know better, I'd say this is due to the
difference in the Colour Profiles, because if I load the PDF file straight
into GIMP and then inspect it - it has the sRGB Colour Profile. Then, when
I copy and paste the same gnuplot generated image into it, the colours of
the plots are correct!

I don't know a great deal about this subject material, so please excuse me
if I have asked something silly. I hope I have explained this clearly and
have provided sufficient information. Any assistance on this matter would
be greatly appreciated.


Another explanation is that the target PNG is color-indexed (if which
case whatever you paste in it has its colors coerced into those of the
colormap of the target).

Otherwise plenty of API to handle color profiles, in the Python console
(Filters>Python-fu>Console) hit "Browse...", then enter "profile" in the
search bar. If you use 2.10, best use the gimp_image* calls, the
plug-in-icc* seems to be carried over from previous versions for
compatibility.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] png file exports - disable metadata?

[Ofnuts]

On 5/16/19 12:03 AM, Paul Jewell via gimp-developer-list wrote:

Hi All, I am wondering about a curious event I am seeing related to
exporting PNG images from Gimp either through the usual interface, or via a
script like so:

pdb.file_png_save2(gimp.image_list()[0], gimp.image_list()[0].layers[0],
'/tmp/test1.png', '/tmp/test1.png', 0, 0, 0, 0, 0, 0, 0, 0, 0)
pdb.file_png_save2(gimp.image_list()[0], gimp.image_list()[0].layers[0],
'/tmp/test2.png', '/tmp/test2.png', 0, 0, 0, 0, 0, 0, 0, 0, 0)

It seems that exporting these two pngs, some different data is written
because they have a different sha1sum. (I would guess timestamp, but I
disabled this with the plugin option as shown) This weirdness does not seem
to happen with other file formats like webp, raw, etc. Is there any way to
disable the writing of this extra data?



Can't reproduce. Saving the same PNG twice gives two files with
identical hashes even when saving:

* background color

* gamma

* layer offset

* resolution

* comment




the comment


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] When writing a GIMP Plugin using Python, can the Plugin display a GIMP based Dialog box informing the user if they haven't provided an argument?

[Ofnuts]

When you write a Gimp plugin in Python, either you do your whole
interactive UI with PyGTK, or you let Gimp auto-generate a dialog to
collect parameters from the user before calling you. Of course the
second solution is a bit less user-friendly(*) but in many scripts,
doing the whole UI would represent the larger and most complex part of
the code.

(*) though not as bad as it looks, you can normally expect passed
image/layers/files/colors to exist since they have been specified using
specific dialogs.

On 5/12/19 5:50 PM, Michal Vašut wrote:

You should IMHO prevent performing an operation when the input is
invalid.
Yes, it's definitely easier to throw an exception, but those are IMHO
rather to deal with some unexpected errors.

On Sat, May 11, 2019, 23:44 Ofnuts mailto:ofn...@gmx.com>> wrote:

If the plugin is for public use, gimp.message() is a better solution
because it will display in a dialog box or in the Gimp message
console
depending on user preferences. You don't really need to drag in
all the
GTK support just to display an error message.

On the other hand, I don't see how you pass a list of files to a
plugin.. If this is a batch script, things are a bit different,
but then
there may be no UI at all, and the message would be better printed to
the console.



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] When writing a GIMP Plugin using Python, can the Plugin display a GIMP based Dialog box informing the user if they haven't provided an argument?

[Ofnuts]

If the plugin is for public use, gimp.message() is a better solution
because it will display in a dialog box or in the Gimp message console 
depending on user preferences. You don't really need to drag in all the
GTK support just to display an error message.

On the other hand, I don't see how you pass a list of files to a
plugin.. If this is a batch script, things are a bit different, but then
there may be no UI at all, and the message would be better printed to
the console.

On 5/9/19 1:32 AM, Craig Sanders via gimp-developer-list wrote:

Ahhh. I didn't even think that it might be able to be done that way - but
your solution is exactly what I was looking for. Thankyou very much.

I was thinking that there might be a GIMP Procedure such as;

 pdb.display_dialog(...)

or something similar.

After I submitted my question, I found a snippet of Python code on the
Internet which did what I needed, but nowhere near as nicely as your
answer. When I modified this snippet of Python code, it looked as follows;

import gtk

# A whole lot of code has been left out here!!!

 errDialog = gtk.MessageDialog(

  None,

  0,

  gtk.MESSAGE_ERROR,

  gtk.BUTTONS_OK,

  "You must specify at least one file."

 )

 errDialog.show_all()

 errDialog.run()

# And a whole lot of code has been left out here!!!

Thanks once again for your assistance. It is most appreciated.

On Thu, May 9, 2019 at 1:22 AM Carol Spears  wrote:



On Wednesday, May 8, 2019, Craig Sanders via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:


Hello.

I am writing a GIMP Plugin using Python, and this Plugin expects to
receive
a list of files as one of its arguments. My question is, if the user
doesn't provide any files as arguments, can my Plugin display a GIMP based
Dialog box informing them of this?


gimp.message(You did not provide files)

The message part should be in quotes probably


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] How is supposed to work the "dash_offset" when stroking paths in line mode?

[Ofnuts]

On 5/1/19 7:45 PM, Ofnuts wrote:

*  the Python help says the input value range for "set" is 1..100 while
the output value range for "get" is 0..2000

* whatever the value I seem to always get the same result

Is this supposed to shift the dash pattern? Is it an absolute value or
is it relative to the dash pattern length?

Assuming I have a pattern like:

"  ##    ##    ##"

what do I need to do to stroke it as:

"    ##    ##    ##"



OK, so the answer is: it's an absolute length in pixels, so in practice
you have to compute it from the sum of the dash pattern elements and the
line width.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Is there any way to free Gimp memory and avoid restarting it?

[Ofnuts]

On 2/5/19 5:35 PM, jEsuSdA 8) wrote:

El 2/2/19 a las 9:58, Ofnuts escribió:
The fact that the memory isn't marked free doesn't mean it is 
unusable. Tried in Gimp 2.10 on Ubuntu:


- load 5 20MPx Jpegs: memory is 1.35GB

- close all: memory still at 1.35GB

- load them again: memory is 1.4GB

- close all: memory still at 1.4GB

- load them again: memory is 1.4GB

- close all: memory still at 1.4GB

So the memory seems reused...


I was thinking about your tests and the values seems to be a bit 
strange: I mean, I you load 5 images and Gimp takes 1.35GB Memory, why 
when you close all the images gimp still taking 1.35GB instead of less 
than?


In the same way, if you load again the same images, why Gimp consumes 
more memory and its memory consumption rises from 1.35 to 1.40... and, 
again, when the images are closed the memory does not get back to a 
lower value.


I think this values can corroborate my theory about Gimp lack of 
memory release I suffer and which is absolutely needed when working in 
professional environments.


Why Gimp does not free the memory?
Any idea? 



If memory was truly leaked,  I would have seen 1.35, 2.7, 4.05... Since 
there is no significant memory increase, we can assume that this memory 
is reused. For the rest, see Øyvind's answer.


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Is there any way to free Gimp memory and avoid restarting it?

[Ofnuts]

On 2/1/19 11:35 PM, jEsuSdA 8) wrote:

El 1/2/19 a las 23:15, jEsuSdA 8) escribió:

Hi!


When editing several images in Gimp (10Mpixels each one), Gimp 
consumes memory little by little (sometime not so little by little ;) 
) and this memory does not get free instead the images where closed.



So, after few time using Gimp, it consumes ALL MEMORY available and I 
must close and start again.


Is there any way to force Gimp to free memory?

Why if I open a image, when I close it after editing the memory used 
by Gimp for this image is not liberated?


I mean, if I load an image and the Gimp memory consumption increases 
400MB, and I open another one (another 400MB more), I expect when I 
close the first one, Gimp should free the 400MB of memory reserved to 
the first image edition. Is something working wrong?



This is a very important think to me because I usually do long 
editing session where I could retouch about 50 images and, obviously 
is very annoying to close and restart Gimp every 5 or 6 processed 
images.



Thanks a lot.


GIMP 2.10.8 over Debian GNU/Linux (Testing)



Here some screenshots:


After opening and editing 3 images (10Mpix each one):


http://pasteall.org/pic/show.php?id=9066d31d4341eb69702b2dc223500215
http://pasteall.org/pic/show.php?id=6382dab480d0042e8d1479e226efb0e7

3 opened images = 4.4 GB of memory

Here, after opening, edit AND CLOSE 4 more images:

http://pasteall.org/pic/show.php?id=ee7a14d2803d7f62f0eb65d23c54650a
http://pasteall.org/pic/show.php?id=1f442cc78affbb9cde59be9e13e5a2d4


3 opened images = 6.3 GB of memory



The fact that the memory isn't marked free doesn't mean it is unusable. 
Tried in Gimp 2.10 on Ubuntu:


- load 5 20MPx Jpegs: memory is 1.35GB

- close all: memory still at 1.35GB

- load them again: memory is 1.4GB

- close all: memory still at 1.4GB

- load them again: memory is 1.4GB

- close all: memory still at 1.4GB

So the memory seems reused...




___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] [Gimp-web] Alexandre Prokoudine attacks on GIMP critics around the Web

[Ofnuts]

On 1/8/19 7:23 PM, Ryan Stark via gimp-developer-list wrote:

A sign of the problems is that on Linux we have Krita
and Mypaint. If Gimp's tools had been better for painting and manipulating
things on the canvas we would not have needed those apps.


Now, that's a weird argument. Linux has always been about choices:

 * Half a dozen major distros (not counting the server-centered ones),
   and scores of variants
 * Half a dozen desktop managers
 * Many editors
 * Many IDEs
 * Two full-scale C compilers
 * Two web servers in wide use
 * Two RDBMS

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Command line Gimp on OS X

[Ofnuts]

On 1/2/19 10:09 PM, Alain Jennotte via gimp-developer-list wrote:

Hi,

I'd like to open a file in Gimp as part of a script.

If Gimp is not launched, it works perfectly with:
open McGimp-2.10.8.app --args ~/Documents/Archive/scanpic.jpg

But I don't know how to open a file with the script when Gimp is already
launched.

Any idea how to achieve that on a Mac (Sierra)?


Use the -n/--new-instance parameter to make a new Gimp instance.

And see "gimp --help" for other useful parameters

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Please Help

[Ofnuts]

On 12/12/18 12:22 PM, Alexandre Prokoudine via gimp-developer-list wrote:

On Wed, Dec 12, 2018 at 2:20 PM Göran Persson via gimp-developer-list wrote:

Hello.

Please, I am very pleased with GIMP.
Very nice and good program.
but now a virus has appeared.

See attached file.
I don’t like this cow.

How do I get rid of it?

There are no cows on the GIMP farm, only five-legged goats. They are
yours forever.

Please upload the screenshot. There are no attaches here.


Maybe the OP doesn't like Wilber's head in the empty image window.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Behavior change in paint modes between 2.8 and 2.10

[Ofnuts]

On 12/9/18 3:56 PM, Ell via gimp-developer-list wrote:


On 12/7/18 6:16 AM, Ofnuts wrote:

In 2.8, on a transparent layer, paint something blue, set the FG color
to red, set the paint tool to "Hue" mode, paint over: the blue parts
turns to red, the transparent parts remains unchanged.

In 2.10, if you do the same thing with the non-legacy modes, the
transparent parts are painted. The legacy modes behave as in 2.8, and it
seems that setting the alpha-lock also provides the 2.8 behavior.

It used to be that painting a layer with the paint tool in mode XXX
would give the same result as adding a transparent layer in mode XXX and
painting on it in "Normal" mode.

Is it a bug/regression or is it a deliberate change, and if the latter,
what is the rationale?

Tl;dr: it's deliberate, but it needs to be improved.

In 2.10, layers have a new property called the "composite mode", which
is available when using the new layer modes.  It controls which parts of
the combined layers remains visible: the opaque parts of either layer
(Union), the opaque parts of the bottom layer (Clip to Backdrop), the
opaque parts of the top layer (Clip to Layer), or the opaque parts of
both (Intersection).  There are a few examples in the "Composite Mode"
section of:

   https://docs.gimp.org/2.10/en/gimp-layer-new.html

The default composite mode of a layer currently depends on its layer
mode, in a way that mimics the legacy modes: Union for Normal and
Normal-like modes, and Clip to Backdrop for the rest.  By changing the
composite mode of a non-Normal layer to Union, you can get the same
result as for painting.

Unfortunately, the other way around is currently not true: there is no
UI for controlling the composite mode of paint tools.  The composite
mode used for painting is currently determined according to the paint
mode: Union for everything, except for the "subtractive" modes: Erase,
Split, and Color Erase, which use Clip to Backdrop.

"Why?" is a good question.  There is no great answer, but this sort of
behavior for the paint tools is what a lot of people seem to expect, and
what most other software provide.  Ultimately, I hope to revamp the
layer-mode UI, and expose all the relevant options for both layers and
paint tools, so that you could paint using either composite mode.

In the meantime, there is no great way to restrict painting to opaque
regions.  Like you said, you can use the alpha lock, but this works only
superficially: it produces correct results when either the existing
pixel or the new pixel are fully opaque, but if both are
semi-transparent, the result is wrong.  Likewise, the result of
combining semi-transparent pixels using the non-Normal legacy modes,
while painting *or* using layers, is also wrong (that's part of the
motivation for the new modes; we're keeping the broken behavior of the
legacy modes for backward compatibility -- they really shouldn't be used
in new images.)  The only fully-correct way to do this right now is
using layers, using the new modes with Clip to Backdrop.

--



OK, that makes sense...


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Behavior change in paint modes between 2.8 and 2.10

[Ofnuts]

In 2.8, on a transparent layer, paint something blue, set the FG color 
to red, set the paint tool to "Hue" mode, paint over: the blue parts 
turns to red, the transparent parts remains unchanged.


In 2.10, if you do the same thing with the non-legacy modes, the 
transparent parts are painted. The legacy modes behave as in 2.8, and it 
seems that setting the alpha-lock also provides the 2.8 behavior.


It used to be that painting a layer with the paint tool in mode XXX 
would give the same result as adding a transparent layer in mode XXX and 
painting on it in "Normal" mode.


Is it a bug/regression or is it a deliberate change, and if the latter, 
what is the rationale?




___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] primitive drawing tool Request

[Ofnuts]

On 10/13/18 22:36, Jacques Koffaltretes via gimp-developer-list wrote:

Hello,

I love gimp, and use it for all my game dev image manipulation and also for
artwork.

Can you PLEASE add simple primitive drawing tools, If you can add line/box
and circle tools with option to fill shapes or outline, and line tool has
option to hold CTRL to snap to 90/45/27.5/15 angles when drawing continous
segments.

I know this is primarly not a drawing program, but I hate to have to load
other software just to draw a line or a solid circle or box. Every beginner
art app/program is capable of doing this, and I have no idea the logic why
this was never included in gimp.

Stroking a path is simply laborious and dumb, the path is unpredictable and
disappears on undo..

I will donate cost for the developer time to get some primitive drawing
tool into gimp. At least a line tool, please.

The line part is already in the brush tool. Click on start point, 
depress Shift, move to end point, Click. If you depress Ctrl (in 
addition to Shift) you have constrained angles. You can also see 
Filters>Render>GFig.


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Regressions

[Ofnuts]

On 09/30/18 03:32, Diogo Piçarra via gimp-developer-list wrote:

Please create "regression" and "data loss" tags on gitlab. Make them
topmost priority and fix all regressions, data losses and most crashes
before releasing a new "stable" version.
Or use the money you just got to hire somebody to do that.
Maybe starting with this:
https://gitlab.gnome.org/GNOME/gimp/issues/1439
This is "totally unacceptable" and probably easy to fix but it's not fixed yet.


While I have created the bug report, I don't think this one is a major 
issue. There are work-arounds (in most cases you
can just flip the path..., and there are also scripts to reverse the 
path direction).


Gimp is mostly community-based, and the community isn't helping much. 
The code change that creates the bug is two years old, so this bug has 
been around in the 2.9 version and the 2.10 release candidates,  and no 
one encountered it? Reporting bugs is a service to developers... It's 
almost a way to thank them :)

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] blocking fonts enumeration

[Ofnuts]

On 06/30/18 02:24, Liam R E Quin wrote:

On Fri, 2018-06-29 at 23:35 +, 1980_undergro...@insiberia.net
wrote:

My question is, is there a way to prevent GIMP from reading system
fonts, and to only read fonts from it's own folder?

Which Linux distribution are you using? Or, what operating system?
Which GIMP version exactly?


My problem is that no matter what options I use in the Font Manager,
system fonts are *always* shown.

On Linux at least you can a fonts.conf file in your gimp data dir or
fonts folder that excludes specific fonts. This probably also works on
MacOS and Windows but i don't know for sure.

In other words exactly how best to do this may depend on your operating
system and in some cases, where you downloaded gimp from (i.e. which
exact build).


AFAIK the font.conf also works on Windows, but its exact location eludes me.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Errors in the new gimp version registering python scripts

[Ofnuts]

This seems due to the script importing another module:

Traceback (most recent call last):
  File "E:\Gimp\Arakne\arakne-path-shape-creator8.py", line 35, in 
    import gtk, gimpui, pnt2d, drawUI
ImportError: No module named pnt2d

In other words, the plugin main module is making the assumption that it 
is in the python path, so any module in the same directory can be 
imported. This doesn't seem to be true for the Windows version (the 
plugin works OK in Linux 2.10). This is possibly a bug in the Windows 
version.


On 06/25/18 07:26, Paco Garcia via gimp-developer-list wrote:

​The scripts are working fine until ​the last gimp release, two of the
scripts failing are:
http://www.arakne.es/en/dessign/gimp-guideslab-edit-guides-numerically/
and
http://www.arakne.es/en/programming/python/gimp-plugin-shape-creator-v8/

Calling gimp with the verbose option don't give more clues about the error:

Querying plug-in: 'C:\Users\yo\Desktop\gimp_plugins\pnt2d.py'
gimp-2.10: LibGimpBase-ADVERTENCIA: gimp-2.10: gimp_wire_read(): error
Querying plug-in: 'C:\Users\yo\Desktop\gimp_plugins\drawUI.py'
gimp-2.10: LibGimpBase-ADVERTENCIA: gimp-2.10: gimp_wire_read(): error
Querying plug-in:
'C:\Users\yo\Desktop\gimp_plugins\araknepathshapecreatorshapes.py'
gimp-2.10: LibGimpBase-ADVERTENCIA: gimp-2.10: gimp_wire_read(): error
Querying plug-in: 'C:\Users\yo\Desktop\gimp_plugins\arakne-stitch3b.py'
Querying plug-in:
'C:\Users\yo\Desktop\gimp_plugins\arakne-path-shape-creator8.py'
gimp-2.10: LibGimpBase-ADVERTENCIA: gimp-2.10: gimp_wire_read(): error
Querying plug-in: 'C:\Users\yo\Desktop\gimp_plugins\arakne-guide-lab.py'
gimp-2.10: LibGimpBase-ADVERTENCIA: gimp-2.10: gimp_wire_read(): error
Querying plug-in: 'C:\Program Files\GIMP 2\lib\gimp\2.0\plug-ins\gimpfu3.py'
Any help is welcome

2018-06-23 18:29 GMT+02:00 Carol Spears via gimp-developer-list <
gimp-developer-list@gnome.org>:


On Sat, Jun 23, 2018 at 10:23 AM, Carol Spears 
wrote:



On Sat, Jun 23, 2018 at 8:25 AM, Ofnuts  wrote:


On 06/19/18 21:43, Paco Garcia via gimp-developer-list wrote:


Is there any way to get more information about the gimp_wire_read ()
error
that occurs when loading python scripts? Many scripts that worked in
previous versions of gimp fail in the new one without apparent cause.
Spanish version:
¿Hay alguna forma de obtener mas información sobre el error
gimp_wire_read() que se produce al cargar scripts de python?. Muchos
scripts que funcionaban en versiones anteriores de gimp fallan en la
nueva
sin causa aparente.
___


I have seen plenty of such errors and they don't make the registration
fail. In 2.10 for Windows, scripts that import pygtk can have problems

(you

have to make sure you import gimpfu first). Would you have the URL to

such

a script?



That's right.  I've seen that error before though, but I write crappy
python also.  Maybe it is missing its beginning:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

or pygtk is not installed.  Or maybe the script is a template and broken
from the fill ins.

My earlier suggestion to poke around with it was not wrong, however.


Maybe the file is base64 or whatever that format was for mail in the 1980s.

carol
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-
developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Errors in the new gimp version registering python scripts

[Ofnuts]

On 06/19/18 21:43, Paco Garcia via gimp-developer-list wrote:

Is there any way to get more information about the gimp_wire_read () error
that occurs when loading python scripts? Many scripts that worked in
previous versions of gimp fail in the new one without apparent cause.
Spanish version:
¿Hay alguna forma de obtener mas información sobre el error
gimp_wire_read() que se produce al cargar scripts de python?. Muchos
scripts que funcionaban en versiones anteriores de gimp fallan en la nueva
sin causa aparente.
___


I have seen plenty of such errors and they don't make the registration 
fail. In 2.10 for Windows, scripts that import pygtk can have problems 
(you have to make sure you import gimpfu first). Would you have the URL 
to such a script?



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Problems using the PF_STRINGARRAY parameter type when writing a Python plugin for Gimp.

[Ofnuts]

If you want to run the script as a batch it doesn't need (and really 
shouldn't be) a plugin. Then your code is just a plain Python function 
that takes string parameters, and you don't need to register it. See


https://stackoverflow.com/questions/44430081/how-to-run-python-scripts-using-gimpfu-from-windows-command-line/44435560#44435560



On 05/23/18 02:17, Craig Sanders wrote:

Hello.

I'm trying to write a very basic plugin for Gimp using Python and I
want its one and only parameter to be of type PF_STRINGARRAY. The goal
of my plugin for the time being, is to receive a list of files, and
then simply print their names on the Command line, when the plugin is
run.

The code for my plugin is as follows;


BEGIN CODE SEGMENT >

from gimpfu import register, main, pdb, PF_STRINGARRAY


def \
process_list_of_files(

   listOfFiles
) :

for filename in listOfFiles :

print("")
print("Filename = %s" % filename)
print("")


register(
"process-list-of-files",# The name of the command
"Process a list of files",  # A brief description of the 
command
"Process a list of files",  # Help message
"John Doe", # Author
"John Doe", # Copyright holder
"2018", # Date
"/Image/Process list of files",  # The way the script will be
referred to in the menu
"RGB*, GRAY*",  # Image mode
[
(PF_STRINGARRAY, "listOfFiles", "List of files", [""])
],
[],
process_list_of_files,
menu="/File/ProcessListOfFiles")


main()

< END CODE SEGMENT <

I then run this plugin from the Command line using the following command;

gimp --no-interface --verbose --console-messages
--batch-interpreter='plug-in-script-fu-eval' --batch
'(python-fu-process-list-of-files RUN-NONINTERACTIVE
["/home/john/test.txt"])' --batch "(gimp-quit 1)"

Unfortunately, it doesn't work for me and complains with the messages;

Starting extension: 'extension-script-fu'
batch command experienced an execution error

If I now change my plugin's parameter type to be PF_STRING, and update
my code and Command line invocation method accordingly, it works! I
know that I could get around this problem by passing filenames in as
one string, where the filenames are separated by the ":" character,
but I want the code in the plugin to be as simple as possible.

So I guess my question is; is the PF_STRINGARRAY type supported, or am
I doing something wrong? I am using Gimp version 2.6.9.

Any help would be immensely appreciated.

Thanks in advance.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Participation at Apple Developer Program

[Ofnuts]

On 03/26/18 00:45, alexandre.prokoud...@gmail.com wrote:

I've invited you to fill out the following form:
Participation at Apple Developer Program

To fill it out, visit:
https://docs.google.com/forms/d/e/1FAIpQLSdRepYcE1dLD0342FaVGenU0Nr519SyK-MYzdGylmNXYq5rUQ/viewform?c=0w=1usp=mail_form_link 



Hi.

Wed like to know opinions of all developers and contributors of 
GIMP, but not everyone is on IRC. Please vote :)


P.S. Collecting emails in this form is disabled. Its safe to vote.

Alex 


Did we try to get in touch with Apple developer relations and see if 
they would give us a rebate or even complete waive the fee? That would 
be good PR for them...

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Using gimp in a script

[Ofnuts]

You don't  need to register the python code as  a plugin if you are only 
using it in this kind of script.


Link to a ZIP with a sample Python script and a sample shell

https://www.dropbox.com/s/hgg08yen5220wu9/gimpbatch.zip?dl=0

(written in Gimp 2.6 times but not much changes since)


On 02/23/18 07:12, John Tapsell wrote:

Can I improve this somehow?

I have a gimp plugin as myplugin.py.  I want to run this from the command
line on given file(s).  I wrote this script which works, but I'm wondering
if I can improve it at all.   I have this script in a folder, and the
plugin in a subfolder  gimpplugin/



FILENAME="$1"
if [ ! -f "$FILENAME" ]; then
 echo File not found - you must pass the psd file to be converted
with gimp
 exit 1
fi
BASE="${FILENAME%.*}"
mkdir "$BASE"
DIR_OF_THIS_SCRIPT="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
echo "(plug-in-path
\"\${gimp_dir}/plug-ins:\${gimp_plug_in_dir}/plug-ins:$DIR_OF_THIS_SCRIPT/gimpplugin\")"

gimprc

gimp -i -g gimprc -b "
(let* ((image (car (gimp-file-load RUN-NONINTERACTIVE \"$FILENAME\"
\"$FILENAME\")))
(drawable (car (gimp-image-get-active-layer image
(python-fu-myplugin RUN-NONINTERACTIVE image drawable)
(gimp-image-delete image))"  -b '(gimp-quit 0)'

rm gimprc
echo $BASE done
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Using Gimp 2.8

[Ofnuts]

On 12/13/17 00:59, Deb Kennedy via gimp-developer-list wrote:

I am new to programand I am puzzled by the conversion I had to do in order to 
open the files I hadbuploaded.   I shot photos on the RAW setting on my camera. 
N70 Nikon. I wanted ti ability to make corrections so that is why I opted for 
that setting. I noticed they uploaded as NEF files but they were not readily 
available for viewing so  I then converted to JPEG using GIMP 2.8.  Now my 
inquiry is this. Why are the files all grainy /noisy? They appear as basically 
thumb print and when i tried changing the resolution in the GIMP 2.8 the photos 
still had very noticeable noise. Very pixelated. Annoyed i kept persistent to 
my task. To no avail. I need to upload said photos to a website Shutterfly for 
a book I  am putting together for a dear friend. Is there anything I can do 
with GIMP 2.8 that would allow for better results? Shutterfly gives me an error 
code that the NEF files are not acceptable and I have tried diligently to fix 
my dilemma. Can you kindly advise me? Perhaps there is away to go around this 
and end up with actual good quality resolution so that the book can be made? 
Unfortunately re-shooting is not an option. I live a state away from where I 
was taking photos.
Any advice would be greatly helpful. Kindest Regards Dphotogirl



By default Gimp doesn't read "raw" files, you need a raw processing 
pluging (Nufraw, photozone..). It is possible that what you see is the 
embedded JPEG thumbnail and not the full image.


If you want to do correction from raw files, you have better use 
specialized applications such as RawTherapee or Darktable, especially if 
you are still using Gimp 2.8.


The pixls.us site is devoted to OpenSource photography software (and 
many authors of such software use it for support).


For  a list of raw-capable applications: https://pixls.us/software/

For discussion; https://discuss.pixls.us/



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Size on disk vs size reported on status bar

[Ofnuts]

On 11/24/17 19:06, Kevin Cozens wrote:

Le 04/10/2017 à 15:51, Elle Stone a écrit :
So a byte is 8 times a bit? For people like me who can never remember 
the difference between a byte and a bit, is there a one-sentence 
explanation for why there are bytes *and* bits?


Perhaps a food analogy might help you remember the difference between 
byte and bit.


If you aren't hungry you may just nibble a bit (bit) at your food



Actually a "nibble" is 4 bits : https://en.wikipedia.org/wiki/Nibble
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP testing cooperation

[Ofnuts]

On 10/06/17 19:29, Sam Gleske wrote:

If anybody is interested in joining me as an admin for maintaining the GIMP
CI server I encourage anybody to reach out to me regardless of your skill
level.  Even if you're new to Linux and wish to get better at Linux (zero
experience) I'm willing to provide you training and act as a senior for
advice in Linux system administration.



*steps forward*
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] request

[Ofnuts]

On 06/23/17 14:14, Bert de Jong wrote:

When saving a JPG, please warn if there is transparency.
Currently GIMP saves such images without warnings and just uses the
current background color.
I think a lot of people do not use XCF and are used to saving
transparency to PNG and GIF files.

I think it's customary for GIMP to warn when operations initiated by
the user will be performed slightly different than the user might
expect.
An example is when scaling indexed images.
It then says: "Indexed color layers are always scaled without
interpolation. The chosen interpolation type will affect channels and
layer masks only."

Thanks.

Given the number of times I've seen people complaining about the loss of 
transparency, that would be a good idea.



What Gimp could have is either a counter of the number of times a 
warning has been issued (and stop issuing it after a while) or a "Don't 
tell me again" checkbox.


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] gimp-edit-copy

[Ofnuts]

On 17/04/17 12:05, Peter Suetterlin wrote:

I could fix the problem by selecting the full area before the call to
gimp-edit-copy.  But acording to the docs it should do this by itself if
nothing is selected.
IMHO the real fix is to use other ways to move pixels. Applications 
should not use the clipboard for their own purposes, this interferes 
with the user's other apps.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Proposal for erasing background from an image

[Ofnuts]

On 02/03/17 10:05, Simon Budig wrote:

John Tapsell (johnf...@gmail.com) wrote:

So to restate this again - I want to know how to change the top layer
$latex src$ so that I can have the maximum possible alpha without changing
the final visual image at all.  I.e. remove as much of the background as
possible from our foreground+background image.

This is what color-to-alpha does. Except that it uses a constant color
for the whole image. It might be interesting to convert this to a gegl
op that takes two input drawable and picks the "background color" from
each corresponding pixel in the background image.

Should be an easy fun hack. Who wants to take it?

Bye,
 Simon

Fun hack, but would it be useful in practice? Do we want the lion to be 
partially transparent because its hair is more or less the color of the 
dry grass (with some help from Darwin). Try the two pictures in 
difference mode, and check all the places that are near black.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] An idea / feature for future releases of GIMP

[Ofnuts]

On 15/12/16 18:14, M. Hammoud wrote:

Hi.
New users spend a lot of time looking for an effect / filter / brush / tool
/ pattern in the multiple menu tabs, each with a long list of submenus,
each with a lot of sub-sub-items.
It would be great, if one could simply type in a box what they are looking
for, such as for example "Gaussian Blur" and gimp would look for this or
suggest closest potential results.


Did you try Help>Plugin browser? The menu location is at the top of the 
right panel...

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Rasterize a text layer with GIMP Python or Script-Fu

[Ofnuts]

On 11/07/16 22:34, Lucian Naie wrote:

Hi everyone,

I have looked at the docs, even checked the source code, to find the magic
libgimp call (http://developer.gimp.org/api/2.0/libgimp/) that will allow
me to do programmatically what the UI text layer option "Discard Text
Information" is doing, but without much success.

How do I achieve that (https://docs.gimp.org/en/gimp-layer-text-discard.html)
from libgimp or gimp python (maybe script-fu)?
Merge it to a transparent layer... But why do you want to do that? If 
you do something pixellish to the layer it will be done automatically, 
otherwise keeping the text information can be useful.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Pencil - Tool Options and Hardness

[Ofnuts]

Shouldn't we instead get rid of the pencil tool and add a 
no-anti-aliasing option to the brush?


On 20/06/16 20:51, C R wrote:

Yep, may as well. lol
-C

On Mon, Jun 20, 2016 at 6:49 PM, Andrew Pullins 
wrote:


Sounds like a good idea
On Jun 15, 2016 10:51 PM, "Americo Gobbo"  wrote:


Hi all,
The Hardness parameter to Pencil Tool is not utilized, but is present in
its Tool Options. Reading the documentation: “The Pencil tool is used to
draw free hand lines with a hard edge. The pencil and paintbrush are
similar tools. The main difference between the two tools is that although
both use the same type of brush, the pencil tool will not produce fuzzy
edges, even with a very fuzzy brush. It does not even do anti-aliasing.”
If I have reason, I suggest delete the hardness Pencil parameter on tool
options, to avoid mistakes/misleading on the UI.
Thanks,
americo



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] [darktable-dev] Darktable plug-in in GIMP - Darktable for Windows?

[Ofnuts]

On 28/04/16 21:07, Carmelo DrRaw wrote:

Hi!

I’m not sure to understand what you mean by "if these could save to 
high-bit-depth XCF directly, that would be even nicer”, but what I can say is that 
photoflow works as a “native” plug-in, in the sense that it does not call an 
external program, and it copies the output into the GEGL buffer of a newly created 
GIMPO image.

The code is very similar to UFraw in this respect, except that the image data 
is passed in 32-bits floating point format.



Personally I don't use the raw processors as plugins. I use raw files 
when I have to do extensive work on the picture (otherwise the camera 
Jpeg is good enough). So I don't see the point of using a plugin to 
spend 20 minutes in the plugin without being able to use any Gimp 
functionality. I can just as well use an external program (which until 
recently, gave me a lot more choice...). And after these 20 minutes I 
want to have something I can show/share before doing further edits so 
I'll anyway do an export, and this export is also the file I will open 
in Gimp for final edits.


With 8-bit Gimp, a 8-bit PNG or high-quality JPEG is enough. With the 
new Gimp, it will be better to use some 16-bit format. There are several 
already (TIFF, 16-bit PNG...) but using XCF could have benefits (passing 
metadata, etc).

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] [darktable-dev] Darktable plug-in in GIMP - Darktable for Windows?

[Ofnuts]

On 28/04/16 12:31, Elle Stone wrote:

On 04/27/2016 12:11 PM, Elle Stone wrote:


Hmm, now that I have darktable properly installed using Lua, and GIMP
opening 32f raw files processed with darktable, I can't figure out how
to open a raw file from GIMP using the PhotoFlow plug-in.

What's the procedure for bypassing the darktable plug-in to use a
different GIMP raw plug-in?



Uninstalling darktable does allow the user to use the PhotoFlow raw 
plug-in. But this doesn't seem like a very user-friendly way to 
proceed. Also, it only seems to work if GIMP is recompiled and 
reinstalled *after* darktable has been uninstalled. Or at least delete 
the config folder, or whatever file in the config folder holds 
information about the raw plug-ins.


So is there some place in the GIMP UI - that so far I haven't been 
able to find - to choose which raw plug-in to use?


If not, are there plans to add a way in the GIMP UI for users to 
choose which raw plug-in to use?




Perhaps the best solution is to use the stand-alone version of the 
plugins. Of course, if these could save to high-bit-depth XCF directly, 
that would be even nicer.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] A better way to close a path where an end nodeis on top of a start node

[Ofnuts]

On 31/01/16 09:08, Joseph Bupe wrote:

Hi,

Is there a reason why the path can close by just clicking the last node
onto the first node? Why do we have to CTRL or Command + Click ?


Because clicking on a node is selecting it, and this i something you'll 
want to do if you want to extend the path from the other end. In other 
words, you create a path with M, N, O, P, Q and then you want to add 
points L, K, J, so after adding Q you'll click on M, and you don't want 
this to close the stroke.



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Scanning coins

[Ofnuts]

On 13/01/16 18:11, billgoldbe...@frontier.com wrote:



 Greetings, I have heard Gimp is great for scanning images of coins to be 
sold internet. Can you tell me to set up Gimp to do this?Regard,William.
Sent from my Verizon 4G LTE Tablet



Gimp has no built-in scanning capabilities. Even if you can scan from 
Gimp, it will rely on some external application to do the scanner 
capture. Gimp is then used to edit the image. Most/all scanners come 
with a scanner application...

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Future of Python v2 scripts

[Ofnuts]

On 26/11/15 11:53, Simon Budig wrote:

It would make sense to switch to python 3 in sync with the
(plugin-breaking) switch to gtk3 with the 3.0 release.


Why would gtk3 break python plug-ins? I don't see that many that come 
with their own UI. I would expect 2.10 and the high bit-depth to break 
more scripts

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Future of Python v2 scripts

[Ofnuts]

The latest Ubuntu (15;10) has dropped support for Python V2 (Python V2 
is still available via a PPA). Are there any plans to support V3 in 
Gimp, possibly alongside V2? Maybe as a minimum look at the script's 
shebang to determine if it is compatible with the supported Python version?

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] acceleration smoothing interpolation

[Ofnuts]

On 06/11/15 21:26, Ben Thurston wrote:

Hi I posted an idea about an interpolation method a while back, I've
improved the idea a lot in the meantime so I thought I'd post a link to the
new version.. I saw I got quite a few views to the blog from posting to
this mailing list last time but no replys so I wasn't sure what that meant
but if it's not relevant I'll understand, I'm just posting it to see if
anyone has some ideas for applications... thanks!
http://benpaulthurstonblog.blogspot.com/2015/11/acceleration-smoothing-interpolation.html
_


There is already a very efficient algorithm to obtain the smoothest 
series of Bézier splines that go through given points:


https://www.particleincell.com/2012/bezier-splines/

It has even been implemented as a Gimp plugin: 
http://registry.gimp.org/node/20069

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Fade length setting for paint dynamics

[Ofnuts]

On 08/10/15 14:05, Jon Tait wrote:
1. The "percent" setting is relative to maximal image dimension (ie. 
image width or height, whichever is larger).
Ref: 
https://git.gnome.org/browse/gimp/tree/app/paint/gimppaintoptions.c?h=gimp-2-8#n591
And as far as I can see it *does* work as intended - eg. Paintbrush 
Tool with Dynamics=Fade Tapering, Fade length=100% will fade in/out 
over a *stroke* length equal to the larger of image width and height. 
And pro rata for other values of "percent". [But note that it is the 
maximal *image* dimension, not *drawable* dimension.]


I tried that and it didn't seem to work.



2. No it cannot currently be set programmatically. The fade parameters 
are *dynamic options* (ie. specific to the fade dynamic), not common 
*paint options* (ie. applicable to all paint tools regardless of 
dynamics). And setting dynamic options is AFAIK not currently 
supported via PDB. IIRC this problem has been noted before but I 
cannot find anything on bugzilla about it now. Note this is a wider 
problem than just fade length, it requires a generalized method of 
getting/setting *all* dynamic options.




Dynamics take their other values from the general context For instance 
the varying "color" in the Dynamics uses the context gradient, the brush 
size is the context brush size, etc... And if I change a 
dynamics-related setting (fo instance, the "repeat") for one tool 
(brush), the value changes for other tools (airbrush, clone...).

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Fade length setting for paint dynamics

[Ofnuts]

On 06/10/15 19:35, Joao S. O. Bueno wrote:

Sttting it programatically is likely a missing feature - it shouldbe
available as gimp-context-fade-set-length  -- and yes, it has nothing
to do with percents




Should I file a bug report for this?

What should be done with the percent "unit" then? Remove it?


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Fade length setting for paint dynamics

[Ofnuts]

I see that some changes have occured in that area in 2.8.14... However:

 * I can't figure out the "percent" setting. Percent of what? From what
   I tried, it is not a percent of the total path length, not a percent
   of the stroke length, and not a percent of some image dimension.
 * is there a way to set it programmatically? searching "fade",
   "context" or "dynamics" in the procedure browser doesn't show
   anything (not does looking at dir(gimp) in Python).



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Portable development environment for GIMP

[Ofnuts]

On 28/09/15 19:22, Sam Gleske wrote:

On Mon, Sep 28, 2015 at 10:21 AM, Michael Schumacher 
wrote:



On 09/27/2015 08:35 PM, Sam Gleske wrote:


1. Install vagrant https://www.vagrantup.com/
2. Clone: git clone https://github.com/samrocketman/vagrant-gimp

Um... why is KDE in there?



Because it's a UI.  Would you rather build headless?



Plenty of UIs and desktop managers, and plenty of development tastes... 
I'm myself on KDE, but if your VM was running Gnome or Unity, it would 
be useless to me. I do use a VM for some development that can only be 
done on Windows, but using a Linux VM over my existing Linux install is 
a bit wasteful?




___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Cropping border color

[Ofnuts]

On 02/06/15 17:50, Burnell West wrote:

On Jun 1, 2015, at 11:07 PM, Brad Gibson bradgibson...@yahoo.com wrote:

It would be great if I could choose to see pure black around whatever I'm 
cropping, because I make very meticulous crops of photos for artistic purposes, 
and I often have to crop and go back multiple times because it looks different 
in the final version with solid white/gray/black compared to transparent while 
I'm cropping. Or else, if it's easier, make it so that I can undo the 
finalization of the crop but go back to where I left the crop at. Thanks.Brad G.

Simply add a black layer and put it behind the image



Or EditPreferencesDisplayTransparencyCheck styleBlack only
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Sourceforge downloads

[Ofnuts]

The Sourceforge gimp-win downloads are now pointing to a 730K downloader:

http://i.imgur.com/ImWKmHN.png

Should this site be closed down entirely (assuming it is still under the 
control of someone related to Gimp development)? There are still plenty 
of links pointing to it, and it would be better for them to be invalid 
instead of pointing to this crap?


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Mapping Matrix and the Tool Options

[Ofnuts]

On 24/05/15 10:26, Joseph Bupe wrote:

Dear Developers,

The paint tools Mapping Matrix is such as cool feature and I am requesting
you to kindly move it to the Tool options where it initially used to be.
The reason is that it is easier to access from the Tool options since they
are related than having them in separate dialogs or tabs. I assume many
people don't even know where/how to get it in the current setup.

Since already the Tool Options itself has too many controls,  I request
that the Mapping Matrix be placed above all controls in the Tool Options
and make its control labels (Opacity, Size, Angle, Color,  Hardness, Force,
Aspect Ration, Spacing ...) clickable so that only one combo box
corresponding to the clicked label will appear in the Tool options for
adjusting settings.

Please, see the mockup:  http://s29.postimg.org/w546vdnav/Brush_dynamics.png

So, creating combo boxes dynamically with the clicked labels in the Mapping
Matrix could reduce on the number of controls in Tool options (if it makes
sense).


I don't remember seeing the mapping matrix (I assume you mean the 
paint dynamics editor dialog) in the Tool options.


This editor dialog is dockable so you can dock it below the Tool options 
or as another tab in the same dock. Note however that it has a minimum 
vertical size that constrains the size of the docks you put it in (and 
this sheer size is IMHO one good reason to not make it part of the Tool 
options).



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

[Ofnuts]

On 01/05/15 04:00, Gez wrote:

Hi Elle,
You know I'm with you regarding giving users more control over how
operations are performed, but tossing buttons for toggling between
linear and perceptual everywhere in the UI is not a proper solution.
It would be extremely confusing, and people would start toggling them
randomly without knowing what exactly they are for, and only a few
people would benefit from it.
I think that allowing that would complicate the UI and the the tools
themselves, as all of them should have both paths available.
A better solution would probably have to wait until proper
no-destructive editing is finally implemented, and operations are
visualized as a stack/chain/whatever.
I mean, instead of putting toggles on EVERYTHING, why not adding a tool
that says from this point, the following operation/s will be performed
in linear/perceptual gamma?
People used to node-based UIs will understand exactly what I mean.
The difference would be that only users who need the toggle will add an
operation that makes the switch when it's required. The UI will remain
lean, without extra options that could potentially confuse less advanced
users.



It depends a bit what the workflow is. If users need to switch all tools 
at random between linear and perceptual, this will be complicated. But 
if you can categorize workflows into those that are always perceptual, 
those that are always linear, and those that are let the tool choose 
what is more appropriate, then the only thing needed is a state 
indicator in the context, like antialiasing or feather. Ah, but 
antialiasing and feather are in the individual tool options so we don't 
gain much... OTOH we start having a good excuse for a context 
dialog/widget, and isn't that exactly what the toolbox is already, with 
the color swashes and the brush/pattern/gradient display?

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Lack of accuracy

[Ofnuts]

On 27/04/15 14:19, Nicolas Robidoux wrote:

By calc, you mean a layer mask?
___



In French a calque (*) is a layer.

(*) calque is originally the word for a sheet of tracing paper.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Gimp in private schools and educational institutions

[Ofnuts]

The name is a blocker in some US schools with teachers or student 
parents that over-sensitive (and somewhat dirty-minded, since gimp has 
other meanings in English).


By the way, one of the most popular Web server software is called 
Apache. In French, it is also slang for a street robber and any person 
of ill repute. Doesn't make it any less popular with corporate IT.


On 28/04/15 07:03, Sam Bagot wrote:

Renames have worked in the past as I see it and for the most part, as I'm
sure you've heard people consider before, a product named gimp can't
succeed against a product named professionally like PhotoShop.  So you

[...]
I could certainly find people in the professional world to talk about it if
a name change was in consideration.  What about GIM and pronounce it as
gem?  Why not just drop the P and it would be fine.  It would be explosive
and people could use it.  It would start to have young adopters and brand
loyalty.  Don't you want to have all your hard work go into a successful
product?


Best,
Sam


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Create New Layer Button

[Ofnuts]

On 28/03/15 11:46, Michael Schumacher wrote:
A context menu that acts like a real context menu, i.e. shows options 
that are most relevant to the current context either exclusively or at 
least in some kind of prominent position, e.g. at the top. This has 
been discussed a few times already, but not real plans or work have 
been done yet. A downside is that it would change the order of the 
option in the latter case (think of e.g. the Select menu being sorted 
to the menu bottom is there is no selection) and not show some at all 
in the former case (if e.g. all disabled options would not be shown at 
all in GIMP menus). 


These contextual menus are a mixed blessing. Of course they make things 
simple, but it can be somewhat too simple. How will new users discover 
options or functionalities that are new to them(*)? The people who 
really benefit from this are the advanced users but they don't really 
care...



(*) taking that to an extreme: you wouldn't see the bump map filter 
until you have at least two layers of the same size in your image, or 
Text along path unless you have already created a path


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Create New Layer Button

[Ofnuts]

On 26/03/15 09:29, Tobias Oelgarte wrote:

Am 25.03.2015 um 19:54 schrieb jEsuSdA 8):

El 23/03/15 a las 18:49, Alexandre Prokoudine escribió:

On Mon, Mar 23, 2015 at 4:16 PM, Joseph Bupe wrote:
IMO, the new layer button should just create a new transparent 
layer. The

dialog window should be optional.


Or you can create a transparent layer once and Shift+click the button
the next time. It's in the tooltip even :)


Oh my god! I just discovered this awesome feature! (I will pay more 
attention to tooltips now) :D


Thanks!
I didn't notice this feature as well. Good to know. But since many of 
us missed it, could we say that the implementation of this feature 
sucks, because it is not obvious for the normal user?


It was also not so obvious to some more advanced users :) let's face it, 
in a software with the breadth of Gimp, everyone is going to overlook 
some feature. And anyway you can't have all these clever little things 
jump in your face when you start using the application, that would be 
information overload. Better find/learn about them little by little when 
the need arises.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list