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

List:       quanta-devel
Subject:    Re: [quanta-devel] how to proceed with Quanta?
From:       Eric Laffoon <sequitur () easystreet ! com>
Date:       2005-12-13 4:57:44
Message-ID: 200512122057.44839.sequitur () easystreet ! com
[Download RAW message or body]

Hi Jens,

On Sunday 11 December 2005 4:52 pm, Jens Herden wrote:
> Hi Eric,
>
> I do not quote the long mail, what I write is related to your ideas about
> the new modularity.
>
> Let me try to express what I understood:
> We need a way to merge and unmerge code blocks (I'll call it objects here)
> into existing documents (I'll call it template here). Let's say we have an
> HTML template where we would define some merge points, like for CSS-LINK,
> SCRIPT, MENU, FOOTER etc. and then we would merge this with other files
> which provide objects for a CSS-LINK and a FOOTER or a SCRIPT and a MENU.
> Drag and Dropping an objects file on top of a template would search for
> matching merge points and magically melt the code together. Of course we
> would be able to unmerge at any given time and a change in the objects file
> would start an adoption run to adjust all documents which use the objects.

Well that's probably mostly different in symantics. To clarify what you said, 
merging and unmerging code blocks is fundamentally adding templates, but you 
make a good point. My point was that I could drop a template in an object 
outline of a document (or set of documents) and it would follow the rules for 
where to test for or insert functions in the document head. What you are 
saying about it knowing where to go when just dropped on the document would 
be limited to where we knew where something should go... But if people were 
developing in a visual representation or where a project wanted to make 
stylistic and layout structure automatic this is a very interesting idea.

Principally my idea was to have a file act as a container. So when I drop a 
Javascript call on it the container knows the disposition of the required 
function. It would do one of the following...
A) Verify the function is called by the document
B) Go where it knows the function is registered for this "set" (if no sets 
have been defined then project) and include it
C) Ask me to locate or verify the location of the function.
Other rules come into play such as...
1) Do I have a script section in the document head?
2) Are there precedence issues?
3) Do I want this included or in it's own declaration?
4) Is this one of those odd script required in the document body?

Similar rules would apply to using cookies, have we output text for instance. 
I'm not really sure the best way to tune this, but ideally we look for a 
methodology that is flexible and can easily be adapted to diverse uses of 
rules as well as object definitions. So we would have some default elements 
which would be created in a flexible format. I say that because I want 
someone using XML to be able to scrap our definitions and build their own if 
they need to. We would define a document head, and parts of that as well as 
an example key body parts. 

To be candid I'm running on very little sleep and at times I've had this very 
soundly in mind, and other times I think "what kind of mess am I making?" So 
feel free to offer suggestions as I know you will.
>
> Reading your text and having some ideas myself brings me to the first
> question about the implementation:
>
> Where should we store the needed meta information?
> We can create a syntax to add them into comments or we can create external
> files. I am a strong advocate for inline storing to avoid any syncing
> problem when you change the document in a normal editor.

I wouldn't want to argue these points because they're all good. In fact we did 
something similar with annotations, but it seems both is most practical. In 
this case I think defining the operation will mandate both. You need to mark 
you internal components in a file so there are comments in there. At the same 
time your rules are going to be too burdensome to include in the container 
file, and they may apply to sets of files which also makes it impractical 
because you would have concurrency issues. Given that this means we are 
favoring our editor by default (as every sane person should see our 
greatness ;) we should use sane easy to understand definition files. It would 
also be possible to enable much of this to happen with scripting so that 
these features could be available to interact in other editors.
>
> Some other random questions:
> - do we need to be able to nest objects in objects?

We could oner the worth of that in a file, but in the context of sets of files 
it's inherently impossible to avoid. I know there's got to be some ingenius 
way to look at the organization but I think modelling it is where we need to 
begin organizing conceptual application. The problem is that it's both 
procedural application and new interface design. Truly new interface design 
is the hardest because you have nothing to go on. 

> - do we need to have parameters or variables for objects that you have to
> fill before merging? This would be solvable with nested objects as well. -

I should sleep more before answering this question. When pondering this in 
Spain it suddenly became more clear how this would work best. Not having that 
clarity at the moment I'll try for a simple idea. We need to come up with a 
straight forward way to define logical factors. The idea being that we 
gradually teach the system to logically process events much as we would. This 
requires us to design things in a well structured organized way, which also 
provides a benefit. The particulars of this structure need to be something 
users can define based on how they work, assuming they use sound practices.

So my vision is focused on logic, but parameters would be applicable in some 
cases.

> do we need a kind of export that creates plain documents without meta-data?

It's probably a good idea, but in theory documents would work fine as they 
are.
>
>
> Another sidenote: It would be sweet to have command line tools to make the
> merge/unmerge/update scriptable.
>
> Jens
My initial idea was to creat the framework and interface and then lay out a 
base logical design ideas with the tools. The whole thing is really intended 
to be largely scripted right now. For one thing it's totally new and we're 
certain to want to do a lot of fixes. For another it needs to be user 
extensible/re-writable and that means scripting. DCOP or DBUS would be very 
cool with this. Much of it would extend with Kommander dialogs. I think the 
part in Quanta needs to be interface and framework.

Eric
_______________________________________________
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]