<div class="gmail_quote">On Mon, Oct 22, 2012 at 8:08 PM, 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">
<div class="HOEnZb"><div class="h5">On Monday, October 22, 2012 19:49:21 Sven Langkamp wrote:<br>
> On Mon, Oct 22, 2012 at 9:30 AM, Inge Wallin <<a href="mailto:inge@lysator.liu.se">inge@lysator.liu.se</a>> wrote:<br>
> > 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<br>
> > > >> mime-type. And now we have multiple applications with same native<br>
> > > >> format, such as Karbon and Flow, Words and Authors. Applications<br>
> > > >> with same native format should have same set of format filters, but<br>
> > > >> format filter codes 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<br>
> > > > embedded 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<br>
> ><br>
> > since<br>
> ><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<br>
> > > > link directly to Tables and actually don't go though an ODS<br>
> > > > intermediate. Those probably should be moved to the tables folder<br>
> > > > 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<br>
> > 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>
> ><br>
> >   core<br>
> ><br>
> >     libs<br>
> >     words<br>
> >     sheets<br>
> >     stage<br>
> >     ...<br>
> ><br>
> >   ui (or view)<br>
> ><br>
> >     suite (or desktop)<br>
> ><br>
> >       libs<br>
> >       words<br>
> >       sheets<br>
> >       ....<br>
> ><br>
> >     active<br>
> >     ...<br>
> ><br>
> >   filters<br>
> ><br>
> >     libs<br>
> >     xxx2yyy<br>
> >     yyy2zzz<br>
> >     ...<br>
> ><br>
> >   tools<br>
> ><br>
> >     ...<br>
> ><br>
> > In the core/ directory the parts of the applications that are UI<br>
> > 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>
><br>
> I would prefer to have it at<br>
><br>
> app/<br>
>     core/<br>
>     uidesktop/<br>
>     uiactive/<br>
><br>
> The reason behind is that it's much better to keep everything in a single<br>
> folder. For example if I commit somthing in krita/image and krita/ui, the<br>
> commit message shows it as krita/, with the new structure it would show<br>
> calligra/. Considering how many problems the distributions have with a<br>
> seperate filter folder, I think it's better to keep it together.<br>
<br>
</div></div>While I see your point, how would you handle calligra active that has one<br>
interface for three applications at once?<br></blockquote><div><br></div><div>Calligra Active is a special case. It would likely sit on the the top level with the other applications and like to their core libraries. I think it's better to have one exception than completely changing all the others.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And how would you handle Words and Author that share core functionality?</blockquote><div><br></div><div>Maybe an extra folder wordprocessing and in that folder Words and Author as seperate uis for the wordprocessing core. </div>
</div>