Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?

On Thursday June 11 2020 12:43:11 Konstantin Tokarev wrote: >Main reason behind QtWebView is described in the root page of its >documentation, and it's about mobile platforms, namely Android, iOS, and also >WinRT. For me everything QQuick* is (mostly) about mobile platforms, but that's a

Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?

On Thursday June 11 2020 04:31:59 Konstantin Tokarev wrote: >Whole point of QtWebView is to use platform specific backends on platforms >where they do exist, at the cost of limited API. If you need to use >platform-specific backends and want to replace QtWebEngine on platforms with >no

[Development] Patching QtWebView to use QtWebkit "rebooted"?

Hi, Suppose I wanted to patch QtWebView so it will use WebKit2 from the rebooted QtWebKit libraries instead of the QtWebEngine bloatware, how feasible would that be? A rabbithole, a question of reparenting and changing a limited number of function calls, or pointless because QtWebKit already

Re: [Development] QT_GCC_MAJOR_VERSION and building with clang...

Thiago Macieira wrote: >> QT_GCC_MAJOR_VERSION = 3 >> QT_GCC_MINOR_VERSION = 2 >> QT_GCC_PATCH_VERSION = 1 > > This is wrong. Clang reports GCC 4.2.1, not 3.2.1. OK, I don't know what went wrong here, the file actually does have 4.2.1 ... > This Clang is way too old. If you have GCC from

Re: [Development] QT_GCC_MAJOR_VERSION and building with clang...

On Friday December 06 2019 18:36:52 Sérgio Martins wrote: >So you're building QtWebEngine with GCC 8 while Qt was built with clang >mkspec ? It was a test, but IMHO it should be possible (as long as you're not also mixing libstdc++ and libc++). >Anyway, FWIW, I've built QtWebEngine with clang

[Development] QT_GCC_MAJOR_VERSION and building with clang...

Hi, I just noticed this on Linux, after building Qt 5.12.6 with clang 5.0.2 : ``` > cat /opt/local/libexec/qt512/mkspecs/qconfig.pri QT_ARCH = x86_64 QT_BUILDABI = x86_64-little_endian-lp64 QT.global.enabled_features = shared rpath c++11 c++14 c++1z c99 c11 thread future concurrent

[Development] [SPAM] weird SH_DialogButtonBox_ButtonsHaveIcons check in qpushbutton.cpp ?!

Spam detection software, running on the system "mx.qt-project.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details.

Re: [Development] is it possible to increase the max. document size for the JSON parser?

>07.08.2019, 02:21, "Sérgio Martins via Development" >: >> I looked at it again and the test-case was flawed, it was using unneeded >> QStrings and QString::toUtf8(). >> >> By reading directly from the file heaptrack now reports only 300 MB >> peak. I think I would have noticed anything more

Re: [Development] is it possible to increase the max. document size for the JSON parser?

Joerg Bornemann wrote: > Unfortunately, this isn't possible at the moment. > This issue is tracked in QTBUG-47629. Thanks, I'll try the patch! R. ___ Development mailing list Development@qt-project.org

[Development] is it possible to increase the max. document size for the JSON parser?

Hello, I have a 114Mb big JSON file that I'd like to be able to parse but that is rejected because of its size. Is it possible to rebuild Qt with a larger maximum document size for the JSON parser? I found the Value::MaxSize token which is somehow related to the too- large error, understand

Re: [Development] "font emojis", where are they processed?

A related issue (bug, I'd argue): https://bugreports.qt.io/browse/QTBUG-74725 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

[Development] email address to prune

Hi, Sorry to bother the list but I don't know where else to report this: Please unsubscribe frontd...@globaltestmarket.com from your lists ... --- Forwarded message: Date: Wednesday March 13 2019 From: Do-Not-Reply To: René J.V. Bertin Cc: Subject: RE:

[Development] AA_CompressHighFrequencyEvents and remote displaying

Hi, Is it possible that the X11 event compression feature could get triggered inappropriately when running an application on a remote X11 display, esp. when that display is on a slower machine than the host on which the application runs itself?

Re: [Development] "font emojis", where are they processed?

On Tuesday February 19 2019 23:23:45 Tor Arne Vestbø wrote: Hi, > > Grep qfontengine_coretext.mm for “ColorGlyphs” > > The change: https://codereview.qt-project.org/#/c/47527/ I'm beginning to realise that the relevant difference between Qt4 and Qt5 isn't just in support for colour fonts. A

Re: [Development] QPlatformFileDialogHelper and embedded QFileDialog instances

> Is this a known issue or simply something that is not and never will be > supported? Actually, I realise that at least the Mac "native" platform file dialog is also built using QPlatformFileDialogHelper ... and indeed it doesn't support embedding (= being used as a widget instead of as a

[Development] QPlatformFileDialogHelper and embedded QFileDialog instances

Hi, We may have identified an issue with "themed" QFileDialogs (provided through a platform theme plugin and QPlatformFileDialogHelper) when they are intended to be "embedded", i.e. used as a Qt::Widget : https://bugs.kde.org/show_bug.cgi?id=404833 Is this a known issue or simply something

Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"

On Monday February 25 2019 12:24:31 Kevin Funk wrote: > That makes sense in theory. QMake will switch to a different mkspec when you > pass `-spec ...` when building an external project. It's impossible to > instruct CMake to do the same right now, as the mkspec is hardcoded in the > CMake

Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"

On Monday February 25 2019 10:18:01 Kevin Funk wrote: Hi, From my quoted message: > >> Now, I think it's not entirely relevant whether or not this particular > >> setting is a left-over due to me not trashing the entire Qt build > >> directory > >> before rebuilding with clang. The fact is that

[Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"

Hi, Trying to get an answer to the question below once more. In a nutshell: shouldn't the CMAKE_MKSPEC (or some equivalent) be preserved in the installed CMake modules such that the correct mkspec directory is added to the compiler's header include search path? Or should that directory be

Re: [Development] "font emojis", where are they processed?

Tor Arne Vestbø wrote on 20190220::11:58:33 re: "Re: [Development] "font emojis", where are they processed?" No problem, bouncing this back to the ML then to see if someone else picks it up. R. > >> On 20 Feb 2019, at 10:49, René J.V. Bertin wrote: >> >> Tor Arne Vestbø wrote on

[Development] "font emojis", where are they processed?

Hi, I'm trying to understand why Qt4 applications on Mac do not correctly display "font emojis" while they do on Linux. Qt5 apps are fine so I should be able to satisfy my curiosity from the Qt5/Mac implementation of the relevant code. Is there a specific place in the code where these glyphs

[Development] Mac/Win: Let QIcon::fromTheme() return something appropriate even when no theme is defined?

Hi, Freedesktop.org icon themes contain icons with mime-type names that are accessible via QIcon::fromTheme() and widely used to use an appropriate image for document icons. On Mac, using setWindowFilePath() will also show an appropriate icon next to the document filename, and I presume MS

Re: [Development] Using Native web view on OS X

Kai Koehne wrote: > Indeed, and we agreed to solve this properly by introducing a plugin based > architecture: https://codereview.qt-project.org/#/c/207651/ This wouldn't also be of interest for developers who want to target Apple's App Store. Assuming QtWebView is an appropriate choice for

[Development] cocoa:fontengine=freetype and bitmap fonts

Hi, One of the surprising side-effects of using the FreeType fontengine in general use is that I sometimes get a bitmap font, esp. in the Assistant. I'd noticed this on Linux too, btw. Turns out that this happens (only?) with the Helvetica font. I do have XQuartz installed (with the

[Development] QHash

Hi, It took me a while to figure out why my QHash map of a const char* to something else didn't work despite containing the expected key,value combinations. I understand that the bug was in my code rather than in QHash, because the class is not designed to work with basic data types. It could

Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

Konstantin Tokarev wrote: >> It does sound like we're a little too enthusiastic about jumping to a >> conclusion here - is there a better way to decide what we're compiling >> for ? Surely we should ignore uname if configure has options that >> explicitly ask for cross-compilation; but it's a

Re: [Development] about the Cocoa/Freetype fontengine

Nikolaus Waxweiler wrote: >> All I can say is that I didn't turn it off and that the font smoothing gamma >> value matters. > > Be more specific. You asked if gamma correction is enabled in my Qt builds, the only way I can answer that without additional information is the way I did. A priori

Re: [Development] about the Cocoa/Freetype fontengine

Nikolaus Waxweiler wrote: >> Right, and where did *that* come from in discussion that's about font >> engine choice by the user? > > We are talking about giving devs the ability to ship Qt apps with > switched font engines, no? Here's what I currently have locally (disregard the hacks for

Re: [Development] about the Cocoa/Freetype fontengine

Konstantin Tokarev wrote: > Note that Mac OS X at least up to 10.5 allowed setting strong hinting in the > system settings It indeed used to have a combobox with different levels of font smoothing. That went the way of the dodo together with CRTs; nowadays all that's left is "Use LCD font

Re: [Development] about the Cocoa/Freetype fontengine

Nikolaus Waxweiler wrote: > Fair enough, depends on your screen and how much you darken. Ideally, > you match the sRGB gamma curve of roughly 2.2 that in an ideal world, > your screen matches, too. Ha! I recall a difference in opinion between Apple and the rest of the world about what the

Re: [Development] about the Cocoa/Freetype fontengine

Nikolaus Waxweiler wrote: > changes. Nobody could stand to use Macs if bitmap fonts were the > pinnacle of on-screen legibility. ? Where does that come from and what does it even mean? >> tweaking fontconfig files do so in part to reduce such differences. > > You can't fix fonts having

Re: [Development] about the Cocoa/Freetype fontengine

Nikolaus Waxweiler wrote: > We want to get to "Gamma 1.8, darkenend": > https://www.freetype.org/image/BlendingExamples.png On Mac (FT and/or FT+FC *without* Infinality+Ultimate patches) I find 1.5 comes closer to the native CoreText font colour. 1.8 is too thin. And for giggles, which one

Re: [Development] about the Cocoa/Freetype fontengine

Nikolaus Waxweiler wrote: > > DirectWrite rendering looks better than GDI rendering (in the sense that > it is truer to the designed outlines and the spacing with fewer That's not what I call looking better, but more veridical. The two can overlap but just as (actually, more) often they don't.

Re: [Development] about the Cocoa/Freetype fontengine

On Saturday December 30 2017 14:01:33 Jean-Michaël Celerier wrote: [apologies, hit the wrong key] > isn't this a common complaint actually : > https://www.google.com/search?q=qt+quick+blurry+text ? Let's put it this way: not common enough for neither the Qt nor the KWin developers to heed? ;)

Re: [Development] about the Cocoa/Freetype fontengine

ftware on > your desktop (for very practical reasons, too: when you're on stage > performing a show you don't want to spend time finding where is the window > you have to click on, they all have to appear very distinct if you have > multiple software running) > > > Best, > ------- >

Re: [Development] about the Cocoa/Freetype fontengine

Nikolaus Waxweiler wrote: > I think you have to carefully match the rendering of CoreText (and its' > darkening algorithm) for users not to notice. At that point, you might > as well use CoreText, unless you have something very specific in mind. Remember that there's also the issue of getting

Re: [Development] about the Cocoa/Freetype fontengine

Nikolaus Waxweiler wrote: > I don't get it. How will this improve the look of Qt-Mac applications? This is in the eye of the beholder, to some extent. Ideally you will hardly notice a difference as a casual user. > Apps using CoreText will look different than Qt apps linking to a > patched

Re: [Development] about the Cocoa/Freetype fontengine and FontConfig

On Friday December 29 2017 21:44:27 René J.V. Bertin wrote: > It might be trivial to replace QCoreTextFontDatabase with QFontconfigDatabase > in QCocoaIntegration but that would be a build-time choice. In fact it is ... and with a bit of static_cast'ing one can probably make it a runtime

Re: [Development] about the Cocoa/Freetype fontengine

On Thursday December 28 2017 20:08:38 Sérgio Martins wrote: Hi, > What I meant is that you don't need to touch FT code when adding > fontconfig support to macOS. The code already exists and is > cross-platform (even worked on QNX). It's just that it's not being > used by cocoa QPA. So...

Re: [Development] about the Cocoa/Freetype fontengine

On Friday December 29 2017 10:38:04 Jean-Michaël Celerier wrote: > Besides, fontconfig with infinality patches >honestly gives a beautiful rendering, crispier and yet fuller than >everything you can see on othe OSes in my taste. I agree completely, except - I'm not (yet) convinced that the

Re: [Development] about the Cocoa/Freetype fontengine

Sérgio Martins wrote: > What I meant is that you don't need to touch FT code when adding > fontconfig support to macOS. The code already exists and is > cross-platform (even worked on QNX). It's just that it's not being > used by cocoa QPA. Hmmm, I guess I'll need to have another look then. It

Re: [Development] about the Cocoa/Freetype fontengine

On Thursday December 28 2017 19:46:28 Sérgio Martins wrote: > Check the last two comments of > https://bugreports.qt.io/browse/QTBUG-42839, there are no plans. Oops, sorry, I forgot about that. > I also wouldn't call it "evolving FreeType", as FreeType is > independent from the font database.

[Development] about the Cocoa/Freetype fontengine

Hi, Are there any plans to evolve the FreeType support on Mac any further, possibly adding FontConfig support so fonts can really be rendered in identical fashion on at least the major Unix platforms? If so, would you consider making it easier to select the FreeType engine? I've been

Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

On Thursday December 21 2017 20:19:03 Konstantin Tokarev wrote: >> I'm pretty sure `sysctl hw.model` doesn't return anything that starts with >> Mac when you're not on a Mac though? > >Are you trying to distinguish it from PureDarwin? No, in theory that command should always return the

Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

On Thursday December 21 2017 16:25:02 Jake Petroules wrote: > > Possibly: just `uname` returns Darwin. That should certainly work for the > > desktop OS, but I have no way of checking what it returns on other Apple > > OSes > > they all return "Darwin" Figures... > > (and if the

Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

On Thursday December 21 2017 13:47:34 Konstantin Tokarev wrote: > Check uname maybe? Possibly: just `uname` returns Darwin. That should certainly work for the desktop OS, but I have no way of checking what it returns on other Apple OSes (and if the Carbon.framework exists there). R.

[Development] About the presence of /System/Library/Frameworks/Carbon.framework

Hi, Here's a silly one: configuring Qt for building on my Linux rig I was told that I needed Xcode, and how to get it. :) Long story short, it turns out that the configure script determines whether it's building on Mac by checking if the Carbon framework exists in the designated location. And

Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection

I've decided to file this as a bug at least for future reference: https://bugreports.qt.io/browse/QTBUG-64996 I tried my luck with valgrind but apparently that modifies the runtime environment sufficiently to avoid the crash. If there was a useful hint in the valgrind output it got lost in

Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection

On Tuesday December 05 2017 11:11:12 Thiago Macieira wrote: > Ok, the only differences between 5.9 and 5.10 are replacing 0 with nullptr > and > removing one no-op. Has anything changed in the handling of style plugins between 5.8 and 5.9? A few more lines of output later I now know that the

Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection

Thiago Macieira wrote: > Please upgrade to 5.10 and apply the fixes again. But other than that, there > are no known issues because there aren't many changes either. I don't think I'll be trying 5.10 any time soon, 5.9 is the newest version I hope I'll be able to run across all my systems. R.

Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection

René J. V. Bertin wrote: > It appears to be an issue caused by (with?) the QtCurve widget style, though. One that goes away when I add an output tracer just before exiting from the style's dtor ... =/ R ___ Development mailing list Development

Re: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection

Thiago Macieira wrote: > Keep applying the patch on top of the official release. Wasn't that clear? I'm still running 5.8 *with* the fixes. This does look like a related-but-different issue though, trying to disconnect a valid receiver from a sender instance which has apparently already been

[Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection

Hi, Is the crash below another (new?) variant of the on-exit QDBus crashes for which a few fixes were pushed a couple months ago, a new bug I should report, or is this the result of a bug in the dependent code? rekonq built on Linux from the frameworks git head, Qt 5.8 (with the QDBus patches

[Development] Short/medium term evolution of the Assistant?

Andy Shaw wrote on 20171109::22:42:00 re: "[Qt bugreports] (QTBUG-59664) QSqlDatabasePrivate exploses open file limit and causes crash" Hi, I've been tinkering a bit with building the Assistant from the 5.9 branch head against my installed Qt 5.8.0, using a static lib build of the QtHelp

[Development] crash in SimpleScriptFunction::call()

Hi, I've run into a known crashing issue in SimpleScriptFunction::call() that's been resolved sometime after 5.8.0 : https://bugs.kde.org/show_bug.cgi?id=384404 * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1909d3508) * frame #0:

Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

Konrad Rosenbaum wrote: >> And one cannot even rely on mutexes to "fix" or prevent that? > > If you use Mutexes right you can rely on them to serialize the code that > blocks on the same Mutex, i.e. only one blocking code block is executed at > the same time. > Depending on hardware timings

Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

On Monday October 02 2017 11:12:35 Sergio Martins wrote: Hi, > You were probably capturing a local variable by reference inside the > lambda, which then went out of scope. That sounds likely (I used '[&]' as the other lambdas do in the same method. I don't think I considered scope when trying

Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

Konrad Rosenbaum wrote: Hi, I see I'm not the only one accepting the fact that when dealing with event- driven GUIs having a human-in-the-loop one rather quickly reaches a stage where it becomes hard to guarantee anything (with all that implies for writing code that handles unforeseen

Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

Konrad Rosenbaum wrote: > Apart from this I'd suspect you will still get the SEGV if you do not block > - even if the frequency changes. As in when emitting the signal too frequently from multiple threads? For my personal education, what happens behind the scenes when a signal is sent from one

Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

Konrad Rosenbaum wrote: > You do know what a thread is - right? ;-) Yeah, my momma taught me long ago ;) > Sorry, I'm too lazy/busy to read the source right now to make sure that no > signal handlers are used here. No problem, it was just curiosity. > Apart from this I'd suspect you will

Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

Thiago Macieira wrote: >> >> How does QFSW handle a situation in which an already watched directory is >> >> changed while another directory is being added? SNIP >> > >> > The Darwin implementation has an internal mutex so that the dispatcher >> > thread (I'm assuming) is able to get to the

Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

Thiago Macieira wrote: >> How does QFSW handle a situation in which an already watched directory is >> changed while another directory is being added? Would something else happen >> when adding directories happens on a background thread while change signals >> are connected to slots on the main

Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

Thiago Macieira wrote: > We're not claiming that you have no problem. We're saying the problem is > probably in your own code. It's a kind of chicken-or-egg question. I'm indeed doing something that triggers a problem which is clearly deep inside Qt code. What I want to know is whether it's

Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

On Friday September 29 2017 14:27:37 Milian Wolff wrote: > behavior you are supposedly seeing. So you still haven't bothered trying to reproduce this or prove me wrong, aside implying I'm making this all up? In that case I'm not sure why *you* come trolling on a post that intends to find out

[Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

Hi, I've been running into issues using adding and removing entries from QFSW in concurrent threads. This is in KDevelop while adding all directories of multiple projects (source trees) to a single QFSW instance per project. The app is somewhat complex so I think but am not entirely certain

Re: [Development] QStylePlugin::create() being called multiple times?

Apologies for the noise, I should have used a debugger before asking. R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

[Development] QStylePlugin::create() being called multiple times?

Hi, Is there any reason why QStylePlugin::create() would be called multiple times in an application that doesn't do any widget style changing itself? This is on a KDE desktop with the plasma integration plugin installed and KDE_SESSION_VERSION set. Whatever the reason why this happens, what

Re: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole)

And one more thing: I haven't been seeing the issue I reported originally since getting rid of the ibus stuff as described earlier in this thread. Uninstalling at-spi2-core must have been the real fix as I installed ibus in one of my attempts to get a grip on the issue.

Re: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole)

René J. V. Bertin wrote: >> QT_LINUX_ACCESSIBILITY_ALWAYS_ON > > Interesting, I have no trace of that variable, and I cannot imagine that > uninstalling at-spi2-core would have unset it in all running shells. In addition, the code only checks if this variable is set

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

Coming back startTimer()/killTimer(): I don't think they modify any externally visible class state, do they? If not, would it be possible (and acceptable) to add const versions (or mark them const) so that they can be called from a const member function? I just asked about this on the interest

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

Eike Ziller wrote: > Another good question to ask when introducing source incompatible changes, is > “how hard does it make supporting building with both Qt 5 and Qt 6 from the > same code base”. We did that for Qt Creator for quite some while, and it makes > the transition process much smoother

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

Edward Welbourne wrote: Interesting way such as LTTNG/ETW :) ? > >>> Spoiler alert: not on Mac ... > > Konstantin Tokarev (31 August 2017 15:50) >> Mac has DTrace > > Do we have anyone eager to follow up on the LLTNG/ETW work > (see earlier mail in this thread for link), adding DTrace

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

Sergio Martins wrote: > Interesting way such as LTTNG/ETW :) ? Spoiler alert: not on Mac ... R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

[Development] NSMenu validation, QCocoaMenu and button (context etc) menus

Hi, Re: change which caused the CPU burning issue I discovered a couple of days back ("[fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?"). It intrigued me why an application that doesn't use native Mac menus would be calling [NSMenu update] at

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

Thiago Macieira wrote: >> I guess so :) I still don't get what purpose calling QObject::timerEvent() >> has if the method itself does nothing. Gives me something to ponder. > > Again, that's what makes QTimer possible. > > void QTimer::timerEvent(QTimerEvent *e) > { > if (e->timerId() ==

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

Thiago Macieira wrote: > It makes QTimer possible. .. > That sounds quite important to me :-) I guess so :) I still don't get what purpose calling QObject::timerEvent() has if the method itself does nothing. Gives me something to ponder. > function, because it would break the existing code.

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

Thiago Macieira wrote: Oops, missed this one. > Unfortunately, we can't change anymore. Can someone explain what could possibly be broken by changing this? Can the current base-level QObject::timerEvent() be used for anything constructive other than heating the office or preventing a CPU

[Development] NSMenu validation, QCocoaMenu and button (context etc) menus

Hi, I ran into and reported a CPU burning issue a couple of days back, which was quickly resolved. It intrigued me why an application that doesn't use native Mac menus at all would be calling [NSMenu update] at all. I now know that the menu which triggered the scheduled NSMenu update is one

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

On Tuesday August 29 2017 02:02:59 Gabriel de Dietrich wrote: >FYI: QCocoaMenu: Stop update timer >(Merged) Thanks for the heads-up. > >On Aug 29, 2017, at 9:00 AM, Thiago Macieira >> wrote: >

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

On Monday August 28 2017 23:10:22 René J.V. Bertin wrote: I found a potential fix: shouldn't QCocoaMenu::timerEvent() call killTimer(m_updateTimer); before setting m_updateTimer=0? Whether or not it's appropriate, this does solve the CPU burning for me. R. > Hi, > > I noticed an

[Development] Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

Hi, I noticed an annoying change after doing the periodic merge of changes in the qtbase/5.9 branch with my standalone Cocoa QPA. Commit f27d1ccbb24ec2fd4098f2976503478831006cc8 introduced a delayed invocation of [NSMenu update], which looks like a good idea. However, in some applications,

[Development] FYI: QtMultimedia and 3rd-party libopenal.dylib installs

Hi, For what it's worth, I notice that the QtMultiMedia build system picks up libopenal.dylib from the target prefix (and source of dependencies) if it's present, despite the fact that it is supposed to link to the OpenAL.framework . In my case that means it built against the software

Re: [Development] WA_MacBrushedMetal

On Friday July 07 2017 20:55:34 Gabriel de Dietrich wrote: Hi Gabriel, >QMacStyle is no longer using this attribute in 5.10. See >https://codereview.qt-project.org/194383. >We can’t remove it until Qt 6, but it should be documented as deprecated and >effectively useless. That's more or less

[Development] WA_MacBrushedMetal

Hi, Has "brushed metal" mode been maintained in recent history? I haven't seen applications that use it for a long time so I tried WA_MacBrushedMetal out of nostalgia, and was rewarded with what looks most like cast iron (= black on black). Am I doing something wrong or can this attribute be

Re: [Development] QTabBarPrivate::hoveredTabIndex() visibility

On Thursday July 06 2017 15:35:59 Olivier Goffart wrote: > > I'm seeing this when I try to link my standalone version of the QMacStyle > > style against Qt 5.9.0 and 5.9.1 : > > The class was not exported in 5.9.x Thanks for confirming. I guess that also explains why providing just my local

[Development] QTabBarPrivate::hoveredTabIndex() visibility

Hi, Is QTabBarPrivate::hoveredTabIndex() supposed to be visible for software having "QT += widgets-private" in their .pro file? I'm seeing this when I try to link my standalone version of the QMacStyle style against Qt 5.9.0 and 5.9.1 :

Re: [Development] menu item right-to-left mode on Mac (WIP)

https://github.com/RJVB/osx-integration/issues/1 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] menu item right-to-left mode on Mac (WIP)

I've been working on getting R2L rendering in context menus and menus belonging to non-native menubars. I think I'm getting close, there may be only a single thing left to tackle: aligning the actual menu item text. That's the main point of the whole exercise and until now it has proven to be

Re: [Development] right-to-left mode on Mac

Thiago Macieira wrote: > Ah, sorry, my bad. The information is in the .qm file, but not in the .ts one. And there are none of those in qttranslations (5.8.0) itself which explains why I didn't see it. > The array is right above. As I said, I'd like to move that from stored in the > .qm file

Re: [Development] right-to-left mode on Mac

Thiago Macieira wrote: > Except I want to change that. I personally think it's wrong to require the > translators to supply that information. Instead, we should extract from CLDR > and store it in QLocale. I don't see anything in the .ts files that carries this kind of instruction. Instead it

Re: [Development] right-to-left mode on Mac

René J. V. Bertin wrote: > Note (to self): Konsole does the following to force QPainter::drawText to do > L2R rendering; will probably work for the shortcut rendering too. Indeed it does: https://github.com/RJVB/osx-integration/commit/b0c5c13d1f211f664e4d29bf0c29146ef6

Re: [Development] right-to-left mode on Mac

This is side-ways related: among the few bundled *applications* that have a Hebrew (R2l) translation there's a qmlviewer application, for which I cannot seem to find the source. Just trying to find a suitable application with a sufficient UI complexity to test the layout ("pure Qt", otherwise

Re: [Development] right-to-left mode on Mac

Thiago Macieira wrote: >> Shortcut hints are displayed as "C" instead of "C" > > That looks like a Unicode BiDi issue. The  symbol is in the private use area, > so it has no BiDi flow, but "C" does. Note (to self): Konsole does the following to force QPainter::drawText to do L2R rendering;

Re: [Development] right-to-left mode on Mac

Thiago Macieira wrote: > Actually, it can. The Qt translation contains some extra information, like > whether the language is R2L and the plural rules. If you don't load the .qm > file for Qt itself (the qtbase one), you'll have problems. Yeah, I installed the Hebrew translations and can confirm

Re: [Development] right-to-left mode on Mac

Hi Gabriel, I've taken a quick first look at implementing right-to-left support in contextmenus and think it's going to be quite tricky getting the alignment right - a process of educated trial and educating error :) Adding R2L support to my code rendering texted separators was trivial

[Development] right-to-left mode on Mac

Hello, I notice that most styles invert the menu design when you activate right-to-left layout mode, putting the shortcut hint to the left of the (right-aligned) menu item text (and right-aligning texted separators if those are supported and asymmetric). The Mac theme doesn't. Shortcut hints

Re: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole)

Allan Sandfeld Jensen wrote: > QT_LINUX_ACCESSIBILITY_ALWAYS_ON Interesting, I have no trace of that variable, and I cannot imagine that uninstalling at-spi2-core would have unset it in all running shells. > Can you check what im_config sets the QT_IM_MODULE to when ibus is not found? That

Re: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole)

Allan Sandfeld Jensen wrote: > I am on Debian and found the same thing. Apt-get remove im-config solves the > issue. Apparently it is a buggy package that forces Qt to use ibus without > ensuring ibus is launched. That's not what I saw. Ibus was always launched at login, and im-config seems to

Re: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole)

Giuseppe D'Angelo wrote: > https://codereview.qt-project.org/#/c/177188/ Sorry, I was a bit too fast, I'm still at 5.8.0 . Curiously the patch applies with a bit of fuzz, so apparently wasn't refactored for 5.8? R. ___ Development mailing list

Re: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole)

Thiago Macieira wrote: > Check your environment. You must have something that tells Qt to use it. For Qt4 there's QT4_IM_MODULE indeed, and you can configure the input method via qtconfig too. For Qt5 I haven't found anything. In the end I did rename ibus- daemon and ibus-x11, and only then

  1   2   3   4   >