Just select it and update the settings in the attributes panel. You can also modify numerically the coordinates of the control points by either right-clicking on the selected object or by pressing the F2 key. If the attributes panel has not been opened yet, you can open it from the toolbar.
Select the objects you want to modify (using shift-click to enlarge selection), and change the settings in the attributes panel. If the attributes panel has not been opened yet, you can open it from the toolbar.
While holding the Control key pressed, click on a point of the polygon to delete it ; click somewhere else to add a new point.
From inside GnuPlot, export your graph to the pstricks format, that is, type set output mygraph.pst; set term pstricks; plot..., then simply open the produced file in jPicEdt. Alternately, you may achieve the same result from inside octave, where however set is to be replaced by gset.
This is due to the way environment space is being handled on WinXP. I was not aware of this behavior by the time i wrote the launch-script (the point is: there is NO environment space by default!). The faulty variable is JAVA_HEAP_SIZE (=amount of memory available to Java). As a straightforward work-around, open jpicedt.bat in your favorite editor (e.g. notepad.exe), and change -mx%JAVA_HEAP_SIZE%m to -mx64m (= 64 Mb). You may then safely delete the line @set JAVA_HEAP_SIZE=32. You may also want to increase this number to 96m or above if jPicEdt seems slow to react (this actually depends on the complexity of your drawings).
First, a couple of words on how-the-bl****-stuff-really-works. Whenever you click on a command button, e.g. TeX or DVI, jPicEdt actually calls an external batch script (e.g. a BAT file on MS-Windows). These scripts are located in one of the add-ons subdirectories of jPicEdt's install directory whose name matches your current installation, e.g. add-ons\windows\miktex. This approach was aimed at giving users as much flexibility as possible, seeing that the very multi-platform nature of Java makes it impossible to control everything from inside the Java code, especially when it comes to running native external programs. As a rule of thumb, if scripts appear to behave oddly, then first test them from a DOS command-line (or a shell on Linux/MacOSX). Besides, if you've not already done so, open the Edit/Preferences/Commands dialog box, click the load button, and select the script's configuration file which matches your installation, this will at least preconfigure things and save you some work.
As soon as you click on the TeX button, jPicEdt first creates a TeX file on-the-fly (in the appropriate format, e.g. pstricks, and with proper LaTeX commands wrapped around your picture commands, so that the resulting file becomes compilable), then saves it in your current temp directory (e.g. c:\temp), then eventually calls the adequate script (e.g. jlatex.bat on Windows) with this file as the second argument (%2). The first argument (%1) being the temp directory you specified in the Edit/Preferences/Directories dialog box, you should first make sure this directory exists indeed! The temporary file name always starts with jpicedt, and has a random number appended to it. Change to your temp directory, and check if there is such a file there.
If in the affirmative,
try to run the jlatex.bat manually, that is, cd to add-ons\windows\miktex,
then type for instance: jlatex.bat c:\temp jpicedt15367.tex. This should produce a DVI file if everything went
fine. If this didn't work, one possible work-around on WinXP (according to some users) is
to re-install jPicEdt
in a directory whose name doesn't contain any white-spaces, e.g.
c:\jpicedt_1_4_1, since this appears to confuse jPicEdt and/or mikTeX. Apparently,
paths to executables such as latex or yap shouldn't contain white-spaces neither (on WinXP only,
but don't ask me why, I DO NOT use Microsoft softwares at all!), and some of you reported having solved the
issue by creating shortcuts to executables (aka links) with no whitespace.
Well, huu, huu, sounds like open-source software is a good concept indeed, now in practive this is another story... We are only two developpers working on a regular basis on the project, and useless to say, we both have a full-time job being exceedingly time consuming. We do our best to release a new stable and robust version every 8-10 months or so, which is not that bad considered the bunch of new features which are added to each new release. Now, if you are a dab hand at Java programming, or even just have a smattering of it, feel free to join us. Just send us an email at : email@example.com, possibly telling us to which part you would like to contribute, and we will do our best to help you integrate the development team.