I'm beginning Qt/pySide programming and am trying to implement a simple QListView with QFileSystemModel as the model. I have this working and in addition have defined a name filter on the model. I'd like to get a list of all files in the QListView (or rather the underlying model).
The following code appears to do this, but is incredibly ugly and cannot possibly be the correct way. Help!
model = myQListView.model()
idx = model.index(model.rootPath())
for i in range(0, model.rowCount(idx)):
child = idx.child(i, idx.column())
print model.fileName(child)
That is the correct way of working. The whole idea of the QAbstractItemModel abstraction is to provide a unified API for accessing arbitrary and possibly dynamic data which happen to fit into a list, table or tree presentations. Because this API has to accomodate everything from a simple dummy list of a few strings to the contents of an address book, including the rich contact details, it is inherently complex. Depending on what you want to achieve, using a one-purpose tool might be better in your specific situation.
By the way, the QFileSystemModel is very dynamic in nature (the directory enumeration happens on a separate thread). You won't get meaningful data until the directoryLoaded signal is emited, you have to wait for it. If you are simply looking for a list of files to use in your code, using Python's native facilities might be easier.
Related
I'm aware of using selectors in Redux, and make use of them. However I have a case where I feel that it would make more sense to store my newly filtered data in the store. Here's my example:
I have an app which displays lots of items. There is a "global filter" option that will only show a certain subset of these items.
The thing is, this filter is global. It changes this list of items across multiple pages and components (e.g. in a table, in a drop down menu). When the filter is set, as far as the whole app is concerned, the current subset is the only list of items that exist.
I could use selectors everywhere necessary but it feels like it would be more robust to just have a 'filteredItems' part of my store. What would be the disadvantage to doing this?
It's up to you to decide what state you have in your app, and where it should live. Yes, the common advice is to try to keep the store state minimal and use selectors to derive extended values from that, but there's nothing wrong with using reducers to create filtered values that are kept in the state. Your situation sounds like a perfectly reasonable use case for doing that.
I use selectors (reselect) which takes it a step further by caching derived data and other stuff to improve the performance , i use this all the time.
Why?
To keep my components as small and reusable as possible , i noticed that after doing this for while , you start writing your components in a more 'generic' manner, and you use the selectors as kind of plug adapters to shape multiple types of data to fit in a component.
When?
One of the main issue when using reselect , is the setup part , boring... and not without efforts. but when you learn and apply the reselect pattern it will become much simpler to read and maintain a big app
So if you have a lot of computing to do and diversified derived data , you should pay the price (time , efforts) and set this up , but if your derived data is small, you should not bother yourself with this.
My two cents
I am trying to get my head wrapped around the QAbstractTableModel and am not quite sure how to get started. I have the following:
Reading from a socket, It returns a bunch of lines of strings - terminated with EOL..
I dump all of this into a QStringList. I then need to parse this line by line to
create my rows and columns of my table. I have written a function to parse the list,
but not sure if I should pass a pointer to the ModelIndex, and build the table , and if
so what does that look like...
Cant really sseem to find an example that is building a dynamic table with multiple
rows and columns that are of unknown size at creation.
A bit confused about how to do this.
Thanks,
Todd
I think what you're looking for is QAbstractItemModel's canFetchMore and fetchMore methods. These are meant for dynamic models (of unknown/large size), and help to inform your attached views that more data is available to display. An example of using this method can be found in the fetchmore example in the Qt examples.
Much more complex examples (using threads, for instance) can be found throughout the Qt codebase:
QFileSystemModel
QSqlQueryModel
QSortFilterProxyModel
I've wondered this in many different situations, so here I come, looking for the experts knowledge.
Let's say I have to model something that requires a collection. A simple example: an application that stores famous quotes along with their author and a set of tags or keywords. The user should be able to enter a tag or keyword and get matching quotes for it.
My question is: do I really need a class that contains my collection of quotes? Something like this:
Or would this also be correct?
I'm asking this in the more abstract way possible (after all, UML should never depend on the implementation).
I've always thought the second example (just 1 class) was incorrect, but now I'm thinking that maybe the user can press a button on some interface and that button executes some code that gets a quote stored somewhere, and the second example would also be correct?
Basically, should I always have a collection stored somewhere, even if the storing class does nothing else but just store the collection (and provide the methods to access it)?
I definitelly prefer only one class, if there is no strong reason to have another container class (especially on abstract conceptual level). Then I add the collection methods as static functions. A separate container class would only bring more complexity, more dependencies and doubts like yours. :) Doubts often indicate the lack of a real need. When you really need something, you know it.
Here an example with some explanations. I find it simple, clear, elegant and abstract, meaning non-restrictive, easy to transform to any implementation you like:
When it comes to relationships of this class to other class, then you actially have your collection, without introducing new class. This diagram shows two examples. "Other class" actually sees a collection "quotes" which is ordered, like Vector. "One more class" also has a collection of Quotes with different characteristics.
Later on implementation level you can implement it directly like this or eventually adding a Factory or Container class, according to concrete, implemention resctrictions and special reqs.
Good day!
There are instances of classes QListView and QTreeView.
Both of the instances loads data from model (QStandardItemModel).
QTreeView displays positions (For example: Chief, Manager, Developer, etc).
Clicking on the title of position a list of employees revealed.
QListView displays only positions of staff.
Question:
How can I display a full list of names of employees in QListView not showing their positions?
Which methods I need to override?
What can you advise in this situation?
P.S. Thanks!
I don't think you are going to be able to do that with a single model.
This thread suggests using a proxy model to flatten the original one without having to maintain two instances of that data. But the implementation pointed to (KDE's KReparentingProxyModel) isn't exactly trivial.
There is some documentation on proxy models, and the QSortFilterProxyModel might be usable in your context, although I think you'll need something more specific.
You might also find the classes attached to the third response on this thread: ModelView - how to use proxies to filter this data? interesting as a starting point.
(Sorry this isn't very specific. Searching for "qt flatten tree model" will give you other ideas.)
Try to use QListWidget, is easier than QListView.
I was watching a tutorial on Rails and was very impressed that you could so easily create an editing system for a class just by defining it.
Can this be done in ASP.NET?
I know there are ORMs out there, but do they come with an editing system?
To explain what I mean by an editing system, consider a class for defining people
class Person
{
string First_Name;
string Last_Name
}
And then perhaps with one bold stroke something like this:
CreateEditAbleClass(Person)
You would get the functionality below in a browser:
http://www.yart.com.au/images/orm_editor.jpg
And this functionality would extend to all the UML definitions – inheritance, association, aggregation etc. In addition, there would be a simple way of adding customisable validation and so forth.
I currently use DataGrids and a lot of manual coding to achieve these results.
You can do it with reflection. Using reflection, you can enumerate over the members of a class, and therefore create a form to edit the members.
Creating the code for rendering the web form based on the members of the class is a bit more code then I'm willing to type out here, but if you look into reflection you should be able to come up with your own solution in a couple hours.
Sure. This is off the top of my head, but I believe you could connect your class to an ObjectDataSource component which would in turn connect to a DetailsView control. So it's a hair more work, but it would be pretty trivial to have a method that created the needed items on the fly and bound them together.
This is called "Scaffolding".
It really depends on what you are using for your data layer or ORM. Entityspaces, for example, comes with a scaffolding generator.
Absolutely! Scaffolding in Ruby is known as Dynamic Data in ASP.NET. Scott Hanselman speaks to Dynamic Data here.
There's a screen cast from Scott Hunter that shows it off here. It's of note that it's pretty new (still in beta).
You can for simple sites/purposes but it quickly breaks down when you want to do something more complex. Like what happens if you don't want certain fields to be visible, what happens if you have a relationship to a subset of a certain class etc.
Having been down this path before I'm guessing you came at the issue by realizing that:
You spend alot of time creating similar forms/lists etc for similar entities.
You want to minimize this time and are considering if your forms can be automatically generated.
Basically, if you want it to be done automatically then you'll end up creating an overcomplicated system that does half of what you want and actually takes longer to implement.
If however, you want to drastically cut the amount of time doing and maintaining writing repetitive gui code then then I suggest using a declarative style form builder and table builder (like the form builder in ROR).
This lets you quickly create forms/tables without repeating yourself any more than necessary and also gives you the flexibility that you need for complex scenarios.