I need to have a widget for displaying files and folders in a grid like scrollable container... So I need the view given by ListWidget, with the filesystem architecture of TreeWidget.
How should I implement this?
I thought about using the FileSysteModel but it works only with local files and my filesystem will be virtual.
You can have a look at this video https://www.youtube.com/watch?v=92biLZST6Vg
This is very helpful and the exact answer. This is just in cpp but the implementation should be 90% the same.
Related
We need a tree view with File system and check boxes in QT. Is there any way to achieve that?
The tree we need would look something like below:
UPDATE:
I am able to achieve it with subclass of QFileSystemModel. Still have few challenges, but at least subclass is working. Below is the code if anyone needs it. Below is the link to the code -
https://drive.google.com/file/d/1qViZ3iEW2pV2th0jQhzneDL14SEhIgS0/view?usp=sharing
The pending work is to apply a wait cursor (or make treeview uneditable when the check/uncheck is taking place).
PS: It will take a lot of time if root node is checked.
Well, all of that can be achieved with minimal customizations of built-in classes, actually those checkboxes is almost the only thing that has to be done yourself.
QFileSystemModel already provides a proper model for displaying the current filesystem contents, it can be subclassed
As for QML, the best demo is already provided by Qt, check the File System Browser Example. This example uses some deprecaded Qt functionality, but still it shows the basic concept.
The modern techniqes can be also found in the answers to the following question: Qt File Browser based on QML
Hopefully, all that helps you, good luck!
I'm new to Qt and it's quite a learning curve!
I've been search/reading/hacking and learning for most of the day on this one.
I'm working on an app that will have a image in a scroll area as it's main purpose. The image viewer example is where I started. This example appears to be "laid out by hand" if you will - i.e. there are no .ui form files for it (it's trivial so why not).
So here is the rub - I want to use designer to build a much more sophisticated app. If I start fresh with a new project and use designer the resizing doesn't work unless I add layout (used vertical, all appear to fix the resize issue) to the .ui form.
Designer creates a lot more code to do the same thing - I don't care, it is after all an IDE / code generation tool.
However it's not clear to me why the layout is required when I use designer and not if I code it by hand. I searched the code for the image viewer example and there doesn't seem to be ANY layout involved at all, just 3 or 4 nested widgits (Main/Scroll/Label).
Is the default layout basically built in?
The example you linked to uses a QMainWindow. This widget has its own layout because it has built-in support for menubars, toolbars, dock widgets and a statusbar:
Main Window Framework:
Normally, the widget set as the central-widget would need to have a layout explicitly set on it in order to layout its own child widgets. However, in your linked example, the central-widget is a QScrollArea, which also happens to have a built-in layout. This is all just coincidental, though. The large majority of widgets don't have a built-in layout, so most GUIs will need to explictly add at least one layout, and several will usually be needed for more complex applications.
I would say Qt Designer is absolutely essential when it comes to experimenting with layouts (especially when you start learning Qt). Even if you don't actually use the ui file, it's still very helpful to just view the code that would be generated from it.
I've never used QML before and I don't know if the following is even possible at all.
I'm currently porting a C++ Qt Application to Qt 5.5 with existing code and lot of UI files. This application later loads a lot of C++ plugin dll at runtime. Now every plugin should have its own configuration dialog; although none of these plugins currently have a Qt dependency.
I'm currently thinking about extending the interface with something like:
class CPlugin {
public:
virtual std::string const& getQmlDescription() const;
virtual std::string const& getQmlFilePath() const;
};
So every plugin can return a set of QML data on how it wishes it's configuration dialog to look like.
When this plugin should get configured by the user, this application displays an empty QDialog and asks the plugin "give me your qml config data"; which is then rendered and executed inside the empty QDialog.
Can this QML data in terms of a string buffer or a file path to the QML data be interpreted and rendered into a empty QDialog at runtime?
Bottom line:
Can QML be handled like this at runtime?
Can I embed a QML Dialog description inside a traditional QDialog window or does these two types not mix?
Is this even remotely a good idea or should I do a hell lot differently? :)
There's no reason to use a QDialog. You could do it, but a QDialog is rendered using the raster paint engine, and you'd be using the CPU to composite that with the OpenGL frame buffer that Qt Quick renders into. It'd be a bad premature pessimization.
In your scenario, the QML from the plugin would be passed to QQuickView. You will also find that the plugins will need access to the QML engine to set up the context objects to interface C++ to QML, and to register their objects. You can use a global engine instance, and pass it to plugins. Or, to isolate them, use a dedicated engine that only services these plugins.
Qt Quick is flexible in that you are not forced to have the Qt Quick items from the plugins in separate windows. You can set them up in a flickable front-end for mobile devices, dockable front-end for desktop applications, etc. The visual items from the plugins can be instantiated any way you wish - multiple times, inside of other items, etc.
So, it might be a better idea for the plugins to register their visual Item types with the engine, and let your application decide how to use these types, via a Loader, instead of simply passing you raw QML to deal with.
I wanted to consult with the sages here regarding Qt and skinning, get your opinion and chart a path for my development. My requirements are as follows:
My Qt/C++ application (cross platform with Mac, Windows and Linux versions) needs to have modular skins.
A skin is defined as a set of one or more elements: - Window background texture - Look/feel of UI controls such as edit boxes, drop down, radio buttons, buttons etc. - Look/feel of window "caption", resize grips etc.
Skins will be installed with the application installer, allowing the user to choose which one he/she wants to use. Users should be able to change skins on the fly.
Can I go the QML route? should this be custom and based on simple resources which are built into the application? Any design advice will be appreciated.
Thanks.
If I understood you correctly then stylesheet is the best way forward. You can create stylesheets similar to CSS and then pass them as command line option to your application or load on invocation to style your application at runtime. That way you can create multiple stylesheets each having a different look and feel and allow user to load them at will. Since its CSS it doesn't need any new learning and you can keep all your styling outside your source code.
Here are a list of resources that can get you up and running quickly:
http://blog.qt.io/blog/2007/11/27/theming-qt-for-fun-and-profit/
http://doc.qt.io/qt-5/stylesheet.html
I haven't played with QML yet, but you could also create a custom QStyle implementation that supports your resource format. Note that you'd lose style sheet support if you went this route.
Changing window captions is a little trickier if you want portability.
QML, if I understand correctly, doesn't really skin the widgets, it mainly deals with GUI layout etc etc.
QStyle is used to change the looks. It is a bit low-level though, and requires programming, so if you want to load different user-created skins (from an XML or so) it might be tricky to support extensive skinning. Chaining colors and a few items are easy enough though. (There might be someone else who've done something you could re-use.. not sure.)
For modifying widgets, use QStyle::polish(). You could use that to change the background picture (if it's a top-level window, or of a certain class). There are numerous repaint method to change almost every part of every widget.
Store/load the style using QSettings, by reading and setting the desired Style just after QApplication but before your main window is constructed.
I am building an interface similar in features to the Eclipse IDE for a telemetry project. I'll be showing many different widgets and each of them needs to be resizable / moveable / popped_out / popped_in / hideable / "fullscreen-able" / etc... like a "perspective" of the Eclipse IDE.
What would be the best approach using QT? Which classes to use? Using QT's QMainWindow / QDockWidgets / LayoutManager or since any widget can be moved anywhere would it be best to handle everything by hand-coding ?
In my opinion, QMainWindow gives you a good start. You can create and manage DockWidgets all around your central widget and add status and tool bars fairly easily.
The QDockWidget class already handles the dock/undock hide/show options, so all you have to do is do your own widget.
Also, if you want widgets to be hideables, you could look into QSplitter that allows to show two widgets, one on either side and resize them. They are collapsibles by default.
Hope this helps.
EDIT (to answer the comment question):
You can use QSettings to do so. It allows you to save any settings you want in the system directory.
You do so like this:
QSettings settings;
settings.setValue("editor/wrapMargin", 68);
and to get it back:
int margin = settings.value("editor/wrapMargin").toInt();
Hope this helps.