I have tested QML&javascript performance. It looks like works not very well if QML UI control is complex.
Just wonder if it is possible to bind javascript and qtwidgets?
Your comment welcome
I found following project that generates Qt bindings for Qt Script. I haven't tried it though.
https://code.google.com/p/qtscriptgenerator/
It is recommended that Javascript code should be kept to a minimum. Since it is bad for performance as you mentioned, especially when it is run during animation. I don't know what you are up to, but it would be better to implement UI with QML(minimum Javascript) and logic with Qt (C++).
Related
I would like to know if it's possible to load stylesheets a lot faster than using my method in a Qt app.
Here my codes:
this->setStyleSheet("background-color : black;");
Took 270 ms to execute this simple css/qss styling.
With a lot bigger qss styling using this import method
QFile file("style.qss");
if(!file.open(QFile::ReadOnly)){
qDebug() << "Style QSS file not found";
}
css = QString::fromLatin1(file.readAll());
file.close();
this command
this->setStyleSheet(css);
took 330ms so it's not that bad considering the difference of css styling blocks executed.
So it looks like the init of the setStyleShet command is very long.
My question is: Is there a way of speeding up this command (by not using Qstring, other import methods,....) or by threading ?
For me it's huge because I need to update often my stylesheets and it's taking as much time as all my logic executed.
Thanks.
Have a nice day :)
Found this method :
this->style()->unpolish(this); //"this" is my main window
this->style()->polish(this);
this->update();
instead of :
this->setStyleSheet(css);
It's incredibly fast ! (0-1 ms vs 150-200ms)
Solution was there: http://qt-project.org/doc/qt-4.8/stylesheet-syntax.html#note-233
In Linux there can be some serious performance hits using stylesheets. Here's some information:
http://kjellkod.wordpress.com/2011/05/22/moving-to-qt5-will-that-remove-qts-performance-issues-on-linux/
You can try switching your graphics rendering engine to raster. You can do this a few different ways. The easiest way to test it is to set it via command line argument when running your app:
yourApp -graphicssystem raster
To do it in code here's the API:
http://doc.qt.digia.com/4.5-snapshot/qapplication.html#setGraphicsSystem
Although I use CSS in QT a lot I still have concerns about if extensive CSS is a right thing to do in Qt..
I would strongly suggest try to limit CSS usage or at least think very carefully then designing them..
Especially for complex application with a lot of controls and complicated layouts you should be very very careful in using them if you target cross-platforms environments. It's indeed very fast way to go if you need to 'paint' nicely an application targeting only Win32 or MacOSX for example, but running same CSS on other platform could result in even more uglier UI then using native controls.
Then you start working on interfaces where 'each pixel matters' you will see that even basic layouts in Qt has mistakes and adding on top CSS engine which also full of 'small' bugs could lead to even more unpredictable results and development time.
Regarding your question - setting a global CSS on an application level is a fastest thing you can get, BUT remember that it will be inherited within all application widgets so in case you need something different you will have to create special rules.
I tried the polish & unpolish method, but not worked. In the end, I tried qApp->setStyleSheet("style.."); if it’s a small project it worked.
you can reference another similar answer, using dynamic stylesheet as Ton van den Heuvel answered, and replace pushButton->setStyle(QApplication::style()); by widget
->setStyle(widget->style())
wish it will help :)
I want to know which way is efficient if I am having number of UI forms. I don have any idea about memory utilization in both of case I just tried both ways in a simple example.
http://qt-project.org/doc/qt-4.8/designer-using-a-ui-file.html here they described both ways.
Now which one method is more efficient?
I want to know which way is efficient if I am having number of UI forms
Take a look at this thread: Hand Coded GUI Versus Qt Designer GUI (Hand Coded GUI Versus Qt Designer GUI)
I don have any idea about memory utilization in both of case
This is the same in both cases. Apart from that you don't need to care of it if your class is derived from QObject.
UI files are just a simpler way to generate more Qt correct layouts. It's also much easier to work with designer than to hand code your UI and designer allows for previewing your changes so no generation and compilation needed in most cases. Also, designer allows you to insert your custom widgets using the "Promote to..." option in the context menu for each widget.
The net result of designer code may look messier but it's exactly the same as you manually laying out and is much less prone to error.
I'm scratching my head on how to accomplish the following task: I need to write a simple web forms filler/submitter with QT C++, it does the following:
1) Loads page url
2) Fills in form fields
3) Submits the form
Sounds easy, but I'm a web developer and can't find the way how to make QT accomplish the task, I only managed to load url with QWebView object using WebKit, have no idea what to do next, how to fill in fields and submit forms. Any hints, tutorials, videos? I appreciate this.
QWebElement class does all the work, just reading through the class documentation gave me a full idea on how to accomplish my task. Thanks to eveyrone for suggestions.
The best solution would be to write the logic in JavaScript that does what you want and then inject it into the page using QWebFrame::evaluateJavaScript() after it finishes loading.
There's also another way to do this; involving the document tree traversal API that's been available in QtWebKit since 4.6: QWebElement. You'd basically process the form pretty much the same as you would do in JavaScript, except that here the API is different and more limited. It's C++ though and might be a little bit faster. I guess, this approach might be less attractive for you, given you're a web developer and probably already know JavaScript.
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.
I am a quite new to web development and I am trying to do some small form updates without causing a postback. For example making a control visible when a drop down list is changed.
I have so far come across some features that achieve this like the RequiredFieldValidator inside an update panels. However, these are specific to a single task.
What are my options to achieve these client side updates in Visual Studio? At the moment I don't know any JavaScript, so I would prefer another solution if it exists.
If you don't know JQuery you should or at least any other Javascript library this will give you an edge and also pump up your resume. The learning curve of these JS frameworks is so short that you'll be creating awesome UI's in no time. I suggest that you take at least two hours to get to know JQuery you won't regret it.
Here's a few great article on using ASP.NET with JQuery:
http://dotnetslackers.com/articles/ajax/using-jquery-with-asp-net.aspx
http://www.dotnetspark.com/kb/1532-gridview-and-jquery-asp-net-tutorial.aspx
http://www.beansoftware.com/ASP.NET-Tutorials/Using-jQuery-ASP.NET.aspx
Here are a few of the best tutorials on JQuery:
http://www.ajaxline.com/best-jquery-tutorials-march-2010
For display functionality like you have described, javascript really is the best solution. Take a look at jQuery, it makes writing javascript a lot easier, and you should be up and running with it in no time for tasks like your basic show/hide functionality.
Unfortunately, AJAX stands for 'Asynchronous Javascript and XML' so getting this behaviour without using Javascript is going to land you in a bit of a pickle.
Update Panels do work and are very easy, but they're also very slow in comparison as even if you only see the contents of your panel update, the entire ASP page has to be executed.
I'd urge you to take a deep breath and head over to JQuery.Com and practise the tutorials there. Javascript is easier then you think and JQuery takes a lot of the hardships of cross-browser compatibility out of the picture, leaving you to focus on the real tasks.
Good Luck!