Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


Attributes in 0.9.0

  • Currently all values added or changed  at any time in the creation process of the map are stored. This possible increases the amount of data stored although no value is changed. (Imagine the use of attributes as script holders). Proposal for the final release: do only store the current values of the attributes.

    I want to specify the requested behavior more precisely:

    1. In order to remove a name-value pair from the attribute registry I
    should maintain a counter which should always be changed whenever the
    attribute or its value is edited or nodes with attributes are created,
    deleted, inserted or cut. I could implement it if you need it.

    2. In case of restricted attribute values I would not remove the value
    from the list, even if attribute is not present in a map any more

    3. Currently there is an "import" functionality which allows importing
    of the attributes from the other opened maps. Because all new attributes
    are imported with the restriction, this functionality does not need to
    be changed.

    4. Removing the restriction from the attribute list should consequently
    cause removing of all attribute-value pairs not present in the map (with
    the counter equal to zero) from the attribute registry.

    But I just have one further question: I think that introducing of the counter can affect the performance of all cut&paste - operations with many affected nodes. I do not know if the user would notice it.

    But alternatively I could a new attribute property so that the attribute values for such attribute would not be registered at all. I do not know if you are interested in having statistics for all script based attributes you have in the map. So let us continue the discussion in the open discussion forum, I am starting a new thread for it.


    • Dear Dimitry,

      the counter sounds to complicated to me regarding the cases you specified above.

      Another idea would be, to rebuild the database of values to store before saving.
      Then, you can omit the counter.

      What do you think?


      • I prefer the counter-based solution. Rebuiding the "database" in every autosave is not better.


        • Eric L.
          Eric L.


          wouldn't it be possible to only rebuild the database for explicit saves, and not for autosaves?
          My understanding is that the resulting autosaved file might have too many attributes saved, but this would be cleaned up at the next explicit save.

          My 5c.


          • Hi Dimitry and Eric,

            I prefer the rebuild-only-on-save variant, too. For automatic saves, just save all values.
            Advantages are, that the solution is easy to implement, understand and to maintain.


            • The easiest way to achieve what you want is not to save the attribute registry for attributes with not restricted values at all, as it is automatically rebuild on loading. This change is very easy to do, I can implement it very fast. Should I perform it?


              • I have commited the change to CVS.

                • Hi Dimitry,

                  thank you. Great.


    • jcd

      Hello All,

      Just a question : Wouldn't it be interesting to have the "assign attributes" item appearing in the 'right-click' menu of a node ?

      Best regards,