MeGUI development

[Kurtnoise]

why not create your own batch file ?

I believe that the pause is there for a good reason...

[check]

with regards to alternative development communication methods, I am happy to setup a dedicated megui forum on the mewiki box if you would like. The other advantage of that would be it would allow people with problems to have each their own thread, which makes tracking them easier. On the other hand, it moves megui away from doom9, which could be a bad thing..

[bob0r]

why not create your own batch file ?

I believe that the pause is there for a good reason...

Could you explain that reason please?

[berrinam]

Could you explain that reason please?

The only reason I know is that the pause after compiling megui allows you to see if there were any errors in compilation. However, I think this is a relatively unimportant reason since most people develop megui with an IDE.

I would be happy to remove the pauses, if the other devs don't object.

[Sharktooth]

it's ok for me. however if you want the csc output, it can be added to a compile.log file using the good old stdout redirection...

[Sharktooth]

@devs: what about replacing mediainfowrapper with an older version that "seems to work" with Vista?

[bob0r]

@berrinam
Ok, thats why you can run it from start>run>cmd
Please remove the pause. Thanks.

[Kurtnoise]

I would be happy to remove the pauses, if the other devs don't object.
ok for me too...

[Kurtnoise]

what about replacing mediainfowrapper with an older version that "seems to work" with Vista?
honestly, the problem remains even with the old one...I mean that you're are able to have the preview but when you restart MeGUI randomly, that raises an error.

I tried also the C# how-to use MediaInfo included into MediaInfoLib trunk and traced the functions. Seems that the problem is after the Opening...


iirc, it's due to an issue with the openFileDialog according to this post (http://forum.doom9.org/showthread.php?p=1062833#post1062833). So, how to code a new openFileDialog, berrinam ?

[berrinam]

According to winnydows, just run the openFileDialog in an external application (invoked by commandline). I've written a quick patch which changes some of the dialogs to use this approach; get that patch here (http://megui.org/berrinam_patches/openfiledialog/). It works by running a program called "openfiledialog.exe" in the same folder as megui.exe. The sourcecode for this executable is given below.

using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;

namespace OpenFileDialog
{
class Program
{
static void Main(string[] r)
{
System.Windows.Forms.OpenFileDialog d = new System.Windows.Forms.OpenFileDialog();
d.InitialDirectory = r[0];
d.Title = r[1];
d.DefaultExt = r[2];
d.FileName = r[3];
d.Filter = r[4];
MessageBox.Show("Special ofd");
DialogResult dr = d.ShowDialog();
string[] s = new string[6];
Console.WriteLine("{0}\n{1}\n{2}\n{3}\n{4}\n{5}\n", d.InitialDirectory, d.Title, d.DefaultExt, d.FileName, d.Filter, (dr == DialogResult.OK ? "OK" : "Cancel"));

}
}
}

This program gives you a message before opening the dialog, so that you know it is being used. If it isn't being used somewhere it should be used, the solution is simple: just rename any instances of OpenFileDialog to CmdOpenFileDialog, and it should all work out fine.

Hope that helps. If it works, we can make it more reliable.

[berrinam]

with regards to alternative development communication methods, I am happy to setup a dedicated megui forum on the mewiki box if you would like. The other advantage of that would be it would allow people with problems to have each their own thread, which makes tracking them easier. On the other hand, it moves megui away from doom9, which could be a bad thing..
I'm not too fussed either way. The important thing for me is just that people post their bug reports and feature requests on the SF tracker.

[berrinam]

Please remove the pause. Thanks.

Done.

[Kurtnoise]

Hope that helps. If it works, we can make it more reliable.
For the moment, that works fine...mainly tested with the old and the new MediaInfo and the old and fresh MediaInfoWrapper compile.

Anyway, it's very strange this behaviour...maybe it's that (http://www.tmssoftware.com/atbdev6.htm) (old/new form) ? or a bug with the Framework...dunno frankly and I don't want to install the 3.5 right now to check this out.

[Sharktooth]

stable:
0.2.6.1039
- (berrinam) Increase sensitivity of DAR. (fixes #1832218)
- (Kurtnoise) [x264] checked = false for Turbo with manual multipasses modes & cosmetics.
- (Kurtnoise) [ProgressWindow] New format for Time Elapsed/Remaining.
- (Kurtnoise) [BitrateCalculator] DTSBlockSize != AC3BlockSize

Dev:
0.3.0.0001
- (berrinam) Sliding window time estimation instead of based on entire code. (#1832899)
- (berrinam) Add extra files for dragdrop and dropdown persistence
- (berrinam) Remember columns position for the job queue (#1817092)
- (berrinam) Dragdrop support in the bitrate calculator (#1819618)
- (berrinam) The custom filesizes, ARs, and FPSs in the dropdown comboboxes are now persistent. (#1822492)
- (berrinam) Make mux window output file editable.
- (berrinam) Change tools windows from modal dialogs to standalone windows. (#1822493)
- (Kurtnoise) [LogItem] added the Date.
- (berrinam) Commit the newlog patch. Changes:
- new, hierarchical log
- moved delete intermediate files stuff to cleanupjob
- Log and Error removed from StatusUpdate -> use log.LogValue("Encoder log", encodeLog), and log.Error(...) instead
- added a non-null check to Util.ThreadSafeRun
- (Kurtnoise) ASS & SSA support for the MKV muxer.
- (Kurtnoise) [MeGUISettings] removed divxMuxerPath.
- (Kurtnoise) [OneClick] sorted = true for Audio codecs.
- (Kurtnoise) Added more bitrate values for AC3 encoders.
- (Kurtnoise) Aften support as AC-3 encoder (FR #1663719)
- (Kurtnoise) Delays on audio output filenames now have meaning and are checked for correctness (implements #1819281)
- (Kurtnoise) Changed the default bitrate for FFAC3 (256 to 384 kbps).
- (Kurtnoise) Audio codecs List refactoring.

[berrinam]

Nice long changelog. Looks good. :)

[Kurtnoise]

*Note for the end users* : all bugfixes included in the stable release are also included in the dev build...:)

[Sharktooth]

well... that was somewhat implied...

[Kurtnoise]

:p


I've written a quick patch which changes some of the dialogs to use this approach; get that patch here (http://megui.org/berrinam_patches/openfiledialog/).
Here is (http://kurtnoise.free.fr/index.php?dir=MeGUI/&file=openfiledialog_r401.patch) an update against the last rev including pstart.CreateNoWindow = true;

[wiak]

---------------------------
Fatal error
---------------------------
MeGUI encountered a fatal error and may not be able to proceed. Reason: Kan ikke laste inn filen eller samlingen ICSharpCode.SharpZipLib, Version=0.85.4.369, Culture=neutral, PublicKeyToken=1b03e6acf1164f73 eller en av avhengighetene. Manifestdefinisjon til samlingen som ble funnet, samsvarer ikke med samlingsreferansen. (Unntak fra HRESULT: 0x80131040) Source of exception: megui stacktrace: ved MeGUI.UpdateWindow.SaveNewFile(iUpgradeable file, Stream data)

ved MeGUI.UpdateWindow.InstallFiles(SortedDictionary`2 groups)

ved MeGUI.UpdateWindow.BeginUpdate()

ved System.Threading.ThreadHelper.ThreadStart_Context(Object state)

ved System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

ved System.Threading.ThreadHelper.ThreadStart()
---------------------------
OK
---------------------------

[Kurtnoise]

wrong thread + having an error message without a short description of what you do is useless.

[Kurtnoise]

Some news...

For the moment, that works fine...mainly tested with the old and the new MediaInfo and the old and fresh MediaInfoWrapper compile.

Anyway, it's very strange this behaviour...maybe it's that (http://www.tmssoftware.com/atbdev6.htm) (old/new form) ? or a bug with the Framework...dunno frankly and I don't want to install the 3.5 right now to check this out.
Finally, I jumped to the Orcas testing (seems very good btw) and my assumption about Framework issue seems to be correct.

Now, having the Framework 3.5 installed and running on Vista, openFileDialog issues seem to be gone (w/ MediaInfo library and his wrapper 0.7.5.5). :) but I need to test this more extensively.

Extra Notes:
With the openfiledialog command line tweak, MeGUI hangs with the last framework. Dunno why...
One of the good trick with Orcas (MSVC9) is that we can specify the target Framework (either 2.0, or 3.0 or 3.5) during the compilation. Keep in mind also that 3.0 or higher is *not* compatible with win2k or lower.
Now, I got the beautiful new Forms as described here (http://www.tmssoftware.com/atbdev6.htm)...That's great. :p
MSVC 2008 Express Edition is free...so it's worth to try it.

[berrinam]

MSVC 2008 Express Edition is free...so it's worth to try it.Does it come with C# 3.0 or is that not out yet? I'm very much looking forward to the type inference in C# -- it'll help a lot with the generics code in MeGUI.

[Eamon21]

I've just about finished the first version of my transcode tool, it works for what I need to do, just adding extra error checking etc. for when someone inevitably tries to do something I hadn't intended with it.

There are a few things I have come across in doing it that I would like to bring up however as suggestions for improvement.

Firstly, the video encoding job always takes as input an *.avs file even if that file is only a temporary file. the AviSynthScriptEnvironment is just as capable of handling a script passed as a string rather than by a file and to me it would make more sense this way for scripts of a transient nature. I currently create a temporary script based on a template for transcoding and then delete the file afterwards.

Secondly, with the avssettings, while they contain bools to indicate if resizing, colourcorrection etc are required, there is not enough info to apply them. Take for example resize, there is a bool to indicate it should be done and also the filter that should be used but you can't specify the size.

I understand that the AVSprofile was probably only ever intended to be used from the AVISynth Script Creator tool which does provide these extra settings, but in my opinion they should be in the profile, and possibly overridden if needed.

Eamon

[Kurtnoise]

@Eamon: I'm looking forward to test it...:) Keep up the good work.


Does it come with C# 3.0 or is that not out yet? I'm very much looking forward to the type inference in C# -- it'll help a lot with the generics code in MeGUI.
Framework 3.5 is out, yes. If you download the complete iso DVD, I'm pretty sure that it's included with it. Otherwise, you have to install it before MSVC9...

[Sharktooth]

got the dvd iso and the framework. thanks.
if the new .net framework ensures a better megui "compatibility" with Vista, we should move to it since the only big problems we have are with Vista...

[Eamon21]

Don't forget though that the minimum requirements for .NET 3.0 is Windows XP SP2, moving to .NET 3 would kill off support for win2k and earlier. Might be worth it though as according to http://marketshare.hitslink.com/report.aspx?qprid=2 there are only a small precentage running anything windows based older than XP, and more vista users than win2k and earlier anyway.

Eamon

[Doom9]

The Express Tools ISO you can download includes everything.. the 4 different express editions and of course the framework 3.5 - which in turn brings C# 3.0. I'm about to upgrade my work machines..

[Eamon21]

patch to fix bug 1836041 submitted.

...and one for 1832675

Eamon

[Kurtnoise]

both applied...thanks.

[berrinam]

I've just about finished the first version of my transcode tool, it works for what I need to doGreat! I look forward to seeing it.

just adding extra error checking etc. for when someone inevitably tries to do something I hadn't intended with it.

There are a few things I have come across in doing it that I would like to bring up however as suggestions for improvement.

Firstly, the video encoding job always takes as input an *.avs file even if that file is only a temporary file. the AviSynthScriptEnvironment is just as capable of handling a script passed as a string rather than by a file and to me it would make more sense this way for scripts of a transient nature. I currently create a temporary script based on a template for transcoding and then delete the file afterwards.The problem is that the commandline encoders take an input filename, not an input script, so there is no way to pass in a temporary script to most of them. Most of the command line encoders don't have direct access to the AviSynth environment in the way megui does, but they often just access it via the AVIFile interface, which doesn't allow file-less scripts. So I'm afraid your current solution is the best.

Secondly, with the avssettings, while they contain bools to indicate if resizing, colourcorrection etc are required, there is not enough info to apply them. Take for example resize, there is a bool to indicate it should be done and also the filter that should be used but you can't specify the size.It really depends on where the settings are used. For the avs creator, the settings are appropriate. However, the OneClick encoder adds a setting for the resolution. I'm not sure of the neatest way to handle all of this, but different tools certainly need different settings. I'm not yet convinced that the output resolution should be a setting in the avssettings.

[berrinam]

Wheee, C# 3.0 is fun.

This 2.0 code:
info.VideoOutputChanged += new StringChanged(delegate(object _, string val)
{
videoOutput.Filename = val;
});

turns into

info.VideoOutputChanged += (_, val) => videoOutput.Filename = val;

See what else there is (http://en.wikipedia.org/wiki/C_Sharp#C.23_3.0_new_language_features). Some of the highlights are type inference ('var'), automatic properties, and extension methods.

[Eamon21]

The problem is that the commandline encoders take an input filename, not an input script, so there is no way to pass in a temporary script to most of them. Most of the command line encoders don't have direct access to the AviSynth environment in the way megui does, but they often just access it via the AVIFile interface, which doesn't allow file-less scripts. So I'm afraid your current solution is the best.
OK, makes sense in that respect. I guess I was getting that idea from the AviSynthAudioEncoder class which creates an AVS script to encode the audio, but never actually has to write the script to file.

It really depends on where the settings are used. For the avs creator, the settings are appropriate. However, the OneClick encoder adds a setting for the resolution. I'm not sure of the neatest way to handle all of this, but different tools certainly need different settings. I'm not yet convinced that the output resolution should be a setting in the avssettings.For me it depends on where the settings are used, if they will actually go into the AVS script (resize resolution will) then they belong in the AVSSettings. Ideally i am looking for a way to define an AVS profile such that all i need to pass is an input file and create a complete script. I am doing that at the moment for the transcode, however I have simply commented out the resize, crop and de-interlace lines. I know it is technially possible to achieve all of this in the actual template by doing something like:
<input>
LanczosResize(640,480)

but I think it would be nicer and easier as part of the actual profile.

Eamon

[Eamon21]

Wheee, C# 3.0 is fun.

This 2.0 code:
info.VideoOutputChanged += new StringChanged(delegate(object _, string val)
{
videoOutput.Filename = val;
});

turns into

info.VideoOutputChanged += (_, val) => videoOutput.Filename = val;

See what else there is (http://en.wikipedia.org/wiki/C_Sharp#C.23_3.0_new_language_features). Some of the highlights are type inference ('var'), automatic properties, and extension methods.

I'm usually one for moving to newer version of languages and the changes that 1.1 -> 2.0 brought were awesome but there is a danger that "new" features will be used and abused just because they are there.

Automatic properties are nice enough, I'm partial to the code-snip "prop" in the current version (ctrl+k, ctrl-x, prop).

The one I worry the most about in 3.0 is the anonymous types keyword "var". Yes it is useful and indeed needed to implement a few new features of 3.0, but it brings with it the risk of abuse. If you know the type, specify the type. Anonymous types can potentially make code much less readable.

Also, many of the situations that people might be inclined to use "var"s just "because they can", would be better solved using currently available methods such as generics, interfaces or base and abstract classes.

I brought this up as it brings me to a something that has sort of bothered me a bit in the MeGUI code and that is the (over)use of generics. It seems some parts of the code are so heavily loaded with generics that it gets hard to read and follow, especially first time into the code. Begrudgingly I would say this is fair enough if it was necessary but at times it appears they have been used as a catch-all "just in case we ever want to use something else here". Without examples, I'm sure there are several places in the code where a generic is used that is only ever of the one type.

I'm more for the philosophy of coding for what is required now, not for what may or may not be required later. In my experience later may actually never come and if it does, often there are enough changes that the code is completely re-factored anyway. </rant>

I guess it is probably a consequence of OSS, no one ever wants to do the boring bits of cleaning up the code and re-factoring. I've just found it a little difficult at times navigating through the code to find out how things get done.

Eamon

[berrinam]

OK, makes sense in that respect. I guess I was getting that idea from the AviSynthAudioEncoder class which creates an AVS script to encode the audio, but never actually has to write the script to file.What you suggest could very well be done for audio. Just not for video. :)

For me it depends on where the settings are used, if they will actually go into the AVS script (resize resolution will) then they belong in the AVSSettings. Ideally i am looking for a way to define an AVS profile such that all i need to pass is an input file and create a complete script. I am doing that at the moment for the transcode, however I have simply commented out the resize, crop and de-interlace lines. I know it is technially possible to achieve all of this in the actual template by doing something like:
<input>
LanczosResize(640,480)

but I think it would be nicer and easier as part of the actual profile.I'd like to know what other people think. I don't have very strong opinions on this.

Automatic properties are nice enough, I'm partial to the code-snip "prop" in the current version (ctrl+k, ctrl-x, prop).Automatic properties are better than this code snippet since they don't leave the private variable lying around. That's only a small difference, though...

The one I worry the most about in 3.0 is the anonymous types keyword "var". Yes it is useful and indeed needed to implement a few new features of 3.0, but it brings with it the risk of abuse. If you know the type, specify the type. Anonymous types can potentially make code much less readable.Things like this are just stupid:
List<Named<GenericProfile<x264Settings>>> profs = new List<Named<GenericProfile<x264Settings>>>();
While this exact line probably doesn't appear in MeGUI, new()ing like that is a common pattern, and no readability is lost by typing the variable with 'var'. Granted, though, it can be inappropriate in some places.

Also, many of the situations that people might be inclined to use "var"s just "because they can", would be better solved using currently available methods such as generics, interfaces or base and abstract classes.

I brought this up as it brings me to a something that has sort of bothered me a bit in the MeGUI code and that is the (over)use of generics. It seems some parts of the code are so heavily loaded with generics that it gets hard to read and follow, especially first time into the code. Begrudgingly I would say this is fair enough if it was necessary but at times it appears they have been used as a catch-all "just in case we ever want to use something else here". Without examples, I'm sure there are several places in the code where a generic is used that is only ever of the one type.I can only assume you refer to the terrible mess of generics with ISettingsProvider, SettingsProviderImpl2, ProfileHandler, and generally associated with profiles. I agree this is a mess, and in fact I have a local working copy of MeGUI in which that code is all deleted, and we have great improvements. For example,
ISettingsProvider<AviSynthSettings, MeGUI.core.details.video.Empty, int, int> avsSettingsProvider = new SettingsProviderImpl2<
MeGUI.core.gui.AviSynthProfileConfigPanel, MeGUI.core.details.video.Empty, AviSynthSettings, AviSynthSettings, int, int>("AviSynth", 0, 0);
ProfilesControlHandler<AviSynthSettings, Empty> avsProfileHandler;
private void initAvsHandler()
{
// Init AVS handlers
avsProfileHandler = new ProfilesControlHandler<AviSynthSettings, Empty>(
"AviSynth", mainForm, profileControl1, avsSettingsProvider.EditSettings, Empty.Getter,
new SettingsGetter<AviSynthSettings>(avsSettingsProvider.GetCurrentSettings), new SettingsSetter<AviSynthSettings>(avsSettingsProvider.LoadSettings));
SingleConfigurerHandler<AviSynthSettings, Empty, int, int> configurerHandler = new SingleConfigurerHandler<AviSynthSettings, Empty, int, int>(avsProfileHandler, avsSettingsProvider);
}

has become
private void initAvsHandler()
{
avsProfile.Manager = mainForm.Profiles;
}


Other than that collective mess, though, I think the use of Generics in MeGUI is appropriate.

I'm more for the philosophy of coding for what is required now, not for what may or may not be required later. In my experience later may actually never come and if it does, often there are enough changes that the code is completely re-factored anyway. </rant>Well, the mess we had evolved gradually as video settings had more and more requirements. The refactor is coming very soon. :)

[Eamon21]

Automatic properties are better than this code snippet since they don't leave the private variable lying around. That's only a small difference, though...
I guess it is more a case of familiarity but
public string mySetting{ get; set; }
is very similar to an abstract declaration of a property or interface definition.
abstract string mySetting{ get; set; }
string mySetting{ get; set; }
The compiler will pick up errors, but eyeballing the code I would currently think of that as an abstract property.
I don't have a problem with automatic properties, I like the idea, just will have to get used to seeing/using them once I move to 3.0, currently do all my work in 2.0 and doesn't look like that'll change anytime soon for the most part.


Things like this are just stupid:
List<Named<GenericProfile<x264Settings>>> profs = new List<Named<GenericProfile<x264Settings>>>();
While this exact line probably doesn't appear in MeGUI, new()ing like that is a common pattern, and no readability is lost by typing the variable with 'var'. Granted, though, it can be inappropriate in some places.
I assume you mean writing that as
var profs = new List<Named<GenericProfile<x264Settings>>>();Granted it is probably actually a bit nicer to look at, but that's more to do with the fact that the first way was just horrible. var will have it's place, I just dread it being thrown around and used everywhere. God forbid people start using it instead of thinking. I also hope people don't start using it with hungarian notation e.g. var strMyVar;

My concerns about var are general and in no way directed at devs of MeGUI, I'm sure everyone here has enough sense to avoid the pitfalls.


I can only assume you refer to the terrible mess of generics with ISettingsProvider, SettingsProviderImpl2, ProfileHandler, and generally associated with profiles. I agree this is a mess, and in fact I have a local working copy of MeGUI in which that code is all deleted, and we have great improvements. For example,
ISettingsProvider<AviSynthSettings, MeGUI.core.details.video.Empty, int, int> avsSettingsProvider = new SettingsProviderImpl2<
MeGUI.core.gui.AviSynthProfileConfigPanel, MeGUI.core.details.video.Empty, AviSynthSettings, AviSynthSettings, int, int>("AviSynth", 0, 0);
ProfilesControlHandler<AviSynthSettings, Empty> avsProfileHandler;
private void initAvsHandler()
{
// Init AVS handlers
avsProfileHandler = new ProfilesControlHandler<AviSynthSettings, Empty>(
"AviSynth", mainForm, profileControl1, avsSettingsProvider.EditSettings, Empty.Getter,
new SettingsGetter<AviSynthSettings>(avsSettingsProvider.GetCurrentSettings), new SettingsSetter<AviSynthSettings>(avsSettingsProvider.LoadSettings));
SingleConfigurerHandler<AviSynthSettings, Empty, int, int> configurerHandler = new SingleConfigurerHandler<AviSynthSettings, Empty, int, int>(avsProfileHandler, avsSettingsProvider);
}

has become
private void initAvsHandler()
{
avsProfile.Manager = mainForm.Profiles;
}


Other than that collective mess, though, I think the use of Generics in MeGUI is appropriate.

Well, the mess we had evolved gradually as video settings had more and more requirements. The refactor is coming very soon. :) :) You pretty much hit exactly the code I had in mind. Profiles can be powerful, but they were a headache to get my head around initially, very happy to hear about what you've done to improve this and eagerly look forward to seeing the results. (p.s. please tell me that the interface Gettable<TSettings> has been put permanently to sleep :) or at the very least been named IGettable)

Eamon

[Gilgamesh83]

Hiya!

I am normal user of megui and would like to put my thoughts on the new log in megui... i think the more detailed info of the old log was better specially after an x264 encode when I can see how the quantizers are distributed.

love megui and all the other work you guys do :)

[berrinam]

Any information missing from the new log is a bug. Please report the specifics on the SourceForge bug tracker. A link is in my signature.

[berrinam]

p.s. please tell me that the interface Gettable<TSettings> has been put permanently to sleep :) or at the very least been named IGettable

Why? It currently has been replaced by Editable<TSettings>, which is perhaps a more appropriate name since the settings can be both got and set, but otherwise, what's wrong with the interface?

[berrinam]

Would there be any objection if we switched MeGUI to C# 3.0? I think we can get all of the C# 3.0 features except extension methods while still producing .NET 2.0 binaries, so the users should see no difference in requirements.

Alternatively, if you think it worth it, we could switch to .NET 3.0 or 3.5, although that is a bigger change and perhaps requires more thought.

[Kurtnoise]

I am normal user of megui and would like to put my thoughts on the new log in megui... i think the more detailed info of the old log was better specially after an x264 encode when I can see how the quantizers are distributed.

AFAIK, the new MeGUI x264 profiles use --no-pnsr & --no-ssim switches. That's why we haven't anymore some details. So, it's clearly not a bug.

Sharktooth, could you confirm that ?

[Kurtnoise]

Would there be any objection if we switched MeGUI to C# 3.0? I think we can get all of the C# 3.0 features except extension methods while still producing .NET 2.0 binaries, so the users should see no difference in requirements.
It's ok for me, although that it'll require some time to switch all the code...

Alternatively, if you think it worth it, we could switch to .NET 3.0 or 3.5, although that is a bigger change and perhaps requires more thought.
I'd say that the .NET 3.5 is highly recommended for Vista users (to avoid issues mentioned above).

[berrinam]

My profiles patch: http://megui.org/berrinam_patches/profiles_refactor/profiles_refactor_1.patch.

The main change is new profile handling, including new internals and externals of profilemanager, and two new profile controls to replace ProfileControl, requiring much less initialisation code. They are currently named SimpleProfileControl and ConfigableProfileControl, with the latter deriving from the former, simply adding a config button. The names were chosen just to not collide with the previously existing ProfileControl, but since that is now gone, they are free to be changed. Also, there are at present no uses of SimpleProfileControl, and I don't know if we will want it in the future, so that may just be removed as well.

The other change is the removal of the zones configuration from video config panels. I did this because it required silly code in the constructor, and it doesn't really belong there, since zones are a per-file setting, not a per-profile setting. I plan to add them back to the VideoEncodingComponent directly, but haven't yet done so.

Profile serialization works pretty much the same as before, but is unfortunately slightly incompatible. Obviously, this incompatibility must be fixed so that people can load their old profiles.

Also, profile importing currently doesn't work either, because it relied on the old serialization engine. I obviously also plan to fix this.

Thoughts, anyone?

Is the introduction of the *scratchpad* profiles ok? This is the major change in user functionality from before.

[berrinam]

It's ok for me, although that it'll require some time to switch all the code... We can do this gradually, though.

[Gilgamesh83]

I'm sorry if people got mixed up with my earlier post. Not a bug it's just that I preferred the old text-based log with advanced statistics showing after a x264 and xvid encode.

Is there no way one can choose between the two.

[Eamon21]

Why? It currently has been replaced by Editable<TSettings>, which is perhaps a more appropriate name since the settings can be both got and set, but otherwise, what's wrong with the interface?I never liked it because of how it is used. It feels superfluous because it is only ever implemented on settings config usercontrols and as such to me it would make more sense to create a base generic config panel usercontrol that contained the settings property as defined in Gettable (Editable). A possible problem here is Visual Studio's support for generic usercontrols for design time, but this can be overcome by wrapping the control. would also mean that the contructor for Configuration window would change likepublic ConfigurationWindow(ProfileManager p, Control sPanel, Gettable<TProfileSettings> s, string initialProfile, string title)

to

public ConfigurationWindow(ProfileManager p, ConfigControl<TProfileSettings> sPanel, string initialProfile, string title)because currently sPanel and s are always the same object.

andpublic class EditorProvider<TPanel, TInfo, TSettings, TProfileSettings>
where TProfileSettings : GenericSettings
where TSettings : TProfileSettings, new()
where TPanel : System.Windows.Forms.Control, Gettable<TProfileSettings>

becomes

public class EditorProvider<TPanel, TInfo, TSettings, TProfileSettings>
where TProfileSettings : GenericSettings
where TSettings : TProfileSettings, new()
where TPanel : ConfigControl<TProfileSettings>
and for config panels like AudioConfigurationPanelpublic partial class AudioConfigurationPanel : UserControl, MeGUI.core.plugins.interfaces.Gettable<AudioCodecSettings>

to

public partial class AudioConfigurationPanel : ConfigControl<AudioCodecSettings>

If you don't agree, can we at lest stick with the convention of naming all interfaces with a capital "I"? i.e. IEditable.

Would there be any objection if we switched MeGUI to C# 3.0? I think we can get all of the C# 3.0 features except extension methods while still producing .NET 2.0 binaries, so the users should see no difference in requirements.

Alternatively, if you think it worth it, we could switch to .NET 3.0 or 3.5, although that is a bigger change and perhaps requires more thought.I'm reluctant for the moment simply because I have VS 2005 Pro installed and I have heard reports that VS2008 express does not play nice when installed side by side. Give it maybe a couple of weeks to see how things settle first?

Eamon

[Eamon21]

My profiles patch: http://megui.org/berrinam_patches/profiles_refactor/profiles_refactor_1.patch.

The main change is new profile handling, including new internals and externals of profilemanager, and two new profile controls to replace ProfileControl, requiring much less initialisation code.
...snip...
Thoughts, anyone?

Is the introduction of the *scratchpad* profiles ok? This is the major change in user functionality from before.I think some of your changes here make some of my ramblings above irrelevant. I like what I've seen so far. Any idea when this goes into the trunk? It will mean changes to the transcode tool so I'd rather make the changes now before submitting it if this patch is merging shortly.

The more I look through this the happier I get, there are so many little gripes I've silently had that have been addressed with this...Christmans has come early :)

Love your work berrinam. :thanks:

Eamon

[berrinam]

@Eamon: I think the patch I posted just a few posts above will satisfy you. Here's an extract from the new ProfileConfigurationWindow class:

public partial class ProfileConfigurationWindow<TSettings, TPanel> : Form
where TSettings : GenericSettings, new()
where TPanel : Control, Editable<TSettings>
{

...

public ProfileConfigurationWindow(TPanel t, string title)
{
The parameter is only passed once, but it has the dual generic constraints of Control and Editable<TSettings>.

When I wrote the previous code you quoted, I was aware that it always referred to the same object (and that's expected in the design) but there was no way to express the two inheritance constraints without generics (which were ruled out in that situation for some reason I can't remember). Your suggestion of making ConfigControl<TSettings> an abstract base class deriving from UserControl and defining the abstract property, Settings, is nice but unfortunately doesn't work, as the Visual Studio GUI designer won't allow a user control with an abstract base class to be designed.

As to the prefixing of interfaces with 'I', I'm not sure of the merits of this convention. The two things I see in it are that it allows both List and IList -- ie both an abstract and concrete specification of a class -- and that it makes it easy to recognise interfaces from other things. For me, the former point has merit but the latter does not, as Visual Studio's IntelliSense tells you that all already. I'm not too fussed, though.

[berrinam]

It seems to me that we've been getting more autoupdate bug reports since I added the update_cache. I personally find the update cache useful since I have very many copies of megui, so the update cache saves me downloads when autoupdating. However, most people are undoubtedly not in my situation, and will therefore probably not benefit the same way.

The update cache also adds severals potential problems, if stale downloads aren't replaced with new ones, and also perhaps if Vista is blocking MeGUI from accessing other folders it doesn't own (although I'm just guessing here).

Is the update cache useful, or should we remove it and hope for fewer autoupdate bugs as a result?

[berrinam]

I think some of your changes here make some of my ramblings above irrelevant. I like what I've seen so far. Any idea when this goes into the trunk? It will mean changes to the transcode tool so I'd rather make the changes now before submitting it if this patch is merging shortly.I'm not sure what you're saying. Would you prefer committing your patch before or after I commit mine?

Anyway, I would expect to commit mine before yours, simply because I'm a developer with SVN write access. :D If necessary, I can help with merging, though.

In any case, the best thing to do if your patch is (nearly) finished is to post it here so we can try it out and give you feedback.

The more I look through this the happier I get, there are so many little gripes I've silently had that have been addressed with this...Christmans has come early :)

Love your work berrinam. :thanks:Nice to hear. And in all honesty, please continue to complain about the code, so it continues to become better. :D

berrinam

[Eamon21]

I'm not sure what you're saying. Would you prefer committing your patch before or after I commit mine?

Anyway, I would expect to commit mine before yours, simply because I'm a developer with SVN write access. :D If necessary, I can help with merging, though.

In any case, the best thing to do if your patch is (nearly) finished is to post it here so we can try it out and give you feedback.

Nice to hear. And in all honesty, please continue to complain about the code, so it continues to become better. :D

berrinamI've applied your patch locally and working through all the changes i need to support the new profilemanger.

One problem I've come across which you might be able to help with is that I can't really see a way to get the settings from a profile if you only know the name, I'll explain.

I have a new profile type to support my transcode tool. The settings of which contain 3 other profiles, an AVS, an Audio and a Video profile. In my TranscodeSettings class I only keep the name (FQName) but it seems like I can't directly access the settings associated with these profiles without a ConfigableProfilesControl associated (unless I also keep the profile type and name and use GetProfile(string type, string name)).

What I'd like is another method in the ProfileManager like GetProfile(string type, string name), but without having to specify the type as I don't know this (e.g. could be x264Settings, could be xvidSettings). I could try to parse the FQName, but really that belongs to the ProfileManager so should be done there. Basically looking for another method:
public Profile GetProfile(string FQName)

found the a private function in ProfileManager that does what I need, I've made a public overload of GetProfile to support this, are you happy to add this to the ProfileManager?
public Profile GetProfile(string FQname)
{
return byFormattedName(FQname);
}

Eamon