Re: [CinePaint] Interface Design for OSS

First I want to apologize for the late answer, but our mid-term 
presentation kept us busy.

> That's exciting! What's the schedule and the scope of your R&D? How will 
> you be graded? Is this for a thesis? Will your work be published? What 
> will be the end-product of your work?


The scope of our project is it to build a basic concept for interface 
design in the OSS-community. Therefore we try to combine different 
theoretical concepts, mainly the communication theory as proposed by 
Niklas Luhmann and psychological theories on interaction and learning.
The idea is, that the typical works in this field like Raskin or Norman, 
maybe helpful for designers but for the programmers there has to be a 
more basic concept. Also we aim to give designers the idea, that the 
informational architecture of a software is very important to the design.
If this project works out, it will be the base for my Diploma in the 
next semester. It is graded as our main project for the 7. semester (I 
don't know if I answered your question correctly, how grades are handled 
in German universities is different from the USA).
I can't say if our work will be published, because in this semester 
we're doing all the basic studies, maybe my diploma next semester will 
be published.

> Good. Workflow is everything in motion picture pipeline production. 
> You'll have a learning curve to overcome without the domain experience 
> of working in a studio motion picture pipeline.
> 
> FYI, there's interesting UI R&D that's been done at Georgia Tech based 
> on GIMP. Pretty stuff. You may want to look at this prior art.

We try to tackle the learning curve with a different approach, basically 
humans make failures, this is how we learn. So a error shouldn't be 
capable of destroying your work. So how could we achieve this?
By building a UI that lets you undo, change and rearrange all your 
previous steps. And additionally it works with source files and these 
aren't changed by the program.
I will refer to the technical aspects here to keep it together.
Right now it is just impossible for us to do the programming, but right 
here are a few programmers we can ask silly questions and maybe they can 
use our ideas.
First question: How can Cinepaint execute different settings at the same 
time (like color correction and gamma exposure)?
Second question: Can gimp process a written script?
If the answer to the latter question is yes, we already have the most 
important tools. The idea would be, to let the user program Cinepaint 
himself. This can be done in a way Pure Data handles it 
(http://puredata.info/), so you can set up a worksession having your in- 
and output. Change it at every point and then let it process as many 
files as you like.
Two problems will remain, how can the preview be handled (is the "core" 
of gimp fast enough to have real time linking?) and second, what happens 
if tools like paintbrush or the stamp are used?

What do you think about this idea?

I want to wait for your answer, before I answer how we proceed, because 
this depends on the previous questions.
If it is to difficult to do, we can do a redesign on skin and behavior 
also our project will take a different direction, because we want to 
work on the more basic concept of a program like this.

> CinePaint Film Gimp (0.x series) is based on a legacy GIMP architecture. 
> It's largely monolithic, single-tasking, brittle, and difficult to work 
> on because of design choices that defeat debugging such as the use of 
> variargs in the plug-in communications protocol, plug-in spawning, image 
> tiling with layers of indirection, and a GTK maze of plumbing that can 
> render bugs untracable except by the brutish method of sprinkling print 
> commands in the code. Because QA is so hard, working of Film Gimp is 
> very challenging technically and time-consuming. CinePaint Film Gimp 
> development enhancement is led by Kai-Uwe in Germany. He's taken that 
> over while I focus on CinePaint Glasgow.
> 
> CinePaint Glasgow (in CVS only so far) is a ground-up rewrite of 
> CinePaint that does have a modular architecture, but is only mostly 
> there (in CVS, but some features are missing or not integrated across 
> modules), buggy (not because it's hard to debug but because it hasn't 
> had very much QA yet), and hasn't had its first release yet. (December, 
> knock wood.) I'm preparing that release. I'm based in California.
> 
> When everyone considers Glasgow a complete replacement, CinePaint Film 
> Gimp will be retired.
> 
>> What we lack is a knowledge on the programming, so what can be done and 
>> what not. 
> 
> That would slow you down considerably! Where will you find programmers 
> to implement your ideas?
> 
> There's a lot I'd like to do myself in the interface design of Glasgow, 
> but can't yet because I'm working on more basic building blocks. To me, 
> the UI is the fun part. Other nuts-and-bolts stuff comes first.
> 
>> What we have is experience in interface design as a very 
>> important element in the communication between man and machine.
> 
> How do you want to proceed?
> 
> Robin
> --
> CinePaint Project Manager
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Cinepaint-users mailing list
> Cinepaint-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/cinepaint-users


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV