PS: assuming the QEP will be accepted... Il 13/nov/2014 00:05 "G. Allegri" <gioha...@gmail.com> 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" <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