Difference between revisions of "Grouping of geometries"

From apm
Jump to: navigation, search
(Massive improvements on intro and section == Heavily restricted functions ==)
Line 2: Line 2:
 
Up: '''[[Software trouble pages]]'''
 
Up: '''[[Software trouble pages]]'''
  
Grouping functionality for geometries like found in very many rastergraphic, vectorgraphic and 3D-modelling programs that have a graphical user interface and mouse interaction is (beside holding things together against accidental breakup) supposed to make the grouped things reusable.
+
The grouping functionality for geometries like it is found in <br>
 +
many rastergraphic, vectorgraphic and 3D-modelling programs which have <br>
 +
a graphical user interface and mouse interaction is supposed to make the grouped things reusable.
 +
(well and to holding things together such that they can be drag and dropped moved as a whole)
  
While this works for the very simplest cases the approach fails for anything beyond that.
+
While this approach works for "simple" cases the approach fails for anything beyond that.
  
 
The problems are that:
 
The problems are that:
  
* Groupings are crippled functions.
+
* Groupings are basically just heavily restricted functions.
 
* When duplicated groupings are often irreversibly detached from the original.
 
* When duplicated groupings are often irreversibly detached from the original.
* Groupings have usually no or broken inheritance.
+
* Groupings have usually no or awfully implemented inheritance.
  
== Crippled functions ==
+
== Heavily restricted functions ==
  
Groupings have a fixed set of parameters that all are implicitly hidden in most cases.
+
Groupings have a fixed set of parameters that all are implicitly hidden in most cases. <br>
Linear transformations: translation (insertion point), scaling, rotation, sometimes shearing.
+
The implicit parameters are usually only linear transformations applied to the whole grouping: <br>
Other transformations (programmatic in general not only continuous nonlinear like swirls and such) are usually not possible. Even less if one wants nontrivial changes where the same object may even have completely different looks (good abstractions ~~ high levels of [[data compression]]).
+
That is: translation (insertion point), scaling, rotation, sometimes shearing. <br>
 +
Other transformations are usually not possible. <br>
 +
Other transformations does not just meas simple weird (and rarely useful) nonlinear transformations like swirls and such but <br>
 +
General programmatic transformations changing specific details in specific ways on specific potentially highly nontrivial conditions. <br>
 +
Even nontrivial changes where the same "object" may end up with a completely different look. <br>
 +
(good abstractions ~~ high levels of [[data compression]]).
  
== Broken inheritance ==
+
== Awfully implemented inheritance ==
  
 
* Desired: semi manual backward update distribution ...
 
* Desired: semi manual backward update distribution ...

Revision as of 09:02, 11 October 2023

This article is a stub. It needs to be expanded.

Up: Software trouble pages

The grouping functionality for geometries like it is found in
many rastergraphic, vectorgraphic and 3D-modelling programs which have
a graphical user interface and mouse interaction is supposed to make the grouped things reusable. (well and to holding things together such that they can be drag and dropped moved as a whole)

While this approach works for "simple" cases the approach fails for anything beyond that.

The problems are that:

  • Groupings are basically just heavily restricted functions.
  • When duplicated groupings are often irreversibly detached from the original.
  • Groupings have usually no or awfully implemented inheritance.

Heavily restricted functions

Groupings have a fixed set of parameters that all are implicitly hidden in most cases.
The implicit parameters are usually only linear transformations applied to the whole grouping:
That is: translation (insertion point), scaling, rotation, sometimes shearing.
Other transformations are usually not possible.
Other transformations does not just meas simple weird (and rarely useful) nonlinear transformations like swirls and such but
General programmatic transformations changing specific details in specific ways on specific potentially highly nontrivial conditions.
Even nontrivial changes where the same "object" may end up with a completely different look.
(good abstractions ~~ high levels of data compression).

Awfully implemented inheritance

  • Desired: semi manual backward update distribution ...

(wiki-TODO: elaborate)

Microcomponents

In physical systems microcomponents could be seen as such groupings with all its detriments. But microcomponents are low level instances of a high level abstract software representation. Systems of microcomponents are compiled (decompressed) results of a high level highly compressed abstract software representation that does not suffer from the "grouping"-problem.
(TODO: More investigation is needed in the microcomponent-as-group-problem direction.)

Related