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

List:       quanta-devel
Subject:    Re: [quanta-devel] new template ideas
From:       "Samir M. Nassar" <quanta () steamedpenguin ! com>
Date:       2005-12-20 5:55:37
Message-ID: 200512192355.37624.quanta () steamedpenguin ! com
[Download RAW message or body]

On Monday 19 December 2005 21:10, Jens Herden wrote:

> 2. the meta info is separate from the source -> you can edit it in whatever
> editor you want and _will_ break it every time you touch it.

Well, that's the rub. Let's run with this idea though:

Say you start a project. You have your Templates (I don't see a separation 
between Objects and Templates, everything is a larger or smaller template) 
assigned and you are good to go.

Quanta creates a quick hash of every file in the projects that is editable. 
This could make use of freedesktop's mimelib by checking mimetypes. Only 
files defined as editable by a text editor get hashed. So a project 
containing several dozen images and or Ogg Vorbis files, will not have to 
hash those.

This lets the project know whether a file was edited since the last time 
quanta opened the project, by comparing hashes.

Next step. When a project opens quanta maintains data that can be in memory as 
well as saved on project exit, of file layouts. Basically everytime you tell 
Quanta to insert template Foo at column X, line Y quanta commits that to 
memory/file.

Now, if the file changes, and quanta has a note about the file in its 
foo.templates you get a passive popup, or On Screen Display (like juk or 
amarok) saying file was changed since last opening. Last known template 
coords were X,Y for template foo (shows snippet) This allows the developers 
to check what template foo is, where quanta thinks it should be, and where 
they really want it know, having edited a quanta project owned file outside 
quanta.

You wouldn't have to hold all files on memory, just the metadata, and it could 
be a feature that is turned on or off, so as to leave quanta fully functional 
on even the slowest machine.

I know hashes aren't the best method, since small changes can change the hash, 
but it seems like a workable method.

Even better, if projects were able to share their meta-data on a directory 
writable by all developers then you even have the basis for a lightweight 
source control mechanism built into quanta. At least enough of one so that 
developers don't trample each others metadata.

---

Mind you, this is a very rudimentary sketch, and in implementation it could be 
worse than not having this at all. Except for that it us better than having 
quanta project meta data in the files themselves.

-- 
Samir M. Nassar
SteamedPenguin - http://steamedpenguin.com/
_______________________________________________
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]