Re: [Development] Tagging private symbols as such

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 7 de diciembre de 2016 08:02:20 ART Thiago Macieira wrote:
[snip]
> But the extra versioning is a further safety check: if something was missed
> in the update, like for example some code compiled by the user (regardless
> of use of package management), it will necessarily stop working.

I not sure of the usefullnes in this case. If I remember correctly the linker 
will try first to locate the symbol with the right version and if it fails the 
first symbol that matches no matter it's version.

I remember that when the symbols' version was added to Qt we did not have to 
rebuild anything: things just worked out without issues. And we where dealing 
with public symbols here.

I never the less give it a try and compiled Qt 5.7.1 (latest snapshot) with 
the patch that changes QPA symbols' version to private ones. I've got 
segfaults while running Plasma, but no linking problems that I could see.

Granted, I don't know why the crashes happened but I didn't directly see any 
effect of changing QPA's symbols's versions, so I don't know if code compiled 
by the user will necesarily stop working.

Am I missing something here?

-- 
If little green men land in your back yard, hide any little green women
you've got in the house.
  Mike Harding, "The Armchair Anarchist's Almanac"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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] Fwd: [Interest] QtIFW 2.0.4 Release?

[Konstantin Podsvirov]

Hello guys!QtSDK maintenance now based on 2.0.4 framework, but what about 2.0.4 tag and binaries for QtIFW?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Rules for Third-Party components in Qt 5.8 onwards

[Kai Koehne]

Hi,

(I'll try to answer some comments made in the gerrit review here. IMO gerrit
works great for editorial stuff, but not for more substantial things).

> [Tobias Hunger]
> I would make the homepage mandatory in the attribution file. That information 
> is critical IMHO when you want to find out more about that piece of code.

If there's a homepage, by all means, specify the "Homepage" property. I didn't 
make it mandatory though because we have code where there's just no legitimate 
upstream homepage, most often because Qt itself is the 'upstream'. Putting 
"www.qt.io" here would be possible, but also confusing ;) That's e.g. the case 
for some of the text codes, like 
http://doc-snapshots.qt.io/qt5-5.8/qtcore-attribution-qtsciicodec.html. 

> I would also suggest to add something about giving the exact revision of the 
> code (full download link, repo where the code came from and exact version 
> specification in that repo) in the commit message when initially > importing 
> the code or when updating it. For my taste it is currently too hard to find 
> out which exact versions of stuff we use.

It is very important to track the upstream version used, so that we can easily 
see when something is outdated and track custom changes done before it's 
imported.

You should not only put that in the commit message though. In 
qt_attribution.json file you should set a 'Version' field that you should set 
to the official property. This could also be e.g. an SHA if there's no marked 
upstream version. In addition, you should set the 'DownloadLocation' field that 
should link to the upstream package / installer / ...  

When creating the initial qt_attribution.json files, I was adding this 
information when it was obvious, but I didn't do much due diligence. I'd 
appreciate it if contributors/maintainers would complete the information 
wherever possible.

> [Robin Burchell on Copyright field being mandatory]
> Having the license for instance as mandatory seems quite reasonable, but I'm 
> less certain about this. Keeping it maintained could be quite a burden, and 
> for complex software I can imagine it ending up quite long. Does > it have 
> significant value? What's the purpose of it?
> 
> For example, I looked at another project I've been a significant part of, 
> started around 2002, with a fairly constant stream of random contributors. 
> There are 135 unique "Copyright" lines throughout the source, 
> although a number of these are duplicated authors with different year 
> information. The most frequently repeated lines are repeated >100 times.

I'm a bit unsure about the extra 'Copyright' field myself, especially if it 
duplicates the Copyright in the license file (like it is for the BSD licenses). 
I added it because it's sometimes requested by customers, and is also part of 
e.g. the SPDX and debian/copyright specifications [1,2].

In general, the copyright field shows the user a) when the copyright protection 
might run out and b) whom to contact in case one has questions. Also, even if 
not strictly required by some licenses, it is also acknowledging the original 
authors. So, I do think it adds value, also to the documentation.

In practical terms, often bigger projects tend to have generic acknowledgements 
like

  Copyright  the  authors

or 

  Copyright  the  and contributors

If that is done upstream, it obviously is the right thing to keep it like that 
in the qt_attribution.json file, too. I can try to find out whether it's also 
ok to consolidate on our own.

So, in summary, I'd keep the field mandatory, potentially consolidating it to 
one name. If the Copyright is also part of the License text itself (like for 
the typical BSD license), I've duplicated the lines in the past.

If we decide to keep it this way, I can try to clarify it in the QUIP.

[1]: https://spdx.org/spdx-specification-21-web-version#h.2grqrue
[2]: 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field

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

Re: [Development] A new approach for Qt main()

[Edward Welbourne]

Morten Sorvig supplied:

> For some background, here’s what typical application startup looks
> like on macOS, NaCl, and Emscripten:

I've updated [0] to illustrate these.
[0] https://wiki.qt.io/Application_Start-up_Patterns

> macOS: Define the application delegate, create instance of it in main()
>
>  // Define application delegate with app lifecycle callbacks
>  @interface AppDelegate ()
>  @end
>
>   @implementation AppDelegate
>   - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
>  // Init application here
>   }
>
>   - (void)applicationWillTerminate:(NSNotification *)aNotification {
>  // Tear down here
>   }
>   @end

Please say more about what has to happen in these, especially init;
presumably, we need to add some handlers to something like an event
queue, to ensure our application gets told what's happening and when to
respond to it.

>   // In main, install application delegate and start the app
>   int main(int argc, const char *argv[])
>   {
>NSApplication *app = [NSApplication sharedApplication];
>app.delegate = [[AppDelegate alloc] initWithArgc:argc argv:argv];
>return NSApplicationMain(argc, argv);
>   }

I take it NSApplicationMain(argc, argv) contains a system standard event
loop that looks to the shared NSApplication for its control.

> Native Client: Define pp::CreateModule() and return the application
> module (which is a subclass of pp::Module)
>
>   namespace pp {
> Module* CreateModule() {
>return new ApplicationModule();
> }
>   }

I need some clue what methods pp::Module allows us to override and how
we can, by doing so, control what the resulting app does.

> Emscripten: implement main()
>
>   int main(int argc, const char *argv[) {
>  // Init application here
>  return 0;
>   }
>
> main() should/must return to keep the web page responsive.

I take it, then, that "main()" isn't the whole program, in the classic C
way, just an insertion into an existing running something - into which
we presumably inject some application-specific objects that connect
themselves into the event stream and provide ways to respond.

> There is API for simulating a main that does not return and preserve
> the stack, see emscripten_set_main_loop() in the emscripten
> documentation.

Sounds complicated.  Better to fit in naturally with the native system's
preferred modus operandi.

Illustrations (maybe provided by link to existing examples) of how we
presently shoe-horn our existing architecture into the various cases
would be a passable first attempt at answering the open questions ...

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

[Development] Rules for Third-Party components in Qt 4.8 onwards

[Kai Koehne]

Hi,

I'd like to put down the rules on how we handle code in Qt that we as Qt 
contributors do not have copyright over ourselves in a QUIP:

https://codereview.qt-project.org/#/c/177201/6/quip-0004.txt

I suggest that
- Every third party component must be documented by a qt_attribution.json file
- Adding a third-party component that will become part of a Qt library, plugin 
or tool needs approval by the Chief Maintainer
- Third-party components that become part of a Qt library, plugin, or tool need 
to be mentioned in the change log of the release in a [Third-Party Code] area.

Regards

Kai

-- 
Kai Köhne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. 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

Re: [Development] A new approach for Qt main()

[Simon Hausmann]

Hi,


I don't think it does handle those cases. But we're not talking about 
eliminating main(), we're talking about a second supported "launch" method.


That said, it's still possible to run code before the constructor, although 
it's not pretty.


Simon


From: Laszlo Agocs
Sent: Tuesday, December 13, 2016 10:42:05 AM
To: Simon Hausmann; Mathias Hasselmann; development@qt-project.org
Subject: RE: [Development] A new approach for Qt main()

Hi,

How does this handle the cases that need code before the QGuiApplication 
construction? AFAICS it does not.

Laszlo

From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Simon Hausmann
Sent: Tuesday, December 13, 2016 10:37 AM
To: Mathias Hasselmann ; development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()


Hi,



The joke of the bikeshedding aside I for one do like the idea of exporting a 
QObject sub-class instead of a function. That makes it easier to extend in the 
future with more entry-points as slots for example.







Simon


From: Development 
>
 on behalf of Mathias Hasselmann 
>
Sent: Monday, December 12, 2016 7:53:50 PM
To: development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()

Hi,

Seems this turned into a nice bike shed discussion quickly, so let me
use the chance to present my preferred Qt main(). I am totally convinced
that this one should rule the Qt world:

 class BlueBikeShedApplication : public QApplication
 {
 Q_OBJECT

 public:
 using QApplication::QApplication;

 int run()
 {
 if (!parseCommandLine())
 return EXIT_FAILURE;
 if (!initializeColorBucket())
 return EXIT_FAILURE;

 setupBrush();

 return exec();
 }
 };

 int main(int argc, char *argv[])
 {
 return BlueBikeShedApplication{argc, argv}.run();
 }

The big advantage I see in this approach is, that you work within a
proper QObject context with fully setup QApplication early. Also this
main() is sufficiently generic to be hidden in a platform specific
macro, or static library.

Thank you for reading,
Mathias
___
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] A new approach for Qt main()

[Laszlo Agocs]

Hi,

How does this handle the cases that need code before the QGuiApplication 
construction? AFAICS it does not.

Laszlo

From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Simon Hausmann
Sent: Tuesday, December 13, 2016 10:37 AM
To: Mathias Hasselmann ; development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()


Hi,



The joke of the bikeshedding aside I for one do like the idea of exporting a 
QObject sub-class instead of a function. That makes it easier to extend in the 
future with more entry-points as slots for example.







Simon


From: Development 
>
 on behalf of Mathias Hasselmann 
>
Sent: Monday, December 12, 2016 7:53:50 PM
To: development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()

Hi,

Seems this turned into a nice bike shed discussion quickly, so let me
use the chance to present my preferred Qt main(). I am totally convinced
that this one should rule the Qt world:

 class BlueBikeShedApplication : public QApplication
 {
 Q_OBJECT

 public:
 using QApplication::QApplication;

 int run()
 {
 if (!parseCommandLine())
 return EXIT_FAILURE;
 if (!initializeColorBucket())
 return EXIT_FAILURE;

 setupBrush();

 return exec();
 }
 };

 int main(int argc, char *argv[])
 {
 return BlueBikeShedApplication{argc, argv}.run();
 }

The big advantage I see in this approach is, that you work within a
proper QObject context with fully setup QApplication early. Also this
main() is sufficiently generic to be hidden in a platform specific
macro, or static library.

Thank you for reading,
Mathias
___
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] A new approach for Qt main()

[Simon Hausmann]

Hi,


The joke of the bikeshedding aside I for one do like the idea of exporting a 
QObject sub-class instead of a function. That makes it easier to extend in the 
future with more entry-points as slots for example.




Simon


From: Development  on 
behalf of Mathias Hasselmann 
Sent: Monday, December 12, 2016 7:53:50 PM
To: development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()

Hi,

Seems this turned into a nice bike shed discussion quickly, so let me
use the chance to present my preferred Qt main(). I am totally convinced
that this one should rule the Qt world:

 class BlueBikeShedApplication : public QApplication
 {
 Q_OBJECT

 public:
 using QApplication::QApplication;

 int run()
 {
 if (!parseCommandLine())
 return EXIT_FAILURE;
 if (!initializeColorBucket())
 return EXIT_FAILURE;

 setupBrush();

 return exec();
 }
 };

 int main(int argc, char *argv[])
 {
 return BlueBikeShedApplication{argc, argv}.run();
 }

The big advantage I see in this approach is, that you work within a
proper QObject context with fully setup QApplication early. Also this
main() is sufficiently generic to be hidden in a platform specific
macro, or static library.

Thank you for reading,
Mathias
___
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