RSS/Atom feed Twitter
Site is read-only, email is disabled

menu cluttage

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

15 of 15 messages available
Toggle history

Please log in to manage your subscriptions.

menu cluttage Joao S. O. Bueno Calligaris 27 Jun 06:43
  menu cluttage Sven Neumann 28 Jun 08:45
  menu cluttage Kevin Cozens 04 Jul 07:11
   menu cluttage Sven Neumann 05 Jul 21:47
    menu cluttage Joao S. O. Bueno Calligaris 06 Jul 02:36
     menu cluttage Joao S. O. Bueno Calligaris 06 Jul 02:41
      menu cluttage Sven Neumann 07 Jul 20:28
     menu cluttage Sven Neumann 06 Jul 07:50
     menu cluttage Alan Horkan 08 Jul 14:20
    menu cluttage Akkana Peck 06 Jul 05:28
  menu cluttage jernej@ena.si 04 Jul 10:19
   menu cluttage Fennec 04 Jul 17:13
    menu cluttage Jakub Steiner 05 Jul 12:57
     menu cluttage Alan Horkan 08 Jul 15:47
    menu cluttage Alan Horkan 05 Jul 14:03
Joao S. O. Bueno Calligaris
2006-06-27 06:43:59 UTC (almost 18 years ago)

menu cluttage

Hi,

I e mentioned once or two that when the script-fu and python-fu scripts where brought togetehr to teh same menu space as the C filters there would be confusion about which menu entry is associated with a script in which language.

I have been normally replied that "it does not matter" for the end user in which language the script is in.

Well...it _does_ matter. The specif\c language matters little, but there are some side-effects. Knowing which package brought which filter is more still important (and also impossible in the current "everything mixed" system)

Now I just stumbled into an 'interesting' bug arising from this confusion:
Python-fu Whirl and Pinch had overwritten the menu entry for C Whirl and Pinch (moreover Python whirl and pinch is currently crashing)

Please notice there is no way a normal user can be aware of situations like this. Actually, it is almost as annoying (to say the least) as win95 and beyond "feature" of not showing the image file extensions in the file browsers.

But even win95 has different icons for different kinds of images. The GIMP currently has just no clue.

SO, I am bringing this subject to discussion once more, and asking about adding a small icon to menu entries, or some other indicator to tell users which entry came from where.

Regards,

JS ->

Sven Neumann
2006-06-28 08:45:26 UTC (almost 18 years ago)

menu cluttage

Hi,

On Tue, 2006-06-27 at 01:43 -0300, Joao S. O. Bueno Calligaris wrote:

I e mentioned once or two that when the script-fu and python-fu scripts where brought togetehr to teh same menu space as the C filters there would be confusion about which menu entry is associated with a script in which language.

I have been normally replied that "it does not matter" for the end user in which language the script is in.

Well...it _does_ matter.

No, it doesn't.

The specif\c language matters little, but there are some side-effects. Knowing which package brought which filter is more still important (and also impossible in the current "everything mixed" system)

Now I just stumbled into an 'interesting' bug arising from this confusion:
Python-fu Whirl and Pinch had overwritten the menu entry for C Whirl and Pinch (moreover Python whirl and pinch is currently crashing)

There's a problem here in our menu registration code. I don't see why two plug-ins should not be able to install menu entries with the same label. That's a somewhat unfortunate situation then, which should of course be avoided, but at least both procedures would be accessible then.

Please notice there is no way a normal user can be aware of situations like this. Actually, it is almost as annoying (to say the least) as win95 and beyond "feature" of not showing the image file extensions in the file browsers.

But even win95 has different icons for different kinds of images. The GIMP currently has just no clue.

No clue?? We have a plug-in browser that allows you to find out quite a bit of information about the plug-in. We certainly don't need to clutter our menus by adding icons that are meaningless in almost all circumstances.

Sven

Kevin Cozens
2006-07-04 07:11:20 UTC (over 17 years ago)

menu cluttage

Joao S. O. Bueno Calligaris wrote:

Now I just stumbled into an 'interesting' bug arising from this confusion:
Python-fu Whirl and Pinch had overwritten the menu entry for C Whirl and Pinch (moreover Python whirl and pinch is currently crashing)

Now that GIMP handles registration of the same menu item from different plug-ins, I am just waiting for the time a user reports a bug in Whirl and Pinch (for example) and doesn't realize which version they were using (as in the Python version or the C version).

Please notice there is no way a normal user can be aware of situations like this. Actually, it is almost as annoying (to say the least) as win95 and beyond "feature" of not showing the image file extensions in the file browsers.

Not showing file extensions in Windows is a configurable option. It defaults to not showing the extensions but you can click an option to have Windows show the extensions.

But even win95 has different icons for different kinds of images. The GIMP currently has just no clue.

The icons shown in Windows for various files is related to file associations and not to Windows knowing the type of image file. I use one program to view almost all image types so almost every image type carries the same icon on my machine.

jernej@ena.si
2006-07-04 10:19:16 UTC (over 17 years ago)

menu cluttage

On Tuesday, June 27, 2006, 6:43:59, Joao S. O. Bueno Calligaris wrote:

But even win95 has different icons for different kinds of images. The GIMP currently has just no clue.

Currently the GIMP on Windows has 1 icon that is used for all file formats associated with it. It would be possible to have separate icons for every format handled by the GIMP, but somebody would have to create them.

Fennec
2006-07-04 17:13:47 UTC (over 17 years ago)

menu cluttage

jernej@ena.si wrote:

Currently the GIMP on Windows has 1 icon that is used for all file formats associated with it. It would be possible to have separate icons for every format handled by the GIMP, but somebody would have to create them.

I don't suppose the Tango project has anything we could swipe, does it? We should ask them to do it. :)

Jakub Steiner
2006-07-05 12:57:49 UTC (over 17 years ago)

menu cluttage

On Tue, 2006-07-04 at 11:13 -0400, Fennec wrote:

jernej@ena.si wrote:

Currently the GIMP on Windows has 1 icon that is used for all file formats associated with it. It would be possible to have separate icons for every format handled by the GIMP, but somebody would have to create them.

I don't suppose the Tango project has anything we could swipe, does it? We should ask them to do it. :)

Hi.
Actually I've been trying to avoid the mimetype hell and only drawn generic types for now. Making a distinct icons for XCFs may sound like a usable thing to do. But I don't think having a distinct icon for each and every image type out there will bring us any good.

cheers

Alan Horkan
2006-07-05 14:03:13 UTC (over 17 years ago)

menu cluttage

On Tue, 4 Jul 2006, Fennec wrote:

Date: Tue, 04 Jul 2006 11:13:47 -0400 From: Fennec
Cc: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] menu cluttage

jernej@ena.si wrote:

Currently the GIMP on Windows has 1 icon that is used for all file formats associated with it. It would be possible to have separate icons for every format handled by the GIMP, but somebody would have to create them.

I don't suppose the Tango project has anything we could swipe, does it? We should ask them to do it. :)

The gnome (and tango) icons sizes aren't particularly useful on Windows.

You might be better off to try checking the gimp Windows mailing list, I vaguely recall previous attempts to create a suitable set of document icons but I dont know if anything came of it.

Sven Neumann
2006-07-05 21:47:50 UTC (over 17 years ago)

menu cluttage

Hi,

On Tue, 2006-07-04 at 01:11 -0400, Kevin Cozens wrote:

Now that GIMP handles registration of the same menu item from different plug-ins, I am just waiting for the time a user reports a bug in Whirl and Pinch (for example) and doesn't realize which version they were using (as in the Python version or the C version).

The Python version will of course not be in any stable release.

And so far I don't see anyone complaining about my proposal to not install any Python scripts at all with GIMP 2.4.

Sven

Joao S. O. Bueno Calligaris
2006-07-06 02:36:51 UTC (over 17 years ago)

menu cluttage

On Wednesday 05 July 2006 04:47 pm, Sven Neumann wrote:

Hi,

On Tue, 2006-07-04 at 01:11 -0400, Kevin Cozens wrote:

Now that GIMP handles registration of the same menu item from different plug-ins, I am just waiting for the time a user reports a bug in Whirl and Pinch (for example) and doesn't realize which version they were using (as in the Python version or the C version).

The Python version will of course not be in any stable release.

And so far I don't see anyone complaining about my proposal to not install any Python scripts at all with GIMP 2.4.

Hey.
It is allright for me if you do not install then- but I had complained. - At least count that.

Actually we could think of then case by case. Almost all of then are just clones of other plugin/scripts, buyt, py-slice, for example, has only an equivalent in gimp-perl, and currently py-slice is far more capable.

Also, IRCC, some scripts dealing with palettes where implemented in python, using some I had done as basis. These also provide unique features.

JS
->

Sven

Joao S. O. Bueno Calligaris
2006-07-06 02:41:01 UTC (over 17 years ago)

menu cluttage

On Wednesday 05 July 2006 09:36 pm, Joao S. O. Bueno Calligaris wrote:

On Wednesday 05 July 2006 04:47 pm, Sven Neumann wrote:

Hi,

On Tue, 2006-07-04 at 01:11 -0400, Kevin Cozens wrote:

Now that GIMP handles registration of the same menu item from different plug-ins, I am just waiting for the time a user reports a bug in Whirl and Pinch (for example) and doesn't realize which version they were using (as in the Python version or the C version).

The Python version will of course not be in any stable release.

And so far I don't see anyone complaining about my proposal to not install any Python scripts at all with GIMP 2.4.

Hey.
It is allright for me if you do not install then- but I had complained. - At least count that.

Forgot to say this: not only had I complained, but I also offered to fix the issues with the python scripts right away, and you just said it was too late.

Akkana Peck
2006-07-06 05:28:22 UTC (over 17 years ago)

menu cluttage

Sven Neumann writes:

And so far I don't see anyone complaining about my proposal to not install any Python scripts at all with GIMP 2.4.

Not installing scripts that are there strictly as example code makes sense. Would they stay in CVS head, so it would be easy for people learning gimp-python to find them?

What about the few python scripts that perform functions that aren't otherwise available? Even if they're not perfect, some of them seem useful. For instance, py-slice can be very handy for some people (if they don't have gimp-perl and perlotine). Foggify is a bit different from anything else that's installed by default, isn't it? And it seems to work okay even if the default color makes me wonder where the author lives (orange reflections from low-pressure sodium lighting?)

...Akkana

Sven Neumann
2006-07-06 07:50:07 UTC (over 17 years ago)

menu cluttage

Hi,

On Wed, 2006-07-05 at 21:36 -0300, Joao S. O. Bueno Calligaris wrote:

It is allright for me if you do not install then- but I had complained. - At least count that.

IIRC, there hasn't been a comment in the respective bug report, but I might be wrong.

Actually we could think of then case by case. Almost all of then are just clones of other plugin/scripts, buyt, py-slice, for example, has only an equivalent in gimp-perl, and currently py-slice is far more capable.

Also, IRCC, some scripts dealing with palettes where implemented in python, using some I had done as basis. These also provide unique features.

Right, but as long as the scripts aren't internationalized and localized, I am afraid we can't install them by default. So if we really need them, someone should better look at doing that right now.

It would also be nice to give the pygimp UI an overhaul so that their dialogs look more like the rest of the GIMP UI.

Sven

Sven Neumann
2006-07-07 20:28:35 UTC (over 17 years ago)

menu cluttage

Hi,

On Wed, 2006-07-05 at 21:41 -0300, Joao S. O. Bueno Calligaris wrote:

Forgot to say this: not only had I complained, but I also offered to fix the issues with the python scripts right away, and you just said it was too late.

Me saying that it is late, even too late, doesn't mean that it shouldn't happen. If the Python scripts are not localized at some point, we can never install them by default. So if there's interest to install them, perhaps even still for 2.4, someone would better start to review the strings now and prepare them for translation.

Same for the improved statusbar messages. Raphael made a nice proposal, but the strings really need to go into CVS real soon now or they will miss the string freeze.

Currently we aren't ready for doing the string freeze, but hopefully we will be there soon...

Sven

Alan Horkan
2006-07-08 14:20:53 UTC (over 17 years ago)

menu cluttage

On Wed, 5 Jul 2006, Joao S. O. Bueno Calligaris wrote:

Date: Wed, 5 Jul 2006 21:36:51 -0300 From: Joao S. O. Bueno Calligaris
To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] menu cluttage

On Wednesday 05 July 2006 04:47 pm, Sven Neumann wrote:

Hi,

On Tue, 2006-07-04 at 01:11 -0400, Kevin Cozens wrote:

Now that GIMP handles registration of the same menu item from different plug-ins, I am just waiting for the time a user reports a bug in Whirl and Pinch (for example) and doesn't realize which version they were using (as in the Python version or the C version).

The Python version will of course not be in any stable release.

And so far I don't see anyone complaining about my proposal to not install any Python scripts at all with GIMP 2.4.

Hey.
It is allright for me if you do not install then- but I had complained. - At least count that.

Actually we could think of then case by case. Almost all of then are just clones of other plugin/scripts, buyt, py-slice, for example, has only an equivalent in gimp-perl, and currently py-slice is far more capable.

There is an equivalent web slice written in Script-fu. I have my own modofied copy lying around somewhere but if I recall correctly you can find the original in the gimp plugin registry.

It will be good to have the Python support turned on by default on windows so that developers (script writers) can count on it being there but not including the redundant scripts isn't any great loss.

-- Alan H.

Alan Horkan
2006-07-08 15:47:09 UTC (over 17 years ago)

menu cluttage

On Wed, 5 Jul 2006, Jakub Steiner wrote:

Date: Wed, 05 Jul 2006 12:57:49 +0200 From: Jakub Steiner
To: Fennec
Cc: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] menu cluttage

On Tue, 2006-07-04 at 11:13 -0400, Fennec wrote:

jernej@ena.si wrote:

Currently the GIMP on Windows has 1 icon that is used for all file formats associated with it. It would be possible to have separate icons for every format handled by the GIMP, but somebody would have to create them.

I don't suppose the Tango project has anything we could swipe, does it? We should ask them to do it. :)

Hi.
Actually I've been trying to avoid the mimetype hell and only drawn generic types for now. Making a distinct icons for XCFs may sound like a usable thing to do. But I don't think having a distinct icon for each and every image type out there will bring us any good.

It is certainly useful to have icons for the major types. One icon to rule them all is not enough.

There was some concern when the icons were changed so that PNG and JPEG had the same icons since it is particulaly useful to distinguish the losless and lossey formats. (I'm not sure if that was Tango/Ubuntu/Gnome exactly and this may well have been fixed already since I last noticed it.)

I understand you dont want to create icons for every type of graphics file format but it might also be useful to have an icon for XCF, PSD, MNG and perhaps other layered image file formats.

The icons in Windows were rubbish but Windows/Internet explorer did at least provide 'picture frame' style icons for GIF, JPEG, and PNG with each having a different central colour (green, red and pink respectively). One option might be for the windows installer to leave the default icons alone for these types (use the default icons provided by windows) and only set the gimp document Icon for XCF and a few other gimp specific formats? I've manually changed the icons like this in the past but other programs have long since stolen the file associations back again and now only a few of my files have the gimp icon on them. If this sounds like what windows users want they should talk sweetly to the developer who puts together the windows installer.