General and Desktop

Deleted

Yes, I completely agree with you, Raul, and handle it this way myself (I use ascii approximations of what I want to say hardcoded and the UTF-8 is in ts/qm translation files, although I nevertheless encode my code files as UTF-8 – that's a religious thing). @gosuperninja: if translation files aren't overkill for your project, rather use them than hardcoding UTF-8. But if you still want to do it, rather use QString than wchar_t. (When in rome, do as the romans do.)

the answer was to reuse setIcon and setStyleSheet but for some reason it didn't worked... now its working :)

Problem is solved now, but I appreciate the insight of timer ownership. I'm sure that will come in useful. :)

It will be the main thread, since that is the only thread at the time of initialization before main() is called. It may however not be transparent to Qt, because QApplication was not created yet. If it is not necessary to create static global instances, it may be better to create that object in main() after QApplication is created.

Concerning your doubts of licensing. assert is part of the standard and supplied with the compiler. Check out "boost":http://www.boost.org/ is states: [quote]The Boost license encourages both commercial and non-commercial use. [/quote] The licensing is not homogeneous, but in most cases there should be no problem. There is even a Qt version of assert, but I never used. Concerning your actual problem, you should place break points in the debugger where ever you think it is important. That way you can even follow into routines and methods. In your case you may want to put a break point onto the check statement in question. Personally I find it more convenient than debug statements. The problem I see currently is the way you are setting the check state. You should use the supplied macros for "checkState":http://qt-project.org/doc/qt-4.8/qt.html#CheckState-enum I just saw that this is "tristate bool for QCheckBox":http://qt-project.org/doc/qt-4.8/qcheckbox.html and 1 does not mean checked anymore. But that may be dependent on the version you are using. When using the predefined values you avoid such traps.

thank you lukas, that cleared it!

I've posted a bug report which I guess will go without comments :/ https://bugreports.qt-project.org/browse/QTBUG-25997 I'd even work on this if somebody said 'hmh, that should be fixed'. The issue is that it could break api for the case of operator->, the rest i think could be tricked into proper behavior.

thanks a lot

isntall an eventfilter on the editor and handle the key before it is delivered to the editor.

Thanks for quick answer. I figured out part of the ABI issue is differences between implementations and runtimes etc between compilers and versions. I don't like users having to pass in a buffer, it's ugly and makes coding painful. Standard for C users, not expected by C++ users in a modern library. Perhaps I need to follow the herd and provide a simple wrapped string class in my API? I'll always be returning const data so the wrapper should be pretty simple. I've been looking at popular C++ libraries and this seems to be common - I can't see any way around returning copies of strings when crossing module boundaries?

This made me think about the "Callback approach":http://en.wikipedia.org/wiki/Callback_(computer_programming) . Out of the box it won't work with just strings though.

The license comes with no advertising requirements, but it must be possible for the user to understand the Free Software origins. A link in the about box pointing to a page where you publish your modifications should be enough. If the modifications are of general use, how about pushing them into Qt?

I think it is working. I don't know what I was doing wrong, but now it works fine. The code: @bool EventWidget::eventFilter(QObject *obj, QEvent *event) { //qDebug() << event->key(); if (event->type() == QEvent::MouseButtonPress) { if(Qt::ShiftModifier == QApplication::keyboardModifiers()) { QMouseEvent *mouseEvent = static_cast<QMouseEvent *>(event); if(mouseEvent) { if (mouseEvent->button() == Qt::LeftButton) { //I do the other thing here. return true; } } } } return QWidget::eventFilter(obj, event); }@ And this, apparently, works just fine. So its [SOLVED]

There is unfortunately no automatism to mark posts as solved "yet":http://qt-project.org/forums/viewforum/46/, so just prepend the inital post title with [Solved], as Sam already suggested.

@Tobias - whether or not "second hand bug reports" are helpful is entirely up to people like you. If you see it and instead of posting it, you just say "file a bug report" then the effort of that user to alert of that bug is wasted. As I said, alerting of a bug goes half the way through, saying "file it" and ignoring the actual bug does nothing. Regular users are not obligated to even alert of bugs, doing so is a product of good will and a contribution on its own, contributors on the other hand are supposed to do that kind of stuff, so where you have a "going beyond responsibilities" for general users who alert of bugs toy have a "not following their responsibilities" for contributors who don't forward it. Not to mention as a troll, you get paid to improve on the library. Let me put it in a slightly more serious context - you are a vehicle engineer, there is a fatal flaw with a vehicle you designed that causes accidents and claims people's lives. Does this mean you sit idly by when the forum of your company gets informed of that flaw, waiting for some official bit of paper while more defective and dangerous products get shipped to unsuspecting consumers? Or do you pay attention, investigate and forward the issue yourself instead of waiting on others? So you getting paid to maintain Qt means you should ignore flaws you stumble upon? How is finding a bug in the forum different from finding a bug in the source code? Why should you take different course of action and ignore the bug just because someone else found it and bothered to inform of it in a place you are likely to see it??? Not intending to offend anyone in particular, but being a long time user of other libraries - the Qt community certainly doesn't make a good impression. Bug alerts in the forums of those libraries are not being ignored after provoking a useless "file it" response. EDIT: I agree there is no guarantee any qualified contributor will stumble upon a bug alert here in the forum (heck there is no guarantee a bug will be resolved if filed too, there are plenty that are unresolved despite their age and vote count), but after one does it is on him too, I have my doubts it falls into his professional responsibilities to do nothing about it. Maybe I should address your employer with an inquiry whether you are paid to ignore bug alerts... If you wouldn't ignore a bug in the source code, why would you ignore a bug someone else found and forwarded to a location of your attention?

Eureka, I miss checkable on Show button, if having anyone' support, I didn't waste much time ... to bite pencil =_=

Hello Radek, Thanks for your reply.

I was not clear enough, but i would use a spacer below the gridlayout, not in it;) Also i'm used to test layouts in a ui. Afterwards then you can have a look at the code in the generated ...ui.h file.