headers
Ivan Johansen | 1 Jan 2007 01:13
Picon
Favicon

Re: how

Lisa Freund wrote:
> how do you turn two points into the F (x )
>  
> how do you make the program make the line (29,-23) (30,-30)

That is actually very easy. Create a point series with the two points 
and insert a linear trendline from the point series.

Best regards
Ivan Johansen

-------------------------------------------------------------------------
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
Permalink | Reply | 0 comments |
headers
Cort Ammon | 1 Jan 2007 02:33
Picon
Favicon

Re: Scripting Language

I took a look at the 4.3 beta, and I like the way the plugin interface 
was designed, it took me maybe 3 minutes to figure out how to work with 
it.  For a plugin API, thats short =)

My first instinct is that the problem lies in tk's mainloop() function. 
  It expects to be the only code that matters, so it will block at will.

I just perused through some of the code for Tk, _tkinter, and python.  A 
solution might work out if you force developers to use Tk only (as 
opposed to the other GUIs Python offers).

It seems that, if you initialized and ran Python on a separate thread, 
maintained your own root level Tk object (everyone else uses 
Tk.Toplevel), it should work out.

The logic: separate threads for Python and Graph would decouple the 
Graph main loop from python (and the eventual Tk.mainloop).  And if you 
run the Tk main loop, and everyone else's scripts mooch off of it using 
Tk.Toplevel windows, you could have windows from multiple scripts open 
at the same time (you are the only one calling Tk.mainloop, not them).

Ivan Johansen wrote:
> Conrad B Ammon wrote:
>> This would also open the door to custom UIs as well.  A user could 
>> import a script, have it generate a family of fuctions, select one and 
>> have the Python code create a window with information about that 
>> specific function.
> 
> Actually the user interface seems to be the problematic part. 
> Unfortunately different GUI frameworks don't interact well. Graph uses
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ivan Johansen | 1 Jan 2007 18:06
Picon
Favicon

Re: Scripting Language

Cort Ammon wrote:
> I took a look at the 4.3 beta, and I like the way the plugin interface 
> was designed, it took me maybe 3 minutes to figure out how to work with 
> it.  For a plugin API, thats short =)

It is also a very limited API. :-)

> My first instinct is that the problem lies in tk's mainloop() function. 
>   It expects to be the only code that matters, so it will block at will.

Yes, there are two frameworks that both think they are the only one.

> I just perused through some of the code for Tk, _tkinter, and python.  A 
> solution might work out if you force developers to use Tk only (as 
> opposed to the other GUIs Python offers).

I haven't tried any other GUI frameworks, but I think it is okay to 
limit the scripts to use Tkinter.

> It seems that, if you initialized and ran Python on a separate thread, 
> maintained your own root level Tk object (everyone else uses 
> Tk.Toplevel), it should work out.

Yes, but maintaining the root level Tk object seems to be the difficult 
part.

> The logic: separate threads for Python and Graph would decouple the 
> Graph main loop from python (and the eventual Tk.mainloop).  And if you 
> run the Tk main loop, and everyone else's scripts mooch off of it using 
> Tk.Toplevel windows, you could have windows from multiple scripts open
(Continue reading)

Permalink | Reply | 6 comments |
headers
Cort Ammon | 1 Jan 2007 23:57
Picon
Favicon

Re: Scripting Language

Ivan Johansen wrote:
> The problem seems to be that Tkinter wants a root window, but Graph 
> already has a main window. So I just call Tk().withdraw() to create an 
> invisible root window for Tkinter. But that means that the dialog in the 
> example doesn't have a parent, which makes the dialog show up in the 
> task bar and the dialog cannot be modal. As a workaround for the modal 
> part I tried to disable the Graph main window while the Python script is 
> running, but I cannot prevent the dialog from showing up in the task bar.
> 
> If it is possible to use the Graph main window as the Tk root window 
> that would solve a lot of problems.
> 
> Best regards
> Ivan Johansen
> 

Is the code for 4.3 available anywhere?  I couldn't find it when I 
looked on sourceforge.  It'd be a lot more convenient than just tossing 
ideas at you and hoping some of them work!

SetParent() in the Win32 API may be useful (or may not).  It seems to be 
one of those dangerously low level functions that can do tricks behind 
the TCL/Tk library's back.  It seems like you could hook the 
CreateWindowEx function that TCL/Tk uses, get the window, and then make 
it your child (which I THINK takes it off the taskbar)

As for the threading, you can always do what both Python and TCL end up 
doing: whenever you're doing something dangerous (which, in this case, 
would be modifying or looking at the graph data), you have to acquire a 
lock.  This makes it appear to be single-threaded for all Graph
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ivan Johansen | 2 Jan 2007 10:43
Picon
Favicon

Re: Scripting Language

Cort Ammon wrote:
> Is the code for 4.3 available anywhere?  I couldn't find it when I 
> looked on sourceforge.  It'd be a lot more convenient than just
> tossing ideas at you and hoping some of them work!

You can find the latest source code in Subversion at:
https://graph.svn.sourceforge.net/svnroot/graph/Trunk

But you will need an svn client (for example TortoiseSVN) to get it. 
Alternatively you can read it online at:
http://graph.svn.sourceforge.net/viewvc/graph/Trunk/

> SetParent() in the Win32 API may be useful (or may not).  It seems to
> be one of those dangerously low level functions that can do tricks
> behind the TCL/Tk library's back.  It seems like you could hook the 
> CreateWindowEx function that TCL/Tk uses, get the window, and then
> make it your child (which I THINK takes it off the taskbar)

It might be possible to do something like that. I have not used Tkinter
much so I don't know what can be done behind the back of Tk. But instead 
of doing this for all windows in all scripts, it might be better to 
create some kind of root widget that can be passed as parent to all 
other windows.

> As for the threading, you can always do what both Python and TCL end
> up doing: whenever you're doing something dangerous (which, in this
> case, would be modifying or looking at the graph data), you have to
> acquire a lock.  This makes it appear to be single-threaded for all
> Graph activities while allowing it to be multi threaded for
> everything else.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Cort Ammon | 4 Jan 2007 20:17
Picon
Favicon

Re: Scripting Language

Ivan Johansen wrote:
> Unfortunately it is not that simple. Many API functions will interact 
> with the GUI framework, e.g. create a new menu item, and that may only 
> be done from the main thread.
> 
>> How difficult would it be to have a global lock on all Graph data?
> 
> That would be very difficult. There are a lot of Graph data and they are 
> used from several hundred places. I would surely miss a few places and 
> such bugs are incredible difficult to find. It is also a bad design and 
> may introduce deadlocks.
> 
> I think it would be much better to have the API functions request that 
> the main thread handle the actual work and wait for it to finish. But I 
> am not sure that it helps anything to run the Python interpreter in 
> another thread. I am also unsure whether a window can have a parent in 
> another thread.

I'm almost certain a window can have a parent in another thread, at 
least according to the wording in the MSDN.  They say that a root window 
has its parent set to the desktop, and since the desktop window is in 
another process, I'm pretty sure its another thread ;- )

Running the python interpreter on a separate thread should help.  I've 
found no rule that says two threads cannot both have message queues.  By 
having two threads, with one queue each, one can handle the graph window 
messages while the other runs the Tk main loop.  With some clever 
event/mutex coding, the two threads would behave similar to fibers - a 
script can choose to stop executing and wait for the main thread to 
handle the work.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ivan Johansen | 4 Jan 2007 22:23
Picon
Favicon

Re: Scripting Language

Cort Ammon wrote:
> I'm almost certain a window can have a parent in another thread, at 
> least according to the wording in the MSDN.  They say that a root window 
> has its parent set to the desktop, and since the desktop window is in 
> another process, I'm pretty sure its another thread ;- )

You are probably right. I just wasn't sure.

> Running the python interpreter on a separate thread should help. 

Maybe.

> I've 
> found no rule that says two threads cannot both have message queues.  By 
> having two threads, with one queue each, one can handle the graph window 
> messages while the other runs the Tk main loop. 

Yes that should be possible. But I am not sure how the main thread can 
tell the Python thread to execute a Python function while it is running 
the Tk main loop. But it should be possible.

> With some clever 
> event/mutex coding, the two threads would behave similar to fibers - a 
> script can choose to stop executing and wait for the main thread to 
> handle the work.

Yes, that is possible and I will try that later.

> I'm hoping to have some spare time this weekend to delve into the code 
> and see if anything helps at all =)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Cort Ammon | 5 Jan 2007 00:15
Picon
Favicon

Re: Scripting Language

Ivan Johansen wrote:

> It doesn't seem very common to embed Python with Tkinter into another 
> application. I expected to find others with the same problem and 
> hopefully some solutions.
> 

Python has this concept that it is gods greatest gift to mankind, and 
obviously all programs should extend from it instead of embedding python 
in each of them.  Thus all tutorials tend to advise that route.

In the real world, that is almost never an option, and usually a lot 
better to just embed,but Python people don't like to admit that =)

I think I've seen one app which extends python, and maybe 4 or 5 that 
embedd it, but none of them use it for GUIs

-------------------------------------------------------------------------
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
Permalink | Reply | 1 comment |
headers
Ivan Johansen | 6 Jan 2007 01:35
Picon
Favicon

Re: Scripting Language

Cort Ammon wrote:
> Python has this concept that it is gods greatest gift to mankind, and 
> obviously all programs should extend from it instead of embedding python 
> in each of them.  Thus all tutorials tend to advise that route.

Yes I wondered why everyone always say extend Python instead of 
embedding it.

> In the real world, that is almost never an option, and usually a lot 
> better to just embed,but Python people don't like to admit that =)

Well, even though they say extending is better, the documentation about 
embedding Python is rather good, though there are a few subtle traps.

> I think I've seen one app which extends python, and maybe 4 or 5 that 
> embedd it, but none of them use it for GUIs

I actually don't have much trouble embedded Python. The problem is that 
Tkinter and VCL doesn't work well together. But I think that is very 
common with different frameworks. Actually it is possible to hook into 
the internals of the VCL. If the same is possible with Tkinter, I think 
they can be made to work together.

I have only used Python for minor things previously. And I have never 
used Tkinter before I started trying to embed it into Graph. I chose 
Tkinter because it seems to be the most common and easiest to use GUI 
framework for Python. But maybe it is easier to get another framework to 
interact with Graph.

But I think I will look a little more into how Tkinter an Tk actually
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cort Ammon | 7 Jan 2007 03:34
Picon
Favicon

Re: Congrats to this great tool! And some suggestions

Ivan Johansen wrote:
> Michael Schneider wrote:
> 
> I have actually wondered why SVG isn't used more. I will take a look at
> SVG for one of the next versions. It is probably much easier to 
> implement than EPS.

SVG is a nice easy XML format.  Like all XML documents, its difficult to 
parse, because you have to worry about all the possibilities and 
complexities that SVG and XML allow, but it is very easy to write (just 
look up what portions you need to use for your job, and hardcode them).

If your drawing engine is an adapter style pattern, writing a new engine 
that outputs SVG would be easy.

If you're just doing raw windows API calls with no abstraction, it may 
be worth abstracting it.

-------------------------------------------------------------------------
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
Permalink | Reply | 1 comment |

Gmane