I am finally upgrading from version 0.48 to version 1.2 and noticed something interesting/cool. As a matter of procedure I run all my downloaded programs through a quick scan before installation, and to my amazement I saw that the Inkscape installer contains 52,245 files! That suggests an astonishing amount of work has gone into this program.
My question specifically, is 'why' - or perhaps 'what are all of those fifty two thousand files doing?' I had no idea so much was going on in the engine room, and I'd like to understand (on a very basic level) how Inkscape approaches the task of image/vector/visual editing. I'm just beginning a programming course which has made me notice more details like this, and as soon as I saw how many files were in Inkscape I felt the urge to find out just how complex it is. (For comparison my Blender installation has under ten thousands files.) I can't help but feel awed by the development effort. Thank you all for the incredible dedication and contributions you've made.
Just extract the installer files and have a rummage around.
The inkscape-1.2.2 install ZIP for Windows contains 13,000 files. The MSI seems to contain 15,000 files. Not sure where you're seeing over 50k files, but I haven't checked the other distributions.
When I did the scan it may have reported several thousand more files because I scanned an archive (before extracting the files), and perhaps many of the files were broken into several pieces in the compressed archive. I have exactly bugger-all understand of file compression so if this is completely wrong I insist, please correct me.
Having looked into the folders was a trip through very unfamiliar territory. I am quite familiar with .dll files (or at least I became familiar with them 10/20 years ago when they were in everything,) but .cse, .cmap, .rws, .pc, .tm, .cmake, .amf, .la, .tcl - this list goes on. I expect many of these are setting related and things like brushes or presets, but having just hit the lecture about modular programming in my coursework, I suspect there are so many files because that was either the most efficient, or perhaps just the preferred way to do it. Using a myriad of individual files to cover code which could otherwise be contained within a single amalgamated file, allows contribution from as many creators, whose work may need to be added after any major program iteration is pushed. In the case of brushes for example, an approach like this is extremely suitable, because plug-ins, add-ons, features, and presets, and anything else which might expand the program, are typically peppered on as garnish for the main program throughout its lifetime. Looking at Blender again, their approach has been to build an affordance for community and 3rd party additions by way of the add-ons manager in preferences. Blender has a long and decorated history of extra bits being bolted onto it, and now instead of including all approved features, they just give you a big friendly list of check boxes so you can call up which modules you need per-project. At first I found it a bit silly, but if you don't need all that power just to make a simple box with a lid, its nice to have the program remain light as a feather.
I wouldn't be surprised to find that Inkscape does something similar in having a whole bunch of its code separate from the main running routines. If it only calls for the tools you're using at the time you click on it, the program is not forced to frequently and intelligently skip the functions it doesn't need each cycle. In visually massive projects with hundreds of objects, such behaviour in the loop would turn nanoseconds into microseconds, then seconds, and all of a sudden you're running too slowly to even minimise the program. PCs these days really spoil us for resources, but I'm sure if these techniques were not used in programming, we'd still be working at a crawl. For whatever reason we have so many files, I'm now certain there's an important reason for it.
Oh I see, I was just looking at the distribution files. If you're looking at the source code bundles, that would be many more files. It's normal to split those into small files with single units of responsibility in.
Beginners' Questions Curiosity about program file structure.
Inkscape.org
Hello to all.
I am finally upgrading from version 0.48 to version 1.2 and noticed something interesting/cool. As a matter of procedure I run all my downloaded programs through a quick scan before installation, and to my amazement I saw that the Inkscape installer contains 52,245 files! That suggests an astonishing amount of work has gone into this program.
My question specifically, is 'why' - or perhaps 'what are all of those fifty two thousand files doing?' I had no idea so much was going on in the engine room, and I'd like to understand (on a very basic level) how Inkscape approaches the task of image/vector/visual editing. I'm just beginning a programming course which has made me notice more details like this, and as soon as I saw how many files were in Inkscape I felt the urge to find out just how complex it is. (For comparison my Blender installation has under ten thousands files.) I can't help but feel awed by the development effort. Thank you all for the incredible dedication and contributions you've made.
I'd ask the developers: https://chat.inkscape.org/channel/team_devel
Just extract the installer files and have a rummage around.
The inkscape-1.2.2 install ZIP for Windows contains 13,000 files. The MSI seems to contain 15,000 files. Not sure where you're seeing over 50k files, but I haven't checked the other distributions.
When I did the scan it may have reported several thousand more files because I scanned an archive (before extracting the files), and perhaps many of the files were broken into several pieces in the compressed archive. I have exactly bugger-all understand of file compression so if this is completely wrong I insist, please correct me.
Having looked into the folders was a trip through very unfamiliar territory. I am quite familiar with .dll files (or at least I became familiar with them 10/20 years ago when they were in everything,) but .cse, .cmap, .rws, .pc, .tm, .cmake, .amf, .la, .tcl - this list goes on. I expect many of these are setting related and things like brushes or presets, but having just hit the lecture about modular programming in my coursework, I suspect there are so many files because that was either the most efficient, or perhaps just the preferred way to do it. Using a myriad of individual files to cover code which could otherwise be contained within a single amalgamated file, allows contribution from as many creators, whose work may need to be added after any major program iteration is pushed. In the case of brushes for example, an approach like this is extremely suitable, because plug-ins, add-ons, features, and presets, and anything else which might expand the program, are typically peppered on as garnish for the main program throughout its lifetime. Looking at Blender again, their approach has been to build an affordance for community and 3rd party additions by way of the add-ons manager in preferences. Blender has a long and decorated history of extra bits being bolted onto it, and now instead of including all approved features, they just give you a big friendly list of check boxes so you can call up which modules you need per-project. At first I found it a bit silly, but if you don't need all that power just to make a simple box with a lid, its nice to have the program remain light as a feather.
I wouldn't be surprised to find that Inkscape does something similar in having a whole bunch of its code separate from the main running routines. If it only calls for the tools you're using at the time you click on it, the program is not forced to frequently and intelligently skip the functions it doesn't need each cycle. In visually massive projects with hundreds of objects, such behaviour in the loop would turn nanoseconds into microseconds, then seconds, and all of a sudden you're running too slowly to even minimise the program. PCs these days really spoil us for resources, but I'm sure if these techniques were not used in programming, we'd still be working at a crawl. For whatever reason we have so many files, I'm now certain there's an important reason for it.
Oh I see, I was just looking at the distribution files. If you're looking at the source code bundles, that would be many more files. It's normal to split those into small files with single units of responsibility in.