Hello Tamura & Steve,
First of all, sorry that I reply so late.
I thought it'd be nice if I could make a custom shape
with which we can set variables, and make a special
variable that specify
the type of custom (or standard) shape to show, but I
didn't implement
it due to time restriction, and ogl shape is not delived
from wxWindow.
(not complaining, of course)
Ya, I agree about maybe having custom shapes. My shapes are derived from
the rectangular ogl one and they can display all their properties
inside the shapes. On the one hand it allows you to see what a block
does at first glance without the need to click it. On the other hand,
blocks with a lot of properties take up a lot of space.
The ideas behind my app are,
- Store most informations to variables.
For example I stored node selection information to a
special node
'toplevel', so selection can be saved. And the
information
is editable using the same way we set a value to
variables.
(Currently the variable is not connectable)
Hmm, this seems interesting to me. I save the selection/connection/...
info into a Document class and saving it directly into the top level
node sounds better to me.
- Use Python language to treat variables
It's mainly to save time.
Ya, writing your own language parser in this situation has no advantages
imo. An extension I thought about is that you could use the current
scheme to write different backends (for example so that the output can
be a python or a perl or a c++ program). However, this might be a lot
of work and requires languiage-independency in the design. I had the
opportunity for this in my last revision of the app, since I had blocks
which would allow for for-loops and such. Translating this into
different languages would be fairly easy. However, when using the
framework for the game editor, I noticed that if your blocks are too
small (as small as for-blocks) then it's not so nice to work with
anymore and you could type the code faster than click the blocks
together.
The main reason why I could probably need language independency is that
in game developement you have to write programs for the CPU and the GPU
(graphics chip). Both are written in different languages. For example
if I want to have a particle system simulated, I can do this on cpu or
gpu (depending on complexity). Having a GPU backend would be nice in
this situation.
- Make the rule as close as python.
If a value is set to a non-existant variable, the
variable is
created, just like python does. I tried to implement
multiple inheritance
but I don't know how to make a GUI for it. (I never
make
non-programmers to use UML, and I think multiple
inheritance might be too
much compricated)
Multiple inheritance is too complicated for non-programmers imo (at
least when the individual classes are not orthogonal to each other). I
had the idea that you could "link" one variable to another. For example
there's a block that can execute code and another block that can create
code and output it. So you would connect the output of the generator
block to the executor block. I think Tamura has a similar thing in his
app.
Some of the above features may not cope with my goals. My
final goals are- Can do complicated job by node creation and connection
It's for non-programmers (and for me
Yes, this will greatly depend on the complexity of the shipped nodes i
think. I don't expect users to actually create many new nodes, but
rather to use the shipped ones. If you only deliver the very basic set
like loops, if conditions etc. then it will be too much work for the
users to create complicated programs with it. Typing the code yourself
in such a situation is faster.
- Ability of free customization. (e.g. you can make any
node)
It't for programmers who set up the environment. But
it can
easily lose application stability unless we make it
carefully.
(My prototype do not care about application stability
well)
I agree.
- Use it for web environment (optional)
I'm thinking if we can use the application with GUI to
make cgi
(The system must be very fast, and consumes low
memory, so I'm
just wondering)
No interest from my side.
And some of the features I didn't implement but interested
are,
- Grouping
A group is a node like others. it has variables and
they are connectable.
But it can contain arbitrary number of nodes and
connecitons.
We can hide complicated connections inside a group.
(Kerama's core module has it, but I didn't use it)
Yes, this is really helpful when the programs get bigger. I thought
about making those group nodes collapsable so that they don't occupy as
much space on screen as when fully expanded.
- Undo
I'm not sure if we shoud implement it. Because we need
to remember every
variable state and it'll slow down the application.
And manipulations such
as saving data to a file is not undoable anyway.
For me undo is a must-have feature. As I need to serialize everything to
network/disk anyways this shouldn't be too much work. Currently I can
observe every variable individually and whenever it is changed I send a
message over the network. Maybe one can use this to create an
undo-history. It won't be perfect as I know a real undo feature
requires more sophisticated methods, but it will probably suit our
needs.
> If you are interested, maybe we can work on improving
this together?
Yes, I'm quite interested if your goal and mine are not so
far.
But I need to ask one thing. If you make it for your
company,
what'll be the license for it? When I posted the first
mail,
I was planning to make it open source. (GPL or LGPL, or
such)
I am not working for a company, so we can release the program under
eveery license we like. GPL or LGPL sound fine to me. I have no strong
opinion for a specific license, BSD or Artistic or whatever are also
fine for me.
-Matthias
P.S.: When Steve is back, we should have a chat about the program (via
IRC or some other way). In the meantime I see if I can get his program
running, but I won't be able to do this before next tuesday.