Re: [Interest] Qt3D point light intesity

[Megidd Git]

Cool, thanks! 

On Sat, Apr 11, 2020 at 9:00 PM Esch Lorenz TU Ilmenau <
lorenz.e...@tu-ilmenau.de> wrote:

> Hi,
>
>
>
> QPointLight inherits from QAbstractLight, which offers setIntensitiy().
> See https://doc.qt.io/qt-5/qt3drender-qabstractlight.html#intensity-prop.
> Hope this helps.
>
>
>
> Cheers,
>
>
>
> Lorenz
>
>
>
> *Von:* Interest  *Im Auftrag von *Megidd
> Git
> *Gesendet:* Samstag, 11. April 2020 11:30
> *An:* interest@qt-project.org
> *Betreff:* [Interest] Qt3D point light intesity
>
>
>
> Hi!
>
>
>
> I'm using point light  in
> a 3D scene with entities of Phong
>  material. I
> just want to be able to increase/decrease point light *intensity*. Point
> light has three properties:
>
>
>
> - constantAttenuation : float
>
> - linearAttenuation : float
>
> - quadraticAttenuation : float
>
>
>
> Documentation mentions that the exact meaning and use of those properties
> is up to the material implementation. Now I wonder how can I simply
> decrease/increase light intensity, considering that I'm using Phong
>  material.
>
>
>
> Thanks
>
> 
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt3D point light intesity

[Esch Lorenz TU Ilmenau]

Hi,

QPointLight inherits from QAbstractLight, which offers setIntensitiy(). See 
https://doc.qt.io/qt-5/qt3drender-qabstractlight.html#intensity-prop. Hope this 
helps.

Cheers,

Lorenz

Von: Interest  Im Auftrag von Megidd Git
Gesendet: Samstag, 11. April 2020 11:30
An: interest@qt-project.org
Betreff: [Interest] Qt3D point light intesity

Hi!

I'm using point light in a 
3D scene with entities of 
Phong material. I 
just want to be able to increase/decrease point light intensity. Point light 
has three properties:

- constantAttenuation : float
- linearAttenuation : float
- quadraticAttenuation : float

Documentation mentions that the exact meaning and use of those properties is up 
to the material implementation. Now I wonder how can I simply decrease/increase 
light intensity, considering that I'm using 
Phong material.

Thanks

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Links in PDF printed from QTextDocument

[Giuseppe D'Angelo via Interest]

Il 10/04/20 23:13, Josh ha scritto:

Currently, I have my own print function which generates the PDF like
following:

...
painter.translate(xmar/scale, -page*pageHeight + ymar/scale);
myDocument->drawContents(, view);
...

Any ideas about getting links into the PDF are appreciated.


This should "just work". Are the links correctly inserted in the 
document? Does it work if you use document->print() and print directly 
on a PDF?


HTH,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt3D point light intesity

[Megidd Git]

Hi!

I'm using point light  in
a 3D scene with entities of Phong
 material. I
just want to be able to increase/decrease point light *intensity*. Point
light has three properties:

- constantAttenuation : float
- linearAttenuation : float
- quadraticAttenuation : float

Documentation mentions that the exact meaning and use of those properties
is up to the material implementation. Now I wonder how can I simply
decrease/increase light intensity, considering that I'm using Phong
 material.

Thanks

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] mingw64: can't compile a lib such that a Qt signal can connect successfully to a binary slot

[Thiago Macieira]

On Saturday, 11 April 2020 05:51:50 -03 Filippo Rusconi via Interest wrote:
> Warning: QObject::connect: signal not found in pappso::PrecisionWidget (:0,
> )
> 
> Note that the pappso::PrecisionWidget class emits a signal that is very
> simple: it just has a conventional pointer as its argument:
> 
> 8<~~
> typedef const PrecisionBase *PrecisionPtr;
> 
> signals:
>void precisionChanged(pappso::PrecisionPtr precision) const;
> ~~>8
> 
> I hope somebody can answer the following questions:
> 
> First question:
> 
> 
> What is the (:0, ) string element above ?

Probably part of the problem. That comes from:

if (!senderMetaObject) {
qWarning("QObject::connect: signal not found in %s", sender-
>metaObject()->className());
slotObj->destroyIfLastRef();
return QMetaObject::Connection(nullptr);
}

It's trying to print the class name. There's no reason for more junk to be 
printed in the line. So either there's something else also wrong with 
debugging or something is wrong with the meta object. Since it can't find the 
signal (which is related to the meta object), there's a good chance the two 
problems are connected.

> Second question:
> 
> 
> Is the windows-specific dllexport macro art required when using the MinGW64
> build environment and using CMake to build shared libs and executable
> binaries ?

Yes. Each class must be either:

a) be a template instantiation (absolutely everything inline and doesn't take 
addresses of any static variables)
b) used exclusively inside one single DLL
c) be exported from exactly one DLL and imported from all others

> Then I tried building the library by specifying the following, according to
> the CMake docs:
> 
> -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE -DBUILD_SHARED_LIBS=TRUE

That accomplishes exporting.

You also need to *import* it from all the other libraries.

> Third question:
> ---
> 
> When building the library, I get systematically two dll artifacts: the
> libname.dll and the libname.dll.a. What are the differences between the two?
> I tried linking against one or the other, but that does not solve my
> problem. I thought the dll.a file was a static library, which indeed seems
> to be (I could extract *.o files out of it using ar). However, when I link
> against the dll.a file, the dll is still required at run time.

The .dll file is the DLL that is used by the Windows OS to load the code at 
runtime.

The .dll.a file is the "import library". It's not a static library. It's how 
the linker on Windows links to a DLL: it links to a very small .a file that 
simply has "imports" for the DLL. That's different from all Unix systems, 
where you link directly to the .so file and the linker takes care of writing 
the correct output.

However, I think the GNU linker for Windows is smart enough to link to the 
.dll file correctly, as you've seen. The MSVC link.exe is not: it still needs 
to link to the import .lib file. So MinGW keeps this legacy. A simple 
advantage of the import lib is that the .dll must live in the bin directory 
for it to be useful at runtime, so you won't need to have a copy in the lib 
dir too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] mingw64: can't compile a lib such that a Qt signal can connect successfully to a binary slot

[Filippo Rusconi via Interest]

Greetings, Thiago,

thank you for your follow-up.

On Thu, Apr 09, 2020 at 11:37:57AM -0300, Thiago Macieira wrote:

On Thursday, 9 April 2020 09:02:32 -03 Filippo Rusconi via Interest wrote:

Why not?


Evidently, my previous mail was somehow crippled. This is my story:

I develop a scientific program using Qt5.12.5 / CMake / Debian testing, with:

gcc (Debian 9.3.0-3) 9.3.0.

The program makes heavy use of QThread, and, of course Signal/Slot connections.
It runs beautifully in my Debian box, with now apparent bugs since weeks of
testing.

I build two artifacts:

- a library with classes that emit Qt signals (pappso lib below);
- an executable binary that connects slots to these library-emitted signals.

When I want to craft a Win10 binary, I'm used to just dump the source code into
Win10/MingW64 (in the msys64 installment) and build it. I magically have a
perfect match of behaviours under Linux and Win10.

My last successful creation of Win binaries dates back roughly one year. At that
time the gcc version was 7.x, if I recall correctly. This last year, I have
rewritten the software almost entirely and now that it is in good shape, I want
to create binaries for Win10 (Qt5.14.1, here).  In this new version, I am making
use of many more signal/slot connections between my executable and the dll.

The program builds just fine, but when I run it, I get this kind of message:

Warning: QObject::connect: signal not found in pappso::PrecisionWidget (:0, )

Note that the pappso::PrecisionWidget class emits a signal that is very simple:
it just has a conventional pointer as its argument:

8<~~
typedef const PrecisionBase *PrecisionPtr;

signals:
  void precisionChanged(pappso::PrecisionPtr precision) const;
~~>8

I hope somebody can answer the following questions:

First question: 



What is the (:0, ) string element above ?

Second question:


Is the windows-specific dllexport macro art required when using the MinGW64
build environment and using CMake to build shared libs and executable binaries ?

The program does not work as expected without the connections, understandably,
although it loads and performs well where signal/slot exe<-->lib connections are
not required (like clicking buttons located in the executable, for example).

This observation makes me think that I am using MinGW64 in an overall good
manner.

Then I tried building the library by specifying the following, according to the
CMake docs:

-DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE -DBUILD_SHARED_LIBS=TRUE

but, although the md5 checksums of the libs are different, the sizes of the libs
(with or without this dllexport art) are identical. So, I gather that the
defines above are not essential ?

Third question:
---

When building the library, I get systematically two dll artifacts: the
libname.dll and the libname.dll.a. What are the differences between the two? I
tried linking against one or the other, but that does not solve my problem. I
thought the dll.a file was a static library, which indeed seems to be (I could
extract *.o files out of it using ar). However, when I link against the dll.a
file, the dll is still required at run time.

What other information should I provide to help you help me fix the problem ?

FYI, I am using -G "Unix Makefiles" and have confirmed that WIN32 is indeed
defined during the configuration of the build. What about using -G "MinGW
Makefiles". I tried, but the build seems to go the exact same way as the other
"Unix way". What is the difference between the two, in a msys64/mingw64 context?

Thank you for your patience and hoping help,
Sincerely, Filippo
Greetings,



--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org


book: http://www.lavoisier.fr/livre/notice.asp?id=3LKW2OAR2KROWZ
http://books.google.fr/books?id=2NmguxmEI1sC=frontcover=rusconi+f+lavoisier=fr=X=nGGOUt2SH_Ly0gX0uIHoBQ=0CDUQ6AEwAA#v=onepage=false

Génétique Quantitative et Évolution & Plateforme PAPPSO
UMR CNRS 8120 – INRA – Université Paris-Sud – AgroParisTech - Université 
Paris-Saclay
http://moulon.inra.fr/ & http://pappso.inra.fr/
Ferme du Moulon
91190 Gif-sur-Yvette
France
Tel : +33 (0)1 69 33 23 54
Fax : +33 (0)1 69 33 23 40
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest