The Title says everything. I'm pretty new to qt and don't really like the editor it provides.
vim form1.ui.h doesn't work.
Most likely you mean header file generated from your .ui file. Well, since it's generated - editing it is not very good idea, because it will be regenerated from .ui each time you build you program.
But you obviously can:
Edit .ui file with any xml/text editor. Though it's really strange and wouldn't win much over using designer itself.
Do not use .ui files at all - encapsulate creation of desired interfaces in your own classes containing simple C++/Qt code. That way actually is not that bad if you're experienced with Qt layout/widget system and know what you wish to achieve. Because there's no any kind of pixel hunting needs to be done in designer and placing things in appropriate way may actually be done even in more structured manner in code than in form creation. Though as I said it's not the way for everyone and you have to be accurate, also it's better separate interface code from other functionality.
Related
I am new to Qt in general, and I have been playing with it to get to learn about it since I have to develop a very specific text editor.
I want to know if anyone could help me understand which one is better (or the most indicated) for the development of a rich text editor. I have worked before with C and C++ but Qt Widgets seems like a very step hill for the time being and I am completely new to javascript in general.
Some of the settings that I would need to implement on the text editor for better context are:
Look for the user to be always connected to internet.
Transfer and receive data from another program.
Grant read only to the opened files and then permission to write on them when a button is clicked.
Has to work on linux and windows.
Needs to look great.
My context:
So far I have done a few little applications and even a little rich text editor on Qt Widgets, but since I was having problems with the GUI implementation that I wanted, I started looking for a way to solve it and found that Qt Quick might be the solution.
I have been trying Qt Quick, and for now on looks great, but I do not know if it has the capabilities to do what I have explained before. Or if it is better to use one or another.
I decided to create a new post since the one that I found looking for something similar is from 2014.
Also, the text editor for now only needs to work on desktop, but in a future might be on other devices and embedded systems.
Well in general I am new to BizTalk and maintaining a very old setup, BT 2013 R2
Overall I am well versed in .XSLT and feel more comfortable managing xml directly than I do in the BT IDE ( well the vstudio IDE)
So here are a couple generic architecture questions:
What are the steps to manage the maps manually through notepad? I see a lot of code in the .BTM.CS file, but those don't seem to get picked up. I seem to have to change the .BTM file first, then it generates the .BTM.CS
My Map is Huge, I'm working with X12 and there are thousands of fields, what can I do to make this easier? I have to scroll through 10 layers deep just to make anything visible, then expand the map. BT IDE seems to have a big issue dealing with such big files
Also any books anyone can recommend on the subject would be appreciated
I will say this first, I totally understand where you're coming from, but...
You don't, sorry. The BizTalk Visual Studio Project System is an integral part of BizTalk development and you really, really, really should not even try using a text editor. .odx, .btm, .btp are all meta files managed by their respective designers. The .cs files are generated at Build-time so there is not opportunity to modify them at all.
One way to improve Mapper performance is to areas of function into separate Tabs. The rendering of the design surface is the problem so the less to render at once, the better. Even separating direct links and Functoids helps.
Sandro's book is the current standard: BizTalk Mapping Patterns & Best Practices
Johns-305's answer is good - I'd just add that with XSLT in maps you do have the option of setting "Custom XSLT" for the map in the properties window. That can then be pointed to an external (source controlled) XSLT file which you could then edit using any XML/XSLT editor (Visual Studio or not). Just be aware that this option means you won't be able to us any of the visual mapper functionality, and the .btm file will basically just be a pointer to the compiler to use your custom XSLT rather than the XSLT that would be generated by BizTalk. You should not try to manage BizTalk's generated XSLT in this manner - only for cases where you're certain you want to use custom XSLT rather than the visual designer. To do that, open the map in Visual Studio (1), click the grid area (2), and then set the Custom XSLT Path (3):
(It's possible to do that by directly editing the .btm file, but not recommended - I did write a blog a little while back documenting the .btm format for what it's worth though: https://blog.tallan.com/2015/03/26/biztalk-mapper-file-format-btm-documented/.)
For orchestrations, you're out of luck.
I write an application, with Qt and it has a pretty big help system, which is including images, tables, links, etc... This help system is stored on a disk in a specific location as simple HTML files, together with the images and using a QWebkit control it's loaded in the application on request, and the user can browse it, etc...
Now, I would like to move away from my "in-house, file based" help solution, meaning: I want a help system which still will use my HTML files, but without the need to ship 100 files to the user, only 1 or 2.
I am aware of Qt's help system ( http://doc-snapshot.qt-project.org/4.8/qthelp-framework.html ) but I am wondering if there are any other solutions providing the same or similar functionality.
What I am looking for:
take all the HTML files and create one of them, including images
reader possibly embeddable in application, but separate application is good too.
multiplatform
support for context sensitive help (ie: "Click on what's this", help shows relevant page)
For huge help docs the best way is to use Qt Help Framework. For example QAssistant is done in this way.
It mainly consists of several html like files and index files. Then you "compile" them to get a binary(and compressed) version. You can split help in sections and so on...
I am using QWebView to display HTML help files. You get a widget and can integrate it in your application.
Qt have a good easy example here: http://qt-project.org/wiki/Open_Web_Page_in_QWebView
Since it is a widget, you can greate a stand-alone or integrated look and it it very flexible.
At times I find myself editing the XML files on Qt creator rather than using the drag and drop interface for example if I can't get my widgets in the correct row of my grid layout. Is there a good reference anywhere on how to lay UIs out using XML? For example, I'd been interested in altering the visibility of a checkbox in the XML rather than in C++ code... is this doable, or am I too much in the WPF mindset? Either way, I'd still be interested in that reference.
You may find the Qt Designer's UI File Format page useful.
I generally just use the designer to prototype something quickly, and then code it up in C++ once the design is correct. Breaking the UI up into custom widgets, rather than one massive form often produces something more manageable.
I've been using Qt for 4 years but I never modified the UI files directly. I always do it using Qt Designer. Not sure why you ever need to modify the XML file directly.
This is not answer to your question, but I believe you're missing how to use Qt Designer. Please check Qt Designer's Manual first.
Every time I start a project with some graphical toolkit, one of the first conflicts happen with the decision of how to deal with the visual design and the widget layout: A graphical tool or handcoding?
This is a quite tricky/subjective question because most people will decide based on personal preference. It also depends greatly on the quality of the graphical tool. In this case I would like to focus just on the latest version of the QT library. I do not intend to discuss which method is better. I am convinced that the best answer is: depends on the project.
What I want is a reference to a good non biased article, based on experience after several projects. The article should just describe the tradeoffs of both choices
I started with doing everything hand-coded, and of late have been switching to using Qt Designer for most forms. Here are some benefits for each position:
Using Qt Designer
The biggest time saver for me is managing complex layouts; it saves a lot of tedious coding. Simply (very roughly) arrange your widgets, select them, right-click, and put them in the correct type of layout. Especially as layouts become nested, this is so much easier.
It tends to keep your implementation files cleaner instead of filling them with all the boilerplate layout code. I'm type-A, so I like that.
If you are translating your application, it is possible to send your translators the .ui files so they can see on your GUI where the text they are translating will be. (Assuming they are using Qt Linguist.)
Hand-coding
Control. If you have a layout where you need to instantiate / initialize the controls in a very particular order, or dynamically create the controls based on other criteria (database lookup, etc.), this is the easiest way.
If you have custom widgets, you can kind-of-sort-of use the Designer, adding the closest built-in QWidget from which your class derived and then "upgrading" it. But you won't see a preview of your widget unless you make it a designer plugin in a separate project, which is way too much work for most use cases.
If you have custom widgets that take parameters in their constructor beyond the optional QWidget parent, Designer can't handle it. You have no choice but to add that control manually.
Miscellaneous
I don't use the auto-connect SLOTS and SIGNALS feature (based on naming convention such as "on_my_button_clicked".) I have found that I almost invariably have to set up this connection at a determinate time, not whenever Qt does it for me.
For QWizard forms, I have found that I need to use a different UI file for each page. You can do it all in one, but it becomes very awkward to communicate between pages in any kind of custom way.
In summary, I start with Qt Designer and let it take me as far as it can, then hand-code it from there. That's one nice thing about what Qt Designer generates--it is just another class that becomes a member of your class, and you can access it and manipulate it as you need.
My answer is based on two years developing biochemistry applications using PyQt4 (Python bindings to Qt 4) and OpenGL. I have not done C++ Qt, because we only used C++ for performance-critical algorithms. That said, the PyQt4 API greatly resembles Qt4, so much here still applies.
Qt Designer
Good
Exploration. Discover what widgets are available, the names for those widgets, what properties you can set for each, etc.
Enforces separation of UI logic from application logic.
Bad
If you need to add or remove widgets at run-time, you have to have that logic in code. I think it's a bad idea to put your UI logic in two places.
Making changes to nested layouts. When a layout has no widgets in it, it collapses, and it can be really hard to drag and drop a widget in to the location you want.
Hand coding
Good
Fast if you are very familiar with Qt.
Best choice if you need to add or remove widgets at run-time.
Easier than Qt Designer if you have your own custom widgets.
With discipline, you can still separate UI layout from behavior. Just put your code to create and layout widgets in one place, and your code to set signals and slots in another place.
Bad
Slow if you are new to Qt.
Does not enforce separation of layout from behavior.
Tips
Don't just jump into creating your windows. Start by quickly sketching several possible designs, either on paper or using a tool like Balsamiq Mockups. Though you could do this in Qt Designer, I think it is too tempting to spend a lot of time trying to get your windows to look just right before you've even decided if it is the best design.
If you use Qt Designer for PyQt, you have the extra step of running pyuic4 to compile your *.ui files to Python source files. I found it easy to forget this step and scratch my head for a second why my changes didn't work.
If you code your UI by hand, I suggest putting your layout code in one place and your signals and slots in another place. Doing this makes it easier to change the way your widgets are arranged on a window without affecting any of your application logic. Or you can change some behavior without having to wade through all the layout code.
Enjoy Qt! Now that I am using Java Swing for work, I miss it.
I tend to layout dialogs using the designer but I do all the event handling stuff in the main code. I also do all the main windows, toolbars, menus in direct code.
The designer is just frustrating - a pity since decent drag and drop sizer based designers have been around for more than a decade
It depends on the number of different windows/panels you need for your application. If the number is small, use a graphical tool. It is much faster to get a few windows designed perfectly. If the number is large, the graphical tool can (and should) only be used for prototypes. You need to code the layout to be able to make application-wide changes at acceptable cost.
That includes creating a model of how the UI of the application works and dynamically adding and removing widgets at runtime. For an excellent example of such a model (in a different environment), take a look at the glamour model for creating object browsers.
I object to the suggestion that it is tricky/subjective (at least more than other development choices). It is easy to come up with criteria to decide on. Personal experience and preference are important for that, as they decide when the number of different windows should be considered small. The same goes for tool quality.
My personal opinion (just personal), all GUI based development distracts me too much, my imagination or my mind works very bad when i'm seeing gui objects, i prefer to hand-coding most the time because my imagination works better, you know, is like you were reading a book with no images... when i see nothing else than code its looks like i finish faster...
Second reason, i like c++ so much, so I see the good side of hand-coding, is that I keep my c++ practice no matter if I'm writing something redundant... Coding skill is improved when you only use text... Indeed, i could use nano or vim, but that is too far slow for debuging.
Hand-coding here ++vote
I use a combination of both:
I find for x,y coordinates, Designer is the way to go.
A lot of the other UI properties etc can be set in your code.
I think trying to do UI completely by hand-coding would be a very time consuming project. It's not as simple as setting up HTML tables.
Yes version 4 is bad, but people at work who have used version 3 said it was REALLY bad. Lots of crashing.
I, along with my fellow QTers, are truly hoping that version 5 will be an improvement.
I know this is an old question, but I hope this helps! One man's experience.