Re: Policy regarding QtWebKit and QtScript

[Thiago Macieira]

On Tuesday 22 December 2015 16:07:06 Lisandro Damián Nicanor Pérez Meyer 
wrote:
> IIRC Thiago said that it didn't use private stuff, so recompiling should be 
> more than enough (in case it is really needed).

I might be wrong. But that's the kind of breakage that is easily caught before 
Qt releases and should get fixed in updated qtwebkit source packages.

qtquick1 is a whole other story. Its life ends now.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Re: Policy regarding QtWebKit and QtScript

[Thiago Macieira]

On Wednesday 23 December 2015 00:06:18 Luigi Toscano wrote:
> Shouldn't it be the other way around? Workable solution first and drop the
> old one later?

The big problem of keeping qtwebkit in the 5.6 release is that it would need 
to be supported for the 3 years of the long term support release and that is 
simply too much to ask for, for a module that needs security updates we are 
hardly getting from upstream.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
 

Re: Policy regarding QtWebKit and QtScript

[Christoph Cullmann]

Hi,

>> Isn't the designated successor for QtScript QJSEngine
>> (I even assumed there should be some porting tools?)
> 
> That's what I meant under 'qml engines'. :)
> 
> A relevant mail by Frederik:
> http://lists.qt-project.org/pipermail/interest/2015-June/017446.html
for KTextEditor:

1) kross is useless for it

2) QJSEngine: I tried to port with Qt 5.4, but it didn't allow for all things 
needed like setting up some
global functions in the engine and wrapping custom datatypes like QtScript did, 
perhaps this has changed
but as IMHO no porting guidelines exist, have not tried it again. (attached the 
state of the port,
if somebody wants to give it a try) But as the above mail indicates, such a 
guide should come up.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234


qjs.diff.gz
Description: GNU Zip compressed data

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

[René J . V . Bertin]

> On Dec. 19, 2015, 11:23 a.m., David Faure wrote:
> > src/kdeui/kpushbutton.cpp, line 256
> > 
> >
> > This patch looks wrong because KPushButton can be used outside of 
> > "dialog button boxes", while the styleHint is supposed to be only about 
> > dialog button boxes.
> > 
> > QPushButton::sizeHint does this:
> > bool showButtonBoxIcons = 
> > qobject_cast(parentWidget())
> >   && 
> > style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons);
> > which is a solution for testing the parent widget.
> > 
> > I still don't fully understand the issue though, at painting time both 
> > QPushButton and KPushButton call QStyle's CE_PushButton, so I don't see why 
> > these two would be working differently.
> > Is this a workaround for KPushButton which doesn't fix QPushButton?
> 
> René J.V. Bertin wrote:
> David, I'm dropping this whole RR, leaving it open only in case Thomas 
> wants to pursue his view on fixing what there is to fix.
> 
> You are right though, it's a workaround for KPushButton which doesn't 
> depend on fixing QPushButton. And whether or not QPushButton requires fixing 
> is apparently the big question. What is your idea on the scope of 
> `ShowIconsOnButtons`?
> 
> Thomas Lübking wrote:
> The "problem" is that this is really scattered around everywhere :(
> 
> One major catch should be (frameworksintegration)
> 
> ```
> diff --git a/src/platformtheme/kdeplatformfiledialoghelper.cpp 
> b/src/platformtheme/kdeplatformfiledialoghelper.cpp
> index 11e7efb..9cd374c 100644
> --- a/src/platformtheme/kdeplatformfiledialoghelper.cpp
> +++ b/src/platformtheme/kdeplatformfiledialoghelper.cpp
> @@ -161,6 +161,11 @@ void 
> KDEPlatformFileDialog::setFileMode(QFileDialogOptions::FileMode mode)
>  m_fileWidget->setMode(KFile::File);
>  break;
>  }
> +// ::setOperationMode happily adds icons to our buttonbox, so we 
> clear them everytime the mode is set
> +if (!style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons, 
> nullptr, this)) {
> +foreach (QAbstractButton *button, m_buttons->buttons())
> +button->setIcon(QIcon());
> +}
>  }
>  
>  void 
> KDEPlatformFileDialog::setCustomLabel(QFileDialogOptions::DialogLabel label, 
> const QString )
> diff --git a/src/platformtheme/kdirselectdialog.cpp 
> b/src/platformtheme/kdirselectdialog.cpp
> index 0a65cd3..13d7dc7 100644
> --- a/src/platformtheme/kdirselectdialog.cpp
> +++ b/src/platformtheme/kdirselectdialog.cpp
> @@ -299,6 +299,10 @@ KDirSelectDialog::KDirSelectDialog(const QUrl 
> , bool localOnly, QWidget
>  m_buttons->setStandardButtons(QDialogButtonBox::Ok | 
> QDialogButtonBox::Cancel);
>  connect(m_buttons, SIGNAL(accepted()), this, SLOT(accept()));
>  connect(m_buttons, SIGNAL(rejected()), this, SLOT(reject()));
> +if (!style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons, 
> nullptr, this)) {
> +foreach (QAbstractButton *button, m_buttons->buttons())
> +button->setIcon(QIcon());
> +}
>  topLayout->addWidget(m_buttons);
>  
>  QHBoxLayout *hlay = new QHBoxLayout(page);
> ```
> 
> But that somehow doesn't scale.
> 
> KGuiItem::apply would have to catch that, but doesn't.
> QDialogButtonBox::addButton *could* catch things, but doesn't (also it's 
> not clear whether or when m_buttons->button(SomeRole)->setIcon() is invoked, 
> so QPushButton::setIcon() would have to catch it and QPushButton would have 
> to catch it on reparenting.
> 
> 
> => For a complete solution, QPushButton actually needs painting code to 
> check the parent & style hint when setting up the style option - or we simply 
> rely on the style testing (widget && 
> qobject_cast(widget->parentWidget())) when calculating 
> sizes and painting the button.
> The only alternative is to walk a long way and tell everyone to please 
> check the hint and fix their buttonboxes eewww.
> 
> 
> 
> ==> QPushButton will require a "fix" to handle the StyleHint, but we 
> cannot expect *Q*PushButton to honor some global KDE setting, that's really a 
> job for the platform integration and in this case ultimately the style.
> 
> 
> 
> 
> => the platform integration plugin (KDE part in all Qt applications) 
> needs to read that setting and expose it to the styles.
> Alternatively the styles could read the setting from kdeglobals directly, 
> but that requires them to link kconfig (to do it correctly, just grabbing it 
> from the users kdeglobals ini isn't that much of a problem ;-), ie. rules out 
> Qt-only styles (and somehow contrasts w/ the KF5 approach to 

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

[Thomas Lübking]

> On Dec. 19, 2015, 10:23 a.m., David Faure wrote:
> > src/kdeui/kpushbutton.cpp, line 256
> > 
> >
> > This patch looks wrong because KPushButton can be used outside of 
> > "dialog button boxes", while the styleHint is supposed to be only about 
> > dialog button boxes.
> > 
> > QPushButton::sizeHint does this:
> > bool showButtonBoxIcons = 
> > qobject_cast(parentWidget())
> >   && 
> > style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons);
> > which is a solution for testing the parent widget.
> > 
> > I still don't fully understand the issue though, at painting time both 
> > QPushButton and KPushButton call QStyle's CE_PushButton, so I don't see why 
> > these two would be working differently.
> > Is this a workaround for KPushButton which doesn't fix QPushButton?
> 
> René J.V. Bertin wrote:
> David, I'm dropping this whole RR, leaving it open only in case Thomas 
> wants to pursue his view on fixing what there is to fix.
> 
> You are right though, it's a workaround for KPushButton which doesn't 
> depend on fixing QPushButton. And whether or not QPushButton requires fixing 
> is apparently the big question. What is your idea on the scope of 
> `ShowIconsOnButtons`?
> 
> Thomas Lübking wrote:
> The "problem" is that this is really scattered around everywhere :(
> 
> One major catch should be (frameworksintegration)
> 
> ```
> diff --git a/src/platformtheme/kdeplatformfiledialoghelper.cpp 
> b/src/platformtheme/kdeplatformfiledialoghelper.cpp
> index 11e7efb..9cd374c 100644
> --- a/src/platformtheme/kdeplatformfiledialoghelper.cpp
> +++ b/src/platformtheme/kdeplatformfiledialoghelper.cpp
> @@ -161,6 +161,11 @@ void 
> KDEPlatformFileDialog::setFileMode(QFileDialogOptions::FileMode mode)
>  m_fileWidget->setMode(KFile::File);
>  break;
>  }
> +// ::setOperationMode happily adds icons to our buttonbox, so we 
> clear them everytime the mode is set
> +if (!style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons, 
> nullptr, this)) {
> +foreach (QAbstractButton *button, m_buttons->buttons())
> +button->setIcon(QIcon());
> +}
>  }
>  
>  void 
> KDEPlatformFileDialog::setCustomLabel(QFileDialogOptions::DialogLabel label, 
> const QString )
> diff --git a/src/platformtheme/kdirselectdialog.cpp 
> b/src/platformtheme/kdirselectdialog.cpp
> index 0a65cd3..13d7dc7 100644
> --- a/src/platformtheme/kdirselectdialog.cpp
> +++ b/src/platformtheme/kdirselectdialog.cpp
> @@ -299,6 +299,10 @@ KDirSelectDialog::KDirSelectDialog(const QUrl 
> , bool localOnly, QWidget
>  m_buttons->setStandardButtons(QDialogButtonBox::Ok | 
> QDialogButtonBox::Cancel);
>  connect(m_buttons, SIGNAL(accepted()), this, SLOT(accept()));
>  connect(m_buttons, SIGNAL(rejected()), this, SLOT(reject()));
> +if (!style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons, 
> nullptr, this)) {
> +foreach (QAbstractButton *button, m_buttons->buttons())
> +button->setIcon(QIcon());
> +}
>  topLayout->addWidget(m_buttons);
>  
>  QHBoxLayout *hlay = new QHBoxLayout(page);
> ```
> 
> But that somehow doesn't scale.
> 
> KGuiItem::apply would have to catch that, but doesn't.
> QDialogButtonBox::addButton *could* catch things, but doesn't (also it's 
> not clear whether or when m_buttons->button(SomeRole)->setIcon() is invoked, 
> so QPushButton::setIcon() would have to catch it and QPushButton would have 
> to catch it on reparenting.
> 
> 
> => For a complete solution, QPushButton actually needs painting code to 
> check the parent & style hint when setting up the style option - or we simply 
> rely on the style testing (widget && 
> qobject_cast(widget->parentWidget())) when calculating 
> sizes and painting the button.
> The only alternative is to walk a long way and tell everyone to please 
> check the hint and fix their buttonboxes eewww.
> 
> 
> 
> ==> QPushButton will require a "fix" to handle the StyleHint, but we 
> cannot expect *Q*PushButton to honor some global KDE setting, that's really a 
> job for the platform integration and in this case ultimately the style.
> 
> 
> 
> 
> => the platform integration plugin (KDE part in all Qt applications) 
> needs to read that setting and expose it to the styles.
> Alternatively the styles could read the setting from kdeglobals directly, 
> but that requires them to link kconfig (to do it correctly, just grabbing it 
> from the users kdeglobals ini isn't that much of a problem ;-), ie. rules out 
> Qt-only styles (and somehow contrasts w/ the KF5 approach to 

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

[Thomas Lübking]

> On Dec. 19, 2015, 10:23 a.m., David Faure wrote:
> > src/kdeui/kpushbutton.cpp, line 256
> > 
> >
> > This patch looks wrong because KPushButton can be used outside of 
> > "dialog button boxes", while the styleHint is supposed to be only about 
> > dialog button boxes.
> > 
> > QPushButton::sizeHint does this:
> > bool showButtonBoxIcons = 
> > qobject_cast(parentWidget())
> >   && 
> > style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons);
> > which is a solution for testing the parent widget.
> > 
> > I still don't fully understand the issue though, at painting time both 
> > QPushButton and KPushButton call QStyle's CE_PushButton, so I don't see why 
> > these two would be working differently.
> > Is this a workaround for KPushButton which doesn't fix QPushButton?
> 
> René J.V. Bertin wrote:
> David, I'm dropping this whole RR, leaving it open only in case Thomas 
> wants to pursue his view on fixing what there is to fix.
> 
> You are right though, it's a workaround for KPushButton which doesn't 
> depend on fixing QPushButton. And whether or not QPushButton requires fixing 
> is apparently the big question. What is your idea on the scope of 
> `ShowIconsOnButtons`?
> 
> Thomas Lübking wrote:
> The "problem" is that this is really scattered around everywhere :(
> 
> One major catch should be (frameworksintegration)
> 
> ```
> diff --git a/src/platformtheme/kdeplatformfiledialoghelper.cpp 
> b/src/platformtheme/kdeplatformfiledialoghelper.cpp
> index 11e7efb..9cd374c 100644
> --- a/src/platformtheme/kdeplatformfiledialoghelper.cpp
> +++ b/src/platformtheme/kdeplatformfiledialoghelper.cpp
> @@ -161,6 +161,11 @@ void 
> KDEPlatformFileDialog::setFileMode(QFileDialogOptions::FileMode mode)
>  m_fileWidget->setMode(KFile::File);
>  break;
>  }
> +// ::setOperationMode happily adds icons to our buttonbox, so we 
> clear them everytime the mode is set
> +if (!style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons, 
> nullptr, this)) {
> +foreach (QAbstractButton *button, m_buttons->buttons())
> +button->setIcon(QIcon());
> +}
>  }
>  
>  void 
> KDEPlatformFileDialog::setCustomLabel(QFileDialogOptions::DialogLabel label, 
> const QString )
> diff --git a/src/platformtheme/kdirselectdialog.cpp 
> b/src/platformtheme/kdirselectdialog.cpp
> index 0a65cd3..13d7dc7 100644
> --- a/src/platformtheme/kdirselectdialog.cpp
> +++ b/src/platformtheme/kdirselectdialog.cpp
> @@ -299,6 +299,10 @@ KDirSelectDialog::KDirSelectDialog(const QUrl 
> , bool localOnly, QWidget
>  m_buttons->setStandardButtons(QDialogButtonBox::Ok | 
> QDialogButtonBox::Cancel);
>  connect(m_buttons, SIGNAL(accepted()), this, SLOT(accept()));
>  connect(m_buttons, SIGNAL(rejected()), this, SLOT(reject()));
> +if (!style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons, 
> nullptr, this)) {
> +foreach (QAbstractButton *button, m_buttons->buttons())
> +button->setIcon(QIcon());
> +}
>  topLayout->addWidget(m_buttons);
>  
>  QHBoxLayout *hlay = new QHBoxLayout(page);
> ```
> 
> But that somehow doesn't scale.
> 
> KGuiItem::apply would have to catch that, but doesn't.
> QDialogButtonBox::addButton *could* catch things, but doesn't (also it's 
> not clear whether or when m_buttons->button(SomeRole)->setIcon() is invoked, 
> so QPushButton::setIcon() would have to catch it and QPushButton would have 
> to catch it on reparenting.
> 
> 
> => For a complete solution, QPushButton actually needs painting code to 
> check the parent & style hint when setting up the style option - or we simply 
> rely on the style testing (widget && 
> qobject_cast(widget->parentWidget())) when calculating 
> sizes and painting the button.
> The only alternative is to walk a long way and tell everyone to please 
> check the hint and fix their buttonboxes eewww.
> 
> 
> 
> ==> QPushButton will require a "fix" to handle the StyleHint, but we 
> cannot expect *Q*PushButton to honor some global KDE setting, that's really a 
> job for the platform integration and in this case ultimately the style.
> 
> 
> 
> 
> => the platform integration plugin (KDE part in all Qt applications) 
> needs to read that setting and expose it to the styles.
> Alternatively the styles could read the setting from kdeglobals directly, 
> but that requires them to link kconfig (to do it correctly, just grabbing it 
> from the users kdeglobals ini isn't that much of a problem ;-), ie. rules out 
> Qt-only styles (and somehow contrasts w/ the KF5 approach to