RFC: Turning flag TINY into ACTIVEONLY, move Author to toplevel dir

Jaroslaw Staniek staniek at kde.org
Tue Feb 19 22:21:23 GMT 2013


On 19 February 2013 23:11, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
> Am Dienstag, 19. Februar 2013, 22:35:19 schrieb Jaroslaw Staniek:
>> On 19 February 2013 22:19, Friedrich W. H. Kossebau <kossebau at kde.org>
> wrote:
>> > Am Dienstag, 19. Februar 2013, 22:07:46 schrieb Inge Wallin:
>> >> Well... not really.  Since Plasma Active is a viewer only only the import
>> >> filters make sense.  ...which suggests another build option: VIEWER.
>> >
>> > But isn't the plan to make it also an editor in the end? If not, where is
>> > the difference to OkularActive or whatever other reader there is for
>> > PlasmaActive?
>> >
>> > Sure, for now ACTIVE_ONLY would limit to import filters, given the needs.
>>
>> Our selling point is modularity, yet the deployment could be improved
>> in some aspects. It would be great to get there also by providing
>> (yes) kernel-like detailed build options, something not present in
>> competing projects.
>> Qt Project is also quite modular if we need examples.
>
> Agreed. A perfect solution would allow the builder to define precisely which
> plugins/filters/modules/apps are to build (and then warn about all which
> cannot due to missings deps), and offer some prepared typical-pattern schemas
> for convenience.
>
> Perhaps a topic for the sprint?


Yes. One thing to think about: BUILD_* variables generated by cmake
are based on the directory name what leads to often not
self-explanatory names. BUILD_words has clear meaning but
BUILD_variables is not if there are more than one 'variables'
directory in the whole calligra. This comes from the way how
macro_optional_add_subdirectory() behaves and could be improved by
adding a way to put extra context information. After that we be would
even able to invent some friendly configurator.

> For now I just want a pragmatic solution for the current known usecases :)
>
>> Enabling VIEWER profile is one of our advantages. Another one apart
>> form single-app-only profiles is: a build without pigment (they are
>> unusable for most Kexi users).
>>
>> For me TINY is somewhat close to what ultimately be called MINIMAL and
>> as such it makes sense as generic template for people playing with
>> their own GUIs.
>
> So MINIMAL in functionality of cores/engines? (current TINY also limited to
> classic MSOFFICE-defined app set, Sheets,Stage&Words)

Works for me!

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek



More information about the calligra-devel mailing list