Re: [Qgis-developer] [Qgis-tr] size of translations, use a distinct repo?
Hi Werner, On Tue, 11. Nov 2014 at 23:24:07 +0100, Werner Macho wrote: > Sounds like a reasonable idea to me, if the translations will be in > nightly I've got no problem (and I also think that the translators > don't have any). For people compiling out of sources it shouldn't be > any problem to pull from transifex either and compile. If I update qgis_en.ts the usual way, there are now differences (e.g. ' instead of '). Looks like qgis_en.ts was pulled from transifex. Is that necessary for anything? And how does transifex handle changes like that? On second thought do we need a uptodate qgis_en.ts in our repository at all? QGIS doesn't use it - it's only there for transifex to watch. Instead of updating and commiting it in the source repository (and see lots of otherwise useless changes) we could simply have update_ts_files.sh pull it from transifex, update it with the latest source changes and push it back. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS release manager (PSC) GermanyIRC: jef on FreeNode signature.asc Description: Digital signature ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-tr] size of translations, use a distinct repo?
Hi Jürgen! I am not sure what are you aiming at, but yes - we could do it that way too. As long as QGIS does not use qgis_en.ts we could just tx pull it - update it and tx push it back to transifex. (And forget about it in the source tree). The same way we could do it with all the translations.. pulling the right in front of a compile run and forget about them afterwards and only commit them right in front of a branching the release branch. As I said - as long as translations can be considered to be in the nightly build I am confident that people compiling QGIS on their own can also pull translations before they build. The only problem I see is when nightly is not updating translations and people cannot see their translations (and possibly adjust it). (This only because I sometimes got asked about updating the languages in the source tree so that translators can see the work before it is getting "released") If I am getting you correct we could update the i18n directory only once per release. Is this what you are aiming for? kind regards Werner On Wed, Nov 12, 2014 at 9:31 AM, Jürgen E. wrote: > Hi Werner, > > On Tue, 11. Nov 2014 at 23:24:07 +0100, Werner Macho wrote: >> Sounds like a reasonable idea to me, if the translations will be in >> nightly I've got no problem (and I also think that the translators >> don't have any). For people compiling out of sources it shouldn't be >> any problem to pull from transifex either and compile. > > If I update qgis_en.ts the usual way, there are now differences (e.g. ' > instead of '). Looks like qgis_en.ts was pulled from transifex. Is that > necessary for anything? And how does transifex handle changes like that? > > On second thought do we need a uptodate qgis_en.ts in our repository at all? > QGIS doesn't use it - it's only there for transifex to watch. > > Instead of updating and commiting it in the source repository (and see lots of > otherwise useless changes) we could simply have update_ts_files.sh pull it > from > transifex, update it with the latest source changes and push it back. > > > Jürgen > > -- > Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 > Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 > Software Engineer D-26506 Norden http://www.norbit.de > QGIS release manager (PSC) GermanyIRC: jef on FreeNode > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQIVAwUBVGMa+xBsJ9SQbsVUAQIbwRAAtuxd3KfMQtBWDm7kYg478kWW9baN4bEe > oTTAst0RzohGrQy9ePN8NQdiWxOzEJih0VnSYoFr9F+6A5eZ2S6IrC6vUUpX0fh6 > 6oTqc0Cxf5GyzGhtMQA1uzLXCjXRLJkEGrylTpC1MvhVzsiRxSj7hCJdEEAzJOKt > rybxf9Gtb7QSxAT2DNedmYPhfPpRzvcTB/JruDSjExHFxH7cH11iQpnhPv06+YVG > 1MTQXIRuNQnMYhPj4MXqSbTzOhH/YcDfgf62k2RnKWhszzcLWIXBVz/m9Wl1gKXJ > J0uNQYX9DKH1PbxR/HQ+GYxdX5/4NPEaM2T/mOGewWgVH0x79FX/3jFzvIhMrXJd > 7yFFkWBlHpf8Ish0XoTaf5NbiH8Kha1DZsiXFwqh0tZOazuxRdoQC+WZ9Kg/0ESQ > /jZe/eWP7/k7Kh9t2QOnJ7iqoqaK8hEdwHjC6MUece4CO8fmj+1SIS+xcb56ILK8 > dmP07G43mkWcnD7Dc25x6/bDB+hjCtMqkbDrBUtmpR4SJMHfJ7crIiQbiuslrHPe > 56MFXud5dY8ykjY0Z0ELZ2XFPaenMLbAu0sUd1DbLi8vyeo8kY4oOeleuFp50Y+x > hHy45bkc1hRlVNrHSHmZjhBJQ+sp0X/N4S7r6RlxkXsWkqx5Kly76lzMM4TVoDBk > Tk8OTIGhSwk= > =YvwM > -END PGP SIGNATURE- > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] "case sensitive" in filter legend
Hi all, just a question. Why is the "case sensitive" checkbox automatically toggled in the filter legend? IMHO is quite confusing and should be toggled if one want to. Cheers Matteo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QEP/RFC sqlite virtual tables
Hi Martin, Le 08/11/2014 07:06, Martin Dobias a écrit : > Hi Hugo > > On Tue, Nov 4, 2014 at 8:36 PM, Hugo Mercier > wrote: >> >> * About indexes on virtual tables, contrary to what I wrote previously, >> the xBestIndex() method of virtual tables should be enough to orient the >> planner, an estimated cost and estimated number of rows can be returned >> for each part of the where clause. So there should be no need to copy >> native indexes. >> But the provider interface should be extended in order to provide such >> statistics. > > I am trying to figure out how the things would work... > > How would you decide whether to copy native index of a virtual table? > (Always?) E.g. pkey at least in Postgres is also index - shall we > always copy it? > When would you make copies of native indexes? (When constructing the > provider? On every getFeatures() call?) > How would you keep the index up to date? (Table may change outside of QGIS) > > What I want to understand is how SQL select statements would execute - > like the one with join filter you need: > > SELECT * FROM tblA LEFT JOIN tblB ON tblA.X = tblB.Y WHERE tblY.Z = 42 > The idea is precisely to avoid copy of native indexes. With this example query, the virtual table implementation of tblA and tblB will be called (xBestIndex) twice : once with and once without constraints : * X = ? on tblA * Y = ? AND Z = ? on tblB If you know there is a native index on tblA(X) then you will return a cost for this constraint that is inferior to the cost needed without constraint (a seq scan). The planner will decide what to do based on these costs. Some discussion here : http://osdir.com/ml/sqlite-dev/2014-11/msg3.html For spatial indexes this is still possible (to avoid copy of native indexes), but would require to introduce some new syntax to translate the spatial predicate into regular comparison operators. See here : https://www.mail-archive.com/sqlite-users@sqlite.org/msg87191.html ... so for spatial indexes some additional SQL must be generated from QGIS (but it is already the case if we want to avoid the spatialite index syntax) >> We are willing to develop this as a plugin if it can be included in QGIS >> as a c++ plugin. Is there any objection to this ? > > Personally I do not see much difference in having some functionality > in 'core' and having some functionality in c++ plugin (included in > QGIS tree) - in both cases that requires us to maintain such code once > it is added... > > Why not develop a prototype that does not require QGIS code - I guess > the only QGIS-specific part is the virtual table implementation. Such > prototype could eventually evolve to a standalone library providing > SQL parser / execute engine with a nice interface... > Ok. It means the optimization part (accessing costs of the native indexes for example, as discussed above) cannot be demonstrated yet with such an external prototype, because it would require to modify providers' interface in the core. But it does not prevent the plugin / library to take them into account. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] "case sensitive" in filter legend
+1 , very confusing for me too -- View this message in context: http://osgeo-org.1560.x6.nabble.com/case-sensitive-in-filter-legend-tp5172501p5172523.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Georeferencer - QGIS master
Hi all, loading in the georeferencer a coloured jpg (clipped aerophoto) it is shown as black or fuzzy coloured image. any known issue? furthermore, as reported in other tickets (10018 and 10459), georeferencing an image it doesn't load in the main canvas when finished or any window opens to say "done". is it normal behaviour? all the best, Nic (win 8.1, QGIS master from osgeo 64bit) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Composer Legend API
Hi All,
QGIS 2.6 has surely a lot of improvement on composer, but I find myself
stuck on a simple problem on composer legend manipulation. Instead of
showing from all the layers, I want to just show a specific layer. This is
a simple code that you can run in QGIS Python Console:
from qgis.core import QgsComposition, QgsLayerTreeGroup
> from PyQt4 import QtXml, QtCore
>
> canvas = iface.mapCanvas()
> renderer = canvas.mapRenderer()
> composition = QgsComposition(renderer)
>
> composer = iface.createNewComposer()
> composer.setComposition(composition)
>
> template_file = QtCore.QFile('/tmp/inasafe-portrait-a4.qpt')
> template_file.open(QtCore.QIODevice.ReadOnly | QtCore.QIODevice.Text)
> template_content = template_file.readAll()
> template_file.close()
>
> document = QtXml.QDomDocument()
> document.setContent(template_content)
>
> status_load = composition.loadFromTemplate(document)
>
> legend = composition.getComposerItemById('impact-legend')
> legend.setTitle('Hoho')
>
> group = QgsLayerTreeGroup()
> group.addLayer(iface.activeLayer())
>
> # 1 Somehow crashes QGIS in inasafe, but not in qgis console
> #legend.modelV2().setRootGroup(group)
> #legend.synchronizeWithModel()
>
> # 2 No effect on legend, sigh
> #legend.model().setLayerSetAndGroups(group)
> #legend.synchronizeWithModel()
>
> # 3 No effect on legend, sigh. Using QgsLegendModel basically obsolete in
> 2.6, not deprecated
> #legend.model().setLayerSet(iface.activeLayer().id())
> #legend.synchronizeWithModel()
>
> # 4 Unfortunately setCustomLayerTree is private method
> #legend.setCustomLayerTree(group)
> #legend.synchronizeWithModel()
> #
>
> # 5 legendmodel linked directly to layer registry in map canvas, so this
> will delete layer in canvas
> #legend.updateLegend()
> #model = legend.modelV2()
> #for r in range(0, model.rowCount()):
> #for c in range(0, model.columnCount()):
> #if model.index(r, c).data() != iface.activeLayer().name():
> #model.removeRows(r, 1)
> #legend.synchronizeWithModel()
>
> composition.exportAsPDF('/tmp/result.pdf')
>
I have tried several possibilities to do that by going through the c++ code
itself. The 1st possibility above is working fine actually in python
console, but somehow it crashes QGIS implementing it in the plugin. The 2nd
and 3rd are giving no effect (It says the QgsLegendModel deprecated, but if
it's not working, shouldn't it say obsolete?). The method
setCustomlayerTree in the 4th unfortunately not available in the SIP. The
5th will delete layer in map canvas.
>From those 5 possibilities, is there any other way to do this simple task?
Regards
--
*---*
*Akbar Gumbira*
*Software Engineer*
*Geospatial, NLP, Data Mining, Machine Learning, Artificial Intelligence*
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] 2.6.1 Windows patch?
Hey, Mainly for Jurgen. Is there any possibility of getting a patched 2.6.1 into the Windows installers and binaries. The bug that Martin fixed just after release that corrupted project files is a pretty nasty one that I think could do with a patched 2.6.1 if we can. Pretty please... Regards, Nathan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 2.6.1 Windows patch?
On Wed, Nov 12, 2014 at 12:00 PM, Nathan Woodrow wrote: > Hey, > > Mainly for Jurgen. Is there any possibility of getting a patched 2.6.1 into > the Windows installers and binaries. The bug that Martin fixed just after > release that corrupted project files is a pretty nasty one that I think > could do with a patched 2.6.1 if we can. +1 for me ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 2.6.1 Windows patch?
Hi Nathan, which ticket are you refering to? I was about to roll out QGIS 2.6 for Windows (both 32 and 64 bit). thanks Bernhard Am 12.11.2014 12:00, schrieb Nathan Woodrow: Hey, Mainly for Jurgen. Is there any possibility of getting a patched 2.6.1 into the Windows installers and binaries. The bug that Martin fixed just after release that corrupted project files is a pretty nasty one that I think could do with a patched 2.6.1 if we can. Pretty please... Regards, Nathan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer __ Information from ESET Mail Security, version of virus signature database 10711 (20141112) __ The message was checked by ESET Mail Security. http://www.eset.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] "case sensitive" in filter legend
should I open a ticket for this? any other opinion? 2014-11-12 11:07 GMT+01:00 Régis Haubourg : > +1 , very confusing for me too > > > > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/case-sensitive-in-filter-legend-tp5172501p5172523.html > Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] "case sensitive" in filter legend
On Wed, Nov 12, 2014 at 12:18 PM, Matteo Ghetta wrote: > should I open a ticket for this? +1 Best wishes, Anita > any other opinion? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QGis Server: obtaining the geometry of the identified feature?
Hi, using the Identify button I can show the popup with the feature fields. It is possibile to obtaing the geometry (i.e. in the format of WKT) of that feature? I would add a link with the geometry of identified feature. Thank you in advance :-) Luca ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGis Server: obtaining the geometry of the identified feature?
Hi, Yes - QGIS Server can output the WKT geometry if you enable the checkbox in "Add geometry to feature response" (in Project properties, OWS Server tab). Andreas On 12.11.2014 15:21, Luca Manganelli wrote: Hi, using the Identify button I can show the popup with the feature fields. It is possibile to obtaing the geometry (i.e. in the format of WKT) of that feature? I would add a link with the geometry of identified feature. Thank you in advance :-) Luca ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 2.6.1 Windows patch?
Hi Bernhard, I believe it's this conversation: http://lists.osgeo.org/pipermail/qgis-developer/2014-November/035492.html - and this ticket: http://hub.qgis.org/issues/11592 --- I think this is a good test of the maturity of the QGIS project; a release has been made which has a significant regression that means opening historical projects not only crashes QGIS in some instances (very bad), but can also *overwrite* and thus corrupt the project file resulting in data loss for the end user. If that doesn't warrant a timely emergency hotfix I don't know what does. As it stands I'd be surprised if there isn't ongoing data-loss from early-adopters. :-( Cheers, Jonathan -Original Message- From: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Bernhard Ströbl Sent: Wednesday, November 12, 2014 11:17 AM To: qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] 2.6.1 Windows patch? Hi Nathan, which ticket are you refering to? I was about to roll out QGIS 2.6 for Windows (both 32 and 64 bit). thanks Bernhard Am 12.11.2014 12:00, schrieb Nathan Woodrow: > Hey, > > Mainly for Jurgen. Is there any possibility of getting a patched > 2.6.1 into the Windows installers and binaries. The bug that Martin > fixed just after release that corrupted project files is a pretty > nasty one that I think could do with a patched 2.6.1 if we can. > > Pretty please... > > Regards, > Nathan > > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > > __ Information from ESET Mail Security, version of virus signature database 10711 (20141112) __ The message was checked by ESET Mail Security. http://www.eset.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer This message has been scanned for viruses by MailControl - www.mailcontrol.com Click https://www.mailcontrol.com/sr/u2otVfl3jp7GX2PQPOmvUizKrmxxhcEG6k4vv+L2k850nqTLme8L4cgt!bBGUvwPDZBLv8O0BTT1VsBVsOva5A== to report this email as spam. HR Wallingford and its subsidiaries uses faxes and emails for confidential and legally privileged business communications. They do not of themselves create legal commitments. Disclosure to parties other than addressees requires our specific consent. We are not liable for unauthorised disclosures nor reliance upon them. If you have received this message in error please advise us immediately and destroy all copies of it. HR Wallingford Limited Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom Registered in England No. 02562099 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Composer... current status and the way forward?
I'm not sure about the final scheduling for the composer refactoring. Following the discussions about LTS and QGIS 3.0 will it be shifted to 3.0? giovanni Il 11/nov/2014 21:20 "Olivier Dalang" ha scritto: > I just checked, there's a rich text example for Qt5 : > http://qt-project.org/doc/qt-5/qtwidgets-richtext-textedit-example.html > > I guess it's also doable with Qt4, since the QTextEdit widget already > works with HTML, but the provided examples are not exactly a wysiwyg editor. > http://qt-project.org/doc/qt-4.8/examples-richtext.html > > However, TinyMCE is also nice, especially since it allows to work easily > on the underlying HTML, so it's even useful for power users. I'd love to > give it a shot but I'm really not enough at ease with C++ to do more than > copy/paste some lines of code. > > > And about the live templates, the nice thing of overrides is for instance > when you have several thematic maps, and want the same layout for all those > (same map extent, same position of the legend, etc.). You can update all of > those at once. I don't know for you, but I have more than one layout in > almost all of my projects. > A good practice is to have a general master defining the very static > elements (company logo, guides for margins...) in all of your projects, and > several other masters dependent of every project that inherit the general > master (for instance one where you display a big map and a small overview, > one with two maps side by side, ...). This way, you can simply reimport > your company template in the general master, and have all your project's > layout update. Still, you're able to reopen old projects without having > them automatically modified. > > > Olivier > > > 2014-11-11 20:57 GMT+01:00 Andreas Neumann : > >> Hi Olivier, >> >> Regarding HTML editor: >> I very briefly discussed this with Nyall (and got an offer to do it)). I >> proposed to embed a Javascript based HTML editor (like TinyMCE (LGPL)). >> However, Nyall is probably now busy with composer/report builder. So it >> would probably be ok, if someone else works on this. I would also like to >> see this HTML editor in a text area widget - so people could write rich >> text in an attribute form. Maybe there is also a qt-based rich text widget >> we could use? >> >> Regarding live templates: >> I was hoping for a global live template that I could link into many >> projects. Otherwise it wouldn't help me much. On the other hand I don't >> need the overrides (maybe only the map title). I would only put fixed >> content in the live templates that needs to be on every print out (like >> company logo, print date, disclaimer, contact information, etc.). However, >> maybe one day I would need the overrides - one never knows ;-) >> >> Andreas >> >> >> >> >> On 11.11.2014 12:46, Olivier Dalang wrote: >> >> Hi, >> >> >> Another thing which deserves some work IMO is the text boxes : either >> you have to write HTML, or you're limited to 1 font/color/size per text >> box. Even if it's not really linked to the global structure of the >> composer, an improvement on this would have great impact on usability. >> >> There must be some lightweight wysiwyg html editor library hat we could >> use ? Ideally it should implement styles that you can apply throughout a >> project (probably through css classes, but I have the feeling someone >> already talked about this idea ?). >> >> >> And more about the live templates idea (if it's too much of a thread >> hijacking please start another one) : >> >> Maybe to avoid confusion between templates and live templates, we could >> call the live templates "masters" ? That's how they are called in Adobe >> Indesign (which is probably the most polished layouting software around). >> >> http://helpx.adobe.com/indesign/using/master-pages.html >> >> The thing Indesign isn't not doing well IMO is overrides : it involves >> an awkward keyboard shortcut and it's hard to know what exactly is >> overridden and what's not (what element, and what part of the element). >> The property system you're mentioning would probably be an excellent >> thing to manage inheritance. >> >> And then, there's a question about whether the masters are global or >> per-project. >> The problem with global masters is that you can have effects on other >> files without knowing it, and also that projects may display differently on >> different setups. I think we should only have per-project masters. >> And updating a project's layouts only involves reimporting the main >> master once (that may be a bit tricky though if we want to keep overrides, >> but using composer's items UUIDs we may make it work for some simple cases). >> >> >> Thanks a lot for those bigger refactoring initiatives ! >> >> Olivier >> >> >> >> 2014-11-11 10:52 GMT+01:00 Andreas Neumann : >> >>> Hi, >>> >>> It would be very awesome to have live-linked templates! I would very >>> much need them. I have a lot of operational projects and it is my fear that >
Re: [Qgis-developer] Composer... current status and the way forward?
PS: assuming the QEP will be accepted... Il 13/nov/2014 00:05 "G. Allegri" ha scritto: > I'm not sure about the final scheduling for the composer refactoring. > Following the discussions about LTS and QGIS 3.0 will it be shifted to 3.0? > > giovanni > Il 11/nov/2014 21:20 "Olivier Dalang" ha > scritto: > >> I just checked, there's a rich text example for Qt5 : >> http://qt-project.org/doc/qt-5/qtwidgets-richtext-textedit-example.html >> >> I guess it's also doable with Qt4, since the QTextEdit widget already >> works with HTML, but the provided examples are not exactly a wysiwyg editor. >> http://qt-project.org/doc/qt-4.8/examples-richtext.html >> >> However, TinyMCE is also nice, especially since it allows to work easily >> on the underlying HTML, so it's even useful for power users. I'd love to >> give it a shot but I'm really not enough at ease with C++ to do more than >> copy/paste some lines of code. >> >> >> And about the live templates, the nice thing of overrides is for instance >> when you have several thematic maps, and want the same layout for all those >> (same map extent, same position of the legend, etc.). You can update all of >> those at once. I don't know for you, but I have more than one layout in >> almost all of my projects. >> A good practice is to have a general master defining the very static >> elements (company logo, guides for margins...) in all of your projects, and >> several other masters dependent of every project that inherit the general >> master (for instance one where you display a big map and a small overview, >> one with two maps side by side, ...). This way, you can simply reimport >> your company template in the general master, and have all your project's >> layout update. Still, you're able to reopen old projects without having >> them automatically modified. >> >> >> Olivier >> >> >> 2014-11-11 20:57 GMT+01:00 Andreas Neumann : >> >>> Hi Olivier, >>> >>> Regarding HTML editor: >>> I very briefly discussed this with Nyall (and got an offer to do it)). I >>> proposed to embed a Javascript based HTML editor (like TinyMCE (LGPL)). >>> However, Nyall is probably now busy with composer/report builder. So it >>> would probably be ok, if someone else works on this. I would also like to >>> see this HTML editor in a text area widget - so people could write rich >>> text in an attribute form. Maybe there is also a qt-based rich text widget >>> we could use? >>> >>> Regarding live templates: >>> I was hoping for a global live template that I could link into many >>> projects. Otherwise it wouldn't help me much. On the other hand I don't >>> need the overrides (maybe only the map title). I would only put fixed >>> content in the live templates that needs to be on every print out (like >>> company logo, print date, disclaimer, contact information, etc.). However, >>> maybe one day I would need the overrides - one never knows ;-) >>> >>> Andreas >>> >>> >>> >>> >>> On 11.11.2014 12:46, Olivier Dalang wrote: >>> >>> Hi, >>> >>> >>> Another thing which deserves some work IMO is the text boxes : either >>> you have to write HTML, or you're limited to 1 font/color/size per text >>> box. Even if it's not really linked to the global structure of the >>> composer, an improvement on this would have great impact on usability. >>> >>> There must be some lightweight wysiwyg html editor library hat we >>> could use ? Ideally it should implement styles that you can apply >>> throughout a project (probably through css classes, but I have the feeling >>> someone already talked about this idea ?). >>> >>> >>> And more about the live templates idea (if it's too much of a thread >>> hijacking please start another one) : >>> >>> Maybe to avoid confusion between templates and live templates, we >>> could call the live templates "masters" ? That's how they are called in >>> Adobe Indesign (which is probably the most polished layouting software >>> around). >>> >>> http://helpx.adobe.com/indesign/using/master-pages.html >>> >>> The thing Indesign isn't not doing well IMO is overrides : it involves >>> an awkward keyboard shortcut and it's hard to know what exactly is >>> overridden and what's not (what element, and what part of the element). >>> The property system you're mentioning would probably be an excellent >>> thing to manage inheritance. >>> >>> And then, there's a question about whether the masters are global or >>> per-project. >>> The problem with global masters is that you can have effects on other >>> files without knowing it, and also that projects may display differently on >>> different setups. I think we should only have per-project masters. >>> And updating a project's layouts only involves reimporting the main >>> master once (that may be a bit tricky though if we want to keep overrides, >>> but using composer's items UUIDs we may make it work for some simple cases). >>> >>> >>> Thanks a lot for those bigger refactoring initiatives ! >>> >>> Olivier >>> >>> >>> >>> 2014-
