On Thu, Mar 14, 2013 at 10:05 AM, Régis Haubourg <[email protected]> wrote: > Hi, > > +1 with Radim. Such hacks do produce inconsistencies and bugs not compatible > with collaborative coding. IMHO, we need clean coding in QGIS. > > A feature already asked I remember could solve both issues. Some of us asked > that for layers having single symbol style, symbol in legend should be drawn > on the same line as layer’s title (like in Arcgis or mapinfo).
That should be default, it is what most users are expecting, I believe. This should not be changed in major line, so if we want that, it must be implemented for 2.0. > http://hub.qgis.org/issues/6960 He asked for single symbol item labels, I have commented and suggested single line representation of single symbol layers instead. Radim > Using groups will then help reaching Mathieu’s goal? > > Opinions? > > > > I’m ready to put that in a contract if needed > > Régis > > > > De : Radim Blazek-2 [via OSGeo.org] [mailto:ml-node+[hidden email]] > Envoyé : jeudi 14 mars 2013 09:47 > À : HAUBOURG > Objet : Re: Multicolumn legends in print composer > > > > IMO, using empty layer title to achieve grouping of items from > multiple layers into a single layer (group) is just a workaround. If > it was working for some reason in previous versions (probably because > there was no difference between layer and item spacing) it does not > mean that we must add new and new hacks to the code to support it > forever. > > I am not convinced that removing layer space if the layer title is > empty > (http://hub.qgis.org/projects/quantum-gis/repository/revisions/08c8857/diff/src/core/composer/qgscomposerlegend.cpp) > is good. It is a hack to support your need but it introduces another > bug and inconsistency because other user may require hidden layer > titles (if empty) but still keeping layer spacing. > > A clean solution could be to add a new group "Road & Railways" with > roads and railways layers inside and implement something like flatten > sublayers check box for the group, which would put items of all > sublayers directly into the group, ignoring layer titles. > > Radim > > > On Wed, Mar 13, 2013 at 1:30 PM, Mathieu Pellerin <[hidden email]> wrote: > > >> Radim, >> >> Thanks for fixing the width issue. >> >> Regarding layers with no titles and the need for treating the space like a >> layer item, see http://hub.qgis.org/issues/3605. We've discussed this with >> Marco Hugentobler back then and came up with a nice compromise. >> >> Beyond being a regression as it stands (i.e. legends from 1.8 projects >> will >> have visible vertical spacing issues), here's a simple scenario in >> picture: >> http://hub.qgis.org/attachments/3161/legend-simple-scenario.jpg (the >> spacing >> should be equal for all companies, as well as btween roads and railways. >> >> Having no layer title is a way to regroup many layers under one layer name >> (i.e. having 5 shapefile polygons representing different ago-industrial >> crops might nicely be represented under one layer title even though the >> items are in five different physical shapefiles). >> >> Math >> >> >> On Wed, Mar 13, 2013 at 5:31 PM, Radim Blazek <[hidden email]> >> wrote: >>> >>> On Tue, Feb 19, 2013 at 4:48 AM, Mathieu Pellerin <[hidden email]> >>> wrote: >>> > Radim, >>> > >>> > Following up on your implementation of the nice legend's multicolumn >>> > feature. I've noticed two regression (one of which I've filed a bug >>> > already). >>> > >>> > 1) The right-side box spacing is now miscalculated as it fails to add >>> > the >>> > icon label space value. Issue 7099 (http://hub.qgis.org/issues/7099) >>> > has >>> > been filed with more details and a accompanying screenshot. >>> >>> Fixed. >>> >>> > 2) There also was a regression in the way vertical spacing is calculate >>> > between layer items and layers. An old issue, 3605, highlighted a >>> > similar >>> > visual problem which was fixed in revision 08c88575 >>> > >>> > >>> > (http://hub.qgis.org/projects/quantum-gis/repository/revisions/08c885759bd280339605ea07a221ab20f7dfdb75/diff/). >>> > Long story short, layers with no titles are often used as part of a >>> > group of >>> > layer items. As such, the solution found in the cited revision was to >>> > take >>> > into account the layer item vertical spacing to the layer vertical >>> > spacing. >>> > The multicolumn appear to have regressed this. I can open an issue with >>> > screenshots if necessary. >>> >>> Layers with no titles? Is it a hack to avoid the layer title to be >>> drawn in the legend for single symbol layers? Wouldn't it be better to >>> modify composer legend so that single symbol layers will be drawn >>> without separated layer title above symbol and the layer title text >>> will be used as the symbol label? >>> >>> Radim >>> >>> > Mathieu >>> > >>> > >>> > On Sun, Nov 18, 2012 at 12:10 AM, Radim Blazek <[hidden email]> >>> > wrote: >>> >> >>> >> On Wed, Nov 14, 2012 at 11:11 AM, Andreas Neumann <[hidden email]> >>> >> wrote: >>> >> > Hi, >>> >> > >>> >> > Thanks to Radim we now have multi-column legends in print composer. >>> >> >>> >> Thanks to Régis and Agence de l'eau Adour as it was already mentioned >>> >> by >>> >> others. >>> >> >>> >> > This >>> >> > was one of my long-time feature requests - but it never got to the >>> >> > top >>> >> > of my requests so that we could pay for the work. >>> >> > >>> >> > Generally it works great, but I noticed two strange behaviors: >>> >> > >>> >> > * when having only one column (default) - the background rectangle >>> >> > is >>> >> > way too small, not covering the full bouding box of the legend >>> >> >>> >> Width? Fixed. >>> >> >>> >> > * when going beyong 4 columns, QGIS gets really slow, hangs or >>> >> > crashes. >>> >> >>> >> Splitting of layers into columns is not that easy as it seems to be. >>> >> It is a special sort of bin packing problem (NP-hard). Maybe it has >>> >> its own name? I have used brute force because: >>> >> - I thought that the number of layer will never be too big >>> >> - implementaion of heuristic algorithm for such a marginal feature >>> >> seemed to be overkill >>> >> - suboptimal solution could look quite bad >>> >> >>> >> You proved immediately that I was wrong. How many layers do you have? >>> >> 70 I have read somewhere? My original idea was to calculate number of >>> >> possibilities first and decide if heuristic should be used. Now it >>> >> seems a necessity. >>> >> >>> >> Maybe I am wrong and there is a simple solution? Well, I did not know >>> >> at the beginning that I am going to solve combinatorial exercises. >>> >> >>> >> Regarding the crash, I was quite careful, using value() where there >>> >> was minimum suspicion that it could run out of range. Many >>> >> combinations should not mean allocation of a lot of memory, just more >>> >> computational time. Only one combination is always evaluated at time. >>> >> Does it seem to be a memory allocation problem or out of list bounds? >>> >> Could you send me backtrace off list? >>> >> >>> >> Please follow/comment http://hub.qgis.org/issues/1841 >>> >> >>> >> Radim >>> >> >>> >> > Did other test the new multicolumn legends? >>> >> > >>> >> > Thanks Radim for your work! >>> >> > >>> >> > Andreas >>> >> > _______________________________________________ >>> >> > Qgis-developer mailing list >>> >> > [hidden email] >>> >> > http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >> _______________________________________________ >>> >> Qgis-developer mailing list >>> >> [hidden email] >>> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> > >>> > >> >> > > _______________________________________________ > Qgis-developer mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/qgis-developer > > ________________________________ > > If you reply to this email, your message will be added to the discussion > below: > > http://osgeo-org.1560.n6.nabble.com/Multicolumn-legends-in-print-composer-tp5016207p5040281.html > > To unsubscribe from Multicolumn legends in print composer, click here. > NAML > > > ________________________________ > View this message in context: RE: Multicolumn legends in print composer > > Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. > > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer > _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
