how do you use MV in Qt? I've tried these two approaches:
If there is an existing/legacy
code "data"-classes, I use model
as a facade. The
Model-implementation class gets a
reference to data, and calls its
functions on model-item access
calls.
For new implementations I derive
the data class from QAbstractModel.
Is there any other way you do it?
The approach I ended up taking is similar to the one you suggest. I am currently using a facade to map between my legacy data model into the QAbstractModel.
At first the facade was a bit too complicated, but slowly I am pulling functionality out of the facade model and pushing it into my data model. And then one day I will remove the facade completely so that my model is THE model.
Having a single model will make my head hurt less.
The MV-code in Qt is a bit messy and feels arkward to implement. Especially if you have to implement hierarchical lists (tree views).
Depending on your need I found that using the QListWidget, QTableWidget and QTreeWidget convenience classes can be much less painful in some cases.
Related
I'm working on a small Django project and I noticed there are different ways to write a view.
What's the difference between a view created with a class and a view created with a function?
When should I use which one?
Thanks!
It has all the same differences that are between Procedural Programming and Object Oriented Programming. It makes sense to write functions for extremely simple views, but not beyond that. There is nothing worse than stuffing 400 lines of code into one big function called view, which becomes a nightmare to read, refactor or test.
In addition to that, Django generic views exploit Template Method design pattern and provide a lot of already written common code for generic use cases, which can often be easily extended to one's needs.
The most important advantage of using a class based views is inheritance.
When working on a big projects, its highly possible to come across multiple views which have similar use, hence you can inherit a class based view to write a new more specific view which is custom to the required method, or you could just reuse the already defined view as is if it serves the purpose.
Generally the function based views are used when the class based views become too complex to implement.
If you are working on a small project you could just use function based views as it will appear to you that the class based views are little more painful to write (At least i felt like it).
I've been trying to figure out the approach to take to allow a JavaFX TableView (or any other JavaFX thing) to represent some Clojure data, and allow the user to manipulate the data through the GUI.
For this discussion, let's assume I have a list/vector of maps, ie something like
[{:col1 "happy1" :col2 "sad1"} {:col1 "happy2" :col2 "sad2"}] and I want it to display in a graphical table as follows:
mykey1 mykey2
------------------
happy1 sad1
happy2 sad2
Pretty straightforward. This has been done a gazillion times in the history of the world.
The problem is the TableView insists on taking an ObservableList, etc., which is inherently a mutable thing, as are all the Observables in JavaFX. This is great for keeping the table up to date, and in a mutable model, it's also great for allowing the user to directly manipulate the data via the GUI. I'm not an expert, but in this case it seems JavaFX wants the GUI object to actually contain the real data. This seems funny (not ha ha) to me. To maintain my own model and communicate between GUI and model via some API or interface also implies that I'm maintaining the data in two places: in my own model, and in the GUI. Is this the Correct Way of Doing Things? Maybe this is ok since the GUI only ever displays a small fraction of the total data, and it lets my model data just be normal model data, not an instance of some Java-derived type.
So this leads to the following three general questions when trying to put a GUI on a stateless/immutable model:
How can the model underneath be truly immutable if the GUI necessarily allows you to change things? I'm thinking specifically of some sort of design tool, editor, etc., where the user is explicitly changing things around. For example LightTable is an editor, yet the story is it is based on immutable data. How can this be? I'm not interested in FRP for this discussion.
Assuming at some level there is at least one Atom or other Clojure mutable type (ref/var/agent/etc) (whether it be a single Atom containing the entire in-memory design database, or whether the design database is an immutable list of mutable Atoms), which of the [MVP, MCP, MVVM, etc.] models is best for this type of creation?
JavaFX has littered the class hierarchy with every imaginable variation of Observable interface (http://docs.oracle.com/javafx/2/api/javafx/beans/Observable.html), with such gems as Observable[whatever]Value, including for example ObservableMap and ObservableMapValue, and then dozens upon dozens of implementing classes such as IntegerProperty and SimpleIntegerProperty... geez! wtf?. Assuming that I have to create some Clojure objects (defrecord, etc.) and implement some of the Observable interface methods on my mostly immutable objects, can I just stick with Observable, or must I implement each one down to the leaf node, ie ObservableIntegerValue, etc.?
What is the correct high level approach? Maintain a single top-level atom which is replaced every time the user changes a value? Maintain a thousand low-level atoms? Let my values live as JavaFX Observables, and forget about Clojure data structs? Implement my own set of Observables in Clojure using some reify/proxy/gen-class, but implement them as immutables that get replaced each time a change is made? Is there a need or place for Clojure's add-watch function? I'd very much prefer that my data just be normal data in Clojure, not a "type" or an implementation of an interface of anything. An Integer should be an Integer, etc.
thanks
I would add a watch to the atom, and then update your observable based on the diff.
http://clojuredocs.org/clojure.core/add-watch
The question applies to the class QGraphicsView of the qt library.
However, the problem is more general. So, if I am not missing any special mechanism in qt, it can probably be discussed without knowing qt.
I am subclassing QGraphicsView to add some features that I need.
E.g. I have a ScalableView, PannableView and LabeledView to add independent functionality.
The sublassing I use for now is linear in the following sense:
ScalableView is derived from QGraphics view.
PannableView is derived from ScalableView view.
LabeledView is derived from PannableView view.
Since those features are independent, there is a design flaw.
Applying the decorator pattern to come around this seems appropriate for me.
The problem there is, QGraphicsView is not an interface and there exists no interface class like QAbstractGraphicsView. So, for me it is not clear how that pattern could be implemented.
A different idea would be to use templates. So I could derive each of the views from a template T. Then, I could make insantiations like ScalableView<PannableView<LabeledView>>>.
Do you see any better solution to that? I would prefer a way to implement the decorator pattern in this situation, since I would like to avoid to many template classes that would increase compilation time.
A simple solution in Qt style would be to create a class that derives from QGraphicsView and simply has flags that control its behavior (whether it's scalable, pannable, labeled, etc.). The implementations of those behaviors would still be split into methods, so it's
not as monolithic as it seems.
The decorator pattern can be of course easily implemented by defining an intermediate (shim) interface. The QGraphicsView does not need to implement that interface - the interface is only for the decorators to use.
The problem with deep inheritance is that it's impossible to finely control the interaction of the behaviors. The only control you have is the order of event processing. This may happen to be sufficient, but it has me somewhat worried. The decorator pattern implemented without embellishment shares this issue.
Without knowing the full design, this may or may not work, but perhaps this will help.
One possible method would be to encapsulate the QGraphicsView and create delegate objects that provide the different functionality that you require. The delegates would then be responsible for providing the interface to the graphics view and forwarding messages.
This would mean creating a different delegate for the different types of functionality; a ScalableDelegate, a PannableDelegate and a LabeledDelegate.
As the delegates are separate objects and not inherited from the QGraphicsView, you can gain a lot of functionality from installing event filters on the graphics views.
Then, instead of objects interacting with your GraphicsView, they communicate via the relevant delegate.
If this is too restrictive,you may need to inherit from QGraphicsView to create a view with the functionality you need and then use the delegates to expose the required functionality as desired.
I just starting on WPF with MVVM, so forgive any misconceptions. I have a model (not a view model but the actual model) that has many List inside classes that are in other List making trees of data.
Important, the data should be XML Serializabled, currently there is no problem doing that with regular properties and List.
The View Model of this class is taking a lot more work than I expected and I'm thinking on converting some or maybe all of the List to ObservableCollections, what are the pros and cons of that?
Also, what would be best in a "bindable model", NotifyPropertyChange or DependencyProperties? I think there would be some memory gains with DependencyProperty since many objects will use default values on most of the properties, what about performance in general, and has it any problems with serialization?
Regards,
The View Model of this class is taking a lot more work than I expected and I'm thinking on converting some or maybe all of the List to ObservableCollections, what are the pros and cons of that?
There is a bit more overhead in ObservableCollection<T> when compared to List<T>, but it does make it easier as data binding directly to your model collections will work.
Also, what would be best in a "bindable model", NotifyPropertyChange or DependencyProperties?
I would not use DependencyProperties within your model. This is taking a dependency on the WPF libraries, and very platform specific. If you want to be able to data bind directly to your model, implementing INotifyPropertyChanged is a reasonable approach.
However, you really should stop and take a minute before making any of these changes. If you're changing your model classes primarily to use them in your View, you're violating the basic principles of MVVM (and most other architectural patterns). One of the main goals here is that your Model is unaware of the presentation layer being used - this makes it more flexible in the future, as you can change presentation layers without changing your model at all.
'm developing a 2D game and I want separate the game engine from the graphics.
I decided to use the model-view pattern in the following way: the game engine owns game's entities (EnemyModel, BulletModel, ExplosionModel) which implement interfaces (Enemy, Bullet, Explosion).
The View receives events when entities are created, getting the pointer to the interface: in this way the View can only use the interface methods (i.e. ask for informations to perform the drawing) and cannot change the object state. The View has its onw classes (EnemyView, BulletView, ExplosionView) which own pointers to the interfaces.
(There is also an event-base pattern involved so that the Model can notify the View about entity changes, since a pure query approach is impraticable but I wont' discuss it here).
*Model classes use a compile-time component approach: they use the boost::fusion library to store different state componets, like PositionComponent, HealthComponent and so on.
At present moment the View isn't aware of the component based design but only of the model-view part: to get the position of an enemy it calls the Enemy::get_xy() method. The EnemyModel, which implements the interface, forwards this call to the PositionComponent and returns the result.
Since the bullet has position too, I have to add the get_xy method to Bullet too. BulletModel uses then the same implementation as the EnemyModel class (i.e. it forwards the call).
This approch then leads to have a lot of duplicate code: interfaces have a lot of similar methods and *Model classes are full of forward-methods.
So I have basically two options:
1) Expose the compoment based design so that each component has an interface as well: the View can use this interface to directly query the component. It keeps the View and the Model separated, only at a component level instead of a entity level.
2) Abandon the model-view part and go for pure component based design: the View is just a component (the RenderableComponent part) which has basically full access to the game engine.
Based on your experience which approach would be best?
I'll give my two cents worth. From the problem you're describing, it seems to me that you need an abstract class that will do the operations that are common amongst all of your classes (like the get_xy, which should apply to bullet, enemy, explosion, etc.). This class is a game entity that does the basic grunt work. Inheriting classes can override it if they want.
This abstract class should be the core of all your interfaces (luckily you're in C++ where there is no physical difference between a class, and abstract class and an interface). Thus the Views will know about the specific interfaces, and still have the generic entity methods.
A rule of thumb I have for design - if more than one class has the same data members or methods, it should probably be a single class from which they inherit.
Anyway, exposing the internal structure of your Model classes is not a good idea. Say you'll want to replace boost with something else? You'd have to re-write the entire program, not just the relevant parts.
MVC isn't easy for games as when the game becomes larger (including menu, enemies, levels, GUI...) and transitions, it'll break.
Component or entity-system are pretty good for games.
As a simpler case for you, you may consider using a HMVC. You'll still have issues with transitions, but at least your code will be grouped together in a more clean manner. You probably want your tank's code (rendering and logic) to get close together.
There have been presentation architectures designed especially for agent-based systems, such as Presentation-Abstraction-Control. The hard part in designing such a system is that you ultimately end up hardwiring sequences of collaborations between the agents.
You can do this, but don't use OO inheritance to model the message passing hierarchy. You will regret it. If you think about it, you are really not interested in using the OO inheritance relationship, since the interfaces defined are really just a "Record of functions" that the object can respond to. In that case, you are better off formally modeling your communication protocol.
If you have questions, please ask -- this is not an obvious solution and easy to get wrong.