- Let’s get that out of the road, right away. I am not here to prove anything to anyone. You are more than capable, given the content of your posts; the scripts; etc.
- This conversation is for heavy-duty users of OG, and the developers (who are not listening).
Very important point.
- What structure ? There isn’t any structure (unless they have a private definition of the word “structure”). It is a barf-bag of tag-value pairs. With massive duplication, data duplication as well as tag duplication. The plist file is massive. When they went from OG4 to OG5, the file quadrupled in size. OG6 is unusable, so I have not used it much, but on the face of it, the file size doubled again. Pathetic.
- The absence of (a) Structure, and (b) Normalisation of the structure, is the single greatest hindrance to the product, and to its progress (versions, features, etc)
- It is also the single greatest hindrance to all users who use it beyond a simple, one-page diagram.
The notion of simple but good-looking diagrams is partly Apple’s dictum, implemented in OSX and therefore partly Apple’s insanity. The idea of reducing OSX products down to the capability of iOS is backward and short-sighted, not surprising, given the schizophrenic CEO. The days of Steve Jobs are long gone.
But as far as OG is concerned, they simply do not appreciate the power of the product, and its utility. They do not have a long-term perspective or goal. OG just “progresses” in fits and starts, servile to OSX changes (fits and starts) and to the users who scream the loudest.
Second, OF and other products have taken over the front stage, and OG is severely neglected.
To understand what I am saying, it may be helpful to understand what a serious product with a long-term focus and commitment to heavy-duty use would be, so allow me to paint that picture.
- The central article is the database that contains the diagram (all objects; characteristics; vectors; etc). It is rendered (a) in memory, and (b) as the plist file.
- Since the date in well past 1970, it should be a Relational Database (Codd’s Relational Model, not the pretenders).
- That would allow any user to use the database, any way they want (ie. not restricted to the ways that Omni thinks that it might be used, which is myopic anyway). Scripts would be simpler, without the headaches, such as this example.
- The database (in both memory and the plist file) would have Structure. It would be the smallest footprint, the fastest. And therefore the product itself would have the smallest footprint and be the fastest (as far as data access is concerned).
- One of the cardinal requirements of a database is elimination of data duplication. One fact in one place. That eliminates a million or so problems.
- Second last but not least, one of the requirements of a long term focus is not removing features (OG4 features are removed from OG5). Therefore users cannot rely on OG features. A serious product would have backward compatibility. They don’t even know the meaning of that, let alone the relevance of that.
- Last but not least, after so many versions, the GUI should have settled down by, and should be more consistent. It isn’t. Just two egs of many: <escape> does one thing in one box and something different in another box; some dialogs require an <ok>, others don’t.
The problem is, each “development team” for each version treats the product as if they were building it for the first time, without reference to the previous version (which put Omni on the map). Each version introduces new and “interesting” problems and bugs that the previous version did not have. It is corporate suicide.
Instead of the above, we have a flat file with massive duplication, and all the problems that are consequent to the absence of Database implementation, the absence of Structure; etc
- The product is very slow once your diagram becomes complex, or goes beyond a few pages.
- Access to the objects (in both memory and the plist file) is crippled.
- Heavy duty use, or use beyond the notion Omni has for the product, is severely crippled.
From an OG5 diagram such as this:
Given as PDF
This example is Table-Key level, not completely Normalised, tiny (a real DM would have one hundred or more tables)
… with a few key strokes, I produce these:
(For completeness, the PDF with Export/IncludeNotes is:
Data Model mit Noten
PDF Notes do not work inside a browser, if you have the interest, download the PDF.
One has to open each Note indicator, but that is a PDF, not OG, limitation.
I trust you can imagine that I do something along the same lines using SVG for websites.
The problem is, the whole exercise is fraught with problems, due to the absence of a Database, of Structure.
- Eg. I have not cracked the connectivity of lines, so the Relations are primitive placeholders, which have to be manually cut-pasted from the separate entires. Therefore the Predicates and DDL are incomplete, one has to manually mess with their hair.
- If there were a Database, a Structure, the exercise would be straight-forward, and the Predicates and DDL would be complete, no manual work would be required.
- Note that you take an object approach (think in terms of objects, and what can be done from an object-centric position). Therefore your scripts are object-centric, and the scope of the products are thusly limited.
- Whereas I take a Relational or Set-based approach: I handle the entire plist file once, extracting all objects and their properties, and produce the three required files. (There is more, I am keeping this example simple.)
Just look at the TemplateChooser. Full of duplication, and therefore full of bugs. The absurd SharedLayers. Full of duplication, and therefore full of bugs. Instead of fixing the duplication, the product forces the user to reduce themselves to handling duplicates, a burden the Computer Science world was released from in the 1960’s.
Therefore, granted, OG has no structure, no database, and therefore the objects are difficult to deal with beyond their simplistic initial scope. From the example provided, I trust you can see, sure, it can be done, but it is severely hindered.
The notion you have for Notes/Satellites is an excellent idea. But it must be implemented, to work within those imposed parameters, and without either adding more duplication (and therefore more problems) or maintaining the products duplication (and therefore maintaining the current problems). It must be implemented without duplication. Here you have three copies of the Notes text. That is one original plus two duplicates. If you can implement it such that:
- the Notes appear in a satellite window,
- as a full Extension
- the Notes text appears once, in that window, and in no other windows
- that is the one-and-only place it is manipulated (ie. the user avoids the Inspector/Property/Note when usiing your Extension)
- the Notes appear in the diagram in the usual manner (wherever, and according to the set characteristics)
To be clear, when using your Extension, for each Extended Note, there will be one Satellite file that is dependent on the OG diagram file, in the same directory, named something like:
- either (a) a tag-value non-structure like the current OG Note, the current barf-bag
- or (b) a decent Structure of plist tag-values for a Note.
Then you will have a serious, feasible, Notes Extension.
Again, if Omni had a long-term product focus, if they appreciated the power of OG, this feature would be a part of the product, not an Extension by an advanced user. The notion of a central diagram, plus satellite diagrams, would raise the product up to the level required for serious use, to the level of a Design Tool (rather than a mere drawing tool), such as:
- a data modelling tool (Document = Export PDF/text, file plus Satellites)
- a website implementation tool (Implement = Export SVG, file plus Satellites).