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" <olivier.dal...@gmail.com> 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 <a.neum...@carto.net>: > >> 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 <a.neum...@carto.net>: >> >>> 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 >>> some day some details would change and I need to go into all of the >>> projects and adopt things like logo, fonts, headers, etc. It would either >>> require a script to process the .qgs files or a lot of manual work. >>> >>> So +1 for having live templates. Nyall, maybe you can plan the redesign >>> in a way to make it possible? I would also participate in financing the >>> development of these live templates. >>> >>> Andreas >>> >>> >>> >>> On 07.11.2014 20:10, Olivier Dalang wrote: >>> >>> Hi, >>> >>> I don't get the point in keeping the old classes if we upgrade the >>> composers to layouts at opening ? Doesn't migration happen at XML level ? >>> >>> >>> Maybe while thinking about reworking the composer, we could think >>> about a new feature : real templates (aka "masters" in Indesign). >>> >>> All elements added to a "master" appear on all the page that apply it. >>> This is very handy: you can always edit the master (move some elements, >>> change the fonts/colors, etc.), and the changes are reflected on all the >>> layouts. The challenging part from an UI point of view is the required >>> ability to override the content of templates elements (for instance the >>> extent of a map, the text of a textbox, etc.) >>> >>> I thought of making a plugin for this, but got discouraged because of >>> the problem you exposed... So it would be a good test case to see if the >>> future API for the layouts allows to implement this easily ;) >>> >>> Thanks ! >>> >>> Olivier >>> >>> >>> >>> 2014-11-07 16:26 GMT+01:00 Andreas Neumann <a.neum...@carto.net>: >>> >>>> Hi Nyall, >>>> >>>> I also think that option 2 would work best. Option one would be very >>>> confusing (I remember the days when we had two labeling versions, 2 >>>> symbology versions, etc. - awful!). >>>> >>>> Thanks, >>>> Andreas >>>> >>>> >>>> On 07.11.2014 16:16, G. Allegri wrote: >>>> >>>> Hi Nyall, >>>> as I already told you privately, I agree with the second approach: >>>> remove the current Composer and guarantee transparent auto-upgrade of >>>> existing layouts in projects. >>>> The improvements to the composer worth the effort, and the consequent >>>> visual impact for users. The important thing is to guarantee old projects >>>> to provide the same results (layouts) though, without re-designing them >>>> from the ground. >>>> Having both the old Composer and the new GUI tools would be misleading >>>> and confusing to the users, and I imagine it would double the effort to >>>> mantain both the tools. >>>> >>>> giovanni >>>> >>>> 2014-11-07 12:37 GMT+01:00 Nyall Dawson <nyall.daw...@gmail.com>: >>>> >>>>> Hi all, >>>>> >>>>> I'm seeking feedback about the best way to move forward with QGIS' map >>>>> composer. I'm currently running up against some large issues with the >>>>> current design and API of composer which are holding back important >>>>> features and fixes. Some of these issues include: >>>>> >>>>> - there's too much composer logic tied up in app and gui. This makes >>>>> it very difficult for plugins to manipulate and export compositions >>>>> without duplicating large blocks of code >>>>> - there's too much item-specific logic and handling scattered through >>>>> QgsComposition, QgsComposerView and QgsComposer. This makes it >>>>> impossible to have features like plugin generated item types, and >>>>> makes maintenance difficult. >>>>> - everything is coded to expect measurements and sizes in mm. I can't >>>>> (nicely) add support for other units without breaking api or resorting >>>>> to a lot of hacks >>>>> - same for mixed page sizes and orientations within a single >>>>> composition, this requires an api break to implement cleanly >>>>> - I need to totally break composer api in order to fix the instability >>>>> in undo/redo commands (see http://hub.qgis.org/issues/11371) >>>>> - QgsComposition should not require a QgsMapSettings/QgsMapRenderer. >>>>> This should instead be set individually for map items. Doing so would >>>>> pave the way for features such as reprojection support for individual >>>>> map items. >>>>> - the composer is full is deprecated methods and legacy api >>>>> >>>>> I've slowly come to the conclusion that the way forward is to move to >>>>> a bunch of new classes, much like what was done with symbologyV2. If >>>>> https://github.com/qgis/QGIS-Enhancement-Proposals/pull/9 passes then >>>>> these would be named QgsLayout, QgsLayoutDesigner, etc. If not, well, >>>>> I'll have to resort to QgsCompositionV2, etc. >>>>> >>>>> The potential problem with this approach is how to handle the GUI and >>>>> existing projects. As far as I can see, there's a few options: >>>>> 1. Expose both the existing composer and the new layout designer to >>>>> users. Composers aren't automatically upgraded to layouts. This >>>>> approach means that existing PyQgis code and plugins will still >>>>> function for existing projects, but at the expense of a confusing >>>>> experience for users. >>>>> 2. Add all the new layout classes and keep the existing composer >>>>> classes. Composer would NOT be exposed in the GUI and compositions are >>>>> upgraded to layouts when projects are opened. This approach means that >>>>> standalone python code would still operate, but plugins or code which >>>>> are designed to be run from within QGIS would no longer function. >>>>> 3. Move totally to the new layout classes and remove all composer >>>>> classes (unlikely) >>>>> >>>>> I'm leaning toward option 2, but what are you thoughts? What's the >>>>> best approach to move forward? Obviously I'll submit all this as a QEP >>>>> when the plans are finalised, but for now I'm just after advice on the >>>>> preferred approach. >>>>> >>>>> Nyall >>>>> _______________________________________________ >>>>> Qgis-developer mailing list >>>>> Qgis-developer@lists.osgeo.org >>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>>>> >>>> >>>> >>>> >>>> -- >>>> Giovanni Allegri >>>> http://about.me/giovanniallegri >>>> Twitter: https://twitter.com/_giohappy_ >>>> blog: http://blog.spaziogis.it >>>> GEO+ geomatica in Italia http://bit.ly/GEOplus >>>> >>>> >>>> _______________________________________________ >>>> Qgis-developer mailing >>>> listQgis-developer@lists.osgeo.orghttp://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 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