[Fluxus] couple of editor fixes

[Kassen]

Evan;


> There's a lot that needs to be done to get it working as a proper editor,
> IMHO.
>
>
I agree. Not in the last place determining what is "proper" to us here as
our needs are quite unique. In addition to a reasonably powerful editor we
want it to be accessible (because of workshops and the like) and we want
stuff like transparency, waves, scaling and for all I know typographic
fireworks that we'd like to control with sound or code or joysticks....


> I thought about it... and then the time needed to do it put me off.
>  Really, I would think that we need a much better approach to handling
> characters than just an array of chars, we should really have a character
> object that can also have color for each individual character, and probably
> other properties as well (font?), and then a character holder object (like
> an array) that wraps these smart characters and adds functionality, and then
> string matching/replacing/etc functions on top of that.  Also, we should
> keep track of edits so we can implement undo in successive stages.  Fun!


Yes. I agree and thought of this too. One issue is that if we don't expose
the editor to the Scheme code it can be made fast and dependable
(mostly...), however then we need to decide in advance what operations we
allow and which ones are impossible. Deciding on this framework will have
artistic implications too... At least that is how far my thoughts went so
far. A framework like the one you propose here -if exposed- would solve much
of that.



>  Until we get any real infrastructure done on the editor, or more
> importantly, until we decide that it is a priority and *should* be done
> (something that may be controversial?  Dave?) I'd discourage anyone from
> doing any real hacking on the C++ side of things, what's the point? (Besides
> adding some neat experimental functions like that code auto-selector Kassen
> just did)
>
>
Yes. So far we have quite little and the plans for the future make it likely
that much of it will be discarded. The current state also seems to encourage
just small tweaks. However this stuff I did now was a few small itches that
I felt improved the feel a lot, I'm hoping I can get them through the memory
check and be a bit more sure about others benefiting too. That said; I think
the "redacted" experiment is useful to me personally regardless of what
happens as it teaches me about C++ in a fun way. If it all explodes and
becomes unusable yet I can figure out why this happened this would be a
great success to me and it wouldn't hurt anyone else too badly.

The underlying message here seems to be that we might need a brainstorming
session about where we want to go and how much effort that's worth. I for
one would be happy to try and contribute within my means. I also think that
Gabor's "scratchpad FX" indicate a desire towards a more serious framework.
They are great (don't get me wrong!) but they indicate a structural
question. Also; we're al artists and programmers, I'm sure we can come up
with a structure without sacrificing too much in the "whimsical fun"
department.


That's just my opinion, take it or leave it.
>
>
You say that as though your mail was very controversial. Maybe I am reading
the past discussion in the wrong way or misunderstanding you, but it seems
to me that we are all more or less on the same page? As I see it the biggest
issue is that we need a real infrastructure design and that the exact
demands for that are yet unclear. You mention fonts, for example. I'm no big
fan of using lots of fonts in a normal document but I am quite interested in
things like the sound modulating fonts in performance. Something that would
provide both would be a new sort of thing with new sorts of problems. I
suppose I mean I'm happy you shared your opinion too :¬)

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20110428/2b0b9d19/attachment.html>