Cross-platform gui?

[ceztko]

Toni, would you ever consider switching the gui to a cross platform gui toolkit?
Gtk, qt and even wxwidgets (which I personally don't like) are very mature nowadays, and often they provide better and cleaner api than win32 native counterpart. I'm not talking about the e-uae gui, but a rewrite from scratch that resemble actual winuae gui (and features).

And, if for your reasons you aren't interested in starting such a conversion, would you accept working in cooperation with other folks if someone provide you an almost done rewrite of the gui in another toolkit (sure, only if the code is good enough...)?

[Toni Wilen]

Originally Posted by ceztko

Toni, would you ever consider switching the gui to a cross platform gui toolkit?
Gtk, qt and even wxwidgets (which I personally don't like) are very mature nowadays, and often they provide better and cleaner api than win32 native counterpart. I'm not talking about the e-uae gui, but a rewrite from scratch that resemble actual winuae gui (and features).

And, if for your reasons you aren't interested in starting such a conversion, would you accept working in cooperation with other folks if someone provide you an almost done rewrite of the gui in another toolkit (sure, only if the code is good enough...)?

Answer to first part: Most likely I won't ever rewrite the GUI yet again. It is too painful.

Second part: 'perhaps'. But it must not require any extra DLLs. (and static linking must not mean 1M+ bigger exe..) and it MUST look "normal". I really hate Windows applications that have non-standard looking GUI (especially most Java programs..)

[MickJT]

We could do with a GUI with theming support.. Look at winamp. Make WinUAE's GUI look like OS3.x, that'd be interesting.. Can't say i'd use it though

[ceztko]

Originally Posted by Toni Wilen

Answer to first part: Most likely I won't ever rewrite the GUI yet again. It is too painful.

Ok, fair.

Originally Posted by Toni Wilen

Second part: 'perhaps'. But it must not require any extra DLLs. (and static linking must not mean 1M+ bigger exe..)

This could be too much restrictive. But there could be other options to investigate.

Originally Posted by Toni Wilen

and it MUST look "normal". I really hate Windows applications that have non-standard looking GUI

This is the problem of the toolkit using (or not using) underlying native widgets of the platform. For toolkits developers, this choice has pros and cons, very well explained here. The main advantage of not relying on native widgets is to provide a single theming mechanism for conformity (and less troubles) among the supported platforms. For example, wxwidgets is using native widgets on windows while GTK and QT are NOT. Again, this is not a problem if you want to code in GTK or QT on windows and want to use its native styles, as smart themes have been coded for these toolkits that integrate perfectly with windows native themes engine, "stealing" settings and preferences. Some screenshots of the solution for GTK.

Originally Posted by Toni Wilen

(especially most Java programs..)

Speaking about Java, that could the problem of (hopefully old) Java programs coded with AWT/Swing that do not choose correctly Look&Feel aspect, maybe because they are relying on defaults of the sdk version they were compiled on. AWT/Swing provide its own theming mechanism, but take a look of what can be done using third party Look&Feel aspects.
Using other toolkit, such as SWT, you can directly use native widgets of the underlying platform. Other differences between AWT/Swing and SWT? AWT/Swing is just a love to code with, probably the most clean/polished/easy to use toolkit on the earth. SWT is a lower level toolkit, and it's part of the more complex Rich Client Platform (RCP) framework, but eclipse, azureus and other famous java apps are coded with it.

[Pyromania]

Toni I thought the next version of WinUAE was done 100% in Java? Just kidden.

[ceztko]

Originally Posted by Toni Wilen

It is too painful.

Another question: surely you know it's very easy to integrate C++ and C code; would be a problem for you to switch to C++ just for the gui?

[Toni Wilen]

Originally Posted by ceztko

Another question: surely you know it's very easy to integrate C++ and C code; would be a problem for you to switch to C++ just for the gui?

It won't be THAT easy..

[Ed Cruse]

I'm sorry, but I have to say this.

Several times now I've read threads where people have wanted the GUI done over, I don't understand this. The GUI looks good enough, it works good enough, WinUAE can be configured easily, so what's the big deal? The more time Toni spends doing the GUI less time he's spending on the emulator itself. Lets face it, the emulator part is the only thing that really counts. If people are going to spend all their time staring at and using the GUI then they shouldn't be using the emulator to begin with.

It's not about the GUI it's about the Amiga emulator, the GUI is simply a tool. This is my main gripe about software in general, to many resources are put into making the GUI look good and not enough are put into making the GUI and program work good. Example-Windows.

[paranoid]

It doesn't seem like there's much danger of Toni being so consumed by the GUI as to let other work on WinUAE slide... But I do agree that for the emulator itself, the GUI needs to only be functional and that it is. It's the job of a frontend like Lemonade or Gamebase Amiga to look flashy or easy or whatever. Someone could even do a frontend that has some new GUI and just writes a new config and launches WinUAE.

But I think this has more to do with trying to port WinUAE or perhaps just the beginning steps to remove dependency on Windows. I'm no programmer, but isn't that the idea of a crossplatform GUI?

[ceztko]

Originally Posted by Ed Cruse

The GUI looks good enough, it works good enough, WinUAE can be configured easily, so what's the big deal?

The deal is having [Win,E-]uae source in one tree. This would pose in serious consideration the need for a refactorizing of the source tree, eventually ending in having better source (~=better future development).

Originally Posted by Ed Cruse

The more time Toni spends doing the GUI less time he's spending on the emulator itself.

In fact I asked what he thought about other people doing the conversion...

Originally Posted by Ed Cruse

It's not about the GUI it's about the Amiga emulator, the GUI is simply a tool.

You simply excluded portability from your reasoning. And portability often add great value to software. It was a great value that original uae (unix amiga emulator) was written in portable ansi C, so today you can have Win-uae, no?

[ceztko]

Originally Posted by paranoid

I'm no programmer, but isn't that the idea of a crossplatform GUI?

Yeah.

[ceztko]

Originally Posted by Toni Wilen

It won't be THAT easy..

That could depends on how you thought communication core --> gui (dunno, at the moment). There are lot of programs having core in C and gui in C++, but that was only an hypothesis. Gtk, for example, are in pure C, so using it would not pose a problem. For now, I can say I could be interested in doing such a work, but I'll start to investigate only after my degree.

[thor]

There are many other Windows-dependent features in WinUAE besides the GUI. Porting the GUI would only be a minor and easy task and doesn't make WinUAE as a whole portable

[Ed Cruse]

I think it would be very difficult to make WinUAE portable. I believe WinUAE makes many windows API calls, which C/C++ don't have equivalents to. C/C++ are basically dos types of languages and have no way of dealing with threads and GUIs, (ANSI C/C++). I suppose there are systems of libraries out there that are cross platform but they're going to be a lot different then the API calls. It will take a serious amount of rewriting of WinUAE. Is it really worth it?

For as much as I don't like Windows or PCs, they're still the best things going. The hardware is the most advanced and everybody makes drivers for windows, so if you have a running windows then WinUAE will most likely work.

I can't believe I just wrote the last paragraph.

[ceztko]

Originally Posted by thor

There are many other Windows-dependent features in WinUAE besides the GUI. Porting the GUI would only be a minor and easy task and doesn't make WinUAE as a whole portable

There are lot of windows specific features that simply don't need to be ported and others that can simply be ported later . Don't forget it already exist e-uae. Listen to me, the reasons e-uae and winuae aren't on the same source tree are:

• suboptimal code organization;
• platform dependent gui(s).

[ceztko]

Originally Posted by Ed Cruse

I can't believe I just wrote the last paragraph.

I can't believe you just wrote the whole post. A part lot of untrue and totally wrong assertions you typed (C/C++ are languages, not libraries), please note Winuae is originally a fork of UAE, the unix amiga emulator. If these days Winuae is full of windows specific features, this just does NOT mean core emulations isn't portable as it has always been, as stated often by Toni. Users of others platforms can just live without these features, unless someone write the specific code for them, and this absolutely doesn't break development on windows side. It's incredible how many users (and developers, sometime...) are so reluctant just listening the word(s) "cross-platform". Even if not complex as winuae, scummvm is a GREAT piece of software and it does run on 15 totally different platforms (just counted now), without slowing development at all.

However...Toni answered all my questions, so for me this thread can be safely closed.