we're maintaining some Qt applications which are running on Linux and Windows desktops. Now, we want to make the applications more attractive by adding customized forms and reports for each customer or at least groups of customers. There may be 10 or more different versions needed.
As we come from Qt, we are wondering how to manage so many configurations and if there already is a framework/development system that would help us here. We were looking at QML/Qt Quick, WT Toolkit or even NC Reports for the reporting part.
Managing configurations and deriving different versions from a base is not a feature which is discussed or promoted.
There should be a clean distinction between Display and Application Logic (Model/View)
Nice would be a textual GUI description, which enables us to release changes in forms or reports without the need to reinstall the whole applications (like QML seems to have that)
Also nice would be a kind of report generator, that helps to create forms and reports for new customers without the need to code them (and so releases our core developers from boring work)
Has somebody experience with such kind of customer based configurations? It would be nice to have a hint what's the best way to do this in the Qt surrounding.
I know comparisons like http://qt-project.org/doc/qt-5.1/qtdoc/topics-ui.html#comparison, but the specific questions that I have are not mentioned.
best regards
I guess you need to differentiate applications in three aspects:
1. appearance - if the application only differs in button color, icon image and background themes, qt's style sheet is light and convenient, you can choose to deploy different qss file and load different ones without recoding. if the variance among customers concerns layouts or available widgets (some has buttons, some use combo boxes, .etc), style sheet cannot meet the requirement, QML seems promising in such case.
business logic - i'm not sure how "generating reports" differs for different customers, if the reports need to be printed, or saved as document, i don't think qt provides good toolkit (QXXXDocument is not suitable to generate / display large amount of document), html? maybe. And i agree with #hyde that loading different plugins or dynamic libraries can solve this.
What I learnt from 8 month qt:
Model/View Architecture is there, for example a tree view that we fill with voyage data. the data is gatheres from several db tables, so we have a good logical distinction.
We hadn't the time to work us into qml, so we stuck with qt designer. It's quite easy, so we're fine with that. Delivering changes in customer forms without recompile will be a feature for a bigger future rework.
Same with report generators...
Related
I have a django app and I would like to display some graphical data visualization to my users. I am looking for an easy-to-use package that would allow me to add graphs and widgets.
The kind of widget I want to build is a kind of speedometer dial that is red at one end and green at the other. As a user completes their job over the day, the graphic/widget adjusts itself. The dial moves from red to green.
I also want an S-curve graphic that shows the cumulative amount of work accomplished against planned. That is kind of an x/y line plot.
My question are: How easy is this to implement? Are there any add-ins libraries or packages that do this already? I am trying to keep my entire application open-source. I've seen a couple subscription services that do this type of thing, but I can't stomach the cost.
I don't mind using ajax or jquery to implement such a thing, but I would like the most elegant and maintainable solution.
Any advice or examples on how to tackle this project?
There are lots of good javascript libraries these days, but all require some effort to learn how to use. I have not found one that really is easy to use, I guess because everyone wants something different. My general experience has been the more effort you put into learning them, the more you get out.
Google has gauges: http://code.google.com/apis/chart/interactive/docs/gallery/gauge.html
Also
http://www.flotcharts.org/
http://philogb.github.com/jit/
http://www.highcharts.com/
http://www.jqplot.com/
Or really take control:
http://mbostock.github.com/protovis/
As first, see the following grid (https://www.djangopackages.com/grids/g/dashboard-applications/) on djangopackages.
Not sure if that's exactly what's asked for, but you might take a look at django-dash (https://pypi.python.org/pypi/django-dash).
It allows each user to make his own dashboard (from plugins available). Those dashboards can be made public.
Some screenshots (http://pythonhosted.org/django-dash/#screenshots).
It's modular and plugin based, so you need to make a plugin and widgets for every specific feature (in this particular case - the speedometer plugin and widgets for it). Each plugin/widget can include own JS/CSS when being rendered.
See the following chart usage examples:
D3.js integration examples (https://github.com/barseghyanartur/django-dash/tree/master/example/example/d3_samples).
Polychart2.js integration example (https://github.com/barseghyanartur/django-dash/blob/master/example/example/bar/).
protovis is no longer under active development, but they started a new poject: http://d3js.org/
You may choose from these packages:
https://www.djangopackages.com/search/?q=dash
I've been using Redmine for almost a year to manage my startup. I have all issues stored in one project with two subprojects for areas that I had to outsource and didn't want to give the contractor access to the main project issues. My problem is that I have ended up with hundreds of issues which all vary greatly in the time required to implement them. Some are small e.g.'Fix bug in controller', 'Add telephone number to contact us page' etc and some require much more effort e.g. 'Create a new Q&A area', 'Migrate server to nginx', and some are more abstract e.g. 'Investigate new SEO opportunities', 'Consider implementing a reseller control panel' etc.
I feel like I must be using Redmine incorrectly as having these all mixed together is a bit confusing. Any ideas on how I could better organize would be greatly appreciated. If supplementing with other tools might be a better idea I'd love to hear suggestions.
I don't think there is a problem having all the issues you mentioned mixed together in a project as long as they're all related to the project.
The most important point when using redmine with projects having lots of issues is to make use of custom queries. This is a great feature, but in order to ba able to use it, you must also use and fill in other fields:
Tracker: Make use of different trackers (the default of bugs, features and tasks works for me)
Category: Can be a specific part of your software, or other aspects of your business (administration, IT/server, ...)
Version: Use the version to group different issues, usually used for a release, but can also be ideas or unplanned
Of course priority and Due Date - I often use them for ordering, but you may create a custom query of issues du in the next 2 weeks
Assignee is usually the most important if there is more than one user - first of all you'll want to see the issues assigned to you, as well as the issues created by you (in order to follow-up)
You can always add custom fields in case you have other information which may be used to filter your issues.
Once a set of custom queries are in place, you'll hardly consult all your open issues at once anymore.
Two little used features for redmine newbies are categories and custom fields.
Categories are usually used for modules in your project ("Database", "Front End", "Administration Panel", etc.) and you can use custom fields for anything else you find useful - i.e. Create a "Time Consumer (Estimated)" custom field as a list with "Whale (Weeks)", "Elephant (days)", "Tiger (Hours)", "Monkey (About an hour)", "Mouse (Minutes)".
I just started to look into Sitecore and I was wondering if anyone can help me enlighten what / how it is exactly from a developer perspective.
I've gone through bunch of their documentation and also their SDN - seems to me so far most of them are just drag/drop click here and there through their interface (ie. through their "Sitecore Desktop") with very minor actual programming.
Is this true? or are their actual C# / ASP.Net programming behind the scene to implement business logic and such?
I went through their basic tutorial (creating basic site for Product), and like I mentioned above, it's all mostly done through their interface without any real programming - as opposed to working with the ASP.Net MVC3 Music Store tutorial where you can see some C# programming.
Thanks!
A Sitecore developer should have the most intense and deepest understanding of Sitecore in general. Developers need to understand the CMS user's perspective (i.e. content editor's POV), they need to understand the architecture of content within the content tree, and they need to know the code, which they build. A developer should have the most intimate knowledge of a Sitecore solution because you need to know the architecture to know how to code. And to know the architecture means you know how content editors will interact with the content.
Architecture
Sitecore is a souped up database. Think of it like that. You can architecture a site how you want. But once you start to learn the principles of Sitecore architecture and best practices you'll notice a pattern. Everything in the content tree is an item. The model for each item (called a template in Sitecore terms) is defined by an architect (which is often often a developer). In fact, even if there's a separate person for the architect role, they likely have developer knowledge as architecture defines the way things are developed. In fact, the architecture is one of the most important things.
Code
Code is broken down into various types, but in its simplest form there are two main things: layouts and sublayouts.
Think of a layout as what a normal a ASP.NET application uses a MasterPage for. In Sitecore, a layout is actually a ASPX WebForm, but it acts as a master page. Some examples of layouts you could have on your site are: One Column Layout, Two Column Layout, Print Layout. These would respectively translate to a header and footer with one main content area, a header and footer with a main column and side bar, and a print-optimized layout with maybe a logo and just main content.
Sublayouts are all of the little components that make up a page. Examples include: main navigation, a promo box in your side bar, a list of 5 recent news pieces, a CTA for a promotion, a sidebar slide show, etc. These components could be modular and moved around by content editors, or they can be fixed within the location of layouts, e.g. a promo box could always appear in the sidebar of the Two Column layout as a business rule defined in the code.
To answer your question about is there actual coding, yes. You write code using ASP.NET controls for Sitecore and Sitecore's C# API to access data that is populated into the templates on each item. So, if you had an item for a page that had a page title for the title tag, your code would use the Sitecore API to access the field "Title Tag" from the template (remember a template in Sitecore speak is a data model) in Sitecore.
Coding For Sitecore
I'd say there are two approaches to coding. I believe you identified one of them, which is using the internal tools within Sitecore's interface. Sitecore has a section called Developer Center that lets you create layouts and sublayouts. Frankly, compare this to using Visual Studio in Design Mode all of the time. I have never once used the Developer Center to do my coding. Instead, I code in Visual Studio which is the most common technique for people to code for Sitecore (at least I think it is). Now if you're wondering, how does the coding connect to Sitecore's data... well the answer is within Sitecore. There's a section of the tree called Layouts. In here are the names of your layouts and sublayouts. Each layout and sublayout item has a path that maps to either a ASPX WebForm or ASCX User Control, respectively. This is how the code on the file system that you write in Visual Studio actually gets used by Sitecore. These layout and sublayout items are then used via the Presentation > Details tabs for each item in Sitecore.
Beginners
One of the hardest things with Sitecore is the learning curve. I've been using Sitecore for years now and love it. In fact, its all I really do. It's by far my favorite CMS as its completely customizable and very developer-friendly. Sitecore recommends that new developers take the developer training classes so they can basically explain what I explained above in an actual training curriculum. In this training you will learn the architecture, and then how the code connects to it. Training involves hand-on architecture work within the content tree and hands-on coding. The recommend training courses for new developers are:
Getting Started With Sitecore Development: Sitecore XP 8 Website Development for .NET Developers (4 days, certification)
Further Training for Sitecore Certified Developers - Sitecore XP 8 Livefire MVC Workshop (1 day, no certification)
Sitecore is an ASP.NET application. That means that you can write any code you like. Our team creates all of the Sublayouts (ASCX files) and Layouts (ASPX files) ourselves in Visual Studio, not the editors built in to Sitecore.
Some installations of Sitecore that I have seen barely rely on the CMS to do the rendering. Instead values are pulled via the codebehind as if Sitecore was just a database. That can work fine in some situations.
The most impressive Sitecore instances use all of the available tools that the developer has access to. Using the Sitecore tools the way they were designed to be used allows some pretty impressive editing options for the (often non-technical) content editors.
For example: Using a Sitecore Fieldrenderer instead of just a placeholder or label will not only automatically render content appropriately (whether they are images or rich text), but it will allow the content editor to edit the content right on the web page as opposed to the only on back end that all CMS systems have.
Workflow is another killer feature for a customer that is the right size to afford Sitecore. It lets you build an approval process for items in the tree. That way legal, marketing and the graphics team call all sign off on a new page before it goes live. Then when all of the approvals are finalized, the site publishes automatically.
To sum up: Sitecore is a .NET application, you can code whatever you want. That means you should focus on the CMS features and make sure it is a good fit for you from a content editor perspective and a financial perspective.
Sitecore is in most cases just drag & drop as you've described in terms of content authoring but to actually turn this content into a webpage you need to implement layouts, sublayouts and so on.
Layouts are generic ASP.NET pages (aspx), sublayouts are just web controls (ascx) and if you prefer you can also use XSLT to generate HTML but it's useful only for basics (Sitecore only supports XSLT 1 at this moment). These ASP.NET controls are more less the same as standard web forms controls with code behind and so on. The difference is that Sitecore is your datasource and it gives you an APIs to access all relevant applications.
But Sitecore APIs also goes beyond that and allows you programatic access to virtually any component of the framework. The APIs are well docummented and quite easy to understand and they can be used for more complex scenarios.
Latest version of Sitecore (6.4) allows you to also use MVC framework for layouts/sublayouts creation if you don't like web forms that much.
Layouts and sublayouts are a great way todo any customizations from a coding standpoint but there is a third way that is not mentioned here. We call it sitecore extensions. I often find that to meet customer requirements, creating custom assembly's for workflow actions or template commands is the only way.
For example, a standard email notification upon entry into a workflow state only allows for you to apply server, recipient, description etc.. to action item field. In our case these values constantly change so we need to be more dynamic. A custom assembly applied to the action allows us the flexibility to do a number of things that the standard action will not. Another example was that we needed to have a treelist in an item scroll to and highlight the current item. The way todo this was to override the core treelist action with our custom assembly.
Keep in mind that adding alot of code to the layout (which could be a master page for a ton of pages) ramps up the runtime overhead.
From a UX perspective, Sitecore is impractical, overpowered and too complex to be effectively implemented for teams with typical content contributors and editors. No thought has been put into streamlining content creation or simple page template maintenance. I would never recommend Sitecore to a team without:
HTML authoring/editing skills
FTP concepts & Site tree understanding
Data management skills
The system is built for developers, with users as a very distant after-thought. In my experience, it offers a huge number of benefits — being a usable system for every-day content authors is not one of those benefits. The system is so modular and over-managed, it forces users on every level to make decisions that only complicate otherwise simple operations. Content publishing is extremely modular, and a big benefit for developers; it is a catastrophe for everyday users.
If you're a developer, Sitecore is a wonderful building environment. It's powerful and flexible.
If you're a user, Sitecore is task-heavy and offers the steepest learning curve I've ever encountered with a CMS. UAT has been a nightmare.
We currently maintain a suit of MFC applications that are fairly well designed, however the user interface is beginning to look tired and a lot of the code is in need quite a bit of refactoring to tidy up some duplication and/or performance problems. We make use of quite a few custom controls that handle all their own drawing (all written using MFC).
Recently I've been doing more research into Qt and the benefits it provides (cross-platform and supports what you might call a more "professional" looking framework for UI development).
My question is - what would be the best approach to perhaps moving to the Qt framework? Does Qt play nice with MFC? Would it be better to start porting some of our custom controls to Qt and gradually integrate more and more into our existing MFC apps? (is this possible?).
Any advice or previous experience is appreciated.
In my company, we are currently using Qt and are very happy with it.
I personnally never had to move a MFC-app into using the Qt framework, but here is something which might be of some interest for you :
Qt/MFC Migration Framework
Qt/MFC Migration Framework
It's part of Qt-Solutions, so this means you'll have to buy a Qt license along with a Qt-Solutions license. (edit: not any more)
I hope this helps !
(This doesn't really answer your specific questions but...)
I haven't personally used Qt, but it's not free for commercial Windows development.
Have you looked at wxWindows which is free? Nice article here. Just as an aside, if you wanted a single code base for all platforms, then you may have to migrate away from MFC - I am pretty sure (someone will correct if wrong) that MFC only targets Windows.
One other option would be to look at the Feature Pack update to MFC in SP1 of VS2008 - it includes access to new controls, including the Office style ribbon controls.
It's a tricky problem, and I suspect that the answer depends on how much time you have. You will get a much better result if you port your custom controls to Qt - if you use the QStyle classes to do the actual drawing then you'll end up with theme-able code right out of the box.
In general, my advice would be to bite the bullet and go the whole way at once. Sure, it might take longer, but the alternative is to spend an age trying to debug code that doesn't quite play ball, and end up writing more code to deal with minor incompatibilities between the two systems (been there, done that).
So, to summarise, my advice is to start a branch and rip out all your old MFC code and replace it with Qt. You'll get platform independence (almost) for free, and while it will take a while, you'll end up with a much nicer product at the end of it.
One final word of warning: make sure you take the time to understand the "Qt way of doing things" - in some cases it can be quite different to the MFC approach - the last thing you want to do is to end up with MFC-style Qt code.
I have lead a team doing this kind of thing before (not MFC to QT but the principles should work).
First we documented the dialogs and what their inputs, controls and outputs were. Also, we create several test cases especially for any clever logic inside the GUI.
Sometimes we had to refactor some business logic to provide a clean interface the GUIs but this is the way it should have been done in the first place tbh.
Now we had a list of GUIs, inputs, outputs, tests and an interface that the encapsulated GUI had to match.
We began, project by project, to create equivilant GUIs to the old ones. Once we did that we could slot the GUI in where the old one was, rebuild and test it. At first we tripped a lot but we soon worked out the common errors and fixed them. We navigated (I think) 612 dialogs although there was a team of about a dozen of us working on it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm spending these holidays learning to write Qt applications. I was reading about Qt Designer just a few hours ago, which made me wonder : what do people writing real world applications in Qt use to design their GUIs? In fact, how do people design GUIs in general?
I, for one, found that writing the code by hand was conceptually simpler than using Qt Designer, although for complex GUIs Designer might make sense. Large GUIs might be possible using Designer, but with time they might become very difficult to manage as complexity increases (this is just my opinion). I also downloaded the AmaroK source code to take a peek at what those guys were doing, and found many calls to addWidget() and friends, but none of those XML files created by Designer (aside: AmaroK has to be my favorite application ever on any platform).
What, then, is the "right" way to create a GUI? Designer or code? Let us, for this discussion, consider the following types of GUIs :
Simple dialogs that just need to take input, show some result and exit. Let's assume an application that takes a YouTube URL and downloads the video to the user's hard disk. The sort of applications a newbie is likely to start out with.
Intermediate level GUIs like, say, a sticky notes editor with a few toolbar/menu items. Let's take xPad for example (http://getxpad.com/). I'd say most applications falling in the category of "utilities".
Very complex GUIs, like AmaroK or OpenOffice. You know 'em when you see 'em because they make your eyes bleed.
Our experience with Designer started in Qt3.
Qt3
At that point, Designer was useful mainly to generate code that you would then compile into your application. We started using for that purpose but with all generated code, once you edit it, you can no longer go back and regenerate it without losing your edits. We ended up just taking the generated code and doing everything by hand henceforth.
Qt4
Qt4 has improved on Designer significantly. No longer does it only generate code, but you can dynamically load in your Designer files (in xml) and dynamically connect them to the running objects in your program -- no generated code however, you do have to name the items in Designer and stick with the names to not break your code.
My assessment is that it's nowhere near as useful as Interface Builder on Mac OS X, but at this point, I could see using the Designer files directly in a program.
We haven't moved back to Designer since Qt3, but still use it to prototype, and debug layouts.
For your problems:
You could probably get away with using the standard dialogs that Qt offers.
QInputDialog or if you subclass QDialog, make sure to use QButtonDialogBox
to make sure your buttons have the proper platform-layout.
You could probably do something more limited like xPad with limited Designer functionality.
I wouldn't think you could write something like OpenOffice solely with Designer but maybe that's not the point.
I'd use Designer as another tool, just like your text editor. Once you find the limitations, try a different tool for that new problem. I totally agree with Steve S that one advantage of Designer is that someone else who's not a programmer can do the layout.
In my experience with Qt Designer and other toolkits/UI-tools:
UI tools speed up the work.
UI tools make it easier to tweak the layout later.
UI tools make it easier/possible for non-programmers to work on the UI design.
Complexity can often be dealt with in a UI tool by breaking the design into multiple UI files. Include small logical groups of components in each file and treat each group as a single widget that is used to build the complete UI. Qt Designer's concept of promoted widgets can help with this.
I haven't found that the scale of the project makes any difference. Your experience may vary.
The files created with UI tools (I guess you could write them by hand if you really wanted to) can often be dynamically loaded at run-time (Qt and GTK+ both provide this feature). This means that you can make layout changes and test them without recompiling.
Ultimately, I think both raw code and UI tools can be effective. It probably depends a lot on the environment, the toolkit/UI-tool, and of course personal preference. I like UI tools because they get me up and running fast and allow easy changes later.
The organisation I work for has ported its GUI application to Qt several years ago.
I think there are several aspects that are worth mentioning:
Working with Qt Designer, at least at that point, was not a realistic option: there were too many features that couldn't be done with Qt Designer;
Conventions and structure that had to be preserved prevented the use of Qt Designer;
Once you've started without Designer, it is probably difficult to return to it;
the most important aspect, though, was that the programmers were very much used to programming using vi or emacs, rather than using a GUI IDE.
My own experience, which goes back approx. 4 years, using Qt3.3, is that dynamic behavior in dialogs was not possible to realise in Designer.
Just to say I've written and maintained complex GUIs in Qt without using Qt Designer -- not because I don't like Qt Designer, but because I never got around to working that way.
It's partly a matter of style and where you're coming from: when I started on Qt, I'd had horrible experiences of Dreamweaver and Frontpage and other visual HTML tools,and far preferred writing code with HomeSite and resorting to Photoshop for tricky layout problems.
There's a danger with visual code IDEs that you try to keep within the visual tools, but end up having to tweak code as well -- in ways that aren't well understood.
Learning iPhone development, for example, I've found it frustrating to hit 'magic' visual stuff ('drag from the empty circle in the Connections inspector to the object in the Interface Builder window...') that would be simpler (for me) to understand in plain old code.
Good luck with Qt -- it's a great toolkit, however you use it, and Qt Creator looks like being a great IDE.
I'd add that one of the reasons for using graphical designer was the lack of layout managers in Win32, for instance. Only absolute positioning was possible, and doing that by hand would have just sucked.
Since I switched from Delphi to Java for GUI apps (back in 2002), I've never used designers any more. I like layout managers much more. And yeah, you get boilerplate code, but moving objects on a UI designer may take as much time as changing the boilerplate. Plus, I would be stuck with a slow IDE; that's for the Java/C# case, OK, while for Qt (especially Qt4) it doesn't apply. For Qt3, I wonder why one should edit the generated code - wasn't it possible to add code in other files? For which reason?
About the discussed cases:
1) Hand Coded GUI is likely faster to write, at least if you know your libraries. If you're a newbie and you don't know them, you may save time and learn less with a designer, since you don't need to learn the APIs you use. But "learn less" is the key factor, so in both cases I'd say Hand Coded GUI.
2) Menu bars are quite annoying to write code for. Also, think to details like accelerators and so on. Still, it depends on what you're used to. After some time, it may be faster to type that boilerplate than to point-and-click into designer to fix all those properties, but just if you can really type like into a typewriter (like those admins for which typing Unix commands is faster than using any GUI).
3) I'd extend the answer for case #2 to this one. Note that, for Win32 platforms, it may be possible that using designers which generate Win32 resources might be faster to load (no idea about that).
However, I'd like to mention a potential problem with using Qt Designer there. Real world case: it took some seconds (say 10) to load a complex Java dialog (the Preferences dialog box for a programmer's text editor) with a lot of options. The correct fix would have been to load each of the tabs only when the programmer wanted to see them (I realized that after), by adding a separate method to each preference set to build its GUI.
If you design all the tabs and the tab switcher together with a designer, can you do that as easily? I guess there might be a similar example where a hand coded GUI gives you more flexibility, and in such a big app, you're likely to need that, even if just for optimization purposes.
One of the main benefits of using designer to create GUIs is that other programmers can change or maintain forms and widgets easily without the need to delve in to a complex code.
Its strange that you're saying the writing code is simpler than manipulating objects in a graphical environment. It's a no-brainer.
The designer is there to make your life easier and in the long term it makes your code more maintainable. It's easier looking in the designer to see what the your UI looks like then reading the code and trying to imagine what it might look like.
With current Qt you can do almost everything from within the designer and the very few things you can't do, you can fix with very few lines of code in the constructor.
Take for instance the simplest example - adding a signal-slot connection. Using the designer it's as simple as a double click. Without the designer you need to go lookup the correct signature of the signal, edit the .h file and then edit write your code in the .cpp file. The designer allows you to be above these details and focus on what really matters - the functionality of your application.
I like to first turn to the designer to develop GUI widgets. As mentioned in the other posts, its faster. You also get immediate feedback to see if it "looks right" and isn't confusing to the user. The designer is a major reason I choose Qt over other toolkits.
I mostly use the designer to make the one-off dialogs.
Having said that, I do the main window and any complex widgets by hand.
I think this is the way Trolltech intended. QFormLayout is a class they provide to easily programatically create an input dialog.
By the way, the designer in Qt 4 is not an IDE like the one they had in Qt 3. It's just an editor for editing .ui files. I like it that way. The new cross platform IDE is going to be called Qt Creator.
It's an old post but I would advise you to look at Clementine - a music player which (I think) derives from Amarok. They use Qt4 and from what I can see there is a ui folder in the src folder of the project. In the ui folder as one might expect they have all sorts of .ui files. If you compile and start Clementine you will see that the GUI is fairly complex and quite nice.
For me, it depends how much logic is encapsulated in the widget/GUI. If it's just about simple forms, I prefer to use QtDesigner.
If it contains complex checks or interaction, I tend to program it.
We're using the Qt Designer if anyone needs to create a Gui.
The thing is to create just little Widgets for certain tasks (like you would do in a class-design) and then get them together into a "parent-gui".
This way your widgets are highly reusable and could be used for Guis in a modular way. You just have to specify which signals each Widget is sending and which slots they provide.
We additionally are creating .ui-Files which than could be generated during build-process. Until now there was no need to edit those files by hand.
Build different parts of your UI
in different .ui files using QtDesigner,
then bring them together (and add complications) in code.
There are things you can't do in Qt Designer, you can only do in code,
so Qt Designer is just one (great) part of the tool chain.