Sven Neumann wrote: > When we split up the GIMP core into sub-directories, we also split the > code into UI and core. You will find a few files in the UI > sub-directories that hold nothing but config settings. Since the non-UI > GIMP should be able to read the same config files that the UI-enabled > GIMP uses, the non-UI code needs to be know about some config settings > that are part of the UI. That's why gimp-console needs to link a few > files from the non-UI parts of GIMP. Does that mean that these files > should be moved to other folders? No, because they are in the right > location, close to the code that actually uses them. Does that mean that > there is a dependency that needs to be fixed? No, not unless you want to > drop the possibility to share config files between the UI-enabled and > the non-UI GIMP. We have special-casing on the includes in app/config/gimpdisplayconfig.c by including types not in the module namespace, and we have special casing on the linking in gimp-console by including individual files instead of only module libraries. If we were to move the files to the config module, we could remove this special casing. Isn't it obvoius that this is what we should do? I don't buy the argument that code must be close to the code that uses them. That completely invalidates service layers in an architecture, i.e. layers that provides services to clients in layers above. And exactly how would moving the display config files to the config module drop the possibility to share config files between the UI-enabled and non-UI GIMP? The UI GIMP has access to the non-UI GIMP. Best regards, Martin _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
