Redesign and clean up GUI architecture
As of now, most GUI logic is part of the MainWindow and scattered across several widgets. This is no good. Program logic should be separated from the view whenever possible. While EgS currently implements the MVC pattern for the bufferviews, we should do the same for the whole of the GUI. This also makes sense in case we'd like to add another GUI at some point, maybe a port to KDE or even a text-based UI. Having most or ideally all of the GUI's program logic separated from the actual widgets should make things considerable easier.
The proposed way of doing this is to use a separate GUI class (similar to what we have in Core) which contains the proxy, the nicklist, buffers etc. The MainWin as well as the other widgets should only contain interaction and display code.
Part of this redesign is also to move the nicklist to the MVC pattern, meaning that we store the nicks in the GUI class and make the individual nicklist widgets views on that model. Which is not too far from what we have now, but we could make this cleaner using Qt's MVC features.
And oh yes, we need real singletons. And I'd like to get rid of three different main.cpps, global pointers and variables etc. pp. So there is much work to do, which I will start as soon as EgS' MVC stuff has made it to SVN.
- Architecture changes mostly complete:
- Core has been split in Core (static) and CoreSession (per-user objects)
- Connection stuff has been moved out of CoreProxy into Core
- Lots of cleanups, and we have finally real singletons!
- Global is now (externally) a static class -- changes throughout the code
- Monolithic Quassel works (or at least it seems to)
- Standalone Core and GUI disabled for now:
- While most of the new infrastructure is in place in Core, we still need GUI stuff for auth (BR #17)
- Syncing with Core as well as getting session states not done yet
Next steps will include the redesign of the GUI to make that cleaner as well (BR #41)
#1 Updated by EgS over 16 years ago
as an ugly (jeah I know... I was lazy...) workaround I currently pass the mainwin itself as parent to the BufferTreeModel. The reason for this was the possibility to create a QMessageBox easily.
bufferviewwidget.cpp Line 338:
tr("Do you really want to merge the following Buffers?<br />%1.%2<br />%3.%4").arg(sourceBuffer->networkName()).arg(sourceBuffer->bufferName()).arg(targetBuffer->networkName()).arg(targetBuffer->bufferName()),
QMessageBox::Yes|QMessageBox::No) == QMessageBox::No)
This should be taken care of in the context of this BR. (I don't mind Putting that MessageBox somewhere else...)