This page is for developer notes they might want to jot down, so others can know what the heck they're thinking about.
Making an executable on Windows[]
I tested this right at the start of porting to Qt. Two things to watch out for:
- if you use Microsoft's Visual C++ rather than GNU gcc/mingw, read this: http://doc.trolltech.com/4.2/deployment-windows.html
- statically or dynamically linked
- if you use Microsoft's Visual C++ rather than GNU gcc/mingw, there's some option to remove dependency on mingw (if you don't, it didn't work outside of the Qt dos prompt). I can't remember what it was, but have a search for it.
Naming of the various 'Views'[]
The various different work areas of qpsycle are each suffixed with View, e.g. MachineView, PatternView, etc. This is not because they subclass QGraphicsView (because they don't.) It just ended up that way due to historical reasons. However! Each of the views tend to *use* QGraphicsViews, essentially as a canvas. So to avoid further confusion, these main drawing areas of the various views are called MachineDraw, SequencerDraw, etc.
Think of it as, for example:
- 'MachineView' maps to 'The top-level widget for the machines screen'
- 'MachineDraw' maps to 'The canvassy section of the machines screen'
Naming of various machine states[]
In the machine view, machines can be in various states. It's a bit confusing and could probably do with a rejig.
Being 'selected' refers to QGraphicsView's in-built selection code for GraphicsItems. A group of items may be selected at once (e.g. by rubberbanding, or by ctrl-clicking.)
Being 'focused' refers to QGraphicsView's in-built code representing which GraphicsItem has the keyboard focus, i.e. which one will handle the keypresses from the keyboard by default, if allowed to do so.
Being 'chosen' (maybe switch this to 'active'?) refers to qpsycle's way of deciding which machine should be dealing with keyjazz.
Some design niggles[]
Machine View[]
- NewMachineDialog is owned by machineview, and we may want to use it elsewhere.
- I can't remember why MachineScene handles keyjazz keypresses at the moment, but there was definitely a reason why I moved to there as opposed to in individual machines.
- MachineGui WireGuiList is just one list -- there's no separate list for inputs and outputs. Might not matter, might even be better as one list. Not sure.
- Feels odd that WireGuis add themselves to their parents' WireGuiList when they are created. The whole wiregui system feels badly designed really.
The Model[]
The idea behind the model is to have a layer of insulation between the Host and the data structures in the CoreSong.
Instead of having lots of places dotted around the Host that perform the same block of code with the Song, the Model can provide an API to the Song's data.
So, for example, the Instruments model provides access to the instrument data in the Song, and various places in the Host that need this data just need to query the model. (e.g. the sample browser, and the main window instrument combo box can both use the instrument model and avoid duplicating code.)
Most Qt widgets that display some kind of data can be loaded with a model, so we don't have to rewrite display code for each of them.
The idea is similar to DB access... rather than peppering your code with lots of (possibly DB-specific) SQL statements, you might use data objects or a data model. This way, if you ever switch from say MySQL to Postgres, say, you don't need to hunt through your code and update all the SQL statements -- you can just update the code in the model that accesses the DB.
Similar, this could work if psy4 format ever becomes psy5, or maybe for whatever reason we support some other formats.
-- <nmather>