Gimp Fork

[JonF]

Is there any chance that the fork of gimp  "noxcf-gimp" could be added to the repos as an alternative for those of us who think the save/export strategy is dim-witted:

https://github.com/mskala/noxcf-gimp

Cheers

Jon

[T6]

hello and welcome to the forum!

there is a couple options to avoid that right now, there is a article in the pclinux magazine that you can read that could help you to avoid asking forks of gimp that possibly can't be added to the repos

the magazine is in this link

http://pclosmag.com/index.html

the article is called

Dealing With Gimp 2.8’s New Save Features

[Archie]

Why should the fork be avoided? Although I will continue to use GIMP in spite of the tear it created on its userbase, I believe that the logic of the GIMP developers have excellent merits and are heading towards the right direction in development. However, the fork noxcf-gimp should be able to appease those users that don't agree with the vision of the GIMP devs.

So with that in mind, what's left is the usual process to see how things would go. If there are enough interest on our users then I suppose one of the packagers have to pick it up.

[T6]

because it is a small modification to the save menu, have two gimps on repo just for that purpose, for me sounds as a waste of repo space and complication for the users

still, you are right, other people will want to have this, i was reading that lots of users didn't liked this change

so maybe if enough people ask for it, there could be a solution from gimp team, maybe something like the change from one window to multiple window option but applied to save native xcf or save as the format you had or you want?

[parnote]

Sorry, but I've got to weigh in here. I think the solution lies somewhere in the middle. Why can't the old "Save/Save As..." features be implemented, but ***could*** default to saving as an XCF file, but the end user has the choice of saving it in another format ... without the whole (confusing) "Export" issue.

But, until/unless the Gimp team gives us this much more palatable solution, I think it's prudent to have both versions in the repo and give users the choice.

[T6]

i was searching the other day for a old post and found a comment about the export option, someone replied that no one complains when they have to export audio in audacity

export is not that bad but it does add a extra step that is a bit annoying, i would prefer to have a a save as that lets me save as the format i want, the export is useful too

the solution is how you describe parnote, something in the middle, that lets users choose, not force them to use only the export option

i still think that have here a fork of gimp is too much for only one option in the file menu

[Archie]

because it is a small modification to the save menu, have two gimps on repo just for that purpose, for me sounds as a waste of repo space and complication for the users

still, you are right, other people will want to have this, i was reading that lots of users didn't liked this change

so maybe if enough people ask for it, there could be a solution from gimp team, maybe something like the change from one window to multiple window option but applied to save native xcf or save as the format you had or you want?

Hey T6, I'm with your reasoning. I'd rather use GIMP since I've gotten used to the Export or Save (as XCF) way and had only to hit my own head on the wall if I don't save the layers and needed to fix a few more things with no XCF available.

But that small change in habit is not becoming of many users thus the fork.

A fork is indeed an overkill, and Akkana's python script should be good for Export/Clean ... yet let's see how much interest the fork on our forum and users can get. And as I mentioned it has to be requested properly.

[Rudge]

Personally, it took me all of two times to realize that I needed to "export" the file. After that tiny learning curve, I haven't given it much thought. 

[Just17]

I think they could easily make things clearer for the user by changing the names of the menu entries .....  and keeping them together.

So Save could be Save Xcf  or something very obvious
Same for Save AS

There is a Save for Web which is fine ....  it saves as Jpg or other suitable format ....  yet it is closely associated (visually) with the "Save" menu entry

And then there is Export ......  separated somewhat from the Save entries.

This could easily be Save As other Formats  or other such descriptive entry

I have no objection to using a specific menu entry to save a file in jpg or other format .........  providing ALL the save entries are similarly named and are clearly distinguishable from each other.

So IMO, a little tweaking with the menu entries is all that is required ..............  to cover MY annoyances during MY use.

Of course others might have different requirements.

[kjpetrie]

The change is annoying but not worth a fork. Any user will soon get used to it. There is even an option in Preferences to turn off the annoying warning if you don't want to save as .xcf. Forking an application over something so trivial just shows how petty some people can be.

I think packagers have higher priorities than packaging two nearly identical programs - a newer kernel, toolchain revision at some point soon, keeping up with KDE and Gnome changes, 64-bit (which seems to be falling behind a bit at present) - the list goes on and I probably don't know half of it.

Adding unnecessary extra work because of such a small change is just not helpful to a small team.

[Archie]

The change is annoying but not worth a fork. Any user will soon get used to it. There is even an option in Preferences to turn off the annoying warning if you don't want to save as .xcf. Forking an application over something so trivial just shows how petty some people can be.

I think packagers have higher priorities than packaging two nearly identical programs - a newer kernel, toolchain revision at some point soon, keeping up with KDE and Gnome changes, 64-bit (which seems to be falling behind a bit at present) - the list goes on and I probably don't know half of it.

Adding unnecessary extra work because of such a small change is just not helpful to a small team.

Definitely +1 from me.

[Meemaw]

Personally, it took me all of two times to realize that I needed to "export" the file. After that tiny learning curve, I haven't given it much thought. 

Yeah, me neither....

 

[JonF]

If You read the 'readme' of the fork, you will see that it is intended to fork into a completely new program and will eventually get a new name. The first fundamental point of the fork is that the save menu is a legitimate place for file format choice.

I have read the PCLinuxOS mag and it does nothing to assuage my annoyance at the Gimp decision.

Libreoffice exports to .pdf because you can't re-open the file once exported, but every openable and savable format is in the open/save menus, not import/export. It should be the same for Gimp, the same as it is for Photoshop, hence my statement that it is 'dim-witted'. The decision of the Gimp Programmers has forced this fork and a division of its userbase for no other reason than wanting to make a Microsoft-like point "You must do it this way, because I am telling to do it this way"

Like many others, I am now going to move along the fork line because Gimp now runs contrary to the file opening and saving strategy logic of every other program I use. It would be better for me and those who share my opinion, that the fork alternative is added to the repos. I would rather not have to compile the source myself but will if I have to.

Gimp has got it wrong and it is time to part ways unless they can quickly come to their senses.

JonF
PS. This is a new ID because the forum is no longer recognising my old ID and Login after a year of not posting.

[Crow]

Personally, it took me all of two times to realize that I needed to "export" the file. After that tiny learning curve, I haven't given it much thought. 

Yeah, me neither....

 

+1

[parnote]

Libreoffice exports to .pdf because you can't re-open the file once exported, but every openable and savable format is in the open/save menus, not import/export. It should be the same for Gimp, the same as it is for Photoshop, hence my statement that it is 'dim-witted'. The decision of the Gimp Programmers has forced this fork and a division of its userbase for no other reason than wanting to make a Microsoft-like point "You must do it this way, because I am telling to do it this way"

I understand and agree with what you're saying, JonF, but the part in red (above) just isn't correct. Let me explain.

Recently, my wife had to have some medical procedures performed. Prior to her visit with a new doctor, she downloaded some forms from the physician's web site, to fill them out before her visit. The forms were in a PDF format, but one of the forms had some wording that would have made it troublesome when seeking coverage from our insurance provider. So, instead of having to "fight that fight," I instead opened the PDF with the offending wording with LibreOffice, changed the wording, and re-exported the corrected PDF.

So, LibreOffice can/will/does open PDF files for editing.