Does anyone know what it would take to port libqalculate to Windows? And which GUI (QT or GTK+) might be the easiest to port? Is kdelibs3 absolutely required for the QT version? I'm assuming we could use the Windows version of GTK+, here: http://gimp-win.sourceforge.net/stable.html What compiler will work best?
I'd love to see a windows GTK+ port happen. I'll take a look at the code and see if It's just a simple compiling issue. If so, all you really would need is to include windows.h into the source and rev up mingw. If the software is using linux only commands, which I severly doubt) It's a calculator, not a firewall), then some serious adapting may be needed. I'd love to help in this regard. I love Qalculate on linux and I'd really love to have it when I'm on my window boxes too. I work with alot of SVG and use Calculate to tweek angles and such in Inkscape (since I HATE non-optimized lines).
I'm currently having issues with my Gmail and My Sourceforge account atm.
--Vulpes Foxnik (SFu: KinxofSepluv)
Alright, been working on this all day. Compilers having some errors in the Libqalculate, but I was able to compile both of the required CLN 1.1 with the gmp support. I'm quite new at compiling using the autoconf (used to telling gcc to directly run my code).
I honestly spent most of today getting all the required librarys required to cross compile for gtk. I even got Readline working.
My major blockade is compiling libqalculate. It just spits out errors. Currently starting from scratch again atm though. With any luck, Tomorrow I'll be compiling the actual program, not the runtime library.
Alright, I've determined the barrier of porting of the source code. Libqalcuate uses pthread.h which is incompatible directly with windows. There are api's and compatability layers that can deal with this, but I'd rather make a native support. I've never delt with threading before, but I've been reading Microsoft's documentation on porting Unix to Windows software and I believe that I have enough basic knollege about programing in C to continue. My only consern is that I don't create some sort of branched code. I'd like to keep the code base of libqalcute the ability to run on both linux and windows from the same source. From what I have read of the code, the only usage of pthread.h is in the protected thread control for the class calculator. I think that the purpose of these threads is to allow simultanious portions of the mathmatical functions for complex equasions. Please correct me if I am wrong.
I've been reading Gaim's source code to help myself understand what needs to be done porting wise, but it's not a very good example because it only uses 1 thread upon creation. I most likely need a different example.
My solution, I think would be to surround the pthread code with:
<windows thread declaration>
<pthread class declaration>
And have 2 sets of classes for waiting processes, creation, and cancling.
Unfortonatly, Windows cannot directly cancle a thread as I've taken from the MS's documentation, but rather, I have to delete the thread and this essentualy does 'the same thing.' No wonder why windows has problems. :P
Threads are only used to be able to cancel long calculations. Otherwise the user would have to kill the program if trying to calculate for example the factorial of 1000000000.
When you've successfully compiled Qalculate! for windows, I will gladly review the code and include it. Do not hesitate to ask any questions if you run into problems.
Ah. Thankyou that clears up what I need to do to port it. It should be simple enough to impliment that functionality for windows users. >^_^<
On secound thought I may be not. I just remembered that porting canceling of threads is hard in windows. XD
I'll figure out a way. Hopefully it won't need some major patch.
Just for you hopeful people, I'm still working on it. I'm having trouble building a stable build enviroment. I swear, if it's the last thing I do, I will get this to work.
What I really need to know is, at any time do the threads you cancel use the heap, Niklas?
Yes. Many objects are allocated on the heap using the "new" operator.
Alright then the windows code may end up needing different parameters since there is no safe way for threads to tell thier parent that it is safe to end. Otherwize the windows version is going to have serious memory leak problems. I'll continue to read up on it, but I don't think if I close the handle for the terminated thread, it will release the heaped files in windows.
Oh I forgot to mention, It may be possible for me to impliment a 'shared variable' through the use of the heap adressing system for cheaking this, but I think I would need a seperate thread processes to monitor this and report back, or simply just wait till it is 'safe to terminate.'
Consider that in normal use of Qalculate!, threads will not be cancelled, so you might want to accept some memory leaks initially to get a working version ready...
Actualy I think I found the solution. The two threads in windows need to be playing ping pong.
You pass the controler that it should now cancel,and since the statement is waiting for the 'ok to continue' (the pong) it can be safely terminated as in Unix. I don't like memory leaks.
I have been following this thread for the past 3 months. Any news on the progress?
Well, I sort of put it on back burner, mainly due to my studying for the ACT, and personal issues that had to be dealt with. I would continue progress now, but my main machine I was working on decided to die and I am now not on my personal machine. The motherboard I replaced it with is not able to compile with reasonable time, and is not able to handle much at all without freaking out and turning off my monitor. I should be able to continue sometime in January when my parts come in. I have 3 of 4 of the necessary files with threading finished.
I can upload a patch difference if someone wishs to continue before I am able.
I know it's a bit selfish, but I'd rather this application was not ported to Windows. It's a shame that every single killer-app for Linux is ported to Windows (because it's open source), leaving Windows users feeling superior (they have both Windows and Linux killer apps!). Qalculate is the kind of application that makes a Windows user contemplate switching to Linux or FreeBSD!
[Quote] I know it's a bit selfish, but I'd rather this application was not ported to Windows. It's a shame that every single killer-app for Linux is ported to Windows (because it's open source), leaving Windows users feeling superior (they have both Windows and Linux killer apps!). Qalculate is the kind of application that makes a Windows user contemplate switching to Linux or FreeBSD![/Quote]
ROFL +1 amen to that bro. :)
How is the porting to windows doing? I would love to have this on my win machine....and yes I also use Kubuntu!
I take then that this project has not been placed on the back burners but rather died a death. What a shame for something that could have taken some money away from the M$ coffers.
By the way Linux is NOT a bad OS, it is just not ready for the masses yet. It needs to be a lot more user friendly, although Ubuntu is getting there slowly. What will happen though if and when Linux takes over from M$ will it not also be treated as the bad lad and be mistrusted? No matter who is top dog there will always be those who fear the worst. And as for not porting software to the Windows OS this is daft. Surely the way to go is to offer lots of excellent free software, then users won't be forced to use buy M$ software to get the job done.
This was my calculator of choice for a long time. Work forced a switch over to windows. I cannot use my favorite calculator anymore :(
As I no longer use windows in my day to day use, I lost interest in porting this.
The issue is Pthreads. Windows NT 5.x does not have a proper analogue to it. Supposedly Windows NT 6.X does. You might be able to make a windows customized threading version. However for the project to be maintained between the two operating systems, the real solution would be to port them to a threading system they both can speak. I know GTK has it's own threads, however if QT 4.6 has these, I do not know.
What about Cygwin? I'm not sure about what does it actually provide, but afaik it brings a POSIX API to Windows.
(It kills 2 birds with 1 stone: it might simplify the Windows porting and makes Windows users depend on software they wouldn't need if they were on linux, mwahahaha!)
I've pretty much given up on Linux ever being a useful OS, and am planning to migrate back to Windows 7, so I'm really interested in a port of this. I'd donate a little money to anyone who can get it working.
(And seriously, no one's going to switch to a crappy OS just because it has a few nice apps. If you want more people using Linux, make Linux stop sucking so much!)
For those of you on 32-bit machines, you can run it in AndLinux for now. http://www.andlinux.org/
For people on 64-bit machines like myself, AndLinux doesn't exist, so there's no choice but to run it in a regular virtual machine. This defeats the whole purpose, though, since it's not convenient or fast, so I'm just going to go back to Google Calculator and Wolfram Alpha. :/
Let's refrain from bashing OSs. It's all about preference and choice, and in this case, the developer's choice was Linux. If you want an app ported to your favorite OS, you will need to port it yourself or find an interested developer.
I'm also interested in a Windows port although i use Linux too.
There is a Windows port of pthread ( http://sourceware.org/pthreads-win32/ ). This might help to port this app to windows.