Single Canvas Presentation Feature in Karbon

[Jean-Nicolas Artaud]

2011/3/22 Thorsten Zachmann <t.zachmann at zagge.de>

> On Tuesday, March 22, 2011 00:37:44 jaham at gmx.net wrote:
> > On Monday 21 March 2011 23:17:09 Aakriti Gupta wrote:
> > > Hi,
> > > I am interested in the following idea of implementing a single canvas
> > > presentation view (like Prezi, Zippl or JessyInk)as a GSoC project for
> > > this year.
> > >
> http://community.kde.org/GSoC/2011/Ideas#Project:_Single-canvas_Presentat
> > > io n_Mode_.28like_Prezi_or_Zippl.29
> > >
> > > I discussed this idea with Kevin Ottens, Thorsten Zachmann and
> > > Jean-Nicholas Artaud over the IRC.
> > > We decided that either this should be added as a feature in Karbon
> (like
> > > JessyInk in Inkscape) or a separate new app (like Zippl).
> > > The feature would be better in Karbon than stage because the workflow
> is
> > > closer to Karbon's use than Stage's and the former has better SVG
> > > support.Also, this would save the extra work required in writing a new
> > > app.
> >
> > Nice idea. I agree, it probably would be easier to do using Karbon as a
> > base.
> >
> > > The workflow would be:
> > > Make a poster in Karbon ->  Mark out frames and set their properties
> > > (order of frames, animation, next frame, etc.) -> Drawing exported as
> an
> > > SVG -> Presentation can be viewed in any browser supporting SVG.
> > >
> > > I have been learning scripting of SVGs, specially the animation,
> movement
> > > from
> > > frame to frame and embedding of images.
> > > I am trying to get familiar with the architecture of Karbon and the
> > > filters used
> > > for exporting of SVG.
> > >
> > > I came across a TODO list but I am not clear on the jobs mentioned.
> > > They are:
> > > SVG export
> > > - pattern strokes
> >
> > This is missing completely. As soon as flake does support patterned
> borders
> > of shapes (solid and gradient borders are already implemented), exporting
> > these can be implemented. Sadly ODF does not specify pattern borders
> > AFAIK, so this will be a svg only feature.
>
> I think that is not really needed for your project.
> >
> > > - text
> >
> > Svg text support is still very basic at the moment, but i think all
> things
> > we support are exported properly.
> >
> > > - for text on path: when on path shape
> > >
> > >     -> path data into defs
> > >     -> path shape with use on defs path data
> > >     => maps back to text on path shape when importing
> >
> > I think this is obsolete and can be removed.
> >
> > > I was wondering what these mean in terms of implementation.
> > >
> > > Let me know what you think about the idea.
> >
> > I think it is a nice project to do. Complexity of the project depends on
> > whether you want Karbon to be able to also play/preview these svg
> > animations or if you just want to setup and export the presentation in
> > Karbon. The latter can probably achieved by implementing some custom
> > tool/shape plugins, which is quite easy to do in calligra.
>
I totally do agree with this, but I think in a user point of view, to have
something
more in Karbon is not a good point. The user wants to make a presentation.
He
will think about Stage. The point is, the way of making a presentation in
the
single canvas way is really too different. So another "presentation" app is
needed IMHO. To have two presentation applications with different type of
app
is not strange in an user mind. He thinks: "2 presentation apps ? hummm,
which
one I need/want ? Let me see what is the difference and what I really need".
If we have something in Karbon, I think it is really strange.
[user mind] "I have to do a presentation, ah yes, I directly go to Stage, it
is the real
full pres app."[/user mind]
To have something in Stage could be defended in a user point of view, but
not in a
technical way. Between the 2 points (technical and user side), a good way
would be
to have something in a new app. If needed, I propose myself to help aakriti
making
the app working. Maybe I can do the new void app, and aakriti could add the
necessary things in it ?


> >
> > > I will soon send out a first draft of my GSoC proposal for review and
> an
> > > example presentation. The draft would contain more details on the
> > > technical implementation of the feature and timeline.
> > > (Should this be sent to the Calligra mailing list?)
> >
> > Yes, please send the draft to the Calligra mailing list, so other people
> > can give input.
>
> I think it should not send to the mailing list as there will be also other
> who
> might want to work on this project and I think they should make up their
> own
> oppinion about the project. Please put it on the GSOC webside as soon as it
> is
> possible.
>
Well, I just just I want to help, but it is nothing with the GSoC, it is
just about
environment of the GSoC :-)


> Thorsten
>



-- 
Jean-Nicolas

PS: I CC'ed Kévin Ottens, he is interested in this feature.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20110322/c4cec03c/attachment.htm>