realXtend / tundra

realXtend Tundra SDK, a 3D virtual world application platform.
www.realxtend.org
Apache License 2.0
84 stars 70 forks source link

Source folder restructuring #750

Open Stinkfist0 opened 10 years ago

Stinkfist0 commented 10 years ago

Suggesting that the current contents of the src folder

Core\
    Math\
    Tundra\
    TundraCore\
    TundraConsole\
    OgreRenderingModule\
    ...
Application\
    EnvironmentModule\
    ...
(TundraAddons\)
(MyPlugins\)

would be restructured (tentative sketch, better suggestions welcome) as follows in order to more distinguishly separate the "heart"/core of Tundra, the Tundra application executables, and the core- and application-level dynamic plugins:

TundraCore\  (dll)
QtApplication\ (lib containing the Application singleton class)
Tundra\ (the default Tundra executables)
    Tundra\
    TundraConsole\
Plugins\
    Core\
        OgreRenderingModule\
        ...
    Application\
        EnvironmentModule\
        ...
    (TundraAddons\)
    (MyPlugins\)
Tests\ (maybe could have such projects at some point?)
    Test1\
    ...
Tools\ (maybe could have such projects at some point?)
    SomeTool\
    ...

Math lib omitted intentionally as it would be in the deps folder ideally.

cadaver commented 9 years ago

TundraCore, Tundra, Plugins separation at the root level looks good.

If Core / Application split inside Plugins is not essential, that could be removed, implying that all plugins contained in the base Tundra repo are considered "core".

antont commented 9 years ago

certainly having some kind of notion of a small clean tundra core is useful, i figure all agree there. but regarding plugins, at least before the separate TundraAddons repo we certainly had many non-core (but still nice and useful) plugins in the base repo. looking at this list, i think that's still the case:

    { "--plugin" : [ "OgreRenderingModule",
                     "OpenAssetImport",
                     "SceneInteract",
                     "EnvironmentModule",
                     "PhysicsModule",
                     "TundraProtocolModule",
                     "ECEditorModule",
                     "JavascriptModule",
                     "AssetModule",
                     "ArchivePlugin",
                     "AvatarModule",
                     "SkyXHydrax",
                     "OgreAssetEditorModule",
                     "DebugStatsModule",
                     "SceneWidgetComponents",
                     "MumblePlugin",
                     "CanvasPlugin",
                     "WebSocketServerModule" ]
    },

e.g. Mumble and SkyXHydrax are not the kind of core that Tundra doesn't work without but optional .. which is ofc what 'plugin' means. if we say that the ones in the main repo are kind of official supported & maintained etc., even if not enabled by default in all distros etc. after all that's what people sometimes mean with 'core' too.

Stinkfist0 commented 9 years ago

It could be nice to migrate some of the good (or half-decent) and working application/non-core plugins to TundraAddons in order to not make TundraAddons a complete graveyard, but having people checking it out more frequently.

OgreAssetEditorModule, OpenAssetImport, SceneWidgetComponents, SkyXHydrax, AssetInterestPlugin, MumblePlugin could be at least considered for migration. ArchivePlugin's functionality could be merged to be part of TundraCore. WebSocketServerModule will be gone maybe some day when kNet has WebSocket support.