[devel] Re: [criawips] some ideas...

[Sven Herzberg]

Hi,

Am Mo, den 05.07.2004 schrieb Adrien Beaucreux um 14:42:
> Le sam 03/07/2004 à 14:46, Sven Herzberg a écrit : 
> > Am Mi, den 30.06.2004 schrieb Adrien Beaucreux um 7:53:
> > > I'm the (or maybe a) guy who asked you about criawips at the Linux Tag.
> > > I've been trying to get the soft to run, but somehow it wouldn't start
> > > properly (babling lots of stuff I don't understand for now).
> > 
> >   I expected this behaviour as criawips has some little issue that
> > prevented me from a successful first presentation in march. Version
> > 0.0.3 (which I'm about to release this weekend) already includes some
> > ideas of main windows and some MVC split.
> > 
> >   Version 0.0.4 (which was just released this night) will have some
> > working main window concept which will enable listing of slides in the
> > side pane and which will provide some feedback when the loading of a
> > slide failed.
> 
> Since last week I managed to get it work, yeah. And even to begin to
> understand part of the bable, yeah ! I'm tring (struggling) to also
> understand the code, but I guess this is gonna be a bit longer to
> achieve.

  Please remember that the first versions of criawips where just some
small hacks that we intended to make the task of creating a text based
slide easier and faster than it's been with magicpoint before.

  Lots of passages (especially the slide-show.c file) do really suck as
they've been created to just display the stuff no matter how beautiful
and maintainable the code was.

  I was rewriting the slide rendering stuff now (take a look at
slide-view.c) to get some kind of maintainable rendering code into the
CVS to be able to drop the ugly stuff from slide-show.c within the next
weeks.

> > > You can even have a kind of slide database, like you have your mp3
> > > database with rhythmbox, or maybe I'm just dreaming.
> > 
> >   Well, a good file manager (maybe combined with storage[1]) should be
> > able to provide the 'database', then one should open the second
> > presentation in criawips and drag and drop the additional slide into the
> > running presentation.
> 
> Yes, looks like what I'm looking for. No need to bloat criawips with it.

(no comment, just resent to become archived at the list)

> > > - Vectorgraphics :
> > > I'd let it completely outside. There are a number of good soft out there
> > > which are specialised in that area (Dia, Sodipodi/inkscape,...) I guess
> > > it may be possible to use bonobo to draw them (or I'm completely
> > > mistaken about what bonobo does). This would allow to keep criawips
> > > small and simple, but to have more functionnalities...
> > 
> >   I *do not* plan to reinvent the wheel, there are just some certain
> > things that a presentation should be able to do: e.g. one thing is to
> > add a text block and emphasise it by creating a simple arrow to hint at
> > the box. So it's just about some shapes to be added usefully, not about
> > creating some vector graphics rendering engine.
> 
> What you mean is to have vector graphic possibilities for edit time, so
> one can see what is where. And also simple for people who want borders
> to their zones, to have better-looking presentations. OK, I had
> misunderstood.

(no comment, just resent to become archived at the list)

> > > -Templates :
> > > If I understood the examples slideshows, you define a layout for
> > > different 'classes' of slides, and then you fill these templates with
> > > your content.
> > > 
> > > A functionnality I always wanted to see is 'special blocks' :
> > > I mean a block whose content can not be changed, and which takes some
> > > properties of the slide or slideshow :
> > >   *title of section
> > >   *title of the slide
> > >   *number of the current slide/total number of slides
> > >   *plan of the slideshow with current slide overlined. (which changes
> > > when the presentation is modified as it runs.)
> > >   *whatever you can think of...
> > 
> >   Well, you don't really want "special blocks" you want to have some
> > automatic text features. Stuff like "chapter's title" or "slide's title"
> > should be available as such auto text features, the slide show plan
> > should be available via some keyboard short cut.
> 
> Yes, these are auto-text features, except that I planned to lock them.
> One can not say "OK, I don't want a title on this slide, so let's throw
> it out". In that case, one must define a new slide template and use
> it...

  Of course...

> And I'm not sure I understand what you mean with this keyboard short-cut
> thing.
> 
> What I mean with this plan is, we have teacher that specifically request
> that one has the presentation plan somewhere on the screen at anytime,
> with the fallacious pretext that it helps one to know how long he has to
> suffer the current inane presentation.
> 
> Automate this come then quite handy.

  Please take a look at magicpoint, if you press <Ctrl> (IIRC) then a
list of slides shows up at the bottom edge of the screen. Whether this
should be displayed all the time or only on demand might become a
configuration option.

> > > I've started thinking about the filestructure, and thought that two DTDs
> > > could be used :
> > > one for the slideshow template, and one for the slideshow in itself.
> > > It's becoming a clearer idea everyday, but I still got some work to do
> > > on it. I'll let you know how it evolves, if you're interested.
> > 
> >   Well, I don't think that we need two DTDs, we just need one well
> > designed DTD using both XML (describing the content) and CSS (describing
> > the layout).
> 
> OK, it's just that I didn't thought about using CSS for the layout
> definition, just did it with XML. The point of having 2 DTDs is to
> really part the presentation and the content, be it in the structure.

  (This is a foreword to the upcoming paragraphs). At the moment,
slides' XML does look quite ugly. One example:

<block title='content'>
        &#8226; Hohe Qualität<br/><br/>&#8226; Leicht
Benutzbar<br/><br/>&#8226; Jedem zugängig<br/>&#160;&#160;&#8226;
Barrierefreiheit<br/>&#160;&#160;&#8226;
Übersetzung<br/>&#160;&#160;&#8226; Usability
</block>

  This is because the current XML parsing code is broken wrt white
spaces. I already had a clear version of this, but unfortunately this
one got lost.

> What i'm not fan about is to see in a slideshow :
> 
> >  <block title='content'>
> >     &#8226; Hohe Qualität<br/>
> >     <br />
> >     &#8226; Leicht Benutzbar<br/>
> >     <br />
> >     &#8226; Jedem zugängig<br />
> >     &#160;&#160;&#8226; Barrierefreiheit<br />
> >     &#160;&#160;&#8226; Übersetzung<br />
> >     &#160;&#160;&#8226; Usability
> >  </block>

  This is a way that I think slides should be able to look like for
version 0.0.6 (0.0.5 will introduce the display slide inside of the main
window correctly stuff).

> It's not that clear. I'd think better to have :
> 
> >  <block title='content'>
> >     <bulletlist>
> >             <item>Hohe Qualität</item>
> >             <item>Leicht Benutzbar</item>
> >             <item>Jedem zugängig</item>
> >             <bulletlist>
> >                     <item>Barrierefreiheit</item>
> >                     <item>Übersetzung</item>
> >                     <item>Usability</item>
> >             </bulletlist>
> >     </bulletlist>
> >  </block>
> 
> and somewhere defining that an item in a list begins by a &#8226;, and that
> you have a &#160;&#160; indentation between 2 levels.
> 
> Thus you define tags such as <table> (This one you won't avoid, anyhow), 
> <emphasize>, <list>, whatever.

  This stuff will require *lots* of refactoring and redesigning inside
of the application. I know that we will need this structure some time in
the future, but for simplicity of the code this stuff has been delayed.

  BTW, I don't plan to introduce <table> ever. Once we have a nice DOM
and a clean MVC split we can work on embedding external data (images,
diagrams, charts, tables, etc.), but I only want to embed tabled using
gnumeric.

> You have multiple advantages to this approach :
> 
> 1. Logical structure is more apparent, making writing the slideshow easier.
> This should be extended to the whole presentation (section, subsection, 
> slides) as well as inside a slide.
> 
> 2. When applying a new style, you don't need to hunt all the &#8226;. That's 
> easier and way faster.
> 
> 3. You get a unified look througout the document. This is, after all, what 
> we're looking for by using templates.
> 
> Of course, you have more to define in the CSS, but I think it's worth.
> And yes, I have had permanent brain damages inflicted by DocBook and LaTeX ;)

> By the way, is there a plan to adapt fontsize to the screen resolution.
> I can't read the sample presentation slides, as I have a 1024x768
> screen, and it looks like everything is written too big, overflowing the
> screen. 
> 
> In a use case such a in school, with many people following a
> presentation on different screens, making assumptions about the screens
> sizes can be problematic.
> 
> On the other hand, using a quarter of the available screen because
> somehow, someone may have to see it on a smaller display doesn't sound
> good either.

  I'm actually working on getting the text resized within the slide
preview in the main window at the moment, once this has been achieved,
the slide show will only embed a widget that will automatically resize
the slide to the current resolution.

Regards,
  Sven
-- 
Sven Herzberg <address@hidden>