<div class="gmail_quote">On Mon, Oct 22, 2012 at 9:30 AM, Inge Wallin <span dir="ltr"><<a href="mailto:inge@lysator.liu.se" target="_blank">inge@lysator.liu.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sunday, October 21, 2012 18:11:18 Yue Liu wrote:<br>
> 2012/10/21 Boudewijn Rempt <<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>>:<br>
> > On Sunday 21 October 2012 Oct, Yue Liu wrote:<br>
> >> Hi,<br>
> >><br>
> >> Currently filters are loaded based on application's native mime-type.<br>
> >> And now we have multiple applications with same native format, such as<br>
> >> Karbon and Flow, Words and Authors. Applications with same native<br>
> >> format should have same set of format filters, but format filter codes<br>
> >> are sorted under application categories.<br>
> >><br>
> >> So I suggest change it from current structure<br>
> >><br>
> >> filters/xxx_app/[im,ex]port/xxx_filter<br>
> ><br>
> > It's even messier in some places, where the odf2html filter is embedded<br>
> > in the epub filter.<br>
> ><br>
> >> to<br>
> >><br>
> >> filters/xxx2xxx<br>
> ><br>
> > I wouldn't mind that change, but then, for Krita, we moved all the<br>
> > filters to the Krita folter anyway.<br>
> ><br>
> >> And tell distributions package filters as one component, not with<br>
> >> apps, to avoid conflicts between same-format apps. At least Arch and<br>
> >> Chakra is already doing it this way.<br>
> ><br>
> > Fedora also did/does that already, which meant lots of bug reports since<br>
> > people only installed the app, not the filter component and then<br>
> > complained that they couldn't even open a simple jpeg in Krita!<br>
> ><br>
> > There's a complication here with the Tables filters: some of them link<br>
> > directly to Tables and actually don't go though an ODS intermediate.<br>
> > Those probably should be moved to the tables folder itself.<br>
><br>
> We can keep the dependency on App and involve new mime-types for those<br>
> filters. Just like Friedrich suggested before:<br>
> <a href="http://mail.kde.org/pipermail/calligra-devel/2012-May/005041.html" target="_blank">http://mail.kde.org/pipermail/calligra-devel/2012-May/005041.html</a><br>
><br>
> For example, if karbon filter depends on KarbonPart, we can make a<br>
> mime-type calligra/karbon.document and use it in the filter, so Flow<br>
> won't load this filter since karon.document is not supported by Flow.<br>
><br>
> And we can place the codes of this kind of app-dependent filters under<br>
> app/filters/xxx2xxx, and place those general filters under<br>
> filters/xxx2xxx, when packaging, app-dependent filters are packaged<br>
> with apps, general filters are packaged as a single package and every<br>
> app depends on it.<br>
<br>
I think we need to make a bigger reorganization. There are two things that are<br>
currently a problem:<br>
<br>
1. The applications themselves have more than one UI, e.g. Calligra<br>
Words/Sheets/Stage and Calligra Active.<br>
<br>
2. Filters sometimes use application internals as the data model.<br>
<br>
So I suggest the following overall architecture:<br>
<br>
calligra<br>
  core<br>
    libs<br>
    words<br>
    sheets<br>
    stage<br>
    ...<br>
  ui (or view)<br>
    suite (or desktop)<br>
      libs<br>
      words<br>
      sheets<br>
      ....<br>
    active<br>
    ...<br>
  filters<br>
    libs<br>
    xxx2yyy<br>
    yyy2zzz<br>
    ...<br>
  tools<br>
    ...<br>
<br>
In the core/ directory the parts of the applications that are UI independent<br>
should reside. It should be basically loading, storage, saving (i.e. the<br>
document), painting, an API for data manipulation and all commands.<br>
<br>
All views under ui/ will of course link to core/*. The filters should be<br>
allowed to link to core/* for loading, storage model or saving.<br></blockquote><div><br></div><div>I would prefer to have it at</div><div><br></div><div>app/</div><div>    core/</div><div>    uidesktop/</div><div>    uiactive/</div>
<div><br></div><div>The reason behind is that it's much better to keep everything in a single folder. For example if I commit somthing in krita/image and krita/ui, the commit message shows it as krita/, with the new structure it would show calligra/. Considering how many problems the distributions have with a seperate filter folder, I think it's better to keep it together.</div>
</div>