Re: [Interest] Bug in QCodoaWindow?

[john]

Thanks, Andy. You're quite right. Now I'm trying to think about troubles I've 
had that require parens, and can't remember... Maybe I was mixing bitwise & and 
bitwise | (or). And certainly it's easy to write buggy code mixing && and ||.

I was primed to find something wrong: I've been getting what as far as I can 
tell are bad window state change events telling me that a window is maximized 
when it isn't. Plays dicky with certain parts of my code!

> On Aug 27, 2020, at 2:25 PM, Andy  wrote:
> 
> Bitwise "&" has precedence over logical "&&", so I think this is alright.
> 

-John Weeks

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

Re: [Interest] Bug in QCodoaWindow?

[Andy]

Bitwise "&" has precedence over logical "&&", so I think this is alright.

https://en.cppreference.com/w/cpp/language/operator_precedence

(Regardless I would always use parens in cases like this to make it easier
for humans reading the code.)

---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney 



On Thu, Aug 27, 2020 at 5:17 PM John Weeks  wrote:

> Isn't this a bug?
>
>  bool QCocoaWindow::isTransitioningToFullScreen() const
> {
> NSWindow *window = m_view.window;
> return window.styleMask & NSWindowStyleMaskFullScreen &&
> !window.qt_fullScreen;
> }
>
> Seems like the bitwise & needs parens.
>
> This is from Qt 5.12.9. Haven't checked Qt 5.15.
>
> -John Weeks
> WaveMetrics, Inc.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Bug in QCodoaWindow?

[John Weeks]

Isn't this a bug?

 bool QCocoaWindow::isTransitioningToFullScreen() const
{
NSWindow *window = m_view.window;
return window.styleMask & NSWindowStyleMaskFullScreen && 
!window.qt_fullScreen;
}

Seems like the bitwise & needs parens.

This is from Qt 5.12.9. Haven't checked Qt 5.15.

-John Weeks
WaveMetrics, Inc.

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

Re: [Interest] Three-file modules vs. moc

[Giuseppe D'Angelo via Interest]

Il 27/08/20 20:46, Bernhard Lindner ha scritto:

This is recommended anyway, regardless of your problem. Always #include the
module output for your headers in your corresponding .cpp files.

Can you explain that general recommendation? It seems to me that such includes 
are only
useful in special cases like mine and like .cpp files containing moc relevant 
code.


Including moc from the C++ code reduces compilation times (one "slightly 
larger" file to compile, not two) and enables the compiler to optimize 
more aggressively without resorting to LTO. As such it's always useful 
to do.


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

Re: [Interest] Three-file modules vs. moc

[Bernhard Lindner]

Hi Thiago!

> Add to your module.cpp:
> 
> #include "moc_module.cpp"

Works well, thank you!

> This is recommended anyway, regardless of your problem. Always #include the 
> module output for your headers in your corresponding .cpp files.

Can you explain that general recommendation? It seems to me that such includes 
are only
useful in special cases like mine and like .cpp files containing moc relevant 
code.

-- 
Best Regards,
Bernhard Lindner

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

Re: [Interest] Three-file modules vs. moc

[Thiago Macieira]

On Wednesday, 26 August 2020 12:40:31 PDT Bernhard Lindner wrote:
> Hi!
> 
> Currently I am facing a problem with a Qt Creator managed Qt 5 project.
> 
> The projects consists of a lot of modules and implements a special but
> useful file concept. Each module has 3 files:
>module.hpp - Public types, macros and declarations
>module.inl - Template function definitions, constexpr and inline function
> definitions module.cpp - All other definitions
> module.cpp includes module.inl and module.inl includes module.hpp.

> How can I solve this problem on the moc side? Is there a way to tell moc via
> the .pro project on a per-module basis to include module.inl instead of (or
> along with) module.inl in moc_module.cpp?

Add to your module.cpp:

#include "moc_module.cpp"

This is recommended anyway, regardless of your problem. Always #include the 
module output for your headers in your corresponding .cpp files.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Interest] Three-file modules vs. moc

[Bernhard Lindner]

Hi!

> I wonder how clients of the class declared in the .hpp file can use that 
> class at all.
> Unless I am missing something, they won’t be able to (at least not in the 
> general case)
> unless they also include the .inl file.

Depends from what part of the module API you want to use. E.g. if only macros or
types/classes are need, including the .hpp is faster and sufficient. This means 
a .hpp
will typically include other .hpp.

If you want to call functions you will include .inl. This means a .cpp or a 
.inl will
typically include other .inl.

> Wouldn’t it be simplier to #include the inl file in the hpp file? That way 
> you still
> have separation of declaration and definition on a file-level, but don’t 
> expose users of
> your C++ headers (including moc) to your way of organizing things.

Tried that before. Then it turned out that on the .inl level a mutual 
dependency lock can
happen (similar to what you get if normal hpp/cpp modules try to include 
include eachother
without using forward declarations). Only the two-level-inclusion as described 
above
reliably solves all mutual inclusion issues.

-- 
Best Regards,
Bernhard Lindner

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

Re: [Interest] Three-file modules vs. moc

[Adam Light]

On Thu, Aug 27, 2020 at 5:43 AM Bernhard Lindner <
priv...@bernhard-lindner.de> wrote:

> > You might also use a custom extra compiler -- that still invokes moc,
> > but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl,
> > and so on...
>
> Hm, I see. Has something like that been done before, is there code I could
> reuse?
>

This is for a rather different use case but attached to
https://bugreports.qt.io/browse/QTBUG-81348 you can find two (very similar)
examples of how to write a custom feature that runs moc in a different way
than the default.

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

Re: [Interest] Three-file modules vs. moc

[Tony Rietwyk]

Hi Bernhard,

I use plain .pro and .pri files with qmake to Visual Studio projects.  
Moc has a feature that prevents the output files being treated as 
separate compiles - if it finds the include in the relevant module 
.cpp.  It works really well for us with thousands of modules.  I not 
sure how that work flow translates to Qt Creator.


If you add

#include 

as the second line in spinbox.cpp, and then run qmake or whatever the 
Creator equivalent is.  After that, the moc steps will run as normal, 
and then the compile of spinbox.cpp without a separate compile for 
moc_spinbox.cpp.


Hope that helps,

Tony


On 27/08/2020 5:40 am, Bernhard Lindner wrote:

Hi!

Currently I am facing a problem with a Qt Creator managed Qt 5 project.

The projects consists of a lot of modules and implements a special but useful 
file
concept. Each module has 3 files:
module.hpp - Public types, macros and declarations
module.inl - Template function definitions, constexpr and inline function 
definitions
module.cpp - All other definitions
module.cpp includes module.inl and module.inl includes module.hpp.

I added all .hpp file names to the .pro file using Qt Creator. All moc relevant 
.hpp files
are parsed fine by moc and a moc_module.cpp file is generated for each module 
as usual.
Unfortunately the moc_module.cpp files includes module.hpp only, since 
module.inl are
unknown to moc.
So all function definitions from moc_module.inl are unknown during compilation 
of
moc_module.cpp and I get undefined reference linker errors (e.g. for property 
related
setters called in the moc_module.cpp code).

Maybe I could use a lot of Q_MOC_RUN preprocessor conditions to work around but 
that would
pollute the code awfully.

How can I solve this problem on the moc side? Is there a way to tell moc via 
the .pro
project on a per-module basis to include module.inl instead of (or along with) 
module.inl
in moc_module.cpp?


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

Re: [Interest] Three-file modules vs. moc

[Volker Hilsheimer]

> On 27 Aug 2020, at 14:42, Bernhard Lindner  
> wrote:
> 
> Hi!
> 
>> Can you make an example of your structure (what's exactly in each of the 
>> three files)? It's not entirely clear.
> 
> Ok, I attached an example of a module containing some pseudo code. Please 
> tell me if you
> need more information.
> 
>> You might also use a custom extra compiler -- that still invokes moc, 
>> but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl, 
>> and so on...
> 
> Hm, I see. Has something like that been done before, is there code I could 
> reuse?

I wonder how clients of the class declared in the .hpp file can use that class 
at all. Unless I am missing something, they won’t be able to (at least not in 
the general case) unless they also include the .inl file.

Wouldn’t it be simplier to #include the inl file in the hpp file? That way you 
still have separation of declaration and definition on a file-level, but don’t 
expose users of your C++ headers (including moc) to your way of organizing 
things.


Volker

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

Re: [Interest] Three-file modules vs. moc

[Bernhard Lindner]

Hi!

> Can you make an example of your structure (what's exactly in each of the 
> three files)? It's not entirely clear.

Ok, I attached an example of a module containing some pseudo code. Please tell 
me if you
need more information.

> You might also use a custom extra compiler -- that still invokes moc, 
> but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl, 
> and so on...

Hm, I see. Has something like that been done before, is there code I could 
reuse?

-- 
Best Regards,
Bernhard Lindner

#include "spinbox.inl"

SpinBoxU64::SpinBoxU64(QWidget* pParent) noexcept :
   AbstractSpinBox(pParent)
{
}
#ifndef SPINBOX_HPP
#define SPINBOX_HPP

template 
class AbstractSpinBox : public QAbstractSpinBox
{
   public:
  explicit AbstractSpinBox(QWidget* pParent = nullptr) noexcept;

  T value() const noexcept;
  void setValue(const T& pValue) noexcept;

  T minimum() const noexcept;
  void setMinimum(const T& pMinimum) noexcept;

  T maximum() const noexcept;
  void setMaximum(const T& pMaximum) noexcept;

  ...
};

class SpinBoxU64 : public AbstractSpinBox
{
  Q_OBJECT

  Q_PROPERTY(quint64 minimum READ minimum WRITE setMinimum)
  Q_PROPERTY(quint64 maximum READ maximum WRITE setMaximum)
  Q_PROPERTY(quint64 value READ value WRITE setValue NOTIFY valueChanged USER true)

   public:
  explicit SpinBoxU64(QWidget* pParent = nullptr) noexcept;

   signals:
  void valueChanged(const quint64& pValue);

  ...
};

#endif // SPINBOX_HPP
#ifndef SPINBOX_INL
#define SPINBOX_INL

#include "spinbox.hpp"

template 
AbstractSpinBox::AbstractSpinBox(QWidget* pParent) noexcept :
   QAbstractSpinBox(pParent)
{
   
}

template 
void AbstractSpinBox::setMinimum(const T& pMinimum) noexcept
{
   
}

template 
void AbstractSpinBox::setMaximum(const T& pMaximum) noexcept
{
   
}

template 
void AbstractSpinBox::setValue(const T& pValue) noexcept
{
   
}

template 
inline T AbstractSpinBox::minimum() const noexcept
{
   
}

template 
inline T AbstractSpinBox::maximum() const noexcept
{
   
}

template 
inline T AbstractSpinBox::value() const noexcept
{
   
}

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

Re: [Interest] Three-file modules vs. moc

[Giuseppe D'Angelo via Interest]

Hi,

Can you make an example of your structure (what's exactly in each of the 
three files)? It's not entirely clear.


Il 27/08/20 13:26, Bernhard Lindner ha scritto:

Hm. I am not sure I get it. That is a global option, right? I have a LOT of 
modules, each
with a different name. When adding an -f option for each of them, each 
moc_*.cpp file
would include all *.inl includes... which would increase compile time 
exponentially. I
would like to avoid that.


You might also use a custom extra compiler -- that still invokes moc, 
but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl, 
and so on...


--
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

Re: [Interest] Three-file modules vs. moc

[Bernhard Lindner]

Hi!

> > I added all .hpp file names to the .pro file using Qt Creator. All moc 
> > relevant
> > .hpp files are parsed fine by moc and a moc_module.cpp file is generated for
> > each module as usual.
> 
> Have you tried adding the .inl files to HEADERS instead?

Yes. But it didn't work. Even more undefined references. 

module.inl never contains moc relevant code but module.hpp does. I guess for 
this to work,
moc would need to resolve the contained #include "module.hpp". It generally 
doesn't
resolve includes, does it?

> > Unfortunately the moc_module.cpp files includes module.hpp only, since
> > module.inl are unknown to moc.
> > So all function definitions from moc_module.inl are unknown during
> > compilation of moc_module.cpp and I get undefined reference linker errors
> > (e.g. for property related setters called in the moc_module.cpp code).
> 
> You can let moc add additional includes in it's output via -f argument,
> Custom options to moc can be set in qmake via QMAKE_MOC_OPTIONS. 

Hm. I am not sure I get it. That is a global option, right? I have a LOT of 
modules, each
with a different name. When adding an -f option for each of them, each 
moc_*.cpp file
would include all *.inl includes... which would increase compile time 
exponentially. I
would like to avoid that.

-- 
Best Regards,
Bernhard Lindner

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

[Interest] [SPAM] Reorganizing Accessibility Tree And Easily Changing Accessibility Properties?

[Chi Kim]

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.

Content preview:  Hi All, I'm trying to reorganize how QT presents QT built-in
   widgets to VoiceOver on Mac just for accessibility purpose. What's the best
   way to reorganize how items appear in accessibility tree without affect [...]
   

Content analysis details:   (5.8 points, 4.6 required)

 pts rule name  description
 -- --
 0.8 BAYES_50   BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
 1.3 RCVD_ILLEGAL_IPReceived: contains illegal IP address
 0.0 FREEMAIL_FROM  Sender email is commonly abused enduser mail
provider (chigookkim[at]hotmail.com)
-0.0 SPF_HELO_PASS  SPF: HELO matches SPF record
-0.0 RCVD_IN_MSPIKE_H2  RBL: Average reputation (+2)
[40.92.42.97 listed in wl.mailspike.net]
 1.0 FORGED_SPF_HELONo description available.
 0.4 KHOP_HELO_FCRDNS   Relay HELO differs from its IP's reverse DNS
 2.3 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla


--- Begin Message ---

Hi All,

I'm trying to reorganize how QT presents QT built-in widgets to 
VoiceOver on Mac just for accessibility purpose. What's the best way to 
reorganize how items appear in accessibility tree without affecting GUI? 
For example, I would like to:

1. Relocate an item from current parent to another parent
2. Create a node and Group a number of items under that node as a sub level
It looks like I can change parent and children relationship through 
QAccessibleInterface. However, is there a way to change 
QAccessibleInterface for QT built-in widgets without modifying QT source 
and recompiling?
On a related note, is there a way to modify accessibility properties 
without having to subclassing and implementing QAccessibleInterface? For 
example QWidget has setAccessibleName, and setAccessibleDescription.
If QWidget had something like removeAccessibleChild and 
insertAccessibleChild, it would be pretty easy to modify the tree.
Or, if there was a way to utilize lambda to override member functions 
and return different accessibility properties to accessibility clients...

Thanks!

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

Re: [Interest] Three-file modules vs. moc

[Kai Köhne]

> -Ursprüngliche Nachricht-
> Von: Interest  Im Auftrag von Bernhard
> Lindner
> Gesendet: Mittwoch, 26. August 2020 21:41
> An: interest@qt-project.org
> Betreff: [Interest] Three-file modules vs. moc
> 
> Hi!
> 
> Currently I am facing a problem with a Qt Creator managed Qt 5 project.
> 
> The projects consists of a lot of modules and implements a special but useful
> file concept. Each module has 3 files:
>module.hpp - Public types, macros and declarations
>module.inl - Template function definitions, constexpr and inline function
> definitions
>module.cpp - All other definitions
> module.cpp includes module.inl and module.inl includes module.hpp.
> 
> I added all .hpp file names to the .pro file using Qt Creator. All moc 
> relevant
> .hpp files are parsed fine by moc and a moc_module.cpp file is generated for
> each module as usual.

Have you tried adding the .inl files to HEADERS instead?

> Unfortunately the moc_module.cpp files includes module.hpp only, since
> module.inl are unknown to moc.
> So all function definitions from moc_module.inl are unknown during
> compilation of moc_module.cpp and I get undefined reference linker errors
> (e.g. for property related setters called in the moc_module.cpp code).

You can let moc add additional includes in it's output via -f argument,
Custom options to moc can be set in qmake via QMAKE_MOC_OPTIONS. 
 
> Maybe I could use a lot of Q_MOC_RUN preprocessor conditions to work
> around but that would pollute the code awfully.
> 
> How can I solve this problem on the moc side? Is there a way to tell moc via
> the .pro project on a per-module basis to include module.inl instead of (or
> along with) module.inl in moc_module.cpp?

See above. Either let moc directly parse module.inl, instead of module.hpp.

Or let the generated moc file include module.inl by setting e.g.

  QMAKE_MOC_OPTIONS=-fmodule.inl


Regards

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