I am going to code a text/code editor (GUI with QML and the rest in D*). But I have several problems:
I code the GUI with QML and C++ and then I connect it with a D-Backend for formatting etc. purposes. What is the best way to connect different Languages? Pipes, Sockets or in D the ability to use C++ Libraries?
IMHO rich text is used to format the text (in most cases). How is it possible to edit this "markup" in an easy way?? Is the formated code like a background image and the user edits an opaque non-formated-text?
Are there common techniques?
*Because QML is cool, platform indepedent and fast. On the other hand D is powerful and easy to use.
As you might know, there is QtD, Qt binding for D. It's not production ready right now, but it might be some day.
Another option would be connecting C++ and D, through C wrapper. This is the most commonly used way of interacting between C++ and D.
extern(C++) interfaces are specific to DigitalMars C++ compiler on Windows and are very limited, so that probably wouldn't help with your problem.
Also you might want to look at SWIG. It's a tool automatically generating glue code for interaction of other languages with C++. It supports D.
If performance is not an issue communications with D code could work through sockets or pipes.
QML isn't for WebApp. It s QtQuick Markup Language. The 'new' way to do UI at Qt. And QWidget will probably be deprecated in favor of QML in Qt5.
I've try to do the same thing. But i fear that qml isn't ready yet to do things like that. Most element available today are just good enought to draw image, rectangle, listview, one line text input and do transition.
I was trying to achieve that by coloring with python and pygments, too slow, using html3.2 style to do that isn't the right way. But it's the only way to style text in qml textedit. ;(
QtQuick 2.0 should bring better text control.
Related
My long term goal is to make HCI development for embedded devices, and by embedded I really mean it, not phone devices.
I've been working on Qt Widgets for a month now, avoiding Qt Quick for some reasons (I feared that QML code wasn't optimize), but yesterday I have watched this video :Youtube
The speaker says at the end : "If you're making an embedded product these days, use Qt Quick, especially now in 5.8. There's no excuse not to use Qt Quick"
But on the contrary, he explains that for embedded devices we should use c++ code, not JavaScript.
I don't really get it, does it means that I have to create all my objects in c++ code and make my architecture using Qt Quick ?
I don't really get what Qt want us to do. Is it just communication, since they don't want to optimize the old and stable Qt widgets, or is Qt Quick really the solution for embedded devices ?
I personally think that Qt is not the solution for embedded devices, as they keep evolving, changing strategy, and seems not to know where they are going.
I apologize for this non-algorithmic question, and thank you for all your answers.
I can't speak to the developer's intent, nor can I speak for other developers. I can only speak to what I understand, as a developer that has been designing embedded devices for 40 years (sorry for being a number dropper).
C++ or JavaScript? I don't feel that question has too much to do with whether you use QtQuick or not. Sure, you can embed some JaveScript in QML code (with limitations), but you can also use C++ in the same code base (just not embedded in the QML). Then there's Python. Both Qt and QtQuick are programming frameworks, and are somewhat language agnostic.
My perspective is that QtQuick is a good, portable way to create your user-interface code. In my current project (a multi-axis industrial servo-control system) I use QML for the user-interface (with a little JavaScript where needed), C++ for the bulk of the higher level processing (like network control and data-streaming), C and assembly language for the lower levels (those routines executed in uC's and DSP's). QML and C++ interface together nicely, in my opinion.
I believe the speaker is getting at the idea that most if not all your business logic should be done using a C++ model back-end. It is possible to do all your logic just in QML with embedded JavaScript however, because JS is an interpreted language its performance at run-time can possibly be less than compiled C++ code(dependent on how well the C++ is written).
Essentially you only want to use JS to manipulate graphical components while using C++ with QObject models to update the QtQuick elements' individual properties.
This is mentioned in the Qt Quick Best Practices wiki,
https://wiki.qt.io/Qt_Quick_Best_Practices
I'm designing a cross-platform map editor for an application I've developed, and I'm unsure what approach to take regarding language/gui library choice. Just for some basic info, the editor needs to parse and output xml files.
I'm most comfortable with C++, Lua, and Perl, but I'd also be willing to use Python (could use the practice). I'd prefer doing it in a scripting language for productivity.
Any recommendations are appreciated, thanks.
I'd also like support for filling out forms, etc.
P.S. I've tested out extending existing map editors but it isn't really worth it since they don't provide the functionality I need on a fundamental level, requiring me to just re-write the whole thing anyway.
My preference is always Gtk2 and Perl 5, but that combination works best on Linux. What OS are you going to run under?
Here is an example Perl 5 script using Gtk2:
#!/usr/bin/perl
use strict;
use warnings;
use Gtk2;
Gtk2->init;
my $window = Gtk2::Window->new;
my $vbox = Gtk2::VBox->new;
my $label = Gtk2::Label->new("click the button");
my $button = Gtk2::Button->new("click me");
my $i;
$window->signal_connect(destroy => sub { Gtk2->main_quit });
$button->signal_connect(clicked => sub { $label->set_text(++$i) });
$window->add($vbox);
$vbox->add($label);
$vbox->add($button);
$window->show_all;
Gtk2->main;
I can recommend using Python and PyQt for the job. Qt offers a class for scene management (i.e. layered object placement, zooming, hit testing, events,coordinate transformations etc., even collision detection) called QGraphicsScene and a matching control to display it all, called QGraphicsView. It also offers support for drag&drop, thus enabling interactive object placement.
Implementing a map using these classes really is just creating QGraphicItems (Rectangles, Polygons etc.) and adding them to the scene, Qt does the rest. You can have a look at how it all fits together reading the documentation, especially the document "The Graphics View Framework". I had to implement something similar for a client recently and was very pleased with this approach.
Building on the base of Lua, I would recommend IUP for the GUI. It is lightweight, portable to linux and Windows, and well integrated with Lua. For those who like Gtk, IUP includes a driver for Gtk so it can in principle be ported to any system where Gtk can port.
Another plausible choice is wxWidgets, which also has a wrapper integrating it with Lua.
Both IUP and wxWidgets are included in the Lua for Windows bundle.
For my school project, I would like to build a gui that someone else can use to create a gui. Upon some research I saw lot of gui builders but didn't see anything along the lines of what I am looking for.
But then I did find a tutorial using C# on here
I rather create this gui editor for linux environment.
Any suggestions to where I should start? what tools I can use? Any links to any tutorials?
Any help/direction would be greatly appreciated.
P.S. I would like to add that it only needs to be very simple. like few text input fields and some button type fields that user can arrange in the order desired.
I would recommend that you not try to build your own GUI builder. It is a daunting task that you will not be able to accomplish as a school project. C++ is fully-compiled, which means that it lacks almost every feature that enables people to build meta-tools (like GUI editors) for it. This mainly has to do with the fact that C++ does not have runtime reflection (natively, anyway). Beyond that, there is no "one GUI toolkit and/or paradigm to rule them all." This makes your problem incredibly difficult to deal with.
So: I would recommend Qt, because it works on a ton of platforms, is easy to use and is just plain awesome. You could also look at the billions of other GUI toolkits like Gtk+, Tk, FLTK, YAAF, GLUI, dlib, CLX...
I'm aware that this does not actually answer the question. However, I do not think that the author is aware of how incredibly difficult the task he has set in front of himself is.
I would recommend starting by implementing it like an interpreter. Start with a very simple command line tool that takes commands like window(300, 400, "window1") and button(50,100, "button1") etc and output the code (native or whatever other GUI code you want), to a file. The goal should be to output a file that can be run and show the GUI that was designed. Once you have that, build a GUI that uses the command line functions as a back-end.
I don't have any exact links to this, but here's an example of what you could do. Gtk has the option of loading a GUI by using a class called GtkBuilder. Glade (the usual Gtk gui editor) has support for outputting it's result as an XML file that the GtkBuilder class then reads.
It would be possible for your program to output an equivalently formed XML file that GtkBuilder could read.
I have no clue as to how difficult it would be to target that XML though.
You should use GTK+ or Qt if you are targeting the linux environment. I think the first step is to learn how to program gui, which takes some time considering you are writing c/c++ code wich is different from higher level languages. Don't you think learning to code gui programs and writing a gui builder at the same time is a little bit too much.? First you should master the basics about gui and then go on to harder projects.
Here's a link to an excellent book on gtk. (Foundations of gtk+ development - Andrew Krause)
http://books.google.com/books?id=L1BZZYRrqSgC&printsec=frontcover&dq=foundations+krause&hl=es&cd=1#v=onepage&q=&f=false
And here's a great tutorial/cookbook for gtk+.
http://zetcode.com/tutorials/gtktutorial/
The official documentation is on library.gnome.org
My final advice is learn one thing at a time.
I am trying to create some charts of data (eg http://www.amibroker.com/). Is there a C++ library that can do this without a lot of extra work? I'm thinking Qt or wxWindows would have something like it, but it wasn't immediately obvious.
Thanks!
FLTK is a light and portable C++ toolkit for GUI. There's a chart class. Sample.
Qwt does at least some of the things you are trying to achieve (basic plots, bar charts and so on), and integrates well with Qt.
I think you need to pick your GUI framework first, then find a charting control for the given framework, since that affects what charting controls you could feasibly use. For example, must this be portable?
For the project I'm working on (a large MFC application) we use Cedric Moonen's ChartCtrl. We've had a pretty good experience with it so far.
I've done some graph plotting with gnuplot lately, which is quite powerful. Although I think it is Linux only, which may or may not be a problem.
Also, believe it or not, some amazing things can be done with LaTeX. I've used the tkz (tikz) library to produce some awesome graphs.
Both solutions plot to a file which you can include in your interface.
They aren't C++ libraries but you can easily create the datafiles and call the necessary programs from within your C++ program (Being creative with system() and possible some shell scripts).
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.