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

[Inge Wallin]

On Sunday, February 17, 2013 23:00:46 Friedrich W. H. Kossebau wrote:
> Hi,
> 
> I am looking currently into proper packaging of Calligra Active. And would
> propose that we redo the flags which control when Calligra Active is build.
> 
> Calligra Active related requirements:
> a) Packagers should have a simple flag/way to build exlusively
> CalligraActive and everything that is useful for that (currently the part
> libs of Sheets, Stage, Words + all the related filters and the
> thumbnailers)
> b) CalligraActive should be optionally also flagged for build in parallel
> with the "normal" program(shell)s of Sheets, Stage & Words.

Agreed.

> Requirement a) will make packagers of PlasmaActive-centered distris happy,
> as they do not need the QWidget-based shells at all. Requirement b) is for
> other packagers who would like to make their users CalligraActive available
> as well, and also for developers who do not want to maintain two separate
> builds just to also develop CalligraActive next to the old-fashioned
> programs. Currently one needs to patch the CMakeLists.txt to have
> CalligraActive built with everything else.
> 
> So the build system needs to be aware that all of Sheets, Stage & Words is
> composed from two things, the core (part) and the shell/app.

And the other apps too, presumably.  But it's not as easy as that, 
unfortunately. The core also contains lots of stuff that is only needed in 
QWidget environments. Just take a look at libs/widgets and the fact that shape 
tools can create a QWidget based tool option widget. QWidget is everywhere.

> Currently CalligraActive is only build in TINY build set. TINY also limits
> the filters which are installed. What is the purpose of TINY? Who is known
> to use TINY? Could it perhaps be removed, or rather changed to ACTIVEONLY?

TINY was originally created for Calligra Mobile. The name comes from the fact 
that it is supposed to work in a tiny environment with little memory. It was 
designed to work with a stripped-down version of kdelibs which we created for 
the Nokia N900 environment. TINY contains a minimal set of the apps and filters 
and I'm not sure it even carries all shapes and plugins either.

So TINY is perhaps a good way to build Calligra Active but since tablets have 
much more memory than old smartphones I think we should make building Active 
not dependent on TINY. They are in some ways orthogonal to each other.

> One thing that also seems strange to me is that the executables are also
> done in the parts/ subdirs for most programs. What about splitting that out
> into a sibling app/ subdir? Would help with structure

For the short term, talk with Boud.  He is refactoring these parts.

For the long term I had a suggestion for last year's Calligra sprint to 
separate the cores (which I call the Calligra Office Engine) from the shells. 
The directory structure could be something like:

calligra/
  -- core/
       -- libs/
       -- plugins/
       -- words/     <--- Here is the part of each app that is common to all 
UI's
       -- stage/
       -- ...
  applications/
       -- desktop/
           -- words/
           -- stage/
          ...
      - active
           -- words/
           ...

I have a real proposal somewhere. If you are interested I can dig it up so we 
can talk about it at the sprint.

> And I would also ask to move Author out of its ambush and give it a full
> real toplevel dir, to reduce the complexity in dir layout. Or is there any
> real need to have it there? Now it even has an icon ;), no need to be shy
> and hide. And time for an own SHOULD_BUILD_AUTHOR.

No need at all except that we then have to take out some common parts of the 
current Words code and make a library out of it. Author does have very much in 
common with Words, especially code wise. It is actually my long-term goal to 
do what you suggest, but there was no time to do it before 2.6. I'd appreciate 
all the help I can get there.

> 
> 
> My current plan:
> 1) move Author files into toplevel dir author/ with usual subdirs (still
> controlled by SHOULD_BUILD_WORDS at this point)

You can use the same linking hack that we do now and just recompile all 
necessary files in words/part two times.

> 2) split program/executable/shell related files of Sheets,Stage,Words from
> the part/ subdir into a sibling app/

I'm all for it but I fear that it will be trickier than you think.

> 3) add SHOULD_BUILD_{SHEETS,STAGE,WORDS}_COREONLY, to be used when
> SHOULD_BUILD_{SHEETS,STAGE,WORDS,AUTHOR) is set to true (also introduce
> SHOULD_BUILD_AUTHOR here)

Great

> 4) turn TINY into ACTIVEONLY, there set
> SHOULD_BUILD_{SHEETS,STAGE,WORDS}_COREONLY to true, and remove any TINY-
> related build restrictions in the filters (but not elsewhere)

There could be a meta SHOULD_BUILD_ACTIVEONLY that sets the appropriate 
SHOULD_BUILD_*_CORE. But I think that TINY should be kept since it has a 
different purpose.

> 5) add ALLANDACTIVE flag to have everything including the Active stuff built

Well, SHOULD_BUILD_ACTIVE could be individually set if you make 
SHOULD_BUILD_ACTIVEONLY a meta option.

> I would do separate patches for 1) and 2). The rest, 3),4),5), should be
> doable in one patch without losing overview.
> 
> What do you think? Suggestions, improvements? ... What, flames? :)

No flames because I love it, but there are hidden pitfalls. Tread with care.

	-Inge


> Cheers, good night
> Friedrich+