Recent Posts

Pages: [1] 2 3 ... 10
1
Hi,

Quote
Could we consider Hervé's "specialization plugin"  as a contribution ?

Partly only. This is a (very useful) contribution to the Archi community. But this is not integrated into Archi because it lacks integration into UI (and designing a user-friendly UI is difficult and takes time). It is also mainly a hack and cannot be used in a multi user context (images are not saved inside the model so every and each people in a team have to set it up) and cannot be used in HTML reports (reports will use default icons) which doesn't make it useful for most communication purposes. Again, this is a very interresting plugin (as all Herve's plugins) which main interrest is to test new use-cases.

Quote
- the wiki page you're talking about is not listed on the main github wiki page (https://github.com/archimatetool/archi/wiki ) , it may then be difficult for people to know about it

In fact it is: you can see it as others pages in the sidebar.

Quote
the fact that there are discussions both here on archimatetool.com  and on github does not make things easier, especially for people like me who are not regular visitors

I agree, but that's not simple to manage. Both places (forum and github) have their pros and cons. We're open to any suggestion to improve this.

Quote
- maybe making it clearer what contributions could be made will make it easier for people to help, according to their skills and/or availability : would donating money help ? Or writing more specifications ? Writing a plugin ?

People willing to help can help us sort out issues and write specifications for key features. This is the first step to share potential future for Archi. This would then allow people to comment or vote on this "roadmap". But the next step is clearly to code things and this means either code contribution (which requires some time to get familiar with underlying frameworks) or money (if someone doesn't want to wait for an important feature).

Other plugins are also great of course...

Regards,

JB
2
Could we consider Hervé's "specialization plugin"  as a contribution ?

A few more thoughts Jean-Baptiste :
- the wiki page you're talking about is not listed on the main github wiki page (https://github.com/archimatetool/archi/wiki ) , it may then be difficult for people to know about it -  the fact that there are discussions both here on archimatetool.com  and on github does not make things easier, especially for people like me who are not regular visitors

- maybe making it clearer what contributions could be made will make it easier for people to help, according to their skills and/or availability : would donating money help ? Or writing more specifications ? Writing a plugin ?

Cheers


3
Hi,

Some time ago I took the time to clarify our vision on how to do it so that people interrested can contribute. This is done on the wiki.

6 months after, nobody contributed (as usual I'd say)...

JB
4
"The relationships that can be used in combination with a junction are all the dynamic and dependency relationships, as well as assignment, realization, and association."

So whatever the source or target is, we should never have composition, aggregation, specialization or association to or from a Junction.

JB
5
That sounds like  :  it's not gonna happen anytime soon  : -)

There's one developer - me. I'll cancel my weekend and get onto it right now.   ::)
6
That sounds like  :  it's not gonna happen anytime soon  : -)
7
The whole rendering of figures needs to be refactored completely. A lot of things need to change first for this to happen.
8
It would be cool to be able to use custom icons on data objects  with hervé's specialization plugin.

I understand this is not possible at the moment because "data objects" (and some other archimate elements) have no icons in archi : maybe archi could use "void" icons instead  of no icons : a 1x1 pixel png image with transparent background for example.

This would change the display of existing models, but we could use tthen custom icons on such objects.
9
We currently allow a Grouping concept to connect to a target Junction as:

<target concept="Junction" relations="acfginortv" derived="" />

Allowing Aggregation and Composition relationships means that a Junction can be part of a Grouping? Should we remove them?
10
So, when a Junction is dragged into a container concept, these relationships should not be offered?
Pages: [1] 2 3 ... 10