[Qgis-developer] Can we remove old labeling from the UI

Sun Jun 9 13:31:18 PDT 2013

Hi,

On Sun, Jun 9, 2013 at 11:28 AM, Tim Sutton <lists at linfiniti.com> wrote:

> Hi
>
> I also think we should hide the old labelling dialog. I think Larry
> was working on migration logic that would allow old labels to be
> converted to new. I cant remember if he kept this back for 2.1 though.
> Assuming its not ready, we should follow Nathan's suggestion of hiding
> the old labels tab unless the project file indicates it is needed.
>

I think the following need addressed before old labeling can be removed:

1) Method to do quick labeling (i.e., maybe bypass PAL's candidate creation
and collision management).

As Borys pointed out, this is very important, even if not 'pretty,' for
quick visualization of data. There are a couple of ways doing this that I
see:

1a) Remove old labeling GUI, but *not* its functionality for 2.0 release.
Instead, update the new GUI components to also be an interface for
configuring old labeling, with a single parent combobox (a la symbology) to
switch between Simple and Advanced. Then for 2.1, find a way to accomplish
1b). From the user's standpoint, the GUI doesn't necessarily change in this
regard, i.e. there remains a 'simple' labeling option for layers.

1b) Update QgsPalLabeling/QgsPalLayerSettings and PAL to allow some form of
bypassing of PAL, i.e. mimic old labeling's direct-to-paint text drawing,
to offer a 'simple' labeling mode. GUI would then be updated to offer a
'simple' GUI mode as noted in 1a). Updating old projects is required, and
old labeling can be totally dropped.

1c) Figure out the absolute fastest current settings to use to migrate old
labeling over to. Do 2) and remove old labeling. Still introduce a 'simple'
labeling mode, but it will not be as fast as old labeling until 1b) is
implemented.

1d) Show old labeling dialog, when project uses it.

Any other options for 1) anyone can think of?

2) Migration routine for projects <= 1.8 to similar 'simple' drawing setup.
For 1a) this would be done at the GUI-level. For 1b) and 1c) this means
creating a migration routine to permanently move those old settings to
new-style labeling (I have not worked on this yet).

My feelings/opinions for 1) and 2) are:

Having a 'Simple,' fast labeling mode will always have its advantages,
regardless of how the labels are actually rendered by the backend, and
especially as labeling becomes even more advanced and possibly even slower.
The simple mode could just be a GUI filter that removes all but options
similar to old labeling: text, buffer, and point-only placement. Behind the
scenes, the method of painting the labels could eventually involve PAL, but
probably initially just paint as per old labeling, under Advanced labeling
(as is the case now).

Such a 'simple' mode should probably be the default when going to Vector
Layer Properties -> Labels. Then, users can reasonably expect, or be
appropriately warned, that Advanced options may be slower.

Option 1a) preserves old labeling speed and much of its GUI work is not
necessarily a dead end, but it does postpone the removal of old labeling
(which shouldn't happen unless there is an equal replacement, right?). 2)
migration to labeling-ng settings could still happen and the changes shown
to user could still appear to have removed old labeling.

Option 1b) should be done, regardless. If done now, 2) is more of a
permanent update process, rather than also having to do more in 2.1
release. This option will take the most time and it will require an unknown
delay to 2.0 release, though maybe needs at least a week.

Option 1c) will result in unhappy users, especially on older hardware.
Marco H's, and any further, PAL optimizations will definitely help here.

Option 1d) the easiest for 2.0 release, but pushes issue of removal of old
labeling to 2.1, and (probably?) defaults to not using a fast labeling
method for new projects, unless optimizations are done.

I would appreciate any PSC guidance, and any developer help, with regards
to this 2.0 release issue.

3) Painting of text so that vector exports preserve text as text [0].

This is an important feature of old labeling that needs to exist in new
labeling if old is to be removed. I have worked on this and have it
exporting text again to SVG and PDF, though some issues with scale and
resolution remain. Need to finish what I am currently working on first (see
below).

> PS optimisation wise couldnt we just have a 'quick' mode that draws a
> maximum of n labels pre render?
>

This was recently suggested here as well [1]. I see it as working like so:

* Divide number of to-be-labeled layers into desired absolute label limit.
* Set each layer's 'Number of features to label..' limit to the new
absolute per-layer amount, unless it is already set lower.
* Maybe introduce a fast means of randomly choosing which features get
labeled (a bit tricky because layers are labeled sequentially).

I think this should be on by default, and set to a reasonable limit
(5000?), then the user can change it later, as a per-app and per-project
setting. A message log notice can also be generated when the limit is
reached.

What I am currently working on for labeling:

Fix for issue #8003, "Font is not written to table when using change label
properties tool" [2]. Along the way to fixing that, I found a nasty
undocumented bug that accidentally allowed font substitutions (when defined
font is missing) to be saved to project. So, I've finally added
notifications to the user when a substitution has occurred.

Then, on to a serious attempt at finishing 3) [0]. Then, work on 1) and 2).
Any help greatly appreciated, especially since my wife could have our
second child any day now.  :^)

[0] http://hub.qgis.org/issues/3975
[1] http://hub.qgis.org/issues/4791#note-20
[2] http://hub.qgis.org/issues/8003

Regards,

Larry

> Regards
>
> Tim
>
> On Sun, Jun 9, 2013 at 2:36 PM, Andreas Neumann <a.neumann at carto.net>
> wrote:
> > Marco Hugentobler is currently working on optimizing the labeling of
> > area features. Because it is feature-freeze I don't know if this will be
> > added to 2.0 or delayed for 2.1 - maybe the PSC can make a decision
> > about this.
> >
> > Personally I would recommend to get rid of the old labeling now.
> >
> > Andreas
> >
> > Am 09.06.2013 12:47, schrieb Borys Jurgiel:
> >> The only thing I *REALLY* miss in the new labelling is an optional FAST
> method
> >> to put labels just in poligon centroids with ommiting any expensive
> collision
> >> algorithms. When just browsing data the speed is priority, I don't need
> >> beautiful map, I need to FAST put ANY labels to see what is in polygons.
> >>
> >> Unless it's not available in the new labelling, we make a regression,
> removing
> >> one of the most fundamental features. Please correct me if I'm missed
> some PAL
> >> option that I can disable to achieve a significant boost.
> >>
> >>
> >> Dnia niedziela, 9 czerwca 2013 o 12:13:01 MORREALE Jean Roc napisał(a):
> >>> What is the status ? Are we going to keep a deprecated label tab for
> the
> >>> next 3 years ?
> >>>
> >>> Le 26/05/2013 14:37, Nathan Woodrow a écrit :
> >>>> Can we finally remove the old label UI from the layer properties
> dialog?
> >>>>
> >>>>   Could we remove it by default and just enable it for old project
> that
> >>>>
> >>>> have old labels defined.
> >>>>
> >>>> - Nathan
> >>>
> >>> _______________________________________________
> >>> Qgis-developer mailing list
> >>> Qgis-developer at lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> _______________________________________________
> >> Qgis-developer mailing list
> >> Qgis-developer at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
> ==============================================
> Please do not email me off-list with technical
> support questions. Using the lists will gain
> more exposure for your issues and the knowledge
> surrounding your issue will be shared with all.
>
> Visit http://linfiniti.com to find out about:
>  * QGIS programming and support services
>  * Mapserver and PostGIS based hosting plans
>  * FOSS Consulting Services
> Skype: timlinux
> Irc: timlinux on #qgis at freenode.net
> ==============================================
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130609/ec7f1beb/attachment.html>