porting Prime95 to GTK+?

ixfd64 · 2010-12-22, 22:25

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

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

The Mac OS X version of Prime95 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, Mprime 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?

tichy · 2010-12-22, 22:49

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 ?

Brain · 2010-12-23, 11:29

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".

Batalov · 2010-12-23, 18:54

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

rogue · 2010-12-23, 19:20

Quote:

Originally Posted by Brain

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".

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.

debrouxl · 2010-12-24, 08:38

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

emily · 2012-02-20, 19:16

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!

Dubslow · 2012-02-20, 19:37

Quote:

Originally Posted by emily

or even an Android remote app, lol :)

Talk about dedication

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.)

chalsall · 2012-02-20, 19:40

Quote:

Originally Posted by emily

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!

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.

ixfd64 · 2012-02-20, 23:37

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.

chalsall · 2012-02-20, 23:45

Quote:

Originally Posted by ixfd64

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.

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.

2010-12-22, 22:25	#1
ixfd64 Bemusing Prompter "Danny" Dec 2002 California 2³·313 Posts	porting Prime95 to GTK+? Currently, all of the OS-specific versions of Prime95 have different UIs. The Windows version of Prime95 puts all of the worker windows and the communication thread into one main window. I personally think this is the cleanest setup. The Mac OS X version of Prime95 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, Mprime 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?

2010-12-22, 22:49	#2
tichy Nov 2010 76₁₀ Posts	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 ? Last fiddled with by tichy on 2010-12-22 at 22:50

2010-12-23, 11:29	#3
Brain Dec 2009 Peine, Germany 14B₁₆ Posts	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".

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Porting my factorization applet to Android	alpertron	Programming	2	2013-03-19 11:28
Porting pari/gp routines into a C program??	EdH	Programming	17	2012-10-30 03:41
Possibly stupid question about porting games to Linux.	jasong	Linux	4	2006-12-23 21:24

2010-12-23, 18:54	#4
Batalov "Serge" Mar 2008 San Diego, Calif. 3²·7·163 Posts	1. No. 2. Yes, Qt. 3. No. :-)

2010-12-24, 08:38	#6
debrouxl Sep 2009 2²·5·7² Posts	I'd suggest using Qt 4 instead of GTK+ as well.

2012-02-20, 19:16	#7
emily Feb 2012 Athens, Greece 47 Posts	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!

2012-02-20, 23:37	#10
ixfd64 Bemusing Prompter "Danny" Dec 2002 California 100111001000₂ Posts	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.