porting Prime95 to GTK+?
 

Currently, all of the OS-specific versions of Prime95 have different UIs.

The [B]Windows version of Prime95[/B] puts all of the worker windows and the communication thread into one main window. I personally think this is the cleanest setup.

The [B]Mac OS X version of Prime95[/B] uses a discrete window for each thread. This results in a cluttered working environment, especially for multi-core systems. For example, an octal-core Mac Pro would have nine separate windows (one for each worker thread plus the communication thread). Yikes!

Finally, [B]Mprime[/B] does not have a GUI to begin with.

It would be better if Prime95 had a consistent GUI across all operation systems. One way to do this is to port Prime95 to a cross-platform GUI toolkit (GTK+ is one of them).

What does George think?

Hi,
if anything, I'd opt for Qt4. Not only it is visually prettier, but enforces priettier code/design patterns as well :)

BTW, do we have someone familiar with Model/View/Controller on board ?

Java & Poll
 

Java is also out there...
I would suggest an open development infrastructure, maybe at sourcefourge.
GUI technology also depends on the possible manpower. We could create a poll:
1. Do we need a cross-plattform-GUI?
2. Can you participate in development? In which technology?
3. If 2. is true, are you willing to help?
By the way, I tend to answer question 1. with "No".

1. No.
2. Yes, Qt.
3. No. :-)

[QUOTE=Brain;243086]Java is also out there...
I would suggest an open development infrastructure, maybe at sourcefourge.
GUI technology also depends on the possible manpower. We could create a poll:
1. Do we need a cross-plattform-GUI?
2. Can you participate in development? In which technology?
3. If 2. is true, are you willing to help?
By the way, I tend to answer question 1. with "No".[/QUOTE]

If the tool to create such a GUI means that the same source can be built on Windows, Mac, Unix, etc., then I would answer question 1 with a "Yes". That basically means that the code is highly portable. I would love to do that with PFGW myself, but it is a big undertaking.

I'd suggest using Qt 4 instead of GTK+ as well.

Ideally, I'd prefer to keep the Mprime/Prime95 engine and the GUI separate, at least on MPrime (GNU/Linux). Kinda like Tor/Vidalia works. So I'd want to be able to run MPrime on the terminal while also being able to control or watch it through a GUI or web app, or even an Android remote app, lol :)

As for the toolkit, I'd prefer GTK+ and definitely neither Java nor Python. The best language for GTK+ development is Vala but it's still in development, so C++ with gtkmm would be great I suppose, as long as there aren't too many GNOME dependencies (so you can run it on XFCE as well), but it should follow the GNOME UI guidelines.

But having a GUI in Qt or anything else is more useful than having no GUI at all, so I'd definitely welcome a Qt GUI as well. In fact the prototype for an specialized editor app I made for myself (but also GPL-published) is on Qt, albeit I plan to make the final project on GTK+ someday.

The reason I prefer GTK+ is because I like its looks better than Qt, I dislike having Qt apps on GNOME (I use LMDE with GNOME, not that I dislike KDE in fact I have it on other computers), and I prefer a toolkit developed by a community to Qt which was developed by a company.

In the mean time, perhaps it would be easier to make an ncurses TUI (text user interface) for MPrime before doing the GUI.

Also think that many people run MPrime on machines without a GUI, for example I was running it on a dedicated server I had and of course I didn't have X there. So a TUI would be beneficial for those running it on servers as well!

[QUOTE=emily;290134]or even an Android remote app, lol :)
[/QUOTE]
Talk about dedication :smile:


Keep in mind that there is little practical advantage to a GUI, except one major point: Individual worker control, and since it is a practical consideration, implementing that on the CLI would be important (for e.g. servers as you said). Otherwise I don't see a practical reason for a GUI, but of course if you have the time, feel free :) (And if you have the time/start the project, you can decide on whatever tools you want, but of course others will have a preference.)

[QUOTE=emily;290134]Also think that many people run MPrime on machines without a GUI, for example I was running it on a dedicated server I had and of course I didn't have X there. So a TUI would be beneficial for those running it on servers as well![/QUOTE]

I completely agree. But please keep in mind:

1. Most people who run Linux/Unix are comfortable with a text-based command line environment.

1.1. Let's be honest -- Linux has lost the "Desktop" (actually, it never really had it). But man, does it ever own the server space.

2. Any "GUI/TUI" which is to be integrated into mprime must pass by George's scrutiny.

3. Any "GUI/TUI" which is not integrated into mprime must work with what it has available to it. This is basicly limited to parcing the prime.txt and local.txt files, the prime.log file, the worktodo.txt file, and (to add work) leverage on the worktodo.add feature.

3.1. mprime has no API.

For most users, the lack of a GUI wouldn't be that much of a hassle. But if you have one of those 48-core Linux servers, etc., then things can get *very* messy.

[QUOTE=ixfd64;290173]For most users, the lack of a GUI wouldn't be that much of a hassle. But if you have one of those 48-core Linux servers, etc., then things can get *very* messy.[/QUOTE]

I would argue that if you have "one of those 48-core Linux servers", if you are not comfortable at the command line then you shouldn't be in control of such a powerful machine.

The problem is, how do I visualise what's going on on my 48 core beast?

[QUOTE=Christenson;290212]The problem is, how do I visualise what's going on on my 48 core beast?[/QUOTE]
You need an [URL="http://en.wikipedia.org/wiki/X-ray_microscope"]x-ray microscope[/URL], and you need to put the beast in vacuum in a beryllium box, that is totally transparent for x-rays. Then you can see exactly what's going on inside.

[QUOTE=Christenson;290212]The problem is, how do I visualise what's going on on my 48 core beast?[/QUOTE]

I do it roughly this way:
I use a script which tells me the progress for every worker.
mprime is started with the command line ./mprime -d | tee log.txt
Then you can check the output/percentage for each worker.
It is just text based (bash script), but it could be visualised as well.
If you need code snippets just tell me.