Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
As far as I understand the next LTS release will be Qt 6.2. If 5.15 will not receive any more patches open source users are left without LTS till 6.2 is released. Am I correct? >From now on, will LTS releases be available only for commercial users? Thanks, Calogero On Mon, Jan 4, 2021 at 3:59 PM Tuukka Turunen wrote: > > > Hi Roland, > > > > Just so that there is no misunderstanding Qt 5.15.2 release stays > available for all users, it is just the upcoming LTS phase patch releases > that will be commercial only. In essence for the open-source users Qt 5.15 > is similar to Qt 5.13 and Qt 5.14 (non-LTS releases). > > > > Yours, > > > > Tuukka > > > > *From: *Development > *Date: *Monday, 4. January 2021 at 16.33 > *To: *Qt Development ML > *Subject: *Re: [Development] Commercial-only LTS phase starts: Closing > the 5.15 branch(es) on 5th January > > Am Mo., 4. Jan. 2021 um 14:38 Uhr schrieb Benjamin TERRIER < > b.terr...@gmail.com>: > > > > > > On Mon, 4 Jan 2021 at 14:14, Oswald Buddenhagen > wrote: > > On Mon, Jan 04, 2021 at 10:55:03AM +, Tuukka Turunen wrote: > >With Qt 6.0.0 released and the first patch release (Qt 6.0.1) coming > >soon, it is time to enter the commercial-only LTS phase for Qt 5.15 > >LTS. > > > that's some brilliant timing, given that no actual qt 6 release even > exists yet. (yeah, 6.0 is a joke given that you intend to break binary > compat in 6.1 - that's the wisdom of linking r's bonus payments to > release dates even for major versions). > > > > Yes, it would have made sense that the Qt Company waits for all modules to > be available in Qt 6 before dropping the 5.15 open support... > > > > I cannot express how much I agree to this. Qt6 has half of the modules > required by my project not yet available, so upgrading is not possible. On > the other hand, 5.15 LTS is closed for the open source users - this is > quite a heavy restriction for me since my project is non-profit and open > source. Buying a commercial license is not an option. > > Yes I'm aware that I'm a small fish in a large pond and QtC won't care > about my contributions or me as a developer using Qt since there is no > profit to make with me. On the other hand, I will carefully think about > using Qt again in future projects or recommend it to other people. > > This is not a complaint. Its your business and your rules. I'm just trying > to express the thoughts of a bigger but usally silent group of open > source/non-profit users which are directly impacted by this. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt 4.8.7 release date
Is there any news on when Qt 4.8.7 is planned to be released? I saw there have been snapshots available but do not have clue which are the blocker issues. Thanks, Calogero -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 4.8.7 snapshot build is available
Hi, would it be possible to have a full changelog for this snapshot. The changelog file inside the pachage is empty. Thanks, Calogero Il 1/13/2015 4:04 PM, Salovaara Akseli ha scritto: Hi, New Qt 4.8.7 snapshot build is available http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-01-12-2/ Snapshot is built against 50223ce5eebfdff01a88474f0589259137997458 Introduce Windows version 10. Changes compared to previous build: 50223ce5eebfdff01a88474f0589259137997458 Introduce Windows version 10. 6f55f3dbbb2cdae33a8b0d00b7bf2ada7fe79a04 Fix empty arrays in QML 1 18c5ff04103eadcb532d03d526714385943295ab Windows: Fix OS version determination for Windows = 8 8d831f5f444802879ae416bd110184d5a6cf1b26 QDateTime: Fix time format in doc 48194c74d3e2d2316fa4c57cf8b2e6687d8d6416 Fix compilation with QDND_DEBUG. 6f83ee60cf616731fb37d7a4357fc264fc167b2e Add Hebrew translation for Qt Linguist 25d972e12eda9dadf212d24af8d8f524572bdbfa Check world matrix is true when seeing if transformations are supported 62323e8d1b16167662c85e412d35804418593cc6 QIdentityProxyModel: remove slow bounds-checking, for more performance 87b82fb345a3384243da50240dab93589d072d7e Autotest: Setting tst_qaudiooutput and tst_qsound as insignificant Please test these snapshots, report possible regressions to bugreports.qt.io and send email about that (with bug id) to releas...@qt-project.org. Br, Akseli -- Akseli Salovaara The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QSharedMemory POSIX implementation
Hi all, I find QSharedMemory very useful, and I'm extensively using it for cross platform IPC. I noticed in the code (qsharedmemory_unix.cpp) there are two implementations for that class, one using System V IPC and the other using POSIX IPC (mmap). On both Linux and Mac versions of Qt, the System V primitives are used and there is no way to compile Qt using the POSIX implementation (-posix-ipc option is not available in configure). Is there any reason why the System V implementation is preferred? I'd like to switch to the POSIX one to overcome limits in some platforms where the maximum shared memory allowed is only 4MB. Thanks, Calogero -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSharedMemory POSIX implementation
On 7/9/2014 5:22 PM, Thiago Macieira wrote: On Wednesday 09 July 2014 16:17:38 Calogero Mauceri wrote: Hi all, I find QSharedMemory very useful, and I'm extensively using it for cross platform IPC. I noticed in the code (qsharedmemory_unix.cpp) there are two implementations for that class, one using System V IPC and the other using POSIX IPC (mmap). On both Linux and Mac versions of Qt, the System V primitives are used and there is no way to compile Qt using the POSIX implementation (-posix-ipc option is not available in configure). Is there any reason why the System V implementation is preferred? I'd like to switch to the POSIX one to overcome limits in some platforms where the maximum shared memory allowed is only 4MB. Warning: here there be dragons. That code path has probably not been compiled in years. Just patch your Qt to enable it. Note that POSIX memory sharing like that runs a huge risk. Never accept shared memory segments from untrusted applications, since they can crash you: all you need to do is use a file-backed segment of memory (as opposed to anonymous mmap) and then shrink the file. Linux is getting an extension to prevent that, called memory sealing, but I'm guessing Linux isn't your problem OS. Thanks Thiago for your quick reply. I did not know the POSIX implementation was not supported. My main problems are on Mac systems, the default shared memory settings there are very restrictive. I'll need to modify them somehow from my application. Thanks, Calogero -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.6 Release Candidate 2 available
Compiling RC2 with the following configuration is failing on our Windows machine: configure -release -qt-zlib -qt-libpng -qt-libjpeg -qt-libtiff -qt-libmng -no-qt3support -platform win32-msvc2003 -no-webkit -nomake examples -nomake demos [...] qapplication_win.cpp qclipboard_win.cpp kernel\qclipboard_win.cpp(313) : error C3861: 'CheckRemoteDebuggerPresent': identifier not found, even with argument-dependent lookup qcursor_win.cpp qdesktopwidget_win.cpp qdnd_win.cpp qmime_win.cpp qsound_win.cpp Generating Code... Compiling... qwidget_win.cpp qole_win.cpp qkeymapper_win.cpp qwinnativepangesturerecognizer_win.cpp qsound.cpp Generating Code... NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\nmake.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. I was able to compile Qt 4.8.5 with the same options. Let me know if you need any additional info. Thanks, Calogero On 4/14/2014 2:40 PM, Salovaara Akseli wrote: Hi, Qt 4.8.6 Release Candidate 2 packages are available at http://download.qt-project.org/development_releases/qt/4.8/4.8.6-rc2/ Sha1 frozen to 343df131f7207d65932c6505769aa2fb7fc04713 Avoid out of bounds memory reads when scaling images. Diff compared to rc1: 343df131f7207d65932c6505769aa2fb7fc04713 Avoid out of bounds memory reads when scaling images 565f5236c6c72effa914ae0537a1fb2b0de1027c Doc: Mention that MINGWM10.DLL only applies to MinGW 4.4 8b6eff876ff8fb0ed041b18d6cf32626804cf891 Fix link to Tier 2 mingw-builds version b95750a275a71fe3c344e562e897648b13670c80 Assistant: Set the url on created QNetworkReply objects. If blocker issues for Qt 4.8.6 release found please report those to bugreports.qt-project.org and raise issue also on releas...@qt-project.org before 17th of April. Br, Akseli -Original Message- From: Salovaara Akseli Sent: 31. maaliskuuta 2014 20:08 To: development@qt-project.org Cc: releas...@qt-project.org Subject: Qt 4.8.6 Release Candidate available Hi all, Qt 4.8.6 Release Candidate packages are available at http://download.qt- project.org/development_releases/qt/4.8/4.8.6-rc1/ Sha1 for Qt 4.8.6 is now considered frozen so please test these packages accordingly. These packages are built against sha1 215a78618b185a71f660201c902da51360d8c30d Pass events to QGestureManager from the main (GUI) thread only. Current version of changes file is available at http://download.qt- project.org/development_releases/qt/4.8/4.8.6-rc1/changes-4.8.6-rc1 There has been quite many recommendations on mailing list and\or via IRC about bug fixes that should be part of Qt 4.8.6. Thank you all from those as well the patches you have made available. Unfortunately not all of the items are included to Qt 4.8.6 but this is not the last Qt 4.8 release. The initial plan is to release next Qt 4.8.7 patch release already during second half of 2014. If blocker issues for Qt 4.8.6 release are found please report those to bugreports.qt-project.org and raise issue also on releas...@qt-project.org before Monday 7th of April. Br, Akseli -- Akseli Salovaara Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Crash in QSystemSemaphore acquire/release
Hi,
I've been digging for days in a very weird problem I found testing a
producer/consumer implementation using QSystemSemaphore for IPC
communication.
I used QSystemSemaphore to synchronize the producer and the consumer
processes. The implementation is working like a charm on Windows/Linux
while it is crashing on Mac OS when an acquire on the semaphore is
performed.
Looking into the Qt implementation, I found out that on unix, the system
semaphore acquire/release is implemented calling semop with SEM_UNDO
flag. If the semop fails a new semaphore is created and a new semop is
performed on it and so on till there is a successful semop. The crash is
due to an infinite recursive loop due to a permanent failure in
modifySemaphore() call.
This is happening because on Mac OS there is a limit set to 10 for the
maximum number of SEM_UNDO structures a process can have initialized to
a value different than 0 (just launch from command line 'sysctl
kern.sysv.semume' to know that value). When more than 10 semaphores have
the SEM_UNDO initialized, then the modifySemaphore() will always fail
causing the crash.
Attached is a simple example demonstrating the issue. A pool of
producers threads are created. After acquire/release have been performed
on more than 10 semaphores I get the crash on the mac.
Why the modifySemaphore, in the unix implementation, should create a new
semaphore if the semop is failing?
Furthermore, I think calling the semop with the SEM_UNDO flag is
basically wrong in the producer/consumer case, where a resource is
always acquired by a process and released by another one (the SEM_UNDO
counter for each process would be wrong, causing a bad semaphore value
reset on process closure). The Qt API should provide a way to
acquire/release the semaphore without the SEM_UNDO flag.
I just made a bugreport https://bugreports.qt-project.org/browse/QTBUG-37766
Thanks,
Calogero
--
Calogero Mauceri
Software Engineer
Applied Coherent Technology Corporation (ACT)
www.actgate.com
#include QCoreapplication
#include QDebug
#include QSystemSemaphore
#include QThread
class Producer : public QThread
{
public:
Producer(int idx)
{
threadIdx = idx;
QString freeBytesSemKey = QString(FB%1).arg(idx);
QString usedBytesSemKey = QString(UB%1).arg(idx);
// qDebug () key idx freeBytesSemKey usedBytesSemKey;
// system semaphores shared with consumer
freeBytes = new QSystemSemaphore(freeBytesSemKey, 1,
QSystemSemaphore::Create);
usedBytes = new QSystemSemaphore(usedBytesSemKey, 0,
QSystemSemaphore::Create);
}
~Producer()
{
delete freeBytes;
delete usedBytes;
}
void run()
{
int i = 0;
while (1)
{
freeBytes-acquire();
// ...
qDebug() thread threadIdx block++i
data produced ...;
usedBytes-release();
// just to emulate other stuff delay
sleep(10);
}
}
private:
int threadIdx;
QSystemSemaphore *freeBytes;
QSystemSemaphore *usedBytes;
};
int main(int argc, char ** argv)
{
QCoreApplication app(argc, argv);
const int nThreads = 10;
QThread *producersPool[nThreads];
// launch a pool of producers
for (int i = 0; i nThreads; i++)
{
producersPool[i] = new Producer(i);
}
for (int i = 0; i nThreads; i++)
{
qDebug() Launching producer thread i;
producersPool[i]-start();
}
// wait
producersPool[0]-wait();
return 0;
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] website down
http://qt-project.org seems to be down. Any chance to get it back soon? Thanks, -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.6 Release Plans
On 10/30/2013 1:45 AM, Sandy Martel wrote: Le 2013/10/30 à 11:06, Nicolás Alvarez nicolas.alva...@gmail.com a écrit : 2013/10/29 Calogero Mauceri mauc...@actgate.com: ... The Qt documentation states that QDir::currentPath() returns The application working directory. Shouldn't the workind directory be initialized with the path the application was launched from? If that's not the case, which is the right way to obtain the working directory? That is the correct way to get the working directory. But there is no documentation from Apple guaranteeing what the working directory will be when Finder launches an application. Calogero, I don't think working directory means exactly what you think it means. Also, as Nicolás says, the path the application was launched from means whatever the Finder wants it to be. Looks like you want something like CFBundleCopyBundleURL(CFBundleGetMainBundle()) . For Qt, I'd say QApplication::applicationDirPath() + ../../.. or Qt5's QStandardPaths::ApplicationsLocation are your best bets. Ok guys, I understand the point. Thanks a lot for your advice! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.6 Release Plans
On 10/30/2013 8:59 AM, Konrad Rosenbaum wrote: Hi, On Wednesday 30 October 2013 00:58:05 Calogero Mauceri wrote: The Qt documentation states that QDir::currentPath() returns The application working directory. Shouldn't the workind directory be initialized with the path the application was launched from? If that's not the case, which is the right way to obtain the working directory? (not the executable path as the QApplication::applicationDirPath() is returning) The current working directory is the directory the application is currently working in (I know, it sounds like a tautology). Or in other words: if you open a file with a relative path name, the current working dir is the one in which your program looks for the file: QFile file(myfile); file.open(QIODevice::ReadOnly); is equivalent to: QFile file(QDir::current()+/myfile); file.open(QIODevice::ReadOnly); You can change it with QDir::setCurrent or the underlying OS function chdir. At application startup the current working directory is the exact same directory that the parent was in when it spawned your process (this is somewhat simplified). This is the same behavior over all desktop OSes. The parent application is free to chose: it can simply refuse to care (result: your CWD is more or less random from your programs perspective; this is why an app started from a KDE desktop is almost always in $HOME, but sometimes somewhere else); it can assume you are a command line tool and want to work in the same place the shell is in (that's what happens if you start anything from a shell); it can try to be helpful and switch to the directory the binary is in (apparently what Mac used to do); or it can try to make things consistent by switching to the root directory (apparently what 10.9 does). In short: relying on the CWD at startup is misguided for most GUI apps. If you need to be in a specific directory: use some other mechanism to find it and then switch there, do not rely on being placed there by magic. Places you may want to be: * somewhere relative to your binary: use QApplication::applicationDirPath() - I do this in apps that have complex trees of files with data needed at runtime, apps that work in their own little universe * in the users home directory: QDir::setCurrent(QDir::homePath()) - desktop apps that interact with user files * in the exact same place you were started from: don't move - this is true for most command line tools (like qmake, moc, ...) * in the root directory - true for most server processes (daemons, middleware, ...) * in the temp dir: use QDir::setCurrent(QDir::tempPath()) - e.g. simulations that create some throw-away data only * in some dir that was configured by the user: read the config then switch - true for other server-like processes (e.g. automation software, ...) The tricky question we're trying to coax out of you: does QDir.current() really return an empty string or the root directory /? The former may indicate a bug on Apple's part, the latter is a perfectly valid place to be in. Konrad, thanks for your exaustive explanation. It is clearer to me now that I can not rely on QDir::currentPath() function for what I need. QDir::currentPath() on Mac OS X 10.9 is returning the root path /. Thanks, Calogero ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.6 Release Plans
On 10/29/2013 4:47 PM, Thiago Macieira wrote: On terça-feira, 29 de outubro de 2013 16:35:31, Calogero Mauceri wrote: Related to problems with OS X 10.9, please consider fixing the following bug with QDir::currentPath() returning root dir: https://bugreports.qt-project.org/browse/QTBUG-34300 our application is no more running for customers having upgraded to Mavericks. Thanks for pointing it out. Looks like Apple broke their OS. We may need a workaround or to document that applications on OS X 10.9 start with no working directory. For some reasons QApplication::applicationDirPath() works properly on OS X 10.9, but it returns the path to the app executable (the one inside the app bundle). I'm wondering whether a similar implementation could fix the issue for QDir::currentPath(). Calogero -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.6 Release Plans
On 10/29/2013 9:01 PM, Sandy Martel wrote: Le 2013/10/30 à 5:24, Thiago Macieira thiago.macie...@intel.com a écrit : On terça-feira, 29 de outubro de 2013 16:53:55, Calogero Mauceri wrote: For some reasons QApplication::applicationDirPath() works properly on OS X 10.9, but it returns the path to the app executable (the one inside the app bundle). I'm wondering whether a similar implementation could fix the issue for QDir::currentPath(). Please understand that the bug might be in your application. QDir::currentPath() returns the *current* path, not the bundle executable path. On older OS X versions, if it returned the bundle executable path, it was a quirk and depended on Finder behaviour. Depending on that behaviour was irresponsible, because we all know that Apple likes to change behaviour and break things. Now, is there something wrong with getcwd(3) on OS X 10.9? Can someone with Mavericks test it? If it returns empty, then we conclude Apple broke their OS. If it returns with error, what error is it? Nothing wrong with getcwd (obviously). But it looks like the Finder now gives root as cwd for its children processes. I think this has always been an undefined behavior, subject to changes. Anyway, relying on the previous behavior was obviously a bug, if you launch from the Finder you get one cwd (whatever the Finder gives you), if you launch from the Terminal you get the cwd the shell gives you (most likely different) and your application doesn't work anymore. There is an API to get the bundle's path and QApplication::applicationDirPath() uses it, so if you want QApplication::applicationDirPath(), don't use QDir::currentPath(). Sandy. The Qt documentation states that QDir::currentPath() returns The application working directory. Shouldn't the workind directory be initialized with the path the application was launched from? If that's not the case, which is the right way to obtain the working directory? (not the executable path as the QApplication::applicationDirPath() is returning) Thanks, Calogero ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Serious problem with Modeless dialogs on Mac (Qt 4.8)
Il 05/12/2012 19.44, Robert Knight ha scritto: All modeless dialogs disappear behind the main application whenever the user clicks outside them (consider a Find/Replace dialog which always needs to be on top of the main application window). Set the window type to Qt::Tool in the QDialog or QWidget constructor on Mac, which corresponds to NSFloatingWindowLevel in Cocoa. Taking your example of the Find/Replace dialog, if you look at this dialog in Pages, you'll see that it is a tool window. If you open a modeless dialog which is not a tool window, like the preferences dialog, it disappears behind the main window when the main window is given focus. Robert thanks for your reply, it seems you are right, also for other Mac applications the preferences dialog disappears behind when the main window is given focus. Now that behavior is different than the one on Windows, Linux and Mac with Qt compiled against the Carbon framework. Shouldn't Qt library adopt an uniform behavior between multiple platoforms? Thanks, Calogero Regards, Rob. On 5 December 2012 15:40, Calogero Mauceri mauc...@actgate.com mailto:mauc...@actgate.com wrote: All modeless dialogs disappear behind the main application whenever the user clicks outside them (consider a Find/Replace dialog which always needs to be on top of the main application window). -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Serious problem with Modeless dialogs on Mac (Qt 4.8)
Hi dear list, We are experiencing serious problems in our mac applications due to this bug https://bugreports.qt-project.org/browse/QTBUG-27879 All modeless dialogs disappear behind the main application whenever the user clicks outside them (consider a Find/Replace dialog which always needs to be on top of the main application window). Is there any plan to fix it? Are we the only ones having that problem? Is there a workaround for it? Sorry I keep asking about that problem, but Qt (Cocoa framework) is almost unusable in lot of application if that problem is not fixed. This problem is happening only on Mac, not on Windows or Linux (Gnome). We noticed this problem after upgrading our application from Qt 4.6.3 to the latest version (Qt 4.8.4). Thanks in advance for your help, Calogero -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.4 bug: mac menu bar not properly shown
Il 09/11/2012 18.48, Calogero Mauceri ha scritto: Hi, On the Mac version of my application, the menu bar is no more properly shown using the Qt 4.8.4_RC2. You can see the same problem in the mainwindows|application example. Attached are some screenshots showing the problem. The menu bar is properly working with Qt 4.8.3. Do you suggest to open a bugreport? I can confirm that this bug was introduced in Mac version of Qt 4.8.4_RC2 compiled with Carbon framework. The applicatin menu bar is properly shown with Qt 4.8.3 (Carbon framework as well). We are obliged to use Carbon framework due to this bug https://bugreports.qt-project.org/browse/QTBUG-27879 which is causing all modeless dialogs to disappear behind the main application whenever the user clicks outside them (this is a very serious problem, e.g. consider a Find/Replace dialog which always needs to be on top of the main application window). I just commited a new bug report for that problem https://bugreports.qt-project.org/browse/QTBUG-27960 Calogero -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 4.8.4 bug: mac menu bar not properly shown
Hi, On the Mac version of my application, the menu bar is no more properly shown using the Qt 4.8.4_RC2. You can see the same problem in the mainwindows|application example. Attached are some screenshots showing the problem. The menu bar is properly working with Qt 4.8.3. Do you suggest to open a bugreport? Calogero -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com attachment: qt_4.8.3.jpgattachment: qt_4.8.4.jpg___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.4 bug: mac menu bar not properly shown
Il 09/11/2012 18.48, Calogero Mauceri ha scritto: Hi, On the Mac version of my application, the menu bar is no more properly shown using the Qt 4.8.4_RC2. You can see the same problem in the mainwindows|application example. Attached are some screenshots showing the problem. The menu bar is properly working with Qt 4.8.3. Do you suggest to open a bugreport? Calogero Actually, I just found out that this problem is happening when Qt is compiled with Carbon framework. The problem is not there if I compile Qt libraries 4.8.4 with Cocoa framework. Unfortunately I'm obliged to use Carbon framework due to this bug QTBUG-27879. Any hints on how to overcome one of those bugs? They are quite blockers for the applications we are developing. Thanks, Calogero -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
