Skip to content

Latest commit

 

History

History
153 lines (117 loc) · 4.17 KB

Refactoring.md

File metadata and controls

153 lines (117 loc) · 4.17 KB
Raw

qTox refactoring Plan

List of the modules (should be a subprojects)

Model module

Added:

  • Friend (moved from non-module)
  • Group (moved from non-module)
  • FriendList (moved from non-module)
  • GroupList (moved from non-module)
  • Message
    • TextMessage
    • FileTransfer (from ToxFile)

Core module

Will interface with c-toxcore

Added:

  • toxsave (moved from persistence)

Removed:

  • RecursiveSignalBlocker (moved to non-module stuff)
  • coredefines.h (kill it)
  • indexedlist.h (kill it)
  • cstring.h (kill it)
  • corestructs.h (move ToxFile to FileTransfer, make DhtServer it's own class? agree @sudden6 @Diadlo)

Old:

  • ToxId
  • ToxPk
  • ToxCall
  • CoreAv -> 'ToxAv' ?
  • Core -> ToxCore (name clash?)
  • CoreFile -> ToxFile

Widget module

Contains all the user interface stuff

Rename module to 'ui'? (agree: @sudden6 @Diadlo)

Submodules:

  • dialog (QDialog inheritance)
    • SetPasswordDialog
    • AboutUser
    • ActiveDialog
    • ContentDialog
    • LoadHistoryDialog
    • FriendRequestDialog
    • RemoveFriendDialog
  • form (GenericForm inheritance)
    • Settings
  • layout (QLayout inheritance)
  • widget (QWidget inheritance)
  • utils (usefull parts used throughout the ui) (agree @sudden6, against @Diadlo (IMO, should be moved in widget module root))
  • chatlog (Moved from src root)

Audio/Video module

Provides qTox audio input and output and notification sounds, provides Video input and output

Has to interface with:

  • toxav
  • platform
  • widget (for video display)

Network module

ToxMe

AutoUpdate

Persistence module

Most part of this module should have one instance, which should be injected in other classes (see Inversion of control) How do we handle qTox upgrades? (how it handled now?)

Settings:

What about using macros here (not everywere)? Example: SETTINGS_PROPERY(name) -> void setName(T name); T getName(); Q_PROPERTY(...)

  • Settings interfaces:
    • I[Global]SettingsGeneral
    • I[Global]SettingsUI
    • I[Global]SettingsNetwork
    • I[Global]SettingsAudio
    • I[Global]SettingsVideo
  • Settings implementations:
    • SettingsFile
    • test/SettingsFake
    • SettingsDb (for the future it would be interesting to store non global settings in the DB)

History:

  • IHistory
  • class DBHistory : public IHistory

FileTransfers:

  • IFileTransfers
  • class DBFileFransfers : public IFileTransfers

DBStorage VS Separate implementation (??):

We can have one DB provider, which implement all persistence interfaces. Or many DB providers, which implement own interface (see above)

Example: class DBStorage : public IHistory, public IFileTransfers

Platform module

Non-module

Removed:

  • Nexus (should be replaced with DI)

Old:

  • RecursiveSignalBlocker
  • IPC
  • main.cpp

Timeline (milestones?)

Only specifies the order, not definite times

  • complete cmake transistion
  • somewhere should be "merge ui/redesign" (WIP by @Diadlo)
  • make module == subproject
  • reorder the files, as defined above, no code changes yet
  • define Interface for Core, ie create clean Header files
  • implement the new Core interface step by step
  • create unit-tests for Core
    • setup tests with ToxId as example
    • setup tests with ToxPk
  • create SettingsInterface
    • port from the existing settings implementation
    • implement test/FakeSettings (to use it in tests)
  • start the UI stuff