Re: [Development] HEADS UP: Changes in QStyle subclasses

[Simon Hausmann]

On Saturday, November 24, 2012 11:09:26 AM Nurmi J-P wrote:
> Hi all,
> 
> Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and
> customize any available style. This is not limited to the built-in styles
> in QtWidgets, but also works fine for any style plugin since it nicely
> avoids the build time dependency to the corresponding style implementation.
> 
> When it comes to the actual style implementations, we have quite a few
> refactoring ideas on the table. These ideas include class renames, possible
> merges and inheritance hierarchy changes. Not to mention the possibility of
> later on pluginizing certain styles to avoid loads of dynamic function
> resolving. These ideas are not feasible to implement in time for Qt 5.0,
> and for compatibility reasons cannot be done later if the style
> implementations remain in the public API.
> 
> Hence we would like to take this opportunity to hide the following QStyle
> subclasses from the public API in Qt 5.0: - QFusionStyle
> - QGtkStyle
> - QMacStyle
> - QWindowsCEStyle
> - QWindowsMobileStyle
> - QWindowsStyle
> - QWindowsVistaStyle
> - QWindowsXPStyle
> 
> Notice that QCommonStyle will stay public, providing a convenient base for
> full custom style implementations. We do also realize that QWindowsStyle
> has been a commonly used base class for custom styles. To address that, we
> have recently promoted some generic styling code from QWindowsStyle to
> QCommonStyle, and changed QFusionStyle, QGtkStyle and QMacStyle to inherit
> QCommonStyle instead. We would like to invite anyone interested in custom
> styles to give it a try and let us know if any other parts should be
> promoted too.

Sounds like a pretty sensible move.

It would've been nice though to fix the existing usages (like in WebKit) before 
landing the change in qtbase. Now the integration of other modules as well as 
qt5.git is broken :(


Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] don't know how to make 'styles\qfusionstyle.h'

[Nurmi J-P]

On Nov 26, 2012, at 3:19 AM, Yang Fan  wrote:

> Hi All,
> 
> I'm trying to build Qt5 from Git with MSVC2010, but got the following errors:
> D:\qt5\qtbase\bin\moc.exe -DUNICODE -DWIN32 -DQT_NO_USING_NAMESPACE 
> -DQT
> _BUILD_WIDGETS_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII 
> -DQT_ASCII_CAST_WARNIN
> GS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS 
> -DQT_DISABLE
> _DEPRECATED_BEFORE=0x040800 -D_USE_MATH_DEFINES -DQT_NO_STYLE_MAC 
> -DQT_STYLE_WIN
> DOWS -DQT_NO_STYLE_GTK -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE 
> -DQT_
> NO_DIRECTWRITE -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2 
> -DQT_OPENGL_
> ES_2_ANGLE -DQT_NO_EXCEPTIONS -I"D:\OpenSSL-Win32\include" -I"..\..\include" 
> -I"
> ..\..\include\QtWidgets" -I"..\..\include\QtWidgets\5.0.0" 
> -I"..\..\include\QtWi
> dgets\5.0.0\QtWidgets" -I"tmp" -I"..\3rdparty\wintab" -I"dialogs" 
> -I"..\3rdparty
> \harfbuzz\src" -I"." -I"..\..\include\QtGui" -I"..\..\include\QtGui\5.0.0" 
> -I"..
> \..\include\QtGui\5.0.0\QtGui" -I"..\..\include\QtCore" 
> -I"..\..\include\QtCore\
> 5.0.0" -I"..\..\include\QtCore\5.0.0\QtCore" -I"tmp\moc\debug_shared" 
> -I"..\..\m
> kspecs\win32-msvc2010" -D_MSC_VER=1600 -DWIN32 kernel\qgesturemanager_p.h -o 
> tmp
> \moc\debug_shared\moc_qgesturemanager_p.cpp
> NMAKE : fatal error U1073: don't know how to make 'styles\qfusionstyle.h'
> Stop.
> NMAKE : fatal error U1077: '"D:\Program Files (x86)\Microsoft Visual Studio 
> 10.0
> \VC\BIN\nmake.exe"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> Any suggestion?
> 
> Regards,
> Fan Yang
> 

Hi,

Try re-running qmake. The header has been renamed qfusionstyle_p.h, so the 
makefile is outdated.

--
J-P Nurmi

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Frameworks on Mac?

[Ziller Eike]

On 22 Nov 2012, at 16:53, Thiago Macieira  wrote:

> On quinta-feira, 22 de novembro de 2012 07.44.24, Koehne Kai wrote:
>>> When I was doing the lib renaming, I thought we had concluded that
>>> frameworks on Mac were not going to be supported anymore.
>> 
>> Can't find it anything on qt-development@. Maybe you are referring to this
>> thread on qt-interest
>> 
> 
> I guess I misunderstood or I'm remembering things wrong then.
> 
> I think the decision was to remove the global install of Qt to 
> /Library/Frameworks. Instead, Qt always comes in a "sysroot-style" prefix, 
> whether it contains frameworks or pure dylibs.

Yes, that was what we were talking about.
It was not about removing framework support from Qt, but about that we should 
not install Qt in a system wide location (/Library/Frameworks). Which, as a 
prominently example, Xcode also has changed to (it installs the sysroots into 
the Xcode app bundle instead of the global /Developer directory).

We do it "correctly" with the SDKs since we create them, and now also with the 
Qt5 installers, so we only have the legacy Qt 4 -only installers do global 
installs anyhow.

++ Eike

>>> Imagine my surprise when I finish my first successful build on Mac and
>>> discover that frameworks are the default...
>> 
>> Did your library renaming break anything with Frameworks, or did you just
>> stumble over it?
> 
> There was a breakage, but that was avoided by not renaming the libraries when 
> frameworks are built.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] New mailing list: web_AT_qt-project.org created

[Verma Gurudutt]

Hi

I am really happy to inform you all that new mailing list web_AT_qt-project.org 
 is created now.
We will be discussing open governance model of web development related stuffs 
for qt-project.org here and proposal for this was made few days ago on this 
mailing  list.

Subscription to this mailing list have to be approved by list admin/moderator 
(Yurvin knuth is only moderator for now) and archive to this list is set to 
private.

You are welcome to join this mailing list if you wish to join our web 
development related activity for qt-project.org.

Looking forwards for exited result from this list :)

--
Best Regards,
Gurudutt Verma

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New mailing list: web_AT_qt-project.org created

[André Somers]

Hi,

Op 26-11-2012 12:12, Verma Gurudutt schreef:


Hi

I am really happy to inform you all that new mailing list 
web_AT_qt-project.org  is created now.


We will be discussing open governance model of web development related 
stuffs for qt-project.org here and proposal for this was made few days 
ago on this mailing  list.



Good, thanks.


Subscription to this mailing list have to be approved by list 
admin/moderator (Yurvin knuth is only moderator for now) and archive 
to this list is set to private.


Why has these private settings been chosen? It doesn't make much sense 
to me. I think we should choose to discus in the open by default, unless 
there are security issues at stake (and even there, there are those who 
disagree on that exception...)


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New mailing list: web_AT_qt-project.org created

[Vasily Sorokin]

Hi,

Gurudutt, Thanks for this,

but +1 from me to question: Why is it private?

-- 
Best Regards,
Vasiliy Sorokin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Request: QML Presentation System on qt-project.org

[Sletta Gunnar]

Hi,

I've gotten a few requests to include the QML Presentation System into the Qt 
Project. It would simplify code reviews and future contributions. What do you 
think?

Current location: https://qt.gitorious.org/qt-labs/qml-presentation-system.

As new location I would suggest qt-labs/qml-presentation-system and myself as 
maintainer.

cheers,
Gunnar

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Changes in QStyle subclasses

[Thomas Hartmann]

Hi,

we are using QWindows style as a baseline for style sheets in the Qt 
Quick Designer. I tried using QCommonStyle instead and it works, BUT
QToolButton::arrowType does not work with QCommonStyle.

It would be nice if this could be fixed, otherwise we have to subclass 
QCommonStyle and fix this in a custom style.

Kind Regards,
Thomas Hartmann

Am 24/11/2012 12:09, schrieb Nurmi J-P:
> Hi all,
>
> Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and 
> customize any available style. This is not limited to the built-in styles in 
> QtWidgets, but also works fine for any style plugin since it nicely avoids 
> the build time dependency to the corresponding style implementation.
>
> When it comes to the actual style implementations, we have quite a few 
> refactoring ideas on the table. These ideas include class renames, possible 
> merges and inheritance hierarchy changes. Not to mention the possibility of 
> later on pluginizing certain styles to avoid loads of dynamic function 
> resolving. These ideas are not feasible to implement in time for Qt 5.0, and 
> for compatibility reasons cannot be done later if the style implementations 
> remain in the public API.
>
> Hence we would like to take this opportunity to hide the following QStyle 
> subclasses from the public API in Qt 5.0:
> - QFusionStyle
> - QGtkStyle
> - QMacStyle
> - QWindowsCEStyle
> - QWindowsMobileStyle
> - QWindowsStyle
> - QWindowsVistaStyle
> - QWindowsXPStyle
>
> Notice that QCommonStyle will stay public, providing a convenient base for 
> full custom style implementations. We do also realize that QWindowsStyle has 
> been a commonly used base class for custom styles. To address that, we have 
> recently promoted some generic styling code from QWindowsStyle to 
> QCommonStyle, and changed QFusionStyle, QGtkStyle and QMacStyle to inherit 
> QCommonStyle instead. We would like to invite anyone interested in custom 
> styles to give it a try and let us know if any other parts should be promoted 
> too.
>
> --
> J-P Nurmi
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request: QML Presentation System on qt-project.org

[Thomas Senyk]

On Mon, November 26, 2012 12:29:24 Sletta Gunnar wrote:
> Hi,
> 
> I've gotten a few requests to include the QML Presentation System into the
> Qt Project. It would simplify code reviews and future contributions. What
> do you think?
> 
> Current location: https://qt.gitorious.org/qt-labs/qml-presentation-system.
> 
> As new location I would suggest qt-labs/qml-presentation-system and myself
> as maintainer.

+1

I maintain a few things in my own repos on gitorious, some of those changes 
could be up-streamed

> 
> cheers,
> Gunnar
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request: QML Presentation System on qt-project.org

[Knoll Lars]

On Nov 26, 2012, at 1:55 PM, Thomas Senyk  wrote:

> On Mon, November 26, 2012 12:29:24 Sletta Gunnar wrote:
>> Hi,
>> 
>> I've gotten a few requests to include the QML Presentation System into the
>> Qt Project. It would simplify code reviews and future contributions. What
>> do you think?
>> 
>> Current location: https://qt.gitorious.org/qt-labs/qml-presentation-system.
>> 
>> As new location I would suggest qt-labs/qml-presentation-system and myself
>> as maintainer.
> 
> +1
> 
> I maintain a few things in my own repos on gitorious, some of those changes 
> could be up-streamed

Another +1 from me.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt Playground - Updating Daemon/Service Support

[BRM]

I am following up to some e-mails I sent on the feedback/interests/dev lists[1] 
and blogs[2] over a year ago for updating the QtService Component.


I would like to open a new Qt Playground project to create a new equivalent for 
Qt5 that is more natively integrated.


Synopsis: QtService Component has not been updated since Qt 4.5. It is template 
based and has several drawbacks - (i) no signals/slots, and (ii) it hard 
terminates programs keeping them from being able to control shutdown or do 
cleanup during shutdown. I had proposed a new API to be in parallel to 
QCoreApplication/QApplication to support the daemon-service applications. 
Initial support will be equivalent of the current QtService component but using 
native classes instead of templates, and with a modular backend component that 
could later be used to add support for other service APIs - e.g. systemd - for 
seamless integration with different OS-level API for managing services.

Initial Goal is support for Qt5.

Ben

[1] Some of the e-mail threads:
http://lists.qt.nokia.com/public/qt5-feedback/2011-June/000449.html
http://comments.gmane.org/gmane.comp.lib.qt.qt5-feedback/76

[2] Some of my thoughts in blog from then:
http://clocksmind.blogspot.com/2011/05/calling-contributors.html
http://clocksmind.blogspot.com/2011/06/qt5-major-update-for-qtservice.html
http://clocksmind.blogspot.com/2011/09/qt5-introducing-qdaemonapplication.html___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New mailing list: web_AT_qt-project.org created

[Thiago Macieira]

On segunda-feira, 26 de novembro de 2012 11.12.42, Verma Gurudutt wrote:
> Subscription to this mailing list have to be approved by list
> admin/moderator (Yurvin knuth is only moderator for now) and archive to
> this list is set to private.

Is this list supposed to be the default destination from webmaster@qt-
project.org? If so, making it private makes sense because clueless users often 
send private information there.

If not, please explain why the subscription was made private.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[Thiago Macieira]

On segunda-feira, 26 de novembro de 2012 06.59.23, BRM wrote:
> I am following up to some e-mails I sent on the feedback/interests/dev
> lists[1] and blogs[2] over a year ago for updating the QtService Component.
> 
> 
> I would like to open a new Qt Playground project to create a new equivalent
> for Qt5 that is more natively integrated.
> 
> 
> Synopsis: QtService Component has not been updated since Qt 4.5. It is
> template based and has several drawbacks - (i) no signals/slots, and (ii)
> it hard terminates programs keeping them from being able to control
> shutdown or do cleanup during shutdown. I had proposed a new API to be in
> parallel to QCoreApplication/QApplication to support the daemon-service
> applications. Initial support will be equivalent of the current QtService
> component but using native classes instead of templates, and with a modular
> backend component that could later be used to add support for other service
> APIs - e.g. systemd - for seamless integration with different OS-level API
> for managing services.
> 
> Initial Goal is support for Qt5.

+1 from me.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 4.8.4 Release candidate 4 available

[Taipale Juhani]

Hi,

Qt 4.8.4 release candidate 4 is available at 
http://releases.qt-project.org/digia/4.8.4_RC4/
It is based on  SHA1: 96311def2466dd44de64d77a1c815b22fbf68f71

Juhani Taipale
Software Specialist, Qt Commercial R&D
Digia Plc
Piippukatu 11, FI-40100 JYVÄSKYLÄ FINLAND
Tel: +358 50 384 3755

Visit us at :www.digia.com or qt.digia.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[Matt Broadstone]

On Mon, Nov 26, 2012 at 10:13 AM, Thiago Macieira  wrote:

> On segunda-feira, 26 de novembro de 2012 06.59.23, BRM wrote:
> > I am following up to some e-mails I sent on the feedback/interests/dev
> > lists[1] and blogs[2] over a year ago for updating the QtService
> Component.
> >
> >
> > I would like to open a new Qt Playground project to create a new
> equivalent
> > for Qt5 that is more natively integrated.
> >
> >
> > Synopsis: QtService Component has not been updated since Qt 4.5. It is
> > template based and has several drawbacks - (i) no signals/slots, and (ii)
> > it hard terminates programs keeping them from being able to control
> > shutdown or do cleanup during shutdown. I had proposed a new API to be in
> > parallel to QCoreApplication/QApplication to support the daemon-service
> > applications. Initial support will be equivalent of the current QtService
> > component but using native classes instead of templates, and with a
> modular
> > backend component that could later be used to add support for other
> service
> > APIs - e.g. systemd - for seamless integration with different OS-level
> API
> > for managing services.
> >
> > Initial Goal is support for Qt5.
>
> +1 from me.

--
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>

+2 (not that my vote carries any weight!)

Do you already have code posted anywhere? I'd be interested in helping you
with this effort, as I've outgrown QtService as well.

Matt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[BRM]

> From: Matt Broadstone 

>On Mon, Nov 26, 2012 at 10:13 AM, Thiago Macieira  
>wrote:
>
>On segunda-feira, 26 de novembro de 2012 06.59.23, BRM wrote:
>>> I am following up to some e-mails I sent on the feedback/interests/dev
>>> lists[1] and blogs[2] over a year ago for updating the QtService Component.
>>>
>>>
>>> I would like to open a new Qt Playground project to create a new equivalent
>>> for Qt5 that is more natively integrated.
>>>
>>>
>>> Synopsis: QtService Component has not been updated since Qt 4.5. It is
>>> template based and has several drawbacks - (i) no signals/slots, and (ii)
>>> it hard terminates programs keeping them from being able to control
>>> shutdown or do cleanup during shutdown. I had proposed a new API to be in
>>> parallel to QCoreApplication/QApplication to support the daemon-service
>>> applications. Initial support will be equivalent of the current QtService
>>> component but using native classes instead of templates, and with a modular
>>> backend component that could later be used to add support for other service
>>> APIs - e.g. systemd - for seamless integration with different OS-level API
>>> for managing services.
>>>
>>> Initial Goal is support for Qt5.
>>
>>+1 from me.
>--
>>Thiago Macieira - thiago.macieira (AT) intel.com
>>  Software Architect - Intel Open Source Technology Center
>>
>>___
>>Development mailing list
>>Development@qt-project.org
>>http://lists.qt-project.org/mailman/listinfo/development
>
>+2 (not that my vote carries any weight!)
> 
>Do you already have code posted anywhere? I'd be interested in helping you 
>with this effort, as I've outgrown QtService as well. 
>


No I have not. I started some code over the Thanksgiving Holiday that i will be 
putting in; but it will still require a bit of work.
It does provide a nice starting outline and is based on 
QApplication/QGuiApplication from Qt5 git.
I am looking to use the playground to push the development effort more for both 
myself and anyone else that wants to help out.

Ben

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[Charley Bay]

>>> " Component >,
>>> I would like to open a new Qt Playground project to create a new
equivalent

+1

IMHO this would be a cross-platform useful module that I'd vote to
ultimately end-up within "Qt-proper".

Disclosure:  I traded emails with BRM off-list, and would like to help.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Changes in QStyle subclasses

[BogDan]

Hi,

Are you planning to use QStyle also to draw QML Components? 
Or we still need to create two separate implementations for the same platform?
If we still need to create two, then IMHO you should make private everything
related to QStyle.

BogDan.



- Original Message -
> From: Thomas Hartmann 
> To: development@qt-project.org
> Cc: 
> Sent: Monday, November 26, 2012 2:55 PM
> Subject: Re: [Development] HEADS UP: Changes in QStyle subclasses
> 
> Hi,
> 
> we are using QWindows style as a baseline for style sheets in the Qt 
> Quick Designer. I tried using QCommonStyle instead and it works, BUT
> QToolButton::arrowType does not work with QCommonStyle.
> 
> It would be nice if this could be fixed, otherwise we have to subclass 
> QCommonStyle and fix this in a custom style.
> 
> Kind Regards,
> Thomas Hartmann
> 
> Am 24/11/2012 12:09, schrieb Nurmi J-P:
>>  Hi all,
>> 
>>  Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and 
> customize any available style. This is not limited to the built-in styles in 
> QtWidgets, but also works fine for any style plugin since it nicely avoids 
> the 
> build time dependency to the corresponding style implementation.
>> 
>>  When it comes to the actual style implementations, we have quite a few 
> refactoring ideas on the table. These ideas include class renames, possible 
> merges and inheritance hierarchy changes. Not to mention the possibility of 
> later on pluginizing certain styles to avoid loads of dynamic function 
> resolving. These ideas are not feasible to implement in time for Qt 5.0, and 
> for 
> compatibility reasons cannot be done later if the style implementations 
> remain 
> in the public API.
>> 
>>  Hence we would like to take this opportunity to hide the following QStyle 
> subclasses from the public API in Qt 5.0:
>>  - QFusionStyle
>>  - QGtkStyle
>>  - QMacStyle
>>  - QWindowsCEStyle
>>  - QWindowsMobileStyle
>>  - QWindowsStyle
>>  - QWindowsVistaStyle
>>  - QWindowsXPStyle
>> 
>>  Notice that QCommonStyle will stay public, providing a convenient base for 
> full custom style implementations. We do also realize that QWindowsStyle has 
> been a commonly used base class for custom styles. To address that, we have 
> recently promoted some generic styling code from QWindowsStyle to 
> QCommonStyle, 
> and changed QFusionStyle, QGtkStyle and QMacStyle to inherit QCommonStyle 
> instead. We would like to invite anyone interested in custom styles to give 
> it a 
> try and let us know if any other parts should be promoted too.
>> 
>>  --
>>  J-P Nurmi
>>  ___
>>  Development mailing list
>>  Development@qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[Matt Broadstone]

On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay  wrote:

> >>> " Component >,
> >>> I would like to open a new Qt Playground project to create a new
> equivalent
>
> +1
>
> IMHO this would be a cross-platform useful module that I'd vote to
> ultimately end-up within "Qt-proper".
>
> Disclosure:  I traded emails with BRM off-list, and would like to help.
>
> --charley
>

Would you guys like to get into your design a little here? Did you mean
that you would be creating two classes: QCoreService/QGuiService (though
I'm not sure why one would want a gui service, maybe to use some of the
graphics classes?). Also, could you speak to your ideas for the pluggable
backend? Will you target systemd as a reference implementation?

Matt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Changes in QStyle subclasses

[Bache-Wiig Jens]

For the desktop components we will use QStyle by default so they look and 
behave as regular widgets. This means that applications with custom styles will 
also get QML component styling for free, avoiding the need to duplicate any 
styling code. I recently also made it possible to style the components using 
pure QML, so that a QStyle backend is not strictly required on any platform. 
Any new touch specific components will probably not be using QStyle though.

What we are trying to do with this change is simply to remove classes like 
QWindowsXPStyle and QWindowsVistaStyle from polluting the public API as there 
is no reason applications should depend on them directly, and it makes it 
easier for us to adapt Qt5 to various platforms in the future without breaking 
binary compatibility. They are merely implementation details of their 
respective platform plugins.

Regards,
Jens

> Hi,
> 
> Are you planning to use QStyle also to draw QML Components? 
> Or we still need to create two separate implementations for the same platform?
> If we still need to create two, then IMHO you should make private everything
> related to QStyle.
> 
> BogDan.
> 
> 
> 
> - Original Message -
>> From: Thomas Hartmann 
>> To: development@qt-project.org
>> Cc: 
>> Sent: Monday, November 26, 2012 2:55 PM
>> Subject: Re: [Development] HEADS UP: Changes in QStyle subclasses
>> 
>> Hi,
>> 
>> we are using QWindows style as a baseline for style sheets in the Qt 
>> Quick Designer. I tried using QCommonStyle instead and it works, BUT
>> QToolButton::arrowType does not work with QCommonStyle.
>> 
>> It would be nice if this could be fixed, otherwise we have to subclass 
>> QCommonStyle and fix this in a custom style.
>> 
>> Kind Regards,
>> Thomas Hartmann
>> 
>> Am 24/11/2012 12:09, schrieb Nurmi J-P:
>>> Hi all,
>>> 
>>> Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and 
>> customize any available style. This is not limited to the built-in styles in 
>> QtWidgets, but also works fine for any style plugin since it nicely avoids 
>> the 
>> build time dependency to the corresponding style implementation.
>>> 
>>> When it comes to the actual style implementations, we have quite a few 
>> refactoring ideas on the table. These ideas include class renames, possible 
>> merges and inheritance hierarchy changes. Not to mention the possibility of 
>> later on pluginizing certain styles to avoid loads of dynamic function 
>> resolving. These ideas are not feasible to implement in time for Qt 5.0, and 
>> for 
>> compatibility reasons cannot be done later if the style implementations 
>> remain 
>> in the public API.
>>> 
>>> Hence we would like to take this opportunity to hide the following QStyle 
>> subclasses from the public API in Qt 5.0:
>>> - QFusionStyle
>>> - QGtkStyle
>>> - QMacStyle
>>> - QWindowsCEStyle
>>> - QWindowsMobileStyle
>>> - QWindowsStyle
>>> - QWindowsVistaStyle
>>> - QWindowsXPStyle
>>> 
>>> Notice that QCommonStyle will stay public, providing a convenient base for 
>> full custom style implementations. We do also realize that QWindowsStyle has 
>> been a commonly used base class for custom styles. To address that, we have 
>> recently promoted some generic styling code from QWindowsStyle to 
>> QCommonStyle, 
>> and changed QFusionStyle, QGtkStyle and QMacStyle to inherit QCommonStyle 
>> instead. We would like to invite anyone interested in custom styles to give 
>> it a 
>> try and let us know if any other parts should be promoted too.
>>> 
>>> --
>>> J-P Nurmi
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>> 
>> 
>> 
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Changes in QStyle subclasses

[BogDan]

Hi again,

I understand what you are trying to do.

What I'm trying to say it that if you are planning to use QStyle also to draw 
QML Components (on all platforms) then there is no problem, otherwise if you 
are planning in the future (e.g. 5.1, 5.2) to deprecate QStyle and come with 
another solution that can be used to paint classic and qml widgets (on all 
platforms), then IMHO you should make QStyle* private now, before you ship 5.0, 
otherwise you'll *MUST* keep it for the entire Qt5 lifetime.

Cheers,
BogDan. 



- Original Message -
> From: Bache-Wiig Jens 
> To: BogDan 
> Cc: Hartmann Thomas ; "development@qt-project.org" 
> 
> Sent: Monday, November 26, 2012 7:47 PM
> Subject: Re: [Development] HEADS UP: Changes in QStyle subclasses
> 
> For the desktop components we will use QStyle by default so they look and 
> behave 
> as regular widgets. This means that applications with custom styles will also 
> get QML component styling for free, avoiding the need to duplicate any 
> styling 
> code. I recently also made it possible to style the components using pure 
> QML, 
> so that a QStyle backend is not strictly required on any platform. Any new 
> touch 
> specific components will probably not be using QStyle though.
> 
> What we are trying to do with this change is simply to remove classes like 
> QWindowsXPStyle and QWindowsVistaStyle from polluting the public API as there 
> is 
> no reason applications should depend on them directly, and it makes it easier 
> for us to adapt Qt5 to various platforms in the future without breaking 
> binary 
> compatibility. They are merely implementation details of their respective 
> platform plugins.
> 
> Regards,
> Jens
> 
>>  Hi,
>> 
>>  Are you planning to use QStyle also to draw QML Components? 
>>  Or we still need to create two separate implementations for the same 
> platform?
>>  If we still need to create two, then IMHO you should make private 
> everything
>>  related to QStyle.
>> 
>>  BogDan.
>> 
>> 
>> 
>>  - Original Message -
>>>  From: Thomas Hartmann 
>>>  To: development@qt-project.org
>>>  Cc: 
>>>  Sent: Monday, November 26, 2012 2:55 PM
>>>  Subject: Re: [Development] HEADS UP: Changes in QStyle subclasses
>>> 
>>>  Hi,
>>> 
>>>  we are using QWindows style as a baseline for style sheets in the Qt 
>>>  Quick Designer. I tried using QCommonStyle instead and it works, BUT
>>>  QToolButton::arrowType does not work with QCommonStyle.
>>> 
>>>  It would be nice if this could be fixed, otherwise we have to subclass 
>>>  QCommonStyle and fix this in a custom style.
>>> 
>>>  Kind Regards,
>>>  Thomas Hartmann
>>> 
>>>  Am 24/11/2012 12:09, schrieb Nurmi J-P:
  Hi all,
 
  Thanks to QStyleFactory and QProxyStyle, it is possible to 
> instantiate and 
>>>  customize any available style. This is not limited to the built-in 
> styles in 
>>>  QtWidgets, but also works fine for any style plugin since it nicely 
> avoids the 
>>>  build time dependency to the corresponding style implementation.
 
  When it comes to the actual style implementations, we have quite a 
> few 
>>>  refactoring ideas on the table. These ideas include class renames, 
> possible 
>>>  merges and inheritance hierarchy changes. Not to mention the 
> possibility of 
>>>  later on pluginizing certain styles to avoid loads of dynamic function 
>>>  resolving. These ideas are not feasible to implement in time for Qt 
> 5.0, and for 
>>>  compatibility reasons cannot be done later if the style implementations 
> remain 
>>>  in the public API.
 
  Hence we would like to take this opportunity to hide the following 
> QStyle 
>>>  subclasses from the public API in Qt 5.0:
  - QFusionStyle
  - QGtkStyle
  - QMacStyle
  - QWindowsCEStyle
  - QWindowsMobileStyle
  - QWindowsStyle
  - QWindowsVistaStyle
  - QWindowsXPStyle
 
  Notice that QCommonStyle will stay public, providing a convenient 
> base for 
>>>  full custom style implementations. We do also realize that 
> QWindowsStyle has 
>>>  been a commonly used base class for custom styles. To address that, we 
> have 
>>>  recently promoted some generic styling code from QWindowsStyle to 
> QCommonStyle, 
>>>  and changed QFusionStyle, QGtkStyle and QMacStyle to inherit 
> QCommonStyle 
>>>  instead. We would like to invite anyone interested in custom styles to 
> give it a 
>>>  try and let us know if any other parts should be promoted too.
 
  --
  J-P Nurmi
  ___
  Development mailing list
  Development@qt-project.org
  http://lists.qt-project.org/mailman/listinfo/development
>>> 
>>> 
>>> 
>>>  ___
>>>  Development mailing list
>>>  Development@qt-project.org
>>>  http://lists.qt-project.org/mailman/listinfo/development
>>> 
>>  ___
>>  Development mailing list
>>  Development@qt-project.o

Re: [Development] HEADS UP: Changes in QStyle subclasses

[Andre Somers]

Op 24-11-2012 12:09, Nurmi J-P schreef:

Hi all,

Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and 
customize any available style. This is not limited to the built-in styles in 
QtWidgets, but also works fine for any style plugin since it nicely avoids the 
build time dependency to the corresponding style implementation.

When it comes to the actual style implementations, we have quite a few 
refactoring ideas on the table. These ideas include class renames, possible 
merges and inheritance hierarchy changes. Not to mention the possibility of 
later on pluginizing certain styles to avoid loads of dynamic function 
resolving. These ideas are not feasible to implement in time for Qt 5.0, and 
for compatibility reasons cannot be done later if the style implementations 
remain in the public API.

Hence we would like to take this opportunity to hide the following QStyle 
subclasses from the public API in Qt 5.0:
- QFusionStyle
- QGtkStyle
- QMacStyle
- QWindowsCEStyle
- QWindowsMobileStyle
- QWindowsStyle
- QWindowsVistaStyle
- QWindowsXPStyle

Does this also mean that you will remove void 
QApplication::setStyle(QStyle* style)? This API seems useless if you 
can't create actual style instances any more because they are public. On 
the other hand, I think that that may cause issues for some applications...


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[BRM]

> From: Matt Broadstone 

>On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay  wrote:
>
 " Component >, 
> I would like to open a new Qt Playground project to create a new 
> equivalent
>>
>>
>>+1
>> 
>>IMHO this would be a cross-platform useful module that I'd vote to ultimately 
>>end-up within "Qt-proper".
>>
>>
>>Disclosure:  I traded emails with BRM off-list, and would like to help.
>>
>>--charley
>
>Would you guys like to get into your design a little here? Did you mean that 
>you would be creating two classes: QCoreService/QGuiService (though I'm not 
>sure why one would want a gui service, maybe to use some of the graphics 
>classes?). Also, could you speak to your ideas for the pluggable backend? Will 
>you target systemd as a reference implementation? 
>


Design is relatively simple. There will be 1 public class - initially 
DaemonApplication (add Q when it becomes part of Qt, following Playground 
rules). Daemon/Service writers can then do:

...
#include 
...


int main(int argc, char* argv[])
{
    DaemonApplication theDaemon(argc, argv);
    ...
    // Create your application instance here - just like with 
QCoreApplication/QApplication.
    ...

    return theDaemon.exec();

}

Inside DaemonApplication there will be a private object that provides the 
daemonization support, command-line support, etc. It will also use a 
QLocalSocket to manage the communications between the Controller and Daemonized 
instances. The user level application should only need to be aware of the 
various transitions - start/stop, pause/resume - and be able to tell the 
internal that it succeeded, failed, needs to delay, etc in response to those. 
(E.g. the application needs to shutdown properly, so a QEvent will need to be 
there to approve, delay, or deny the shutdown.)


There will be signals and events from DaemonApplication that applications can 
use to manage the various transitions, etc.
For instance, there will be a pre-daemonization stage where DaemonApplication 
will need to notify the user application so it can process the command-line in 
case that needs to stop the daemonization process.

Ultimately I want to stick very much to the KISS principles in the design.


Many details are still left to work out, but that's the basic idea floating.


Ben

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[Charley Bay]

On Mon, Nov 26, 2012 at 10:40 AM, Matt Broadstone wrote:

> On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay wrote:
>
>> >>> " Component >,
>> >>> I would like to open a new Qt Playground project to create a new
>> equivalent
>>
>> +1
>>
>> IMHO this would be a cross-platform useful module that I'd vote to
>> ultimately end-up within "Qt-proper".
>>
>> Disclosure:  I traded emails with BRM off-list, and would like to help.
>>
>> --charley
>>
>
> Would you guys like to get into your design a little here? Did you mean
> that you would be creating two classes: QCoreService/QGuiService (though
> I'm not sure why one would want a gui service, maybe to use some of the
> graphics classes?). Also, could you speak to your ideas for the pluggable
> backend? Will you target systemd as a reference implementation?
>
> Matt
>

[UPDATE], I was typing this while BRM responded.  Read his email, it's a
more specific "design-ideas" answer.  However, I'll still reply with this
email, since it talks about other "higher-level" issues-to-be-resolved, and
brings the discussion "current" with what this proposed-playground is to do.

[...what follows is what I was typing when BRM responded...]

I'm "second-seat" (Ben/BRM is taking the lead).  I defer to Ben/BRM for any
corrections needed from malicious dis-information created as a result of
this email, but here's a bullet-list of early thoughts:

TODAY:

 (a)- The existing "QtService<>" is an add-on (not in "Qt-proper"), but
people use it, and it serves a purpose to help provide a cross-platform
"service/daemon" application API.

 (b)- The existing "QtService<>" works for Qt4x (likely "needs-work" to
support Qt5)

GOAL:

After this effort, the result could be considered as a Qt5+ "add-on" for
cross-platform service/daemon support, and possibly considered for
inclusion in a future Qt release (e.g., perhaps Qt5.1+)

POSSIBLE ISSUE:

An "unfortunate" name collision (or user-confusion) is possible with class
names created from this effort to provide a cross-platform service/daemon
API, and those classes within the "Qt Service Framework" (which has a
different purpose).

USE GOAL:

Very simple API to create a service/daemon (server-side), or client-process
instance (client-side), such as merely "instantiating" an object.  Current
thoughts are to make this similar to merely instantiating a
"QCoreApplication" or "QGuiApplication".  (For example, the user may merely
instantiate  from within "main()" a "service-application-instance" or
"client-to-service-application-instance").  (SEE BRM's EMAIL FOR MORE
DETAIL.)

CURRENT DESIGN THOUGHTS:

Speculative design is to:

 (a)- Make "QtService<>" (currently a "template<>") a non-template (e.g.,
"directly-instantiable")

 (b)- Improve "shut-down" semantics (e.g., current "QtService<>" just does
a "hard-kill" on the server process, so no waiting/clean-up is performed,
including within threads; this should handle a graceful resource clean-up)

 (c)- Improve "robustness" (e.g, better use of waits/resource clean-up; the
current "QtService<>" works, but can leave applications "broken" at times)

 (d)- Implementation likely enforces a "local-to-the-same-computer"
client/server inter-process communication (e.g., using something like
"QLocalSocket")  (Might consider future expansion of
non-local-to-the-same-computer).

 (e)- Platform-specific registration (e.g., properly handle
systeminstall/update, system-start, on-demand-start,
system-remove/uninstall, etc.)  Would "by-default" support a command-line
interface, and maintain compatibility between client/server process.
 Further development could add other interfaces (e.g., "systemd") to
integrate with other systems more easily.

FWIW.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Changes in QStyle subclasses

[Olivier Goffart]

(Top-posting because this thread was already top-posted)

QStyle will stay for then entire Qt5 lifetime because that's how QWidgets are 
drawn, and this will not change. And as you know, QWidget is not being 
deprecated, it is just that new developments focus mainly on QML.

The Desktop Components will depends on QtWidgets.  Not only for QStyle, but 
also for other stuff like QMenu and so on (as far as I understand).

This dependency is probably just an implementation details of the desktop 
components, and if, in a few year, we feel like getting rid of that dependency 
(because in a far future widgets may get deprecated), we still could.

-- 
Olivier

Woboq - Qt services and support - http://woboq.com

On Monday 26 November 2012 09:57:04 BogDan wrote:
> Hi again,
> 
> I understand what you are trying to do.
> 
> What I'm trying to say it that if you are planning to use QStyle also to
> draw QML Components (on all platforms) then there is no problem, otherwise
> if you are planning in the future (e.g. 5.1, 5.2) to deprecate QStyle and
> come with another solution that can be used to paint classic and qml
> widgets (on all platforms), then IMHO you should make QStyle* private now,
> before you ship 5.0, otherwise you'll *MUST* keep it for the entire Qt5
> lifetime.
> 
> Cheers,
> BogDan. 
> 
> 
> 
> - Original Message -
> 
> > From: Bache-Wiig Jens 
> > To: BogDan 
> > Cc: Hartmann Thomas ;
> > "development@qt-project.org"  Sent: Monday,
> > November 26, 2012 7:47 PM
> > Subject: Re: [Development] HEADS UP: Changes in QStyle subclasses
> > 
> > For the desktop components we will use QStyle by default so they look and
> > behave as regular widgets. This means that applications with custom
> > styles will also get QML component styling for free, avoiding the need to
> > duplicate any styling code. I recently also made it possible to style the
> > components using pure QML, so that a QStyle backend is not strictly
> > required on any platform. Any new touch specific components will probably
> > not be using QStyle though.
> > 
> > What we are trying to do with this change is simply to remove classes like
> > QWindowsXPStyle and QWindowsVistaStyle from polluting the public API as
> > there is no reason applications should depend on them directly, and it
> > makes it easier for us to adapt Qt5 to various platforms in the future
> > without breaking binary compatibility. They are merely implementation
> > details of their respective platform plugins.
> > 
> > Regards,
> > Jens
> > 
> >>  Hi,
> >>  
> >>  Are you planning to use QStyle also to draw QML Components?
> >>  Or we still need to create two separate implementations for the same
> > 
> > platform?
> > 
> >>  If we still need to create two, then IMHO you should make private
> > 
> > everything
> > 
> >>  related to QStyle.
> >>  
> >>  BogDan.
> >>  
> >>  
> >>  
> >>  - Original Message -
> >>  
> >>>  From: Thomas Hartmann 
> >>>  To: development@qt-project.org
> >>>  Cc:
> >>>  Sent: Monday, November 26, 2012 2:55 PM
> >>>  Subject: Re: [Development] HEADS UP: Changes in QStyle subclasses
> >>>  
> >>>  Hi,
> >>>  
> >>>  we are using QWindows style as a baseline for style sheets in the Qt
> >>>  Quick Designer. I tried using QCommonStyle instead and it works, BUT
> >>>  QToolButton::arrowType does not work with QCommonStyle.
> >>>  
> >>>  It would be nice if this could be fixed, otherwise we have to subclass
> >>>  QCommonStyle and fix this in a custom style.
> >>>  
> >>>  Kind Regards,
> >>>  Thomas Hartmann
> >>>  
> >>>  Am 24/11/2012 12:09, schrieb Nurmi J-P:
>   Hi all,
>   
>   Thanks to QStyleFactory and QProxyStyle, it is possible to
> > 
> > instantiate and
> > 
> >>>  customize any available style. This is not limited to the built-in
> > 
> > styles in
> > 
> >>>  QtWidgets, but also works fine for any style plugin since it nicely
> > 
> > avoids the
> > 
> >>>  build time dependency to the corresponding style implementation.
> >>>  
>   When it comes to the actual style implementations, we have quite a
> > 
> > few
> > 
> >>>  refactoring ideas on the table. These ideas include class renames,
> > 
> > possible
> > 
> >>>  merges and inheritance hierarchy changes. Not to mention the
> > 
> > possibility of
> > 
> >>>  later on pluginizing certain styles to avoid loads of dynamic function
> >>>  resolving. These ideas are not feasible to implement in time for Qt
> > 
> > 5.0, and for
> > 
> >>>  compatibility reasons cannot be done later if the style implementations
> > 
> > remain
> > 
> >>>  in the public API.
> >>>  
>   Hence we would like to take this opportunity to hide the following
> > 
> > QStyle
> > 
> >>>  subclasses from the public API in Qt 5.0:
>   - QFusionStyle
>   - QGtkStyle
>   - QMacStyle
>   - QWindowsCEStyle
>   - QWindowsMobileStyle
>   - QWindowsStyle
>   - QWindowsVistaStyle
>   - QWindowsXPStyle
>   
>   Notice that QCommonStyle will stay p

Re: [Development] Qt Playground - Updating Daemon/Service Support

[BRM]

> From: Charley Bay 

>On Mon, Nov 26, 2012 at 10:40 AM, Matt Broadstone  wrote:
>
>On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay  wrote:
>>
> " Component >, 
>> I would like to open a new Qt Playground project to create a new 
>> equivalent
>>>
>>>
>>>+1
>>> 
>>>IMHO this would be a cross-platform useful module that I'd vote to 
>>>ultimately end-up within "Qt-proper".
>>>
>>>
>>>Disclosure:  I traded emails with BRM off-list, and would like to help.
>>>
>>>--charley
>>
>>Would you guys like to get into your design a little here? Did you mean that 
>>you would be creating two classes: QCoreService/QGuiService (though I'm not 
>>sure why one would want a gui service, maybe to use some of the graphics 
>>classes?). Also, could you speak to your ideas for the pluggable backend? 
>>Will you target systemd as a reference implementation? 
>>
>>Matt
>
>[UPDATE], I was typing this while BRM responded.  Read his email, it's a more 
>specific "design-ideas" answer.  However, I'll still reply with this email, 
>since it talks about other "higher-level" issues-to-be-resolved, and brings 
>the discussion "current" with what this proposed-playground is to do.
>
>
>[...what follows is what I was typing when BRM responded...]
>
>
>I'm "second-seat" (Ben/BRM is taking the lead).  I defer to Ben/BRM for any 
>corrections needed from malicious dis-information created as a result of this 
>email, but here's a bullet-list of early thoughts:
>
>
>TODAY:
>
>
> (a)- The existing "QtService<>" is an add-on (not in "Qt-proper"), but people 
>use it, and it serves a purpose to help provide a cross-platform 
>"service/daemon" application API.
>
>
> (b)- The existing "QtService<>" works for Qt4x (likely "needs-work" to 
>support Qt5)
>
>
>GOAL:
>
>
>After this effort, the result could be considered as a Qt5+ "add-on" for 
>cross-platform service/daemon support, and possibly considered for inclusion 
>in a future Qt release (e.g., perhaps Qt5.1+)
>
>
>POSSIBLE ISSUE:
>
>
>An "unfortunate" name collision (or user-confusion) is possible with class 
>names created from this effort to provide a cross-platform service/daemon API, 
>and those classes within the "Qt Service Framework" (which has a different 
>purpose).
>


Note: Only the use of the QtService /QService name would have such collision. 
That is why the new API would be DaemonApplication (QDaemonApplication), as 
discussed previously on the mailing lists.

Ben
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[Matt Broadstone]

On Mon, Nov 26, 2012 at 1:48 PM, BRM  wrote:

> > From: Charley Bay 
>
> >On Mon, Nov 26, 2012 at 10:40 AM, Matt Broadstone 
> wrote:
> >
> >On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay 
> wrote:
> >>
> > " Component >,
> >> I would like to open a new Qt Playground project to create a new
> equivalent
> >>>
> >>>
> >>>+1
> >>>
> >>>IMHO this would be a cross-platform useful module that I'd vote to
> ultimately end-up within "Qt-proper".
> >>>
> >>>
> >>>Disclosure:  I traded emails with BRM off-list, and would like to help.
> >>>
> >>>--charley
> >>
> >>Would you guys like to get into your design a little here? Did you mean
> that you would be creating two classes: QCoreService/QGuiService (though
> I'm not sure why one would want a gui service, maybe to use some of the
> graphics classes?). Also, could you speak to your ideas for the pluggable
> backend? Will you target systemd as a reference implementation?
> >>
> >>Matt
> >
> >[UPDATE], I was typing this while BRM responded.  Read his email, it's a
> more specific "design-ideas" answer.  However, I'll still reply with this
> email, since it talks about other "higher-level" issues-to-be-resolved, and
> brings the discussion "current" with what this proposed-playground is to do.
> >
> >
> >[...what follows is what I was typing when BRM responded...]
> >
> >
> >I'm "second-seat" (Ben/BRM is taking the lead).  I defer to Ben/BRM for
> any corrections needed from malicious dis-information created as a result
> of this email, but here's a bullet-list of early thoughts:
> >
> >
> >TODAY:
> >
> >
> > (a)- The existing "QtService<>" is an add-on (not in "Qt-proper"), but
> people use it, and it serves a purpose to help provide a cross-platform
> "service/daemon" application API.
> >
> >
> > (b)- The existing "QtService<>" works for Qt4x (likely "needs-work" to
> support Qt5)
> >
> >
> >GOAL:
> >
> >
> >After this effort, the result could be considered as a Qt5+ "add-on" for
> cross-platform service/daemon support, and possibly considered for
> inclusion in a future Qt release (e.g., perhaps Qt5.1+)
> >
> >
> >POSSIBLE ISSUE:
> >
> >
> >An "unfortunate" name collision (or user-confusion) is possible with
> class names created from this effort to provide a cross-platform
> service/daemon API, and those classes within the "Qt Service Framework"
> (which has a different purpose).
> >
>
>
> Note: Only the use of the QtService /QService name would have such
> collision. That is why the new API would be DaemonApplication
> (QDaemonApplication), as discussed previously on the mailing lists.
>
> Ben
>

thoughts:

a) I think the only reason the old QtService uses a template based approach
is to support the different types of Q*Application. It would be quite
useful to have someone who worked on the original solution discuss why they
went with this approach rather than subclassing Q*Application. I imagine
with a subclass approach you would solve a lot of your "cleanup" problems
as well.

b) Not sure what you guys are talking about with IPC/QLocalSocket, this
seems beyond the scope of these classes

c) I believe Service was used originally because it corresponds to the
windows world-view of daemons/services (it also explains why the class
itself seems to be more of a fair player on windows rather than *nix). The
renaming is fine, but I guess you are committing the reverse sin here.

d) at this point talk is cheap, show me the code! :)

Is there any word on whether you guys get a spot in playground?

Matt



> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[Charley Bay]

Hi, Matt--

thoughts:
>
> a) I think the only reason the old QtService uses a template based
> approach is to support the different types of Q*Application. It would be
> quite useful to have someone who worked on the original solution discuss
> why they went with this approach rather than subclassing Q*Application. I
> imagine with a subclass approach you would solve a lot of your "cleanup"
> problems as well.
>

Agreed.  However, I think BRM's thought is that you just instantiate your
instance, and then (separately) instantiate the "QGuiApplication" or
"QCoreApplication" (e.g,. the "SomeNewService" instance does not need to be
a template at all).


> b) Not sure what you guys are talking about with IPC/QLocalSocket, this
> seems beyond the scope of these classes
>

All services/daemons must be able to interface with other processes:

  (a)- a "client-process" can "request-a-client-operation" to occur on that
service/daemon

  (b)- a process can "query" or "control" the service/daemon (such as to
"pause" it, or "stop" it, etc.)

Thus, some inter-process communication is always required.

c) I believe Service was used originally because it corresponds to the
> windows world-view of daemons/services (it also explains why the class
> itself seems to be more of a fair player on windows rather than *nix). The
> renaming is fine, but I guess you are committing the reverse sin here.
>

Agreed -- "Service" is understood on "Windows", and "Daemon" is understood
on "*nix".  I don't really care about the name -- there is merely a need to
disambiguate whatever it is with the things in the "Qt Service Framework".

d) at this point talk is cheap, show me the code! :)
>
Is there any word on whether you guys get a spot in playground?
>

That's why the "playground" was requested.  ;-))

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[BRM]

> From: Charley Bay 

>Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
> 
>
>Hi, Matt--
>
>
>thoughts:
>>
>>
>>a) I think the only reason the old QtService uses a template based approach 
>>is to support the different types of Q*Application. It would be quite useful 
>>to have someone who worked on the original solution discuss why they went 
>>with this approach rather than subclassing Q*Application. I imagine with a 
>>subclass approach you would solve a lot of your "cleanup" problems as well.
>
>
>Agreed.  However, I think BRM's thought is that you just instantiate your 
>instance, and then (separately) instantiate the "QGuiApplication" or 
>"QCoreApplication" (e.g,. the "SomeNewService" instance does not need to be a 
>template at all).
> 


At one point in time it was okay to have a QApplication/QGuiApplication as a 
daemon. However, as of Windows Vista, and more greatly enforced in later 
versions of Windows, Microsoft is severely curtailing the abilities of Services 
to have a GUI interface. As such it is really only valid on Windows to have a 
QCoreApplication-based Service/Daemon.

I don't think most *nix applications typically put a GUI on a daemon, so they 
probably don't run into that issue.

So, I would say that the need for a QGuiApplication/QApplication based service 
is no longer. Developers should instead use a Client-server model approach to 
provide a GUI application with a service back-end, using the communication 
protocol/method of their choice.


>b) Not sure what you guys are talking about with IPC/QLocalSocket, this seems 
>beyond the scope of these classes
>All services/daemons must be able to interface with other processes:

>  (a)- a "client-process" can "request-a-client-operation" to occur on that 
>service/daemon
>  (b)- a process can "query" or "control" the service/daemon (such as to 
>"pause" it, or "stop" it, etc.)
>Thus, some inter-process communication is always required.


Correct. There are two sides to the application - the controller which the user 
interacts with, and the service/daemon which runs without any real interface.
IPC is required, and it should be relegated to local system communications only 
for security purposes.

QtService<> uses a named pipe on *nix and only transfers Strings across. While 
we'll probably only transfer strings, I'd like to leave the option to transfer 
other data as well, and I think QLocalSocket is probably a better option than 
doing what QtService<> did in writing their own wrappers around various methods 
to produce a similar API for their own use. Why reinvent a part of Qt that 
already solves the problem?


>c) I believe Service was used originally because it corresponds to the windows 
>world-view of daemons/services (it also explains why the class itself seems to 
>be more of a fair player on windows rather than *nix). The renaming is fine, 
>but I guess you are committing the reverse sin here. 
>Agreed -- "Service" is understood on "Windows", and "Daemon" is understood on 
>"*nix".  I don't really care about the name -- there is merely a need to 
>disambiguate whatever it is with the things in the "Qt Service Framework".
>

Agreed. And as noted this was discussed at length in the original e-mails back 
in the qt5-feedback days. I had proposed using QServiceApplication figuring 
that would be a nice follow on to QtService and more native, or 
QDaemonServiceApplication to bridge the gap for both. And I honestly don't 
really care except I'd like to keep the Q*Application name to show that it is 
in parallel to QCoreApplication/QApplication/QGuiApplication, so that people 
don't try to create both the daemon-service class and the other in the same 
application.


>d) at this point talk is cheap, show me the code! :)
>Is there any word on whether you guys get a spot in playground?
> 
>That's why the "playground" was requested.  ;-))
>

I have an initial draft I am working on at home. I'll put it in the playground 
project if created once I have access to do so.


Ben
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New mailing list: web_AT_qt-project.org created

[Andre Somers]

Op 26-11-2012 12:12, Verma Gurudutt schreef:


Hi

I am really happy to inform you all that new mailing list 
web_AT_qt-project.org  is created now.


We will be discussing open governance model of web development related 
stuffs for qt-project.org here and proposal for this was made few days 
ago on this mailing  list.


Subscription to this mailing list have to be approved by list 
admin/moderator (Yurvin knuth is only moderator for now) and archive 
to this list is set to private.


You are welcome to join this mailing list if you wish to join our web 
development related activity for qt-project.org.


Looking forwards for exited result from this list J


Following a meeting of interested people tonight on IRC (and for trial 
on Skype and Hangout), the list will be made public.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Changes in QStyle subclasses

[Nurmi J-P]

On Nov 26, 2012, at 7:08 PM, Andre Somers  wrote:

> Op 24-11-2012 12:09, Nurmi J-P schreef:
>> Hi all,
>> 
>> Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and 
>> customize any available style. This is not limited to the built-in styles in 
>> QtWidgets, but also works fine for any style plugin since it nicely avoids 
>> the build time dependency to the corresponding style implementation.
>> 
>> When it comes to the actual style implementations, we have quite a few 
>> refactoring ideas on the table. These ideas include class renames, possible 
>> merges and inheritance hierarchy changes. Not to mention the possibility of 
>> later on pluginizing certain styles to avoid loads of dynamic function 
>> resolving. These ideas are not feasible to implement in time for Qt 5.0, and 
>> for compatibility reasons cannot be done later if the style implementations 
>> remain in the public API.
>> 
>> Hence we would like to take this opportunity to hide the following QStyle 
>> subclasses from the public API in Qt 5.0:
>> - QFusionStyle
>> - QGtkStyle
>> - QMacStyle
>> - QWindowsCEStyle
>> - QWindowsMobileStyle
>> - QWindowsStyle
>> - QWindowsVistaStyle
>> - QWindowsXPStyle
>> 
> Does this also mean that you will remove void QApplication::setStyle(QStyle* 
> style)? This API seems useless if you can't create actual style instances any 
> more because they are public. On the other hand, I think that that may cause 
> issues for some applications...
> 
> André

One can still create style instances using QStyleFactory::create(), so I don't 
see any reason to remove this API. The -style  command line argument keeps 
working as well.

--
J-P Nurmi

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] don't know how to make 'styles\qfusionstyle.h'

[Yang Fan]

Thanks a lot. It does work!


On Mon, Nov 26, 2012 at 5:57 PM, Nurmi J-P  wrote:

> On Nov 26, 2012, at 3:19 AM, Yang Fan  wrote:
>
> > Hi All,
> >
> > I'm trying to build Qt5 from Git with MSVC2010, but got the following
> errors:
> > D:\qt5\qtbase\bin\moc.exe -DUNICODE -DWIN32
> -DQT_NO_USING_NAMESPACE -DQT
> > _BUILD_WIDGETS_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII
> -DQT_ASCII_CAST_WARNIN
> > GS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
> -DQT_DISABLE
> > _DEPRECATED_BEFORE=0x040800 -D_USE_MATH_DEFINES -DQT_NO_STYLE_MAC
> -DQT_STYLE_WIN
> > DOWS -DQT_NO_STYLE_GTK -DQT_NO_STYLE_WINDOWSCE
> -DQT_NO_STYLE_WINDOWSMOBILE -DQT_
> > NO_DIRECTWRITE -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2
> -DQT_OPENGL_
> > ES_2_ANGLE -DQT_NO_EXCEPTIONS -I"D:\OpenSSL-Win32\include"
> -I"..\..\include" -I"
> > ..\..\include\QtWidgets" -I"..\..\include\QtWidgets\5.0.0"
> -I"..\..\include\QtWi
> > dgets\5.0.0\QtWidgets" -I"tmp" -I"..\3rdparty\wintab" -I"dialogs"
> -I"..\3rdparty
> > \harfbuzz\src" -I"." -I"..\..\include\QtGui"
> -I"..\..\include\QtGui\5.0.0" -I"..
> > \..\include\QtGui\5.0.0\QtGui" -I"..\..\include\QtCore"
> -I"..\..\include\QtCore\
> > 5.0.0" -I"..\..\include\QtCore\5.0.0\QtCore" -I"tmp\moc\debug_shared"
> -I"..\..\m
> > kspecs\win32-msvc2010" -D_MSC_VER=1600 -DWIN32
> kernel\qgesturemanager_p.h -o tmp
> > \moc\debug_shared\moc_qgesturemanager_p.cpp
> > NMAKE : fatal error U1073: don't know how to make 'styles\qfusionstyle.h'
> > Stop.
> > NMAKE : fatal error U1077: '"D:\Program Files (x86)\Microsoft Visual
> Studio 10.0
> > \VC\BIN\nmake.exe"' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> > Any suggestion?
> >
> > Regards,
> > Fan Yang
> >
>
> Hi,
>
> Try re-running qmake. The header has been renamed qfusionstyle_p.h, so the
> makefile is outdated.
>
> --
> J-P Nurmi
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 4.8.4 Release candidate 4 available

[Yang Fan]

So many RCs.


On Mon, Nov 26, 2012 at 11:24 PM, Taipale Juhani
wrote:

>  Hi,
>
> ** **
>
> Qt 4.8.4 release candidate 4 is available at
> http://releases.qt-project.org/digia/4.8.4_RC4/
>
> It is based on  SHA1: 96311def2466dd44de64d77a1c815b22fbf68f71
>
> ** **
>
> Juhani Taipale
>
> Software Specialist, Qt Commercial R&D
>
> Digia Plc
>
> Piippukatu 11, FI-40100 JYVÄSKYLÄ FINLAND
>
> Tel: +358 50 384 3755
>
> ** **
>
> Visit us at :www.digia.com or qt.digia.com
>
> ** **
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>


-- 
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Yang Fan]

Any update?


On Fri, Nov 23, 2012 at 8:07 AM, Yang Fan  wrote:

> Yes, I checked this issue on Windows 7, Mac OSX 10.6.8 and Ubuntu 12.10,
> only Windows version has this problem, so I indicated it on Windows in the
> mail subject.
> I didn't create a bug report, since I think there may be some setting
> items of Qt/QtWebkit could resolve this problem.
>
>
> On Thu, Nov 22, 2012 at 11:03 PM, Qi Liang  wrote:
>
>>  At least for me, browser could display simplified Chinese characters
>> correctly on mac. BTW, all the old text codecs are in QtCore 5.0 now. Maybe
>> someone with your configuration could verify it works or not.
>>
>>  Have you created bug report?
>>
>>  Regards,
>> Liang
>>
>>  --
>> *From:* 
>> development-bounces+liang.qi=digia@qt-project.org[development-bounces+liang.qi=
>> digia@qt-project.org] on behalf of Yang Fan [missd...@gmail.com]
>> *Sent:* Thursday, November 22, 2012 7:24 AM
>> *To:* development@qt-project.org
>> *Subject:* [Development] QtWebkit from Qt5 couldn't display Chinese
>> characters correctly on Windows
>>
>>
>> Hi All,
>>
>> Maybe it's not so suitable to ask here, since there's no reply in the
>> Interest maillist.
>> I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build
>> QtWebkit. But I found it couldn't display Chinese characters correctly on
>> Windows, the official example under
>> qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I
>> miss something? Someone has reported this issue before but got no reply.
>> https://qt-project.org/forums/viewthread/21022 .
>> Any suggestion would be appreciated.
>>
>> Regards,
>> Fan Yang
>>
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>>
>
>
> --
> Regards,
> Fan Yang
>
>


-- 
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[BRM]

> From: Matt Broadstone 

>Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
>On Mon, Nov 26, 2012 at 1:48 PM, BRM  wrote:
>> From: Charley Bay 
>Is there any word on whether you guys get a spot in playground?


Since Thiago +1'd, I think I'm good...so I've posted the bug to Jira for it per
http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt#6a17de784cf6db9124e9844959ec8ace


Ben

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[Sascha Cunz]

> All services/daemons must be able to interface with other processes:
Here, I almost agree :-)

>   (a)- a "client-process" can "request-a-client-operation" to occur on that
> service/daemon

But this is totally orthogonal to the application being a daemon/service. To 
some daemons your application "talks" HTTP, SMTP, mysql-protocol or whatever 
others...
Why would someone writing a cron-alike daemon want to listen on some 
QLocalSocket?

>   (b)- a process can "query" or "control" the service/daemon (such as to
> "pause" it, or "stop" it, etc.)

That is the task of:
- launchctl on Mac
- Service-Manager / "net start" / ServiceControlManager-API on Windows
- Init-Scripts (or interfaces to them) on Linux
  [This describtion meats OpenRC, Upstart, systemd and even SysVInit, right?]

Without using those, you blindly bypass any security mechanisms that the OS 
itself provides for services/daemons.
I really wouldn't like anybody on my system capable of creating a QLocalSocket 
to also be able to stop a service.

> Thus, some inter-process communication is always required.
IPC can also be shared-memory or files on disk. This has nothing to do with a 
QLocalSocket.

Sascha


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Development Digest, Vol 14, Issue 81

[chenyw3892]

test




chenyw3892

From: development-request
Date: 2012-11-27 10:54
To: development
Subject: Development Digest, Vol 14, Issue 81
Send Development mailing list submissions to
development@qt-project.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.qt-project.org/mailman/listinfo/development
or, via email, send a message with subject or body 'help' to
development-requ...@qt-project.org

You can reach the person managing the list at
development-ow...@qt-project.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Development digest..."


Today's Topics:

   1. Re: HEADS UP: Changes in QStyle subclasses (Nurmi J-P)
   2. Re: don't know how to make 'styles\qfusionstyle.h' (Yang Fan)
   3. Re: Qt 4.8.4 Release candidate 4 available (Yang Fan)
   4. Re: QtWebkit from Qt5 couldn't display Chinese characters
  correctly on Windows (Yang Fan)
   5. Re: Qt Playground - Updating Daemon/Service Support (BRM)
   6. Re: Qt Playground - Updating Daemon/Service Support (Sascha Cunz)


--

Message: 1
Date: Mon, 26 Nov 2012 22:30:44 +
From: Nurmi J-P 
Subject: Re: [Development] HEADS UP: Changes in QStyle subclasses
To: "development@qt-project.org" 
Message-ID: <7487f65a-b901-4c51-b450-98a4c2050...@digia.com>
Content-Type: text/plain; charset="iso-8859-1"

On Nov 26, 2012, at 7:08 PM, Andre Somers  wrote:

> Op 24-11-2012 12:09, Nurmi J-P schreef:
>> Hi all,
>> 
>> Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and 
>> customize any available style. This is not limited to the built-in styles in 
>> QtWidgets, but also works fine for any style plugin since it nicely avoids 
>> the build time dependency to the corresponding style implementation.
>> 
>> When it comes to the actual style implementations, we have quite a few 
>> refactoring ideas on the table. These ideas include class renames, possible 
>> merges and inheritance hierarchy changes. Not to mention the possibility of 
>> later on pluginizing certain styles to avoid loads of dynamic function 
>> resolving. These ideas are not feasible to implement in time for Qt 5.0, and 
>> for compatibility reasons cannot be done later if the style implementations 
>> remain in the public API.
>> 
>> Hence we would like to take this opportunity to hide the following QStyle 
>> subclasses from the public API in Qt 5.0:
>> - QFusionStyle
>> - QGtkStyle
>> - QMacStyle
>> - QWindowsCEStyle
>> - QWindowsMobileStyle
>> - QWindowsStyle
>> - QWindowsVistaStyle
>> - QWindowsXPStyle
>> 
> Does this also mean that you will remove void QApplication::setStyle(QStyle* 
> style)? This API seems useless if you can't create actual style instances any 
> more because they are public. On the other hand, I think that that may cause 
> issues for some applications...
> 
> Andr?

One can still create style instances using QStyleFactory::create(), so I don't 
see any reason to remove this API. The -style  command line argument keeps 
working as well.

--
J-P Nurmi



--

Message: 2
Date: Tue, 27 Nov 2012 08:27:41 +0800
From: Yang Fan 
Subject: Re: [Development] don't know how to make
'styles\qfusionstyle.h'
To: Nurmi J-P 
Cc: "development@qt-project.org" 
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Thanks a lot. It does work!


On Mon, Nov 26, 2012 at 5:57 PM, Nurmi J-P  wrote:

> On Nov 26, 2012, at 3:19 AM, Yang Fan  wrote:
>
> > Hi All,
> >
> > I'm trying to build Qt5 from Git with MSVC2010, but got the following
> errors:
> > D:\qt5\qtbase\bin\moc.exe -DUNICODE -DWIN32
> -DQT_NO_USING_NAMESPACE -DQT
> > _BUILD_WIDGETS_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII
> -DQT_ASCII_CAST_WARNIN
> > GS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
> -DQT_DISABLE
> > _DEPRECATED_BEFORE=0x040800 -D_USE_MATH_DEFINES -DQT_NO_STYLE_MAC
> -DQT_STYLE_WIN
> > DOWS -DQT_NO_STYLE_GTK -DQT_NO_STYLE_WINDOWSCE
> -DQT_NO_STYLE_WINDOWSMOBILE -DQT_
> > NO_DIRECTWRITE -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2
> -DQT_OPENGL_
> > ES_2_ANGLE -DQT_NO_EXCEPTIONS -I"D:\OpenSSL-Win32\include"
> -I"..\..\include" -I"
> > ..\..\include\QtWidgets" -I"..\..\include\QtWidgets\5.0.0"
> -I"..\..\include\QtWi
> > dgets\5.0.0\QtWidgets" -I"tmp" -I"..\3rdparty\wintab" -I"dialogs"
> -I"..\3rdparty
> > \harfbuzz\src" -I"." -I"..\..\include\QtGui"
> -I"..\..\include\QtGui\5.0.0" -I"..
> > \..\include\QtGui\5.0.0\QtGui" -I"..\..\include\QtCore"
> -I"..\..\include\QtCore\
> > 5.0.0" -I"..\..\include\QtCore\5.0.0\QtCore" -I"tmp\moc\debug_shared"
> -I"..\..\m
> > kspecs\win32-msvc2010" -D_MSC_VER=1600 -DWIN32
> kernel\qgesturemanager_p.h -o tmp
> > \moc\debug_shared\moc_qgesturemanager_p.cpp
> > NMAKE : fatal error U1073: don't know how to make 'styles\qfusionstyle.h'
> > Stop.
> > NMAKE : fatal error U1077: '"D:\Program Files (x86)\Microsoft Visual
> Studio 10.0
> > \VC\BIN\nmake.exe"' : return code 

Re: [Development] Qt Playground - Updating Daemon/Service Support

[BRM]

- Original Message -

> From: Sascha Cunz 
> Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
> 
>>  All services/daemons must be able to interface with other processes:
> Here, I almost agree :-)
> 
>>    (a)- a "client-process" can 
> "request-a-client-operation" to occur on that
>>  service/daemon
> 
> But this is totally orthogonal to the application being a daemon/service. To 
> some daemons your application "talks" HTTP, SMTP, mysql-protocol or 
> whatever 
> others...
> Why would someone writing a cron-alike daemon want to listen on some 
> QLocalSocket?

Kind of.

A daemon/service has two interfaces: (i) user/system-API oriented, and (ii) one 
internal.

The first presents the interface to the outside world on how to control the 
service. This interface
needs to integrated into the system - e.g. Windows Service API, systemd, shell 
scripting, user query.
However, this interface also needs to be able to talk to the daemonized process 
which has had its user-interface (e.g. Tty)
removed from it. You can only do that using some form of communications - 
network port, message queues, etc.

Requiring use of a network port (e.g. TCP XXX, UDP XXX, etc.) seems a little 
extreme. It also makes for a wider target of remote attacks on applications, 
not good.

Many of the technologies for IPC are very platform specific - e.g. message 
queues, named events, named pipes, etc. So we would have to rewrite an 
abstraction layer for that.

Or we could use QLocalSocket to allow the outside (i) to talk to the daemonized 
process (ii), and let Qt do the abstracting for us, likely providing a better, 
more standarized interface,
and expanded comms capability.

>>    (b)- a process can "query" or "control" the 
> service/daemon (such as to
>>  "pause" it, or "stop" it, etc.)
> 
> That is the task of:
> - launchctl on Mac
> - Service-Manager / "net start" / ServiceControlManager-API on Windows
> - Init-Scripts (or interfaces to them) on Linux
>   [This describtion meats OpenRC, Upstart, systemd and even SysVInit, right?]

yes, and we have to implement the interfaces to those. Each of those has a 
front end interface that must talk via IPC to a daemonized process in some form.
Some form of IPC must be used.
 
> Without using those, you blindly bypass any security mechanisms that the OS 
> itself provides for services/daemons.
> I really wouldn't like anybody on my system capable of creating a 
> QLocalSocket to also be able to stop a service.

You don't blindly by-pass it. And not just anyone would be able to necessarily 
talk to it - it's no different than what's used in QtService<> already.
 
>>  Thus, some inter-process communication is always required.
> IPC can also be shared-memory or files on disk. This has nothing to do with a 
> QLocalSocket.

Yes. IPC can be a number of things. But as I noted, I'd rather not reinvent the 
wheel when Qt already has something to offer.

Having looked through the QtService code, it creates internal sockets for 
Windows and Unix, which IIRC are identical to what QLocalSocket uses - a named 
pipe on Windows, and local socket on Unix.
So there is no security difference between using QLocalSocket and what is done 
by QtService; and its less code for _us_ to maintain for the DaemonApplication 
API.

Ben

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[Sascha Cunz]

m Montag, 26. November 2012, 20:36:47 schrieben Sie:
> - Original Message -
> 
> > From: Sascha Cunz 
> > Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
> > 
> >>  All services/daemons must be able to interface with other processes:
> > Here, I almost agree :-)
> > 
> >>(a)- a "client-process" can
> > 
> > "request-a-client-operation" to occur on that
> > 
> >>  service/daemon
> > 
> > But this is totally orthogonal to the application being a daemon/service.
> > To some daemons your application "talks" HTTP, SMTP, mysql-protocol or
> > whatever
> > others...
> > Why would someone writing a cron-alike daemon want to listen on some
> > QLocalSocket?
> 
> Kind of.
> 
> A daemon/service has two interfaces: (i) user/system-API oriented, and (ii)
> one internal.
> 
> The first presents the interface to the outside world on how to control the
> service. This interface needs to integrated into the system - e.g. Windows
> Service API, systemd, shell scripting, user query.
Right.

> However, this interface
> also needs to be able to talk to the daemonized process which has had its
> user-interface (e.g. Tty) removed from it. You can only do that using some
> form of communications - network port, message queues, etc.
But why would it want to do that? I mean: Is there a generic gain that is not 
already provided by the operating system itself?

> > > That is the task of:
> > - launchctl on Mac
> > - Service-Manager / "net start" / ServiceControlManager-API on Windows
> > - Init-Scripts (or interfaces to them) on Linux
> >   [This describtion meats OpenRC, Upstart, systemd and even SysVInit,
> > right?]

> yes, and we have to implement the interfaces to those. Each of those has a
> front end interface that must talk via IPC to a daemonized process in some
> form. Some form of IPC must be used.

Actually, I still don't get what you want to do with that IPC. And by the way: 
I didn't say, that I thought what QService<> is doing right now, was right. 
Instead I doubt that.

Just 2 examples:

To start or stop a service on Windows, you have 3 methods:
1. Via GUI: There's a service management application (nowadays launchable from 
TaskManager)
2. Via Command-Line: "net start" / "net stop"

Both of these are wrappers for:
3. "ServiceControlManager"-API, which is a RPC/IPC mechanism built into 
Windows itself that is esp. designed to do those kind of things.

The service registers itself with SCM and receives the commands you're talking 
about _from SCM_. The SCM takes care of "impersonating" the service correctly, 
etc.
See [1].

On linux, it is very common to "singal" daemons for actions like "stop" or 
"reload your config, please". Then the daemon-process itself acts upon that 
singal. I can't "kill -9" someone else's process, unless I'm root.

What current operating system forces you to tell your daemon via a 
QLocalSocket that it has to perform some administative operation?

Even if you were about to write a cross-platform Daemon-Controller tool, you 
should still not talk to the daemon directly, but rather to the infrastructure 
provided by the operating system.

Sascha

[1] http://msdn.microsoft.com/en-
us/library/windows/desktop/bb540476%28v=vs.85%29.aspx
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 4.8.4 Release candidate 4 available

[Turunen Tuukka]

> From: Yang Fan mailto:missd...@gmail.com>>
> Date: tiistai 27. marraskuuta 2012 2.28
> Cc: "development@qt-project.org" 
> mailto:development@qt-project.org>>
> Subject: Re: [Development] Qt 4.8.4 Release candidate 4 available
>
> So many RCs.

True. We are hoping this is the last one. If all goes well, we should be able 
to release this week.

As you can see 4.8 is quite active. We have gotten valuable items into each new 
RC.

Yours,

Tuukka
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[Lukas Geyer]

Am 27.11.2012 06:15, schrieb Sascha Cunz:
>> A daemon/service has two interfaces: (i) user/system-API oriented, and (ii)
>> one internal.
>>
>> The first presents the interface to the outside world on how to control the
>> service. This interface needs to integrated into the system - e.g. Windows
>> Service API, systemd, shell scripting, user query.
> Right.
>
>> However, this interface
>> also needs to be able to talk to the daemonized process which has had its
>> user-interface (e.g. Tty) removed from it. You can only do that using some
>> form of communications - network port, message queues, etc.
 >
> But why would it want to do that? I mean: Is there a generic gain that is not
> already provided by the operating system itself?

Yes. Each service which needs to interact with the user requires some 
sort of IPC to provide a graphical interface, as interactive services 
are not allowed on most modern operating systems (not to mention design 
considerations).

Basically each service has three different 'interfaces':

- lifetime control: start, stop, restart, installation, removal and 
alike. This is (usually) not a responsibility of the service, but solely 
the system (ie. the Service Manager, systemd and alike). The 'Daemon 
Framework' may provide platform-independent means (a set of classes and 
a simple tool using those) to interact with the platform-specific 
service management system to control the lifetime of a service and to 
interact with the system to provide status and receive events.

- the 'service': which basically abstracts the task the service has been 
installed for, e.g. serving data over HTTP for a web server, scanning 
disks for an antivirus service, transferring data for a backup service. 
'The Daemon Framework' does not have to provide any support for this 
interface, as it is purely application-specific and already provided by 
other parts of Qt (QTcpServer, QFile, QFileSystemWatcher and alike).

- the configuration or user interface: which basically allows for 
interacting with the user, which might be in the simplest form a 
configuration file, but more often then not this is full-blown 
application to do service-specific tasks, be it the user interface for 
the antivirus service (configuration of the scan engine, add and remove 
localtions, on-demand scanning and alike) or the backup service (add or 
remove jobs, on-demand backup and alike).


As a user (as in 'using the framework to develop service applications 
and user clients') I expect (as in 'I would like to see') from the 
'Daemon Framework' to:

- provide a set of classes which allow for interacting with the 
system-specific service manager, both from the service application 
(report status, request reload or restart, notification of system events 
and alike) as well from the user client or a configuration or 
installation utility (start, stop, restart, install, remove and alike).

- provide no support for the 'service' interface.

- provide support to interact with the service from a (graphical) user 
client in a flexible, transparent way. In its 'simplest' form this is a 
Q_INTERFACE implemented on the service side and generated on the client 
side, which automatically routes all signals, slots, properties and 
method calls to the service application using some kind of (local and 
non-local) IPC. If needed, I expect to be able to 'go deeper', selecting 
a specific IPC method, directly accessing the IPC and alike.

- provide support to interface with the service directly. I mean, hey, 
so we may finally get a suitable out-of-the-box command line parser 
after two decades of development ;-)


On a sidenote: There is a scope for non-interactive, but QGuiApplication 
/ QApplication bsaed services. I've seen people doing image processing 
or website grabbing which requires QtGui resp. QtWidgets, but no 
graphical interface.


regards,
Lukas
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Playground - Updating Daemon/Service Support

[Sascha Cunz]

Am Dienstag, 27. November 2012, 08:16:20 schrieb Lukas Geyer:
> Am 27.11.2012 06:15, schrieb Sascha Cunz:
> >> A daemon/service has two interfaces: (i) user/system-API oriented, and
> >> (ii)
> >> one internal.
> >> 
> >> The first presents the interface to the outside world on how to control
> >> the
> >> service. This interface needs to integrated into the system - e.g.
> >> Windows
> >> Service API, systemd, shell scripting, user query.
> > 
> > Right.
> > 
> >> However, this interface
> >> also needs to be able to talk to the daemonized process which has had its
> >> user-interface (e.g. Tty) removed from it. You can only do that using
> >> some
> >> form of communications - network port, message queues, etc.
> > 
> > But why would it want to do that? I mean: Is there a generic gain that is
> > not already provided by the operating system itself?
> 
> Yes. Each service which needs to interact with the user requires some
> sort of IPC to provide a graphical interface, as interactive services
> are not allowed on most modern operating systems (not to mention design
> considerations).
As you said: this applies _only_ to those that "needs to interact with the 
user". These are not the majority on the operating systems I use (Windows and 
Linux, mostly).

> Basically each service has three different 'interfaces':
> 
> - lifetime control: start, stop, restart, installation, removal and
> alike. This is (usually) not a responsibility of the service, but solely
> the system (ie. the Service Manager, systemd and alike). The 'Daemon
> Framework' may provide platform-independent means (a set of classes and
> a simple tool using those) to interact with the platform-specific
> service management system to control the lifetime of a service and to
> interact with the system to provide status and receive events.
Agreed.
 
> - the 'service': which basically abstracts the task the service has been
> installed for, e.g. serving data over HTTP for a web server, scanning
> disks for an antivirus service, transferring data for a backup service.
> 'The Daemon Framework' does not have to provide any support for this
> interface, as it is purely application-specific and already provided by
> other parts of Qt (QTcpServer, QFile, QFileSystemWatcher and alike).
Agreed.
 
> - the configuration or user interface: which basically allows for
> interacting with the user, which might be in the simplest form a
> configuration file, but more often then not this is full-blown
> application to do service-specific tasks, be it the user interface for
> the antivirus service (configuration of the scan engine, add and remove
> localtions, on-demand scanning and alike) or the backup service (add or
> remove jobs, on-demand backup and alike).
Where is the difference to the previous bullet?

> As a user (as in 'using the framework to develop service applications
> and user clients') I expect (as in 'I would like to see') from the
> 'Daemon Framework' to:
> 
> - provide a set of classes which allow for interacting with the
> system-specific service manager, both from the service application
> (report status, request reload or restart, notification of system events
> and alike) as well from the user client or a configuration or
> installation utility (start, stop, restart, install, remove and alike).
That would be awesome to have!

> - provide no support for the 'service' interface.
Agreed.

> - provide support to interact with the service from a (graphical) user
> client in a flexible, transparent way.
How can this be _generic_? This stuff obviously belongs to the bussiness logic 
of the daemon/service.

> In its 'simplest' form this is a
> Q_INTERFACE implemented on the service side and generated on the client
> side, which automatically routes all signals, slots, properties and
> method calls to the service application using some kind of (local and
> non-local) IPC. If needed, I expect to be able to 'go deeper', selecting
> a specific IPC method, directly accessing the IPC and alike.

This "simplest form" describes an IPC technique that is currently not deployed 
in Qt. It would be cool to have it, but it has nothing to do with a 'Daemon-
Framework'. What you describe here sounds to me like something between DBUS 
and COM, readily tailored towards Qt's singal/slot mechanism.

Another thing that comes to mind would be a towards-Qt-tailored implementation 
of Google's protobuf [1]. But again: This isn't service-specific.
There are use-cases for 2 desktop-apps to talk in that manner to each other. 
Just think about Microsoft's "PDB-Server", which is acutally a background 
process (but not as fullblown to be called "service") that the IDE, Debugger 
and Compiler use.

> - provide support to interface with the service directly.
Well, again, I don't think that a "daemon-framework" should force a specific 
way of interaction to the user (=developer).

> I mean, hey, so we may finally get a suitable out-of-the-box command line
> parser after two decade