The future of the Art of Illusion Project

Luke S
1 2 > >> (Page 1 of 2)
  • Luke S

    Luke S - 2016-09-04

    Hello to everyone in the AOI community.

    Peter recently reached out to me regarding the future course of AOI as a project. As you may have noticed, development on Art of Illusion has been at a slower pace of late. We've discussed some possible changes with the goal of making the project more self-sustaining, and thought it would be best to lay them out to the community before committing to anything big.

    Currently, Contributing to AOI is a rather manual process, involving uploading new or changed files here on the forums for review and integration to the project. This is a bit cluncky and old-school, especially since there are good, well established alternatives.

    Proposal: We're considering migrating the AOI source repository from SVN to the git version control system. This system is designed with features that facilitate cooperation between widely spread and ad-hoc teams, and should streamline the process of getting new contributers' work reviewed and integrated. It allows persons who do not have access to change the code repository directly to make a "Pull Request" that is simple to track, and to update if other changes are made before the request is reviewed.

    I've also noticed that Sourceforge is a quieter place these days, in terms of developers that might be looking to contribute, even in a small way, to a cool project.

    We want AOI to be visible to such people, and we want an easy path for others, who may be using AOI in concert with other projects, to help us improve their pain points.

    Proposal: We're considering setting up a presence on Github, for the source repository. Github is an industy standard site for open source software code repositories, with a large user base, and an interface that is focused on making contributing to a codebase quick and easy. It, of course, would require that the repository would be hosted in git format. Open for discussion is whether github should be the only source repository, or if we shoud keep an up-to-date version synced on Sourceforge. If the source repository is Github only, it would make sense to migrate our bug tracking and feature requests to the github systems.

    If we go through with this step, the binary file downloads and the discussion forums here would stay in place and remain the main way for the AOI user comunity to interact, at least for the forseable future. We would still accept bug fixes, new features, etc. as uploaded files, but anyone who knows how to use the git systems would be encouraged to do a pull request.

    We're also looking at the release process. We've seen a lot of good bugfixes and enhancements wait a long time for a new release, partly because the release process takes human intervention, and some effort. We're considering automating parts of it, and Peter may end up deciding to delegate the day to day running of parts of this process.

    Peter said that he would chime in later with his comments. Any feedback on the ideas, concerns, questions, or suggestions are welcome. We're also looking for ideas on how to engage people that would be interested in helping update the website to an extent, etc.

    To keep this thread on track, please stick to thoughts regarding how the project is organized and set up. Specific feature requests or discussions are welcome, but they belong in other threads.

    Last edit: Luke S 2016-09-04
  • Peter Eastman

    Peter Eastman - 2016-09-04

    Thanks a lot for getting the discussion started! I've been using github for a few years for the projects I develop for my job, and it definitely reduces the barriers for people to contribute. Anyone else have thoughts on it?


  • Martin Häcker

    Martin Häcker - 2016-09-04

    Do it, github is great.

  • Nathan Ryan

    Nathan Ryan - 2016-09-04

    Great idea.

  • Peter Eastman

    Peter Eastman - 2016-09-04

    Sounds like we have a clear answer! I suggest we just completely migrate the repository over to there. Maintaining two different repositories seems like an unnecessary complication, and I don't see any benefits from doing it.


  • Luke S

    Luke S - 2016-09-04

    That makes sense to me. Do you think it would also be best to use github's issue traccker in that case?

    Last edit: Luke S 2016-09-04
  • Pete

    Pete - 2016-09-05

    Hi. This occured to me this morning. (A good night's sleep does help!)

    This might be now an opportunity to make some adjustments to the practices otherwise too.

    First coming to mind, that some plugins are missing their latest source files -- those that are no longer updated probably will be in future too -- but at least the active ones.

    Second, that the add on pieces could be more clearly divided into groups, that could be something like 'recommended', 'experimental', 'special case tools' or maybe something else with even deeper "analysis" like 'modelling tools', 'userinterfase modifiers'.... Currently the situtation can be more or less confusing especially to a newcomer and if you just download everything, there will be conflicts and the usability will change in ways you did not expect or wish.

    I'll be the first to admit, that the later case would not necesarily be an easy job to do and people value things differently. The good thing is that at least most of them come with a description of, what they do and things with AoI seem to me a nudge or two clearer than for example with GIMP or Audacity the last time I checked. Somehow I'm still wishing that the jungle could be made easier to navigate. -- How about a simple search tab, with a couple of button groups and/or filters for the categories I mentioned?


  • Pete

    Pete - 2016-09-05

    A further thought:

    First coming to mind, that some plugins are missing their latest source files -- those that are no longer updated probably will be in future too -- but at least the active ones.

    It probably can't be set a as requirement, that all plugins shoud be open source? People might have different reasons to publish their work, but keep the source undisclosed. In that case, I think, it'd be good practice to let it be known if something is OS or not and then publish or not the source accordingly. That means, that there should be a check-box type mechanism to handle it.

    I don't know if the software world already works that way? -- My head has a very mechanical history. :)

  • Luke S

    Luke S - 2016-09-05

    @Pete Thanks for bringin up the plugin repository. It would be nice to improve things here as well, and In the long run, that would be a natural extension of what we're currently planning.

    We should consider re-compiling all the plugins on every release, just to ensure compatibility.

    Most of the plugins do have available source, its just not under version control. I'd prefer, though, to get the AOI Core repository set up smoothly first, as there are some technical considerations about how to set up for the plugins - not a simple, clear cut best way to do that.

    Better sorting of the plugins, and better description of their development status, would be nice, but that's slipping over into feature request territory.

    I don't know if we currenlty have any non-OSS plugins. I'm also not sure what the best way to handle them would be, but there should be a way for their license to be presented to the user. Also in the feature request category.

  • TroY

    TroY - 2016-09-05

    I don't know if I ever linked to this, so I'll just leave this here: Source files of my plugins, some of those are in the plugin repo. I've long stopped developing these, but, yeah, that's the source.

    As for Git and GitHub: Do it. :-)

  • Peter Eastman

    Peter Eastman - 2016-09-05

    I think that all plugins hosted in the main repository should be open source. People are certainly free to create closed source plugins, but if they do I think it's up to them to distribute those plugins themselves. Unfortunately we don't have the source for all the existing plugins, but I think it would be good to collect the source for as many of them as we can, and then moving forward make it a requirement for all new plugins.

  • Pete

    Pete - 2016-09-05

    to get the AOI Core repository set up smoothly first

    Absolutely. First things first. :) -- I guess it comes with the day job, that I sometimes don't notice myself, that I'm thinking in much longer timescales than the rest of the crew. I know there's a lot to do with some of those things and also that it was just a sketch of an idea. Still something to get on to, when the time comes.

    I think that all plugins hosted in the main repository should be open source.

    Sounds right to me to keep it simple.

  • Luke S

    Luke S - 2016-09-06

    Okay, there is now a github repository for the AOI core project:

    Looking forward to interacting with everyone there!

  • Nik Trevallyn-Jones

    While we're on the GIT topic:

    My plan for the plugin manager v2 was to use a GIT server for the plugins themselves.
    The primary feature was to use GIT to manage the different versions of the plugin JARs themselves.

    To avoid the problems where a plugin developer pushed a new version of the JAR but forgot to push a new version of the source, we could set the backend up to either:

    • require that the source be pushed before the JAR can be pushed
    • build the plugin jar from source, on the plugin repository server itself.

    There are Java GIT clients eg JGit that are sufficiently feature complete to accomplish this.

    And while we're on the topic of the plugin manager, the original plan for V2 was to rename it the "Librarian", and make it handle any type of payload - plugins, textures, materials, scene rigging, prefabbed objects, etc.

  • Luke S

    Luke S - 2016-09-07

    Interesting information, Nik, and certainly worth considering. When we get there, I think we'll want to build all plugins from source. I know you and I had talked about a couple of different ways of setting this up once. Based on some previous experiences, it might be best to try to rebuild all plugins at every release....

    TroY, thanks for the link. We'll keep that in mind when the time comes.

  • Peter Eastman

    Peter Eastman - 2016-09-07

    Thank you! Can you add me to the organization? My user ID is peastman.

    Using git as a backend for plugin storage is an interesting idea. We would need to be careful about how we managed it, since the repository could quickly get huge with old versions of jars. The important thing is that it should only contain "released" versions of plugins, not intermediate ones. But I can see how it might work.

    Of course, if we also start putting textures and the like into the same repository, that could easily get out of hand. Git is not a good VCS for storing large amounts of binary data. SVN is a lot better for that.

  • Luke S

    Luke S - 2016-09-07

    Done. You should get the github notification soon, if not already.

  • Stephen Parry

    Stephen Parry - 2016-09-07

    For my tuppence worth (I am British) - git and github would get me contributing more. Also, I wasted a lot of time recently too because I couldn't find the source for one of the plugins - so I think it's important we gather as many as possible, including the ones that are currently 'broken'. That way people like me might actually try to fix them!

    On 'gitting' assets etc, my other fave project is Fritzing - they have just started to use github to host the parts catalog and they are getting some good contributions there. The latest Fritzing checks the repo every time you start the program and automatcially pulls any new parts. Contributors do pull requests from a fork of the repo. They have a great guy doing the quality control on the pull requests. It is not good for novice users (they use the forums), but for serious contributors it means they can get new parts out to the whole community near-instantly. Fritzing parts are mostly xml (+svg) so that does help.

  • Luke S

    Luke S - 2016-09-22

    A little update for those interested:

    We just got our first pull requestes from someone outside of the existing AOI community. Some good code cleanups and updates, which should make maintenance a little easier.

    We (or at least I) also learned some practical lessons about maintaining a repo. Some changes grew out of that which shold also improve maintainability.

  • Pete

    Pete - 2016-09-22

    Anything on how the menus are managed?

  • Peter Eastman

    Peter Eastman - 2016-09-22

    Which menus?

  • Luke S

    Luke S - 2016-09-22

    Nothing quite that high level. More stuff like making sure that all methods that override a superclass method are annotated with @overrides, unused imports are removed, etc. Maintainability from a code readability statndpoint. Sort of like cleaning up a rough draft. For details, please check out the pull requests list on github. If you have any insight, feel free to chime in.

    @pete, I'm going to suggest that you open a new discussion under 'developers' to plot out how an improved menu management system would look. In particular, what the API should look like to the plugin developer.

  • Pete

    Pete - 2016-09-23

    methods that override a superclass method are annotated with @overrides, unused imports are removed, etc.

    Sounds like something that was probably done by a script or some kind of a clean-up/check-up bot.


    At this point I'll just make a short comment here. This is a by product of the view manipulation project.

    Generally speaking the parts of the software that are launched by menuitems in a menubar seem to be communicating with the location of the menu and/or the menuitem. That is OK as long as the locaton is not changed but some functions stop working if the menuitem is moved under a different menu. -- So the idea would be to change the thinking so, that each function would be communicating directly with it's own menuitem rather than the location.

    It's a lot of work and it may be hard to see the benefits, but as I recall, it was something of this sort that eventually got me renewing the DisplayModeIcons. And lately (I believe, this is not a very old feature) on the scene window API there are methods for "getToolsMenu()" and so on, which already seems to be a step into facilitating further development.

    EDIT: Ideas are starting to pour in... But this also needs some bacground study and I'd need "git myself up" first..... :)

    Last edit: Pete 2016-09-23
  • Luke S

    Luke S - 2016-09-29

    @Pete: You're probably right about many of those changes being suggested by tooling. (I suspect the person's IDE has a hints mode) Some of the changes were certainly well taken, though.

    Having a full, in-depth understanding of git is not necessary to interact and contribute with a github project. Github itself has an excellent set of beginner tutorials at, (Check the bootcamp section) and pretty much anything you might want to do with a repository has step-by-step instructions embedded in the site itself.

    If anyone is trying to get set up, and runs into issues that you can't solve with google or the git documentation site, (Don't forget their online book! feel free to ask for help here, or if you have an issue working with a fork/pull request on github, @mention me in your githb comments. (I'm Sailsman63)

  • Luke S

    Luke S - 2016-09-29

    Question for the comunity regarding Bug reports and feature reqeusts:

    What would be teh most convenient way for you to make the project aware of your own bug or feature requests?

    • The existing bug and feature trackers here on Soruceforge? (Currently requires a sourceforge sign in)
    • Github issues? (Requires a github ID)
    • Other?

    One thing we don't have set up at the moment is an option for anonymous users to report bugs or features. The SF trackers are capable of this, but the functionality is not activated (I believe that there was a spammer targetiing the trackers at one time, and was blocked this way)

1 2 > >> (Page 1 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks