Sometimes this feature is needed badly.
Especially, AND operator (or intersection), since OR is there as a trivial overlapping of shapes with the same orientation while opposite orientation yields XOR-ish (only for two shapes - and effectively unachievable for odd number of them).
"Boolean" approach as-it-is seems to be incompatible with the current paradigm of the program.
Below I suggest limited version of the former which will not contradict the latter)))
Consider two overlapping circles (i.e. classic Venn diagram). Windings do not matter! The idea is that a boolean operation creates new independent shape (or shapes) - result of operation while destroying the operands (or shapes-"parents"): AND operator on them will yield a shape that was the overlapping part, OR is practically the same as overlapping while keeping the same orientation and then combining the shapes, XOR will produce two independent moon-like shapes as they have in common only one point. (It's fun to think about result of such XOR on three circles arranged in Venn diagram). This approach will solve potential problem of "ghost" shapes, when shapes don't intersect but AND is applied to them and they supposed to be... invisible? In my approach AND would produce no shape in this case as the "parents" would be destroyed after the operation. It also will allow users create exotic and beautiful shapes naturally.
I hope dev will revisit the request
As I get it, you mean "borders" of a shape, the path, and the feature being ability to work with it only and without black fill effect. If I am right, then this is great an idea. So many problems with lining shapes up will dissappear. Also would be great to on/off the feature. Sorry for breaking language.
Admin, it depends. I could think of three alternatives:
1) (You suggested, unlikely) To add images to txt-file. Consider an extreme case when every unique character has a background image. If the latter are HQ increase in the size of the save file is unavoidable. If they are compressed converting them may cause additional problems. That also would ruin the aesthetic of the current code-like format.
2) (You suggested, better then nothing) To upload images every time one reopens a project. This is more preferable if you want to stick with txt format. But doing it every time would be unhumanly boring and might look like incomplete a feature. Pro: format remains transparent.
3) (My idea, somewhat crazy) To create new (adapt existing) container fileformat for project. This will be a challenge (read: headache) to figure out and program. Will it pay out? Container can still clean instructions (as in current save file) as well as visual information and smth else - who knows what features will appear in future development? - this format likely will allow you to add them from time to time. But... yeah - bye, transparency.
This is it. Other ideas (to store images and txt-instructions in indepedent files, to put links to images to code in form of full path to them on computer) don't seem to be rational to me.
The last word is yours))Марсель Ишимбаев shared this idea ·
This would be great! It is a mystery to me why hangles (pardon my french) are still read only.