Re: [Interest] Qt Binaries for Mingw 4.7
Hi, On Monday 23 July 2012 23:24:38 K. Frank wrote: On Mon, Jul 23, 2012 at 4:33 PM, Konrad Rosenbaum kon...@silmor.de wrote: ... Doubtful. The only way to do this would be to add buffering and prefetching to mingw implementations of read, write, open, close, etc. This would break some of the promises they make - i.e. that they are synchronous in regard to all other processes on the same machine. Well, that's too bad. I wonder how microsoft does it. (My understanding is that the msvc compile times are pretty good.) My guess would be: start a thread per source file, map the entire pre- processed source into memory, generate the object file in memory, and finally write the object file out in one go, end the thread. As compared to most other compilers: keep each compile step in one process (pre-processor, compiler, assembler makes at least 3), read files as you go, pipe them from one process to the next, reading as many bytes as you need for the next step, write out the results as they come along (one function at a time, jumping between different sections of the object file too). But I could imagine that slipping a layer between mingw and gcc could help, since those promises don't need to be quite as strong in the typical GCC scenario (it is enough to be synchronized after the gcc process ends). Hmm, is there an equivalent to LD_PRELOAD on Windows? I.e. is it possible to exchange certain library calls for some processes, but not others? Thanks for the suggestions. Do I take it you have a plan? ;-) ... I should note that when I upgraded to g++ 4.7.0 and Qt 4.8.0-rc1, I almost didn't have enough memory to complete the build. The build process ran out of memory when linking QtGuid4.dll, but after a fresh reboot and killing off what I deemed to be some unnecessary processes (to free up as much memory as I could), I was able to rerun the build process and have it complete successfully. (At that time people made various suggestions as how to reduce the memory requirements of the build. But since I ended up having enough memory, I didn't try any of them, and I did successfully complete the default build.) Out of curiosity: how much memory did it take? I usually give my Windows-VM less than 1GB. I don't know exactly. I would say that I needed pretty close to 2 GB (not just for the linking process itself, but also for whatever else the os felt it needed.) Ok, I definitely need to increase my VM size when building Qt. My reasoning is that I have 2 GB of physical memory. I tired the build after my machine had been running for a while, and with some irrelevant processes running, and the build failed. I then rebooted, and killed of what I thought were extraneous processes, and the build succeeded. If I had to guess, I would guess that the build needed somewhere between 1.5 and 2 GB, but that's just a soft guess. I don't know to what extent the memory you assign your VM and the physical memory on my machine are comparable, In theory it should be pretty much comparable - from the point of view of the VM it has physical memory. The only differences it sees is that the chipset was manufactured by VirtualBox, it has some weird drivers for those chips, and the CPU-counter and clock tend to jump a lot. Memory wise it believes it works with physical RAM and physical hard disks, although both are virtual. and I don't know what effects my using 64-it windows has, but based on my experience, I'm not surprised that your build failed with out of memory if you gave it less than 1 GB. My guess would be a factor or 1.1 - 2 depending on the application, the more it handles pointers the closer it gets to 2. Konrad signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt5: Obtain current layout size
Den 23-07-2012 15:41, Stephen Chu skrev: On 7/23/12 4:52 AM, Bo Thorsen wrote: Den 22-07-2012 21:49, Stephen Chu skrev: On 7/22/12 6:30 AM, Bo Thorsen wrote: Den 21-07-2012 18:27, Stephen Chu skrev: I am working on a dynamically generated form. One thing I'd like to do is to reflow the layout into multi-column when the widgets fill the preset window height. I need to find out what the current layout height is before I add the new widget. The problem is, layout geometry is always 0x0 before the window is shown. And if I show the window before adding the widgets, not only does the window flickers badly, it also doesn't auto-position correctly. What's worse, the geometry reported is still 0x0. So how do I get the correct layout or parent widget size before showing the widget/window? Thanks. You can't use size or geometry because they are properties of what is actually shown. For your case, you should use the minimum sizes instead. Those should be available to you. Thanks. That works. Do you happen to know how I can get the size of a window maximized without first maximize it? You can't do that. The real fix for what you are trying to do here is to write your own layout manager class. You should subclass QLayout and implement the layouting yourself. It's the only way (I think) that truly does what you want to achieve without using a bunch of bad hacks along the way. I wouldn't say it's a hack. I am arranging the layout dynamically by considering how much the window is allowed to grow. What you're trying to do isn't a hack, of course. What you end up having to do to implement it will be. Your problem with the full screen shows this. And even if I go custom layout route, I still need to know where I need to place the new widget so I don't grow the window out of the screen, right? The layout manager is asked the minimum size of the widget, which for you is impossible to answer. This is already an indication why you have problems here. In case you want to discuss if this is possible or not: minimumSize gives a QSize back. In your case, the minimum height is actually the height of one row. But for any number of rows, the minimum width changes. There is, however, a function called heightForWidth or widthForHeight - I don't remember which way they chose. This might actually be exactly what you are looking for. Try experimenting with that. Anyway, once the size of the window is chosen, the layout manager is asked to place the widgets inside the parent. At this point, the layout knows what size the container will have, so it can place the widgets correctly. Bo Thorsen, Fionia Software. -- Expert Qt and C++ developer for hire Contact me if you need expert Qt help http://www.fioniasoftware.dk ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
On terça-feira, 24 de julho de 2012 09.06.36, Konrad Rosenbaum wrote: As compared to most other compilers: keep each compile step in one process (pre-processor, compiler, assembler makes at least 3), read files as you go, pipe them from one process to the next, reading as many bytes as you need for the next step, write out the results as they come along (one function at a time, jumping between different sections of the object file too). While the preprocessor still exists as a separate executable, the preprocessing is not a separate step anymore. You can confirm that by adding -v to the gcc build and you'll see that it does not run cpp anymore. In other words, the compiler will do the preprocessing step. Moreover, in order to do optimisations, it needs to know the entire preprocessed output, but I'd guess it does so in an AST form already. The output from the compiler does jump between sections. But the output from the assembler doesn't, so the assembler needs to read the entire compiler output into memory before it can start writing out its own output. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
Hi Konrad! On Tue, Jul 24, 2012 at 3:06 AM, Konrad Rosenbaum kon...@silmor.de wrote: Hi, On Monday 23 July 2012 23:24:38 K. Frank wrote: On Mon, Jul 23, 2012 at 4:33 PM, Konrad Rosenbaum kon...@silmor.de wrote: ... ... But I could imagine that slipping a layer between mingw and gcc could help, since those promises don't need to be quite as strong in the typical GCC scenario (it is enough to be synchronized after the gcc process ends). Hmm, is there an equivalent to LD_PRELOAD on Windows? I.e. is it possible to exchange certain library calls for some processes, but not others? Thanks for the suggestions. Do I take it you have a plan? ;-) No. Maybe it's a little selfish of me, but mingw / mingw-w64 is good enough for me, even if it is slow on bigger projects. (Also, I'm not sure that I'd have the strength to tackle something like this.) ... I should note that when I upgraded to g++ 4.7.0 and Qt 4.8.0-rc1, I almost didn't have enough memory to complete the build. The build process ran out of memory when linking QtGuid4.dll, but after a fresh reboot and killing off what I deemed to be some unnecessary processes (to free up as much memory as I could), I was able to rerun the build process and have it complete successfully. (At that time people made various suggestions as how to reduce the memory requirements of the build. But since I ended up having enough memory, I didn't try any of them, and I did successfully complete the default build.) ... Out of curiosity: how much memory did it take? I usually give my Windows-VM less than 1GB. I don't know exactly. I would say that I needed pretty close to 2 GB (not just for the linking process itself, but also for whatever else the os felt it needed.) Ok, I definitely need to increase my VM size when building Qt. If you do build Qt again with mingw and happen to get further information on how much memory is required, please consider posting what you learn. I'd certainly be interested. Which part of the build used the most memory would also be nice to know. (In my case linking QtGuid4.dll was the sticking point.) ... Konrad Thanks. K. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
Hello Thiago! On Tue, Jul 24, 2012 at 7:11 AM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 24 de julho de 2012 09.06.36, Konrad Rosenbaum wrote: As compared to most other compilers: keep each compile step in one process (pre-processor, compiler, assembler makes at least 3), read files as you go, pipe them from one process to the next, reading as many bytes as you need for the next step, write out the results as they come along (one function at a time, jumping between different sections of the object file too). While the preprocessor still exists as a separate executable, the preprocessing is not a separate step anymore. You can confirm that by adding -v to the gcc build and you'll see that it does not run cpp anymore. In other words, the compiler will do the preprocessing step. Moreover, in order to do optimisations, it needs to know the entire preprocessed output, but I'd guess it does so in an AST form already. The output from the compiler does jump between sections. But the output from the assembler doesn't, so the assembler needs to read the entire compiler output into memory before it can start writing out its own output. Thanks, that's helpful information to mull over. In terms of compiler speed, it seems to me that the consensus is that gcc on windows (e.g., mingw or mingw-w64) is slow. Would you have any thoughts on why that might be? I've heard a couple of different possibilities: one is that the cost of spawning processes is higher on windows; and now from Konrad that a lot of small i/o operations could be the culprit. ... Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Thanks for any further thoughts. K. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Creating Desktop Widgets (aka Desklets) in Qt
Hi, I am tasked in creating desktop widgets (aka desklets, stuff like system monitors, clocks, etc) in Qt, the target platform is Windows. So far I managed to create a frameless window which stays on bottom and isn't shown on taskbar by following window flags: Qt::SubWindow | Qt::FramelessWindowHint | Qt::WindowStaysOnBottomHint However no matter what I tried, I didn't manage to keep the desklets shown when user presses the Windows show desktop icon. Does anybody know a way? The desklet class is a subclass of QWidget, using QDesktopWidget doesn't help the situation at all (and from docs it's clear it is for different purpose). I tried intercepting events which make the desklet hide, but it seems this is a special case not handled by any event... I tried all prospective window flags, even those more crazy in the aspect. But all to no avail... signature.asc Description: OpenPGP digital signature ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] MouseArea on top of Flickable
On Sun, Jul 22, 2012 at 3:45 AM, Mark mark...@gmail.com wrote:
Hi,
I have a Flickable with a MouseArea on top of it. I only want to use
the MouseArea fro the pressed events, the flackable should just be
working with dragging up/down. This however isn't as easy as it
sounds..
It looks somewhat like this:
Flickable
{
MouseArea
{
anchors.fill parent
onPressed:
{
}
}
}
I think you get the idea.
But how can i get this working? I'm using Qt 4.8, i know this has been
fixed in Qt 5 / QML 2, but i kinda need a workaround for 4.8 if
possible :)
Cheers,
Mark
Bump..
still having this issue.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QTabBar drawBase property- what does it do?
I am in the process of porting code that draws images of controls. Due to history and architecture, I'm not using QWidgets as the basis for these controls, they are drawn using OS primitives. Now I am drawing them with QStyle. There are references amonst the Tab Bar stuff to a base. The QTabBar widget has a property drawBase so I created a test case: a dialog layout with two QTabBars one with drawBase set and the other without. I've looked at Windows, Plastique, CleanLooks, Macintosh and Motif styles and can't see any difference. So... What does drawBase do? What are all those references (especially for QStyle::pixelMetric) to things related to TabBarBase? -John Weeks ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] MouseArea on top of Flickable
On Tue, Jul 24, 2012 at 7:40 PM, Mark mark...@gmail.com wrote:
On Sun, Jul 22, 2012 at 3:45 AM, Mark mark...@gmail.com wrote:
Hi,
I have a Flickable with a MouseArea on top of it. I only want to use
the MouseArea fro the pressed events, the flackable should just be
working with dragging up/down. This however isn't as easy as it
sounds..
It looks somewhat like this:
Flickable
{
MouseArea
{
anchors.fill parent
onPressed:
{
}
}
}
I think you get the idea.
But how can i get this working? I'm using Qt 4.8, i know this has been
fixed in Qt 5 / QML 2, but i kinda need a workaround for 4.8 if
possible :)
Cheers,
Mark
Bump..
still having this issue.
YES, got it fixed!
The solution was quite simple. In this case i simply had to add
preventStealing: true to the MouseArea as given in my example. It's
even described in the docs:
http://qt-project.org/doc/qt-4.8/qml-mousearea.html#preventStealing-prop
It feels a bit nasty though..
While putting that preventSteaning in QtCreator (2.4.1) i also notices
a big in there. QtCreator seems to thing the property preventStealing
does not exist. It obviously does. The import is import QtQuick 1.1 so
everything is fine there.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QTabBar drawBase property- what does it do?
On Tuesday 24 July 2012 21:34:14 John Weeks wrote: I am in the process of porting code that draws images of controls. Due to history and architecture, I'm not using QWidgets as the basis for these controls, they are drawn using OS primitives. Now I am drawing them with QStyle. There are references amonst the Tab Bar stuff to a base. The QTabBar widget has a property drawBase so I created a test case: a dialog layout with two QTabBars one with drawBase set and the other without. I've looked at Windows, Plastique, CleanLooks, Macintosh and Motif styles and can't see any difference. So... What does drawBase do? What are all those references (especially for QStyle::pixelMetric) to things related to TabBarBase? -John Weeks A QTabWidget usually has a frame around its contents (let's forget about documentMode right now). The tab bar at the top breaks this frame for the active tab, in other words, the QTabBar has to render above the frame drawn by QTabWidget. The amount of pixels the two widgets share the frame is called the overlap. The base is historically the line drawn for a QTabBar, that is actually a visual part of the QTabWidget. Depending on the style, the base might include other graphics at the background. For example, using the Skulpture style, the base graphics is a recessed looking background. See http://kdepepo.files.wordpress.com/2009/05/kde4-style- skulpture.png?w=480 -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
Hi Thiago! On Tue, Jul 24, 2012 at 5:20 PM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 24 de julho de 2012 11.04.22, K. Frank wrote: In terms of compiler speed, it seems to me that the consensus is that gcc on windows (e.g., mingw or mingw-w64) is slow. Would you have any thoughts on why that might be? I've heard a couple of different possibilities: one is that the cost of spawning processes is higher on windows; and now from Konrad that a lot of small i/o operations could be the culprit. Another possibility is that the malloc() is slow. There are many reasons why the same compiler in a different OS might be slow. Thanks Thiago. More food for thought ... ... Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Happy Hacking! K. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Creating Desktop Widgets (aka Desklets) in Qt
Sent: Wednesday, 25 July 2012 1:35 AM Hi, I am tasked in creating desktop widgets (aka desklets, stuff like system monitors, clocks, etc) in Qt, the target platform is Windows. So far I managed to create a frameless window which stays on bottom and isn't shown on taskbar by following window flags: Qt::SubWindow | Qt::FramelessWindowHint | Qt::WindowStaysOnBottomHint However no matter what I tried, I didn't manage to keep the desklets shown when user presses the Windows show desktop icon. Does anybody know a way? The desklet class is a subclass of QWidget, using QDesktopWidget doesn't help the situation at all (and from docs it's clear it is for different purpose). I tried intercepting events which make the desklet hide, but it seems this is a special case not handled by any event... I tried all prospective window flags, even those more crazy in the aspect. But all to no avail... They are called gadgets on Windows. From a quick read, I doubt Qt is any use: http://msdn.microsoft.com/en-us/library/windows/desktop/bb456468%28v=vs.85%29.aspx Regards, Tony ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
