So, the right one uses the native rendering engine? In that case, your rendering engine already works quite well, as the two are almost indistinguishable, aside from something that looks like a cursor on the left side (but also looks like it could be a glitch).
The right version certainly starts and ends faster than the left version. The usage speed is not so much different in this example, but it is very clear in some of the demos. I'll keep you posted .
Native fonts...does it mean we can change font styles and sizes now?
I have yet to add a "default font" option in the prefs, but I certainly will some day. Appart from that then yes, Qt uses different fonts and sizes flawlessly (I assume you are refering to one of the early versions, where only one font and style and size was supported).
How about resize on that, can we able to resize the window now ?
The calculator example IS NOT SUPPOSED to be able to resize, since the code specifies that has static size. Other examples resize very well, but the screen update during resize is currently very slow with the native engine (probably due to the fact, that I am freeing and reallocating both the Bitmap associated with the WindowSurface AND the Layer, TmpRas and AreaInfo of that same bitmap (rastport) in the process. I'm not sure if there is a better solution, the only option I see is, that every widget allocates a bitmap the size of the entire screen, which seems to be not such a great idea (even tooltips would then take up a complete 32 bit Bitmap the size of the entire screen)).
The calculator example IS NOT SUPPOSED to be able to resize
Mmm so maybe in that case it would be better to just remove entirely the resize gadget, having it without any resize functionality still a bit confusing, still also to eliminate certain QT internal resize gadget, actually on a few demos we have two gadget resize, one "internal" from the QT framework and another one on the Amiga window .. the standard Amiga resize gadget would be enough, don't know how easy would be but i think it's needed ..
Beside that i'm very happy about your work on native implementation, is very intriguing to follow and i really looking forward to it
Mmm so maybe in that case it would be better to just remove entirely the resize gadget, having it without any resize functionality still a bit confusing
Yes, I know... <sigh> The problem is, that the fixed size in this particular case is only set AFTER the window/Widget has been opened, and I don't know if it is possible to remove a resize gadget from an already opened window. Anyone??
Quote:
actually on a few demos we have two gadget resize, one "internal" from the QT framework and another one on the Amiga window .. the standard Amiga resize gadget would be enough, don't know how easy would be but i think it's needed ..
Yes, I have lazily been overlooking that issue, but it definetely needs fixing at some point. Not a first priority, though .
Yes, I know... <sigh> The problem is, that the fixed size in this particular case is only set AFTER the window/Widget has been opened, and I don't know if it is possible to remove a resize gadget from an already opened window. Anyone??
Is this another case where delayed-opening of the window (based upon some kind of rules) might be a good idea? I don't know QT though, so I don't know how feasible that is.
I am already using delayed opening of Widgets/windows because of the strange resize effects that Qt does when showing Widgets. So in this case, the static size is set even AFTER the delayed opening, which is hard to get at...
I don't know if it is possible to remove a resize gadget from an already opened window. Anyone??
Doesn't look like it. The solution is probably to close and reopen the window without the size gadget, but that's probably quite messy. Personally I don't really see the harm in having a size gadget that doesn't move, provided the same issue isn't stopping a size gadget from being present when it is needed.
re: the other thing about slow resizing due to re-allocating bitmaps An option here might be to use IDCMP_SIZEVERIFY. This removes the "opaque resize" (or whatever OS4 calls it) and will stop you getting loads of events whilst the window is being resized.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
