[Tracking] Refactor Progress

[hexabits]

For discussion and tracking of refactor issues.

Current Issues

#28 Qt 5 Port READY #36 FSEngine Refactor READY #31 Project Restructure READY #27 NifSkope.pro file cleanup READY

24 Separate UI display from logic

13 Settings Restructure

11 Revert change which undid separate registry settings per version

40 Installer make target (NSIS, or alternative)

41 Post-Qt4 Port: Code Review, Refactor

Todo Issues (Not yet ticketed)

• Code style cleanup
• Include file cleanup
• Code restructure

  Ideas for Discussion

• Refactor checkVersion() etc? They are currently not very user-readable. At the very least overload with string as parameter (e.g. 20.0.0.5) if not also having some kind of constants for the various game <-> NIF combinations.
• Coding conventions.
• Debugging conventions. I propose leaving the code cleaner by not using macros heavily (i.e. QT_NO_DEBUG) and instead leaving qDebug() where ever we please and opting to define QT_NO_DEBUG_OUTPUT or QT_NO_WARNING_OUTPUT for release builds in NifSkope.pro, which compiles away the debug statements.

  Completed

  1. Complete Qt 5 port. (#28)
  2. Refactor FSEngine. (#36)
  3. Restructure project code, simultaneously cleanup NifSkope.pro. (#31, #27)

     Roadmap

  4. Post-Qt4 code review and refactor. (#41)
  5. Separate UI display from business logic as much as possible. (#24)
  6. Restructure the menus, by taking Settings out of Render menu. (#13)
  7. Consider how to handle registry settings between versions. (#11)

[hexabits]

OK, so as far as how to progress with this, I believe that I'm going to make a series of branches, one which relies on the next, so that they can be merged to develop easily. I believe this is how this it'd work, but someone please correct me if I'm wrong.

Example:

git checkout -b qt5 dev git commit -am "Initial Qt5 Port" git checkout -b qt5-restructure qt5 git commit -am "Work from Issues #31, #27" git checkout -b qt5-ui qt5-restructure

... And so on. (Obviously I do some work between checkout/commit. :))

That way either branch-by-branch can be merged into the develop branch OR the entirety of all the work can be pulled in by merging just the last branch.

Right? Or... I could just do the series of change in one branch, but I don't like that idea for whatever reason.

[neomonkeus]

It really depends on whether or not you want the original branch merged in first or want to way for all the sub parts to be completed, i.e have your qt5 branch, makes changes, use that as a base for branching other features and then merge them back in.

If feature B needs feature A, local branch merging is fine but the faster things go to develop the quicker the turn around is with review & getting test builds out.that feeling you are getting there is the git merge mentality ;P

[hexabits]

I've created qt5/master, and my first branch is qt5/pre-port which will consist of all the forward compatible changes I can make while still using Qt 4.8.

I will then probably:

1. Merge qt5/pre-port back into qt5/master.
2. Create qt5/fsengine and qt5/opengl. Not sure of the order yet. I will break compatibility with Qt 4 by stripping out GLee and using native Qt wrappers, which were new in Qt 5.

[neomonkeus]

I think that we should probably start into it as it would be nice to get some of your awesome updates into @niftools nifskope/develop.