[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] new template ideas
From:       Jens Herden <jens () kdewebdev ! org>
Date:       2005-12-20 1:08:00
Message-ID: 200512200808.06963.jens () kdewebdev ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


[...]

> > The Quats
> > ========
> > - are files where Quobs can get merged.
> > - know about which Quobs are currently merged in and where.
> > - know the order of the merged Quobs. Order is important when you
> > nest Quobs. - contain the merged Quobs, there is a copy of the Quob
> > inside after merging!
>
> Hm, are you sure about this? Aren't the templates (Quats) only describe
> the place? The actual documents based on the template have the copy of
> Quobs.

My proposal is to have no difference between template and document! A Quat is 
a normal document with some extra information for merging Quobs. There should 
be no need to create a template first where you generate the document from. I 
want to allow the user to take an existing document and simply add 
mergepoints. And in a second step s/he can drag and drop a Quob which will 
merge. 
Of course you are free to create a Quat that only contains merge points ;-) 
But after the merge the Quobs are in the Quat and not in another document 
file. 

> > Implementation
> > ============
> > I think we should create our own namespace and use custom xml tags
> > for this. AFAIK do they not interfere in the rendering of HTML.
>
> I think in HTML unknown tags should simply be ignored. But it is true
> that for some reason such tags are enclosed in comments. It is easier
> to parse if it is not inside comments, though.

We will have to look in this. But we have to solve the parsing issue anyway if 
we want to use this with script and css.


> The problem with
> <quanta:quob merge="xpath:/html/head" weight="0">
>      <META name="x-test" content="none">
> </quanta:quob>
>
> is that it will be inserted in every HTML document, no (there was no
> mergepoint for it)? Do we really want this?

I think this is a misunderstanding. My should it merge in every HTML? Merge is 
triggered by the user. Unless the user does not start the merge it will not 
happen. And after merging there is enough info in the Quat to redo or undo 
the merge again. 


> > Now I would like to get use cases. What would you like to do with a
> > new template system in Quanta?
>
> An idea is to offer a new, graphical view of the document where you
> could just click and edit parts of it, like:
> [source]
> [javascript merge, name="the name of the Quob"]
> [source]
> [header merge, name="the name of the Quob"]
> [source]
> [footer merge, name="the name of the Quob"]
> [source]

Yes it could be a new view on the document or just get include in the current 
structure treeview.

> One could click on the parts and edit in a document editor (I don't mind
> if the whole document is opened and only the cursor is focused in case
> of [source] parts).
> The merge parts should offer different actions, like:
> - edit the Quob
> - replace with another Quob
> - merge permanently
> - umerge (remove mergepoint)
> - with D&D you could move the mergepoints. In this case if you move over
> a [source] part, it should expand to the source and you could select
> the exact place where to drop.

I see you also create many good ideas about the user interface. But before we 
do so, I would like to talk more about the general concept. 


> > I want to know to what extend these ideas can cover the use cases you
> > have in mind.
>
> I would also like more from Eric, based on this. I want to base our
> discussion on your ideas, so we have something concrete that we can
> modify, extend, discuss, instead of talking in general terms about
> ideas.

Agreed, but if possible I would like to think now not about the implementation 
details but about what use cases we have, what we want to cover with such a 
system. 

Jens

[Attachment #5 (application/pgp-signature)]

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel


[prev in list] [next in list] [prev in thread] [next in thread]