<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hi all,</p>
<p>I agree with Régis. It would be useful to have the layouts instead of the old composers in QGIS 3. It would be better than the other alternatives, even if it would mean a further delay of the QGIS 3 release.</p>
<p>We just have to think about the consequences. Personally, I would propose to delay the QGIS 3 release again a bit, e.g. release later in December, just before Christmas - because I do think that the bug fixing period, as it is scheduled now is too short.</p>
<p>Just my personal opinion. I would prefer to have a quick decision here.</p>
<p>Andreas</p>
<p>On 2017-11-03 09:38, Régis Haubourg wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div dir="ltr"><br />
<div class="gmail_extra">Hi all, </div>
<div class="gmail_extra"><br />
<div class="gmail_quote">2017-11-03 8:52 GMT+01:00 Nyall Dawson <span><<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>></span>:<br />
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;"><span>On 2 November 2017 at 22:08, Andreas Neumann <<a href="mailto:a.neumann@carto.net">a.neumann@carto.net</a>> wrote:<br /></span>[...]<br /> But the alternatives are:<br /> <br /> 1. Ship with composer, and keep exposing composer API. We'll be stuck<br /> with composer for the life of 2.x, and when layouts lands in 3.2 we'll<br /> end up with duplicate buttons for "new composer"/"new layout", or some<br /> option to switch the print backend from composer/layouts. Ouch! Not to<br /> mention that we'll be forced to carry around and maintain thousands of<br /> lines of old code for the next x years.<br /> <br /> 2. Ship with composer in 3.0, but remove from bindings (e.g.<br /> <a href="https://github.com/qgis/QGIS/pull/5486" target="_blank" rel="noopener noreferrer">https://github.com/qgis/QGIS/<wbr />pull/5486</a>). Then after thaw I can merge<br /> layouts and drop all the composer code. Downside is no ability to<br /> script or have composer based plugins in 3.0. Upside is layouts lands<br /> with the new clean api in 3.2, and we can have a clean-start then.<br /> Another upside is the additional full cycle of testing for layouts<br /> which means that when it's available to users in 3.2 it should be<br /> rock-solid.<br /> <br /> That's me laying out all the options as I see them. I'm honestly happy<br /> to abide by whatever decision the release manager/PSC makes here. I<br /> don't envy their position in making this call (sorry!)<br /><br /></blockquote>
<div> </div>
<div>Is there no option 3 "drop composer totally and merge layouts " ? It was the very first need that started QGIS3 project IIRC. </div>
<div> </div>
<div>On our side, we will be severely impacted for short time project if we drop composer, but I think the mid term option with mixed composer and layout in QGIS will cost al lot more to all of us. Users won't understand having both, and not having python bindings to layout in 3.0 will be a no go for deploying applications. So that would be the same as tagging 3.0 as a release candidate version, which is not the path we chose. </div>
<div> </div>
<div>Regards</div>
<div>Régis</div>
<div> </div>
<div> </div>
</div>
</div>
</div>
</blockquote>
<p><br /></p>
</body></html>