This may seem like a very strange question but is it possible to generate a Qt Designer form (.ui) from a Qt object, say something that inherits QWidget?
My plan is to build a simple dynamic form in code as the user picks what stuff they want e.g fields, type of control and then dump out a .ui file so that they can tweak the layout if needed after.
The code will then use the QUiLoader class to reload the ui file and show the modified or not ui file.
The Qt-Introspection tool GammaRay can save dialogs from the AUI (Application Under Inspection) to .ui files in its latest version, IIRC.
Since QWidget inherits from QObject, it gets all of the dynamic property inspection QObject provides. QObjects (and QWidgets) also naturally arrange themselves into trees (see QObject::parent and QObject::children). By following the tree of widgets, and getting the properties of each one, you can generate an xml .ui file containing the basic info about each control.
Working out the signal/slot connections from a pre-established form might be a bit more tricky, since there doesn't seem to be any way to get information on them besides QObject::dumpObjectInfo but for the program you describe in your question it's easy enough to keep track of them some other way.
Let my just clarify something, Qt Designer has a WYSIWYG user interface that creates a Qt Designer form in xml format, which is then converted to C++ code at compile time. And you're asking if one can do this backwards?
Yes, i do think it is possible, since Qt Designer Forms are just xml anyway. You can make an application that accepts C++ code, specifically the code used for the complete declaration of a class, then translate the PROPERTIES of the class into their corresponding xml code. This would involve a lot of work, in which at that point, i personally don't see the point anymore.
edit: this project would require you to reverse engineer Qt Designer. but yes, it is very possible.
not that way. As you remember, UI-file is the source code for generating appropriate .cpp-code at compilet-me. Gui-loader is a part of point-to-implementation pattern, which helps to reduce amount of compile-time.
You could also embedd Qt Designer into your own code using the designer module. You need to add CONFIG += designer to your .pro file.
Please take a look at the designer module here: http://developer.qt.nokia.com/doc/qt-4.8/qtdesigner.html
Related
I have a Qt app with multiple QWidgets. I would like to create for each QWidget an .ui file to be able to reuse the same .ui file in different places and to have a simple structure for main.ui. Because now I have a big .cpp file with all slots and signals for all QWidgets and it is not so easy to work. I have not found a solution yet and I would like to know if it's possible. Thank you!
As far as I know including one such file into another is not supported but I might be mistaken.
If you want to use multiple .ui files the general practice is to use QUILoader, which allows loading different such files at runtime.
Frankly I would just go for implementing all this by hand. You can then separate/group the different widgets in whichever way you want.
What is the best way/common practice for maintaining all string resources found on a UI in Qt, especially the textual input/text in combo boxes etc. (since these are the once that are frequently used in the code itself)?
I know that Android has this string resources thing such that resources only have to be modified at one position.
Does Qt have something like that too or do I have to initialize string resources in code instead of in the UI's XML itself...
AFAIK, there is no built-in mechanism for string resources in Qt. If you want to maintain strings at build time you can define them in one .h/.cpp file as global variables and reuse them in your code.
Otherwise you can use Qt's translator files (binary) and load them along with your application. If you need to change a string, you simply will need to edit the translation file (xml) and "recompile" it with lrelease utility without building the application again.
There is a mechanism to dynamically translate texts in application, but it works a bit different than Android string resources, but achieves the same goals.
Qt uses i18n system modelled after standard, well known unix gettext. It works in a very similar way to iOS NSLocalizedString, if that rings a bell.
http://doc.qt.io/qt-5/qobject.html#tr
This is worth reading too:
http://en.wikipedia.org/wiki/Gettext
http://doc.qt.io/qt-5/internationalization.html
Android approach is a bit unique and you should not expect it to be a "standard everywhere". It works, it's ok, but it's not a standard way of doing things on desktop.
I was curious if I can embed printing of HTML markup in my C++ application? Here's what I need:
Ability to specify which printer to print to.
Ability to change paper size.
Ability to specify margins/gutter, etc.
Ability to let end-user preview the result.
It would be easier to virtually print the HTML page to a PDF file using wkHTMLtoPDF C++ Library, and then print it.
Pros:
It allows you to keep a draft copy for future use.
Cons:
It's not a print-HTML-directly library
Have a look at this library: http://www.terrainformatica.com/htmlayout/ . It does everything you need, assuming you want to print the rendered html, and not syntax-highlighted html source code, which is not entirely clear from your question - but
MFC has a CHtmlView class that is part of their Document/View architecture. Hence, you can create a rather simple MDI "Web Browser" in MFC pretty easily.
I am working in C language and creating applications for an embedded device. These applications mainly
include capturing data and storing it into a database for performing an enrollment. This involves lot of
widgets like frames, buttons, check-boxes, radio buttons, widget list boxes, text boxes, entries, combo boxes etc. All these widgets are being created using the X library.
I have tried to make the application generalized using CSV files, having a list of all the widgets that the user wants to create and then creating those widgets accordingly based on the information mentioned
in the CSV file.
The CSV file that I am creating includes things like
Widget name
Widget type
Widget data input type/max length / min length
.....
..... etc.
Please suggest some other ways or how can I improve the current way itself?
I am also creating the DB by the information provided in the CSV itself. I can say that it's
a "Data Driven User Interface" approach. I need some suggestions. Please provide me
some good suggestions.
Platform: Linux, GCC compiler
Maybe not quite what you are looking for but WxWidgets has a format called XRC. It's windows described as XML: http://docs.wxwidgets.org/2.9.4/overview_xrc.html. Are you really writing your GUI in C? I guess that might be a constraint on an embedded product.
Anyway, you might get good ideas from the site. I haven't used it so no specific feedback is available from me.
I'm trying to find out if there's a way to embed an editable text cell in a PDF generated in a Qt application. I'm currently using QPrinter to generate the PDF, but if there's another library that could do this, that would be fine. The environment is limited, though, to C or C++, so libraries like iText are out. In terms of form capabilities, this pdf,
http://examples.itextpdf.com/results/part2/chapter08/text_fields.pdf, is a good example with the exception that I don't need a password text field.
Thanks,
Frank
This may not be terribly helpful, but I'll throw it out there anyway.
wkhtmltopdf is based on QTWebkit.
One of its command line options is to convert HTML fields into PDF fields (off by default).
There's almost no pdf-related code within wkhtmltopdf. Certainly nothing dealing with fields. Something upstream is doing the PDF conversion for them.
So find out what that "something" is and you're golden.
EDIT: That or spend a lot of time writing JNI wrappers for iText. :/ Having done so myself, I can say it'd be much more interesting to write a JNI generator tailored to iText, but far more practical to write a Java app that uses iText and then make JNI calls from your C/C++ app to pass the data it'll need and retrieve any response.
The form field borders are a part of the page, not the field itself. Odd, but that's not the first time I've encountered it. Our own software, LiquidOffice, used to generate fields with backgrounds AcroForms couldn't support the same way (now we use an icon-only button).
Those Real PDF Fields have their visibility flags set to "visible but doesn't print" within the pDF. I doubt wkhtmltopdf will let you control that directly. Patch time.
BUT, you could make a second pass with some PDF manipulation library to go through and change the visibility settings on your fields. I'm partial to iText, but there are many other fish in that particular sea.