Closed GoogleCodeExporter closed 9 years ago
I have now integrated the new Fanart Fading that Moving Pictures (SVN) uses and
it
works really well. Performance+Eye Candy!
Compliments to fforde for making the classes generic, easy to integrate and
maintain.
There have been a few bugs which I would like to get resolved, I will commit
after I
have finished doing some more testing.
I think we should release this at the same time Moving Pictures does, it will
make
for a more consistent user experience.
Original comment by damien.haynes@gmail.com
on 9 Dec 2008 at 1:13
Original comment by damien.haynes@gmail.com
on 9 Dec 2008 at 1:19
Original comment by damien.haynes@gmail.com
on 12 Dec 2008 at 8:20
So is the code checked in now?
Original comment by zefl...@gmail.com
on 13 Dec 2008 at 4:56
Nope, will try get around to it today
Original comment by damien.haynes@gmail.com
on 13 Dec 2008 at 9:37
Done:
* Inclusion of Moving Pictures Cornerstone.MP framework to support Fanart
fading.
A few things to note:
* Do a Update from SVN Trunk
* Add Cornerstone.MP project to your existing solution
* Add core.dll reference to Cornerstone.MP project
* Add Cornerstone.MP project dependency to MP-TVSeries project
* Build Cornerstone.MP project first
* Add Cornerstone.MP.dll as reference to MP-TVSeries project
* Add Post Build event to MP-TVSeries that copies the following tools to the bin
directory:
xcopy "$(ProjectDir)..\External\merge.bat" "$(TargetDir)" /Y
xcopy "$(ProjectDir)..\External\ilmerge.exe" "$(TargetDir)" /Y
Note: ilmerge.exe can be used to merge multiple binaries into a single file, in
this
case we can do MP-TVSeries.dll and Cornerstone.MP.dll.
For Debug environment its recommended that you create a post build event that
copies
both dlls into your Mediaportal plugins directory. For External Releases or
testing
create another post build step using the merge.bat file which will do the merge:
call "$(TargetDir)"\Merge.bat
This will rename the unmerged MP-TVSeries.dll to MP-TVSeries_UNMERGED.dll and
then
merge with Cornerstone.MP.dll to produce a new MP-TVSeries.dll.
* Finially do a rebuild on MP-TVSeries, this should now build both projects
* Modify existing TVSeries.xml skin to support fading fanart, it now requires
two IDs
(one for each GUIImage). Replace your existing definition for id 524 with these
two:
<control>
<description>Fanart Background #1</description>
<type>image</type>
<id>524</id>
<posX>0</posX>
<posY>0</posY>
<width>1280</width>
<height>720</height>
<texture>#TVSeries.Fanart</texture>
<animation effect="fade" start="0" end="100" time="3000">WindowOpen</animation>
<animation effect="fade" start="0" end="100" time="200">Visible</animation>
<animation effect="fade" start="100" end="0" time="200"
delay="200">Hidden</animation>
</control>
<control>
<description>Fanart Background #2</description>
<type>image</type>
<id>525</id>
<posX>0</posX>
<posY>0</posY>
<width>1280</width>
<height>720</height>
<texture>#TVSeries.Fanart2</texture>
<animation effect="fade" start="0" end="100" time="200">Visible</animation>
<animation effect="fade" start="100" end="0" time="200"
delay="200">Hidden</animation>
</control>
Original comment by damien.haynes@gmail.com
on 14 Dec 2008 at 11:45
Ok, so I'm kinda at a loss here. Why not have the cornerstone project in the
solution?
What's all this hocus pocus about merging binaries? I don't get it. We do have
the
code for both things, right?
Original comment by zefl...@gmail.com
on 19 Dec 2008 at 4:19
You can do it either way. It's a separate project because I wanted it to be
clear
that it's separate from Moving Pictures, that there are no dependencies. If the
classes are in the same project, sooner or later some accidental dependency to
Moving
Pictures would crop up and then the code breaks for all the other plug-ins
using the
same code. If it's separate though, you have to manually add a reference, so it
is
safer. You have compile time checking to make sure that Cornerstone is
independent of
the main plug-in.
This of course also means that it's compiled into a separate DLL though, hence
the
use of ILMerge. You guys can do whatever you like, merge it into your existing
TV-
Series project. Just be careful as you make changes though, the more changes
you make
the harder it will be to merge in bug fixes and enhancements made in the main
repository.
For what it's worth though ILMerge (http://tinyurl.com/9xuqf) is an official
tool
developed by Microsoft, so nothing really out of the ordinary is being done
here.
Original comment by conrad.john
on 19 Dec 2008 at 4:40
I just tried, and as far as I can tell, the proper way of doing things would be:
- in build configuration, build cornerstone
- copy the cornerstone output to the debug folder (same xcopy command than for
mptvseries)
- add a reference to cornerstone in mptvseries
and you're done. No need to so some weird ILMerge stuff :)
I've checked those changes.
Original comment by zefl...@gmail.com
on 19 Dec 2008 at 4:43
Crap, forgot to add something.
So I tried, and it's either that change or the fact rtv reverted my fixes on the
texturemanager (grrrr) but when I first enter the series plugin, I don't see any
serie info. I just see the list, and the fanart.
When I go down to the season level, everything shows ok. When I come back up
too.
Furthermore, going through one series to the other really fast just "blocked"
the
fanart to one specific file. After that it wouldn't change anymore, even going
out
and back in mptvseries. And the aspect ratio of the bitmap would be weird after
that
step.
Original comment by zefl...@gmail.com
on 19 Dec 2008 at 4:45
I also now dont see any series info when first entering the plugin....some weird
control visibility issues going on now with the latest MediaPortal 1.0.
Its not because of the above changes as I have been using core.dll from the
latest
RC4 and the problem doesn't exist, but with the latest core.dll from SVN21113
everything is borked for tvseries!
Original comment by damien.haynes@gmail.com
on 19 Dec 2008 at 9:18
Mattsk88 mentioned to me yesterday he was having some issues with an animation
triggering. He said it was set to a visibility change and just attached to a
normal
GUIImage object not referenced to at all by Moving Pictures. He said it used to
fire
on load and now does not. This may be related, there is definitely a change in
the
visibility behavior when a GUIWindow opens though.
Original comment by conrad.john
on 19 Dec 2008 at 9:41
I think some extra logic is needed in the ImageSwapper class (probably in the
FileName property). Right now if you disable fanart by using the Active
property the
fanart is still visible.
In TVseries we have a new option to disable the fanart in Series Listing, but
we also
use Active=false when we come across a series that doesn't have a fanart.
You can do a quick test in Moving Pictures by disabling fanart in your list
view :
case ViewMode.LIST:
backdropActive = defines["#list.backdrop.used"].Equals("false");
If you go from Listview into Details then back out again you will see that the
fanart
is visible
Original comment by damien.haynes@gmail.com
on 21 Dec 2008 at 2:43
You're probably right, I will take a look and give you an update tomorrow.
Original comment by conrad.john
on 21 Dec 2008 at 6:03
I tracked down the revision that was causing the control visibility issues, it
was
introduced in r21030.
"reverting fix for 1755, because it is creating a nonfocused status, when focus
is
switching from one control to the other"
Line 1415 in GUIWindow.cs:
//UpdateVisibility(); //Bav: reverting change, because it is creating a
nonfocused
status, when a focus is switching from one control to the other
If I un-comment this line, the problem goes away. I have let Infinity know by
IM.
Original comment by damien.haynes@gmail.com
on 22 Dec 2008 at 10:42
The issues with the ImageSwapper.Active field causing the backdrop to sometimes
be
visible when it should not be has been fixed in the Cornerstone.MP project.
http://tinyurl.com/9mghpf
Let me know if you have any further trouble.
Original comment by conrad.john
on 17 Jan 2009 at 8:48
Thanks John, I will test and report any issues if I find them.
Original comment by damien.haynes@gmail.com
on 18 Jan 2009 at 1:56
There is a few issues Im aware of but I should raise these separately.
Original comment by damien.haynes@gmail.com
on 19 Jan 2009 at 5:36
Original issue reported on code.google.com by
damien.haynes@gmail.com
on 9 Dec 2008 at 1:11