Porting MeGUI to Mono

[Teegedeck]

A very humble question from a clueless n00b (i.e. me): I'd tought I'd give porting the MeGUI to Mono a shot. More for trying whether .NET and Mono really mean the advent of a Golden Age for cross-platform compatibility than anything else. What can I say, it doesn't work. :p When I try to import the MeGUI.sln MonoDevelop says 'ERROR: Could not import project:/home/[[...]/MeGUI-src.CVS/MeGUI.csproj. Sharing violation on path /home/[...]/MeGUI-src.CVS/MeGUI.csproj'.

Any ideas?

[Warren]

Any progress on this?

[shevegen]

What version btw?

We could point this out to the mono guys, maybe they will have a closer
look if more people are interested :)

[cybernut]

I'm a bit of a noob when it comes to programming and I have never tried something like mono. Since this thread was started over a year ago, perhaps maturing in the program will make it easier. Anyone want to take this on or at least help me try and do it?

Cheers

[shevegen]

I am now on Windows for some time, and I thought I'd give the whole Net/Mono Hype a try too. I be peeking at this thread every now and then :)

[Teegedeck]

No, this was an absolutely naive thought of mine. There is an actual portage project going on, though. Sharktooth has taken on the challenge. There hasn't been any release, yet.

[Sirber]

Sharktooth started the porting. Best ask him.

[RyosukeFC]

Does anyone know where we can find the main discussion of Sharktooth's efforts? Is it a thread here?

[Teegedeck]

No, the only mentions came up in the megui-development thread.

[shevegen]

Can we pull at Sharktooth's sleeve to this thread here? :D

[Major_Kong]

No, the only mentions came up in the megui-development thread.

So there is no info on the progress of the port ?


EDIT: Read the development thread a bit - http://forum.doom9.org/showthread.php?p=871372&highlight=linux#post871372

Can't find much else...

[Sharktooth]

The port is in a frozen state since i have almost no time to even develop the original megui (or even post new x264 builds), i still have no internet connection at home (...) and i had problems porting some of the new features that were added to megui at the time of branching.
Also i couldnt find a way to add automated deinterlacing/IVTCing since MeGUIx (the temp name for the port) does not rely on avisynth but only on mencoder/mplayer.
The final problem was .net 2.0. At the time of the port not all forms and controls used in megui were supported by mono (things have changed though) so i started to redesign the gui (gtk# - and that was a real pain) but that lead to more and more changes to the code...
Actually if you want megui on linux you can import the project in monodevelop (ensure you have the VERY LATEST mono and monodevelop versions), adjust some "quirks" and build it.
You will need wine to run all the non native components required by megui.

[buzzqw]

deint routines of megui is based on Berrinam Bdeint
and source code ( D code) is avaiable.. it could be translated for mono... (i hope)... or at least use bdeint.exe thu wine


BHH

[Sharktooth]

well, porting megui to mono is pretty easy now since mono supports most of the .net 2.0 controls and forms, also it seems all tools can run thru wine, so importing the project and building it should not be so hard.

[mod]

Just a question: why, having to change, you didn't choose Qt? They allow really fast gui development.

[Sharktooth]

gtk# is part of mono

[Henrikx]

@Sharktooth
Big Thanks for your work !!!
Perhaps that is interesting.
First release of Qt4 bindings for .NET (MONO)
http://cougarpc.net/qyoto/

[Sharktooth]

ill have a look but i dont have time to re-make the gui once more...
it would be a good idea starting from scratch and trash all the changes i made since mono now supports most of the .net 2.0 stuff including windows forms.
a better idea is to wait until mono 2.0... but 1.2.4 is just enough for megui.
however try using MoMa (http://www.mono-project.com/MoMA) to scan megui and you'll have better idea ;)

[Major_Kong]

So until Mono 2.0 and/or Avisynth 3 there won't be a MeGUI port to linux ?

[Sharktooth]

If you mean a "native" port then no. However megui can be actually built for linux and it would require wine for the .dlls and external software.

[Major_Kong]

I was thinking more on the lines of a cross-platform version... but i got it.

[Henrikx]

Perhaps any news ?

[Sharktooth]

yes, as you can see from the recent svn logs mutant_fruit is working on the mono compatibility.

[Henrikx]

Good news, thx.

[Major_Kong]

yes, as you can see from the recent svn logs mutant_fruit is working on the mono compatibility.

How is Avisynth being handled ?

[JoeBG]

How is Avisynth being handled ?

MeGUIx will be without avisynth.

... MeGUIx (the temp name for the port) does not rely on avisynth but only on mencoder/mplayer...

I hope they will implement as much mencoder filter as possible.

[Sharktooth]

No, MeGUIx is a fork of MeGUI and im the only one working on it while mutant_fruit is working on making MeGUI codebase compatible with Mono.
When using Mono to launch MeGUI, Avisynth should be handled by Wine.

[Major_Kong]

Is there an ETA on that ?

[Sharktooth]

MeGUIx is in a frozen state.

[JoeBG]

MeGUIx is in a frozen state.

Bad news :o

[Mutant_Fruit]

I have a few patches to get MeGUI working on Mono. At the moment, there is one blocking issue which prevents MeGUI working in mono. I've submitted a patch to mono (which hasn't gone through yet) which resolves that issue. Once that patch is in, MeGUI will run out-of-box on mono.

MeGUI itself needs a handful of relatively minor changes (basically refactoring/removing calls to native windows libraries) to make it work. I have patches for those which i have to apply.

After that, a combination of wine and 'native' libraries/apps should do the job.

I've been away for the last while due to holidays and a death in the family, but over the next week or so i should be able to merge the rest of my patches into MeGUI. I can't give an ETA as to when everything will be ready though.

[Major_Kong]

Thanks for the reply. (to both)

Just one question, in your opinion would a more linux "native" gui for mencoder/x264 would still be a much better solution than using MeGUI ?

[Mutant_Fruit]

Thanks for the reply. (to both)

Just one question, in your opinion would a more linux "native" gui for mencoder/x264 would still be a much better solution than using MeGUI ?
Depends on what you mean by 'native' ;)

I'm not sure how good the separation is between the GUI code and program logic in MeGUI. I know in some places, they are quite entwined. However, if those places are small, it'd be a relatively simple task to create a 'native' linux GUI using GTK# which is similar to the existing GUI. This would give you a native look and feel and possibly allow for better integration into gnome/kde.

[Major_Kong]

I meant 'native' in the GUI sense, and in the sense of not relying on windows specific programs.
My question is if there's a real advantage on using a linux gui of mencoder similar to megui.

[Mutant_Fruit]

I meant 'native' in the GUI sense,

So i assume that means you want a GTK based GUI, in that case, yes, it is doable. Whether anyone has the time or energy to do it, that's another question. It'll more than likely require substantial refactoring in MeGUI.


and in the sense of not relying on windows specific programs.

Well, once again this depends on how MeGUI is laid out. If it is done 'properly', then it could be as easy as writing the wrapper to call the linux version of the app which you've either compiled and installed yourself, or used a package manager (YaST/Synaptic/whatever) to install. However, certain things just aren't available on *nix, such as avisynth. Therefore wine will have to be used for that, at the very least.


My question is if there's a real advantage on using a linux gui of mencoder similar to megui.

That's up to you to decide. I can't do a feature comparison to tell you if MeGUI would be better or not. I can't even tell you what linux has available, i'm not hugely familiar with the linux side of video encoding. However, it'll be another choice. Whether you choose to use MeGUI or not, at least the option will be there.

[nm]

I meant 'native' in the GUI sense, and in the sense of not relying on windows specific programs.
My question is if there's a real advantage on using a linux gui of mencoder similar to megui.
The only real advantage of a "native" GUI is avoiding the overhead of installing and running Mono. I don't know how Mono and its GUI libraries behave currently, but I'm pretty sure that a simple GTK+ or FLTK app written in C/C++ would load faster and use much less memory. Whether that difference is of any significance, is up to you and your hardware.

[Mutant_Fruit]

The only real advantage of a "native" GUI is avoiding the overhead of installing and running Mono. I don't know how Mono and its GUI libraries behave currently, but I'm pretty sure that a simple GTK+ or FLTK app written in C/C++ would load faster and use much less memory. Whether that difference is of any significance, is up to you and your hardware.
Well... the exact same can be said for the Windows MeGUI. If you have a 'native' program, you can avoid the overhead of the .NET framework. That argument can be used against every application written in any managed language. Bearing in mind that a simple GUI does not do any encoding, i don't think speed/memory would be in any way relevant ;)

Also, just to clarify, when people say 'native' do they mean 'native look and feel', or do they mean 'native code'.

[shevegen]

I am a little bit confused, will it require wine + .dll, or only mono, or both?

It is no problem for me either way (the latest of wine, mencoder, windows .dll, mono all work here nicely) but I am just confused right now :-)

By the way, I dont think this "faster or slower" debate is of much use, without real-life usage examples _and_ benchmarks (if they are significant). I could play Warcraft 3 faster with wine on linux, than natively under windows :) (though not in late game 4 vs 4, then it lagged significantly worse than the native, but until then, it was faster)

[nm]

I am a little bit confused, will it require wine + .dll, or only mono, or both?
Both. You'll need Wine to use AviSynth and Mono for MeGUI itself.

By the way, I dont think this "faster or slower" debate is of much use, without real-life usage examples _and_ benchmarks (if they are significant).
Sure, but I don't see a debate going on. I agree with Mutant_Fruit completely. Mono (and Java) may be too heavy for my taste and my old hardware, but I don't use encoding GUIs anyway. People who use this stuff usually have fast machines with enough RAM.

[Mutant_Fruit]

I am a little bit confused, will it require wine + .dll, or only mono, or both?

The .NET framework is required on linux just as it is on windows. Mono is one way to fulfill that requirement. Wine will more than likely be used to allow certain windows apps to be executed on linux so MeGUI can offer it's full featureset.


By the way, I dont think this "faster or slower" debate is of much use, without real-life usage examples _and_ benchmarks (if they are significant).
Faster or slower is irrelevant - a GUI is a GUI. The GUI does no video processing. The only place where speed matters is in the encoders, and they have more or less the exact same speed (assuming the same compilation options) no matter what platform their on.

Anyway, most of this is a moot point until there's something running ;)

[stax76]

Sure, native code loads fast and requires little memory but it's also a lot bigger in filesize. Startup time and memory consumption isn't bad for managed applications when the application is properly designed. There are enough sluggish and resource hungry native resource hog applications like acrobat reader, not because native code doesn't perform well but because the applications are badly designed.

Productivity ist one of the most important factor when chosing a development platform, .NET is the most productive platform, easily 2 times more productive than C++. The user only notices the application need some big framework but he don't realize the application has a very small filesize and has two times more features then would have if it were written with C++. Imagine megui supporting only half of the x264 switches and only half of the formats.

[Henrikx]

NET is the most productive platform, easily 2 times more productive than C++.
Why ?
For system independence ist QT ideal, i think better then net.
Or have I misunderstood you?

[Mutant_Fruit]

Why ?
For system independence ist QT ideal, i think better then net.
Or have I misunderstood you?

Managed languages are more productive than unmanaged languages as a whole slew of possible bugs are immediately rendered impossible.

QT is just another framework which uses C++, an unmanaged language. Productivity wise, a good C#/Java developer can create a program faster than a good C++ developer and with less possibility for bugs.

As for which is 'better' in a cross platform sense, who knows. You can argue whatever way you want with that. A C# app is compile once - run everywhere. A C++ app is compile everywhere run once.

[Henrikx]

Thanks for the explanation!

[stax76]

Why ?
For system independence ist QT ideal, i think better then net.
Or have I misunderstood you?

You have to work a year or two with VB .NET or Delphi and get to know all productivity related features in order to understand that, Microsoft makes constant progress in this area, the new extension methods or linq for instance allow for much more elegant code.

Only thing I can really recommend for a portable GUI application is wxPython. wxWidgets use native widgets mostly, wxWidgets lack solid .NET bindings but the python bindings are robust, it became quite popular. Python has many fundamental flaws but also many nice features, it's much more convenient then C++ doing a GUI.

I know native Win32 widgets both from developer and user side quite well and know exactly which features a control has and what keyboard and mouse tricks it can perform. I'm already pissed of by many Delphi applications as many controls behave awkward. I use Firefox and Thunderbird and XUL sucks even more as the controls support little Win32 UI mouse and keyboard behavior and tricks. All this differences ultimately reduce work flow and productivity. The nuances are distracting already enough, not to mention more obious differences you can find on different platforms so portable applications are doomed to leave a fould taste unless you spend a significant time to compensate platform differences.

[Henrikx]

Thanks again.

[Mutant_Fruit]

Only thing I can really recommend for a portable GUI application is wxPython. wxWidgets use native widgets mostly, wxWidgets lack solid .NET bindings but the python bindings are robust, it became quite popular.

One complaint i heard about wxwidgets is that they are lowest common denominator. Take a textbox as an example. wxwidgets provides an API which is compatible with the Windows textbox, the MacOS textbox and the GTK textbox. Therefore, the wx api cannot expose fancy features that the windows textbox might have because the MacOS/GTK textboxes don't.

I've never used wx myself, but that's what i've heard off a 2-3 people who have.

[cogman]

Are you going to be able to specify a native built encoder (IE x264) with the mono friendly MeGui? It would be nice to limit wine usage to avisynth and its scripts. (as nero AAC encoder is also available in a linux version)