Re: [Pipmak-Devel] Pipmak IDE & integrated authoring

[Christian W. <cwa...@gm...>]

Fabrizio Pistonesi wrote:
> I've started te porting to Wx, this is the source with the main window http://rapidshare.com/files/44154647/PipmakIDE.7z.html

I've tried this (it compiles fine), and the first thing I get when I 
launch it is a row of assertion failures: 
/BUILD/wxPython-src-2.8.3.0/src/generic/hyperlink.cpp(87): assert 
"alignment == 1" failed in Create(): Specify exactly one align flag!

If I say no to all 10 of them, the application seems to continue properly.

Looks nice so far, apart from the non-alpha-blended and cut-off icons 
and some other rough edges. What I don't get at first sight is, what is 
the conceptual difference between the buttons and the hyperlinks?

I can certainly see this as being a useful tool when it's done, so in 
that regard I encourage you to continue with it. But you should know 
that my own goal is to make this obsolete - all editing should be 
possible in Pipmak itself one day (more about that below).

What I'm not sure I'm comfortable with is the Pipmak logo at the top of 
the window. It should be made clear that this is not an official part of 
Pipmak, but an independent project.

> By the way, what do you think about the integration of SciTE?

SciTE is certainly a capable text editor (I use it on Linux, not having 
found anything better there yet), but I don't think I'd want to trade it 
for my SubEthaEdit on Mac OS (I don't even know if there is a Mac 
version). Besides, integrating it would probably add a lot of additional 
dependencies to the code.

Can you explain what would be better with an integrated text editor than 
with the current system of launching the external editor of the user's 
choice? (Apart from the possibility of having an integrated debugger, 
which would probably be quite a lot of work to implement.)

> Is possible to create a secondary trunk in SVN so we don't need to create a patch every time? I'm curious to view all progress.

Make a branch and give you write access to it? That would still leave me 
the work of merging changes from the branch to the trunk. I'd rather 
give you write access to the trunk as soon as I'm confident enough that 
your patches conform to my standards and can be committed without 
needing postprocessing by me.

("You" in that paragraph refers to Andrea and Fabrizio in particular, 
but also to any other potential contributor.)

Of course we could also start some experiments with one of the 
decentralized revision control systems that have cropped up lately - 
I've never used any of them so far. Might be interesting.

Nothing stops one developer from testing patches by another one before 
they go into SVN. As I already mentioned, the natural tool for this 
purpose would be the patch tracker on SourceForge: 
<http://sourceforge.net/tracker/?group_id=112801&atid=663294>.


Now about Andrea's (I think?) "Authoring features on Pipmak" proposal on 
the wiki:

This corresponds more or less with what I have in mind. My ideas are not 
very concrete yet, however. I plan to implement the edit mode using a 
tools palette that contains the existing hand and pan tools, the 
half-implemented brush and eyedropper tools, and more tools related to 
creation and manipulation of node backgrounds, patches, controls etc. 
(classical example of solving the "don't mode me in" problem). The rough 
reference, as in other regards, is HyperCard. I also plan to have a 
project map that shows the nodes and the connections between them (at 
least those that can be deduced because they're specified in the 
"simplified syntax") as a graph.

About writing modifications back into the Lua files without disturbing 
the user's code, you might have noticed that some code fragments 
concerning this already exist: the updateFile() function in misc.c 
(called from a commented-out testing line in main.c), and patches, 
hotspots, and handles recording the location of their definition using 
pipmak_internal.whereami().

  -Christian