Re: [Maniphest] [Commented On] T665: Show default (empty) document on startup in document-based Calligra apps

2016-01-18 Thread René J . V . Bertin 
On Monday January 18 2016 12:47:59 C. Boemann wrote:

>Well what you would get is a really empty document then - not pages, no font, 
>no margins, no nothing - all of those decisions is what is stored in a 
>template. Having to code all those decisions just for the sake of not loading 
>a file with those decisions "coded" through a much nice user interface called 
>a 
>wordprocessor is well.. stupid.

I'm not sure I agree. I'm quite sure that in OpenOffice and a few other 
wordprocessors, things like the default styles, page size etc. are configured 
at a different level than the document template (though a template could 
probably override them). I may be wrong, of course, but I'd certainly 
appreciate it if templates have the option to omit specifying things like 
styles and page size so that my own preference in these matters applies.

Anyway, go ahead, forget I made some noises :)

R.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [Maniphest] [Commented On] T665: Show default (empty) document on startup in document-based Calligra apps

2016-01-18 Thread René J . V . Bertin 
On Monday January 18 2016 10:05:32 boemann wrote:

>One thing tohugh - it shouldn't be an empty document - I wan to get away from 
>this  as we need all sorts ofinitial setup, and i want to remove the custom 
>dialog for the same reason - but anyway the default startup document should be 
>the blank template
>
>but as i said i fear it's not such a low hanging fruit at all

I've never understood why applications would ever need an actual on-disk 
template for a blank document. Even without using an OO programming language 
proper initialisation of the internal document structure should give you (wait 
for it) an empty document. 

R.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

State of Proposal to improving KDE Software Repository Organization?

2016-01-18 Thread Friedrich W. H. Kossebau 
Hi,

(calligra-devel, kexi-devel, kimageshop mailinglists only for heads-up,
 please remove from reply, discussion only on kde-core-devel should be fine)

4 months ago there was the thread "Proposal to improving KDE Software 
Repository Organization" on this mailinglist.
What happened to that plan? Are people preparing its execution?

And would that be a time where some bigger reorganization of the repos is 
possible?

Reason that I ask is that due to the split of Calligra into several repos (see 
background^) the layout in the repo structure does no longer properly reflect 
the project organisation. Right now there are three active repos in the 
calligra/ repo substructure:
"calligra" at "calligra/"
"krita"at "calligra/krita"
"kexi" at "calligra/kexi"

(("calligra" at "calligra/" confuses at least kdesrc-build, sent an email to 
mpyne about if moving it to "calligra/calligra" should fix it.))

Things that are not properly matching organization:
* Krita starting with 3.* no longer is part of Calligra project
  (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
  what people think to which project Krita belongs)
* Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
  so no reason to be in a complete own toplevel structure,
  rather should be in the same sub structure, i.e. "Extragear",
  like extragear/calligra/* and extragear/graphics/krita

More, not only Calligra & Krita related:
* "Extragear" is an awful grouping name for apps with individual
  release plans, a legacy term that no longer fits most of the apps
  in that substructure
* "KDE Applications" is a misleading grouping name for apps with a
  central release plan, as if those with individual release plans
  are not "KDE" applications (as in, not done in the KDE community)
* a single category per app as needed by the current tree structure layout
  of the repos, like "office", "graphics", "utils", is rather awkward,
  many apps do not match exactly one or would match multiple categories

So IMHO some update of the repository organisation would be good, to reflect 
how things are these days.
Renaming of "Extragear" and "KDE Applications" is surely something which needs 
care from promo/marketing/VDG people first to find if that makes sense at all 
and what a good solution would be.
(Being both maintainer of Okteta, which is in "KDE Applications", and meta-co-
maintainer of Calligra, which is not, but still done in the very same KDE 
community, that current naming seems so wrong to me).

But the actual names and grouping aside, for the pure technical renewing 
(which also involves all infrastructure like translation system, 
documentation, phabricator, etc), who is currently planning or working on 
what?
So does it makes sense to wait some more, or should we assume the current 
organization stays for longer, and Calligra & Krita repos should be moved 
inside that organization for now?


^Some background about Calligra repo split, as things are slightly 
complicated:

KRITA)  The "krita" repo was split off, because Krita has finally become a 
full project of its own, separate from Calligra. A logical place for the krita 
repo in the KDE repo structure would perhaps have been somewhere in extragear, 
but at least due to the translators preferring to keep the string catalogs of 
Krita in the "calligra" module as before, for less work, the krita repo was 
for now put as submodule of "calligra/".

KEXI)  Kexi continues to be part of the Calligra project/subcommunity, but the 
Kexi developers preferred a small simple repo "kexi" of their own (for build 
time and size). So the placement at "calligra/kexi" makes perfect sense.

OTHERAPPS)  As the other Calligra apps (Braindump, Karbon, Sheets, Words, 
Stage, etc.) are more tightly coupled and the binary interfaces between libs, 
plugins & apps can still change every other week, for now no further repo 
splitting is planned (to ensure atomic commits on API changes), and they all 
stay in the existing "calligra" repo.


Cheers
Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request 126797: Add kexi.git build with deps

2016-01-18 Thread Jarosław Staniek 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126797/
---

(Updated Jan. 18, 2016, 7:42 p.m.)


Review request for Calligra and Ben Cooksley.


Repository: kde-build-metadata


Description
---

Add kexi.git build with deps, minor updates to kexi's deps


Diffs
-

  dependency-data-kf5-minimum 95dad0d 
  dependency-data-kf5-qt5 3856fe3 
  logical-module-structure 061ca5f 

Diff: https://git.reviewboard.kde.org/r/126797/diff/


Testing
---

no


Thanks,

Jarosław Staniek

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: [Maniphest] [Commented On] T665: Show default (empty) document on startup in document-based Calligra apps

2016-01-18 Thread C. Boemann 
On Monday 18 January 2016 11:28:17 René J.V. Bertin wrote:
> On Monday January 18 2016 10:05:32 boemann wrote:
> >One thing tohugh - it shouldn't be an empty document - I wan to get away
> >from this  as we need all sorts ofinitial setup, and i want to remove the
> >custom dialog for the same reason - but anyway the default startup
> >document should be the blank template
> >
> >but as i said i fear it's not such a low hanging fruit at all
> 
> I've never understood why applications would ever need an actual on-disk
> template for a blank document. Even without using an OO programming
> language proper initialisation of the internal document structure should
> give you (wait for it) an empty document.
> 
> R.
Well what you would get is a really empty document then - not pages, no font, 
no margins, no nothing - all of those decisions is what is stored in a 
template. Having to code all those decisions just for the sake of not loading 
a file with those decisions "coded" through a much nice user interface called a 
wordprocessor is well.. stupid.


___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: State of Proposal to improving KDE Software Repository Organization?

2016-01-18 Thread Boudewijn Rempt 

On Mon, 18 Jan 2016, Friedrich W. H. Kossebau wrote:

Reason that I ask is that due to the split of Calligra into several repos (see 
background^) the layout in the repo structure does no longer properly reflect 
the project organisation. Right now there are three active repos in the 
calligra/ repo substructure:

"calligra" at "calligra/"
"krita"at "calligra/krita"
"kexi" at "calligra/kexi"


What I'm wondering is, where is this "structure" actually visible? Not in

https://quickgit.kde.org/

or

https://phabricator.kde.org/diffusion/

I see it reflected in the old, to be discarded

https://projects.kde.org/projects

But where else? And what is it actually needed for?



(("calligra" at "calligra/" confuses at least kdesrc-build, sent an email to 
mpyne about if moving it to "calligra/calligra" should fix it.))


Things that are not properly matching organization:
* Krita starting with 3.* no longer is part of Calligra project
 (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
 what people think to which project Krita belongs)
* Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
 so no reason to be in a complete own toplevel structure,
 rather should be in the same sub structure, i.e. "Extragear",
 like extragear/calligra/* and extragear/graphics/krita

More, not only Calligra & Krita related:
* "Extragear" is an awful grouping name for apps with individual
 release plans, a legacy term that no longer fits most of the apps
 in that substructure


It's ghastly -- almost insulting. It's perpetuating the fallacy that
there are core KDE projects and peripheral projects.


* "KDE Applications" is a misleading grouping name for apps with a
 central release plan, as if those with individual release plans
 are not "KDE" applications (as in, not done in the KDE community)


Horrible as well.


* a single category per app as needed by the current tree structure layout
 of the repos, like "office", "graphics", "utils", is rather awkward,
 many apps do not match exactly one or would match multiple categories


Honestly, the need to group repositories is, to me, so weird that I think 
it would be best to adopt the following scheme:


a/amarok
a/...
...
c/calligra
g/gcompris
k/krita

And so on. It's meaningless as it is; it would be better to make that clear,
if grouping is really needed.

So IMHO some update of the repository organisation would be good, to reflect 
how things are these days.
Renaming of "Extragear" and "KDE Applications" is surely something which needs 
care from promo/marketing/VDG people first to find if that makes sense at all 
and what a good solution would be.


That again begs the question: where is the "organization" which apparently has
purely technical reasons visible to contributors and users?


(Being both maintainer of Okteta, which is in "KDE Applications", and meta-co-
maintainer of Calligra, which is not, but still done in the very same KDE 
community, that current naming seems so wrong to me).


But the actual names and grouping aside, for the pure technical renewing 
(which also involves all infrastructure like translation system, 
documentation, phabricator, etc), who is currently planning or working on 
what?
So does it makes sense to wait some more, or should we assume the current 
organization stays for longer, and Calligra & Krita repos should be moved 
inside that organization for now?



^Some background about Calligra repo split, as things are slightly 
complicated:


KRITA)  The "krita" repo was split off, because Krita has finally become a 
full project of its own, separate from Calligra. A logical place for the krita 
repo in the KDE repo structure would perhaps have been somewhere in extragear, 
but at least due to the translators preferring to keep the string catalogs of 
Krita in the "calligra" module as before, for less work, the krita repo was 
for now put as submodule of "calligra/".


KEXI)  Kexi continues to be part of the Calligra project/subcommunity, but the 
Kexi developers preferred a small simple repo "kexi" of their own (for build 
time and size). So the placement at "calligra/kexi" makes perfect sense.


OTHERAPPS)  As the other Calligra apps (Braindump, Karbon, Sheets, Words, 
Stage, etc.) are more tightly coupled and the binary interfaces between libs, 
plugins & apps can still change every other week, for now no further repo 
splitting is planned (to ensure atomic commits on API changes), and they all 
stay in the existing "calligra" repo.



Cheers
Friedrich
___
Krita mailing list
kimages...@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: State of Proposal to improving KDE Software Repository Organization?

2016-01-18 Thread Ben Cooksley 
On Tue, Jan 19, 2016 at 8:27 AM, Boudewijn Rempt  wrote:
> On Mon, 18 Jan 2016, Friedrich W. H. Kossebau wrote:
>
>> Reason that I ask is that due to the split of Calligra into several repos
>> (see background^) the layout in the repo structure does no longer properly
>> reflect the project organisation. Right now there are three active repos in
>> the calligra/ repo substructure:
>> "calligra" at "calligra/"
>> "krita"at "calligra/krita"
>> "kexi" at "calligra/kexi"
>
>
> What I'm wondering is, where is this "structure" actually visible? Not in
>
> https://quickgit.kde.org/

Quickgit shows the raw git repository structure, which deliberately
does not include the tree in it.

>
> or
>
> https://phabricator.kde.org/diffusion/

Eventually we'll have projects for each broader category (Multimedia,
Graphics, etc) and repositories will be tagged for those.
Phabricator will never provide a repository tree though (nor should
it, the existing tree is a hell of a maintenance nightmare).

>
> I see it reflected in the old, to be discarded
>
> https://projects.kde.org/projects
>
> But where else? And what is it actually needed for?

The build metadata depends on it, and it is used by:

- The CI system
- API / LXR / EBN
- Scripty.
- kdesrc-build

>
>>
>> (("calligra" at "calligra/" confuses at least kdesrc-build, sent an email
>> to mpyne about if moving it to "calligra/calligra" should fix it.))
>>
>> Things that are not properly matching organization:
>> * Krita starting with 3.* no longer is part of Calligra project
>>  (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
>>  what people think to which project Krita belongs)
>> * Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
>>  so no reason to be in a complete own toplevel structure,
>>  rather should be in the same sub structure, i.e. "Extragear",
>>  like extragear/calligra/* and extragear/graphics/krita
>>
>> More, not only Calligra & Krita related:
>> * "Extragear" is an awful grouping name for apps with individual
>>  release plans, a legacy term that no longer fits most of the apps
>>  in that substructure
>
>
> It's ghastly -- almost insulting. It's perpetuating the fallacy that
> there are core KDE projects and peripheral projects.

I agree. Which is why i'd like to see the Extragear moniker dropped.
If repositories are part of some broader release unit (like KDE
Applications - even if this does have a better name) then they still
need to visible as belonging to it though I think.

>
>> * "KDE Applications" is a misleading grouping name for apps with a
>>  central release plan, as if those with individual release plans
>>  are not "KDE" applications (as in, not done in the KDE community)
>
>
> Horrible as well.
>
>> * a single category per app as needed by the current tree structure layout
>>  of the repos, like "office", "graphics", "utils", is rather awkward,
>>  many apps do not match exactly one or would match multiple categories
>
>
> Honestly, the need to group repositories is, to me, so weird that I think it
> would be best to adopt the following scheme:

Note that "Frameworks", "KDevelop" and "KDE Telepathy" are all fairly
logical groupings of repositories (and things would be completely
unmanagable in so many ways if we didn't have these).

>
> a/amarok
> a/...
> ...
> c/calligra
> g/gcompris
> k/krita
>
> And so on. It's meaningless as it is; it would be better to make that clear,
> if grouping is really needed.
>
>> So IMHO some update of the repository organisation would be good, to
>> reflect how things are these days.
>> Renaming of "Extragear" and "KDE Applications" is surely something which
>> needs care from promo/marketing/VDG people first to find if that makes sense
>> at all and what a good solution would be.
>
>
> That again begs the question: where is the "organization" which apparently
> has
> purely technical reasons visible to contributors and users?
>
>> (Being both maintainer of Okteta, which is in "KDE Applications", and
>> meta-co-
>> maintainer of Calligra, which is not, but still done in the very same KDE
>> community, that current naming seems so wrong to me).
>>
>> But the actual names and grouping aside, for the pure technical renewing
>> (which also involves all infrastructure like translation system,
>> documentation, phabricator, etc), who is currently planning or working on
>> what?
>> So does it makes sense to wait some more, or should we assume the current
>> organization stays for longer, and Calligra & Krita repos should be moved
>> inside that organization for now?
>>
>>
>> ^Some background about Calligra repo split, as things are slightly
>> complicated:
>>
>> KRITA)  The "krita" repo was split off, because Krita has finally become a
>> full project of its own, separate from Calligra. A logical place for the
>> krita repo in the KDE repo structure would perhaps have been somewhere in
>> extragear, but at least due to the translators preferring to keep

Re: Review Request 126797: Add kexi.git build with deps

2016-01-18 Thread Ben Cooksley 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126797/#review91297
---


Ship it!




This is fine, please go ahead and commit.

- Ben Cooksley


On Jan. 18, 2016, 6:42 p.m., Jarosław Staniek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126797/
> ---
> 
> (Updated Jan. 18, 2016, 6:42 p.m.)
> 
> 
> Review request for Calligra and Ben Cooksley.
> 
> 
> Repository: kde-build-metadata
> 
> 
> Description
> ---
> 
> Add kexi.git build with deps, minor updates to kexi's deps
> 
> 
> Diffs
> -
> 
>   dependency-data-kf5-minimum 95dad0d 
>   dependency-data-kf5-qt5 3856fe3 
>   logical-module-structure 061ca5f 
> 
> Diff: https://git.reviewboard.kde.org/r/126797/diff/
> 
> 
> Testing
> ---
> 
> no
> 
> 
> Thanks,
> 
> Jarosław Staniek
> 
>

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request 126797: Add kexi.git build with deps

2016-01-18 Thread Jarosław Staniek 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126797/
---

(Updated Jan. 19, 2016, 8:55 a.m.)


Status
--

This change has been marked as submitted.


Review request for Calligra and Ben Cooksley.


Changes
---

Submitted with commit b19332e12b534dd7ef03956aed9b87fb49bb64ee by Jaroslaw 
Staniek to branch master.


Repository: kde-build-metadata


Description
---

Add kexi.git build with deps, minor updates to kexi's deps


Diffs
-

  dependency-data-kf5-minimum 95dad0d 
  dependency-data-kf5-qt5 3856fe3 
  logical-module-structure 061ca5f 

Diff: https://git.reviewboard.kde.org/r/126797/diff/


Testing
---

no


Thanks,

Jarosław Staniek

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: State of Proposal to improving KDE Software Repository Organization?

2016-01-18 Thread Jaroslaw Staniek 
On 18 January 2016 at 20:27, Boudewijn Rempt  wrote:

> On Mon, 18 Jan 2016, Friedrich W. H. Kossebau wrote:
>
> Reason that I ask is that due to the split of Calligra into several repos
>> (see background^) the layout in the repo structure does no longer properly
>> reflect the project organisation. Right now there are three active repos in
>> the calligra/ repo substructure:
>> "calligra" at "calligra/"
>> "krita"at "calligra/krita"
>> "kexi" at "calligra/kexi"
>>
>
​Thanks ​Friedrich, as always you introduce great amount of structure and
logic to KDE projects :)

It's even a bit more interesting that that; there are sub-sub-projects
playground/libs/kdb
playground/libs/kproperty
playground/libs/kreport​


- all historically and by heart ​being part of Calligra. In the future
Calligra _initiative_ can contain repos from any "category", why not?
Everyone can. See below for simple solutions to have that.


> What I'm wondering is, where is this "structure" actually visible? Not in
> ​​
>
> https://quickgit.kde.org/
>
> or
>
> https://phabricator.kde.org/diffusion/
>
> I see it reflected in the old, to be discarded
>
> https://projects.kde.org/projects
>
> But where else? And what is it actually needed for?
>

​build.kde.org's config (I remember that only because ​

​today I edited it: https://git.reviewboard.kde.org/r/126797 )​
Is this visible on the web page? No idea.
e.g. https://build.kde.org/view/Calligra/ groups some Calligra builds with
direct deps, that's all.

I know chiliproject.org that's used for projects.kde.org would better be
not patched. I hope this can be solved somehow and we can model our KDE
structures by our tools, not the other way round.


>
>> (("calligra" at "calligra/" confuses at least kdesrc-build, sent an email
>> to mpyne about if moving it to "calligra/calligra" should fix it.))
>>
>> Things that are not properly matching organization:
>> * Krita starting with 3.* no longer is part of Calligra project
>>  (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
>>  what people think to which project Krita belongs)
>> * Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
>>  so no reason to be in a complete own toplevel structure,
>>  rather should be in the same sub structure, i.e. "Extragear",
>>  like extragear/calligra/* and extragear/graphics/krita
>>
>> More, not only Calligra & Krita related:
>> * "Extragear" is an awful grouping name for apps with individual
>>  release plans, a legacy term that no longer fits most of the apps
>>  in that substructure
>>
>
> It's ghastly -- almost insulting. It's perpetuating the fallacy that
> there are core KDE projects and peripheral projects.
>

​Trees are dead. ​

I'd suggest a flat structure:
- relations between apps is a graph not a tree anymore (Kexi can be both in
office /productivity category as well as software development like KDevelop)
- it's 2016, people search, not browse

Or if categorization is needed, on top of the flat structure, tags are the
real means for that that people understand

There are app description formats: .lsm, .appdata.xml... I use them for
Kexi. Some others too. .lsm supports keywords.

I think semantic tags would be best (or do we use them already?).
A repo can be in a subproject and also belong to a number of categories.


>
> * "KDE Applications" is a misleading grouping name for apps with a
>>  central release plan, as if those with individual release plans
>>  are not "KDE" applications (as in, not done in the KDE community)
>>
>
> Horrible as well.
>

Yes, it's a surprise even to KDE people. Here, Calligra and KDevelop, to
name just them, are not KDE Apps to normal people.


>
> * a single category per app as needed by the current tree structure layout
>>  of the repos, like "office", "graphics", "utils", is rather awkward,
>>  many apps do not match exactly one or would match multiple categories
>>
>
> Honestly, the need to group repositories is, to me, so weird that I think
> it would be best to adopt the following scheme:
>
> a/amarok
> a/...
> ...
> c/calligra
> g/gcompris
> k/krita
>
> And so on. It's meaningless as it is; it would be better to make that
> clear,
> if grouping is really needed.
>
> So IMHO some update of the repository organisation would be good, to
>> reflect how things are these days.
>> Renaming of "Extragear" and "KDE Applications" is surely something which
>> needs care from promo/marketing/VDG people first to find if that makes
>> sense at all and what a good solution would be.
>>
>
> That again begs the question: where is the "organization" which apparently
> has
> purely technical reasons visible to contributors and users?
>
> (Being both maintainer of Okteta, which is in "KDE Applications", and
>> meta-co-
>> maintainer of Calligra, which is not, but still done in the very same KDE
>> community, that current naming seems so wrong to me).
>>
>> But the actual names and grouping aside, for the pure technical