From 9e88754b26413976b613da9d8f9b0c86df948cac Mon Sep 17 00:00:00 2001
From: Chris Tallon <chris@vomp.tv>
Date: Sun, 1 Jun 2008 18:53:57 +0000
Subject: [PATCH] Code cleaning
---
boxstack.cc | 24 --------------------
timers.h | 58 +++++++++++++++++++++++++++--------------------
vaudioselector.cc | 5 +++-
vchannellist.cc | 20 ++++------------
vconnect.cc | 3 +--
vdr.cc | 7 ------
vdr.h | 1 -
vradiorec.cc | 8 -------
vvideorec.cc | 8 -------
wprogressbar.cc | 2 --
10 files changed, 43 insertions(+), 93 deletions(-)
diff --git a/boxstack.cc b/boxstack.cc
index 2d33758..e4c620f 100644
--- a/boxstack.cc
+++ b/boxstack.cc
@@ -18,30 +18,6 @@
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
-
-/*
-
-#ifndef WIN32
- pthread_mutex_lock(&boxLock);
-#else
- WaitForSingleObject(boxLock, INFINITE);
-#endif
-
-
-#ifndef WIN32
- pthread_mutex_unlock(&boxLock);
-#else
- ReleaseMutex(boxLock);
-#endif
-
-
-
-
-*/
-
-
-
-
#include "boxstack.h"
#include "command.h"
diff --git a/timers.h b/timers.h
index d554aa8..34ab673 100755
--- a/timers.h
+++ b/timers.h
@@ -12,30 +12,40 @@
FYI
-Timers ... deprecated. Maybe.
-
-This whole thing will be replaced with a timed-message idea. It will be possible
-to send yourself (or whoever) a message with a delay, or delivery time. The message
-will be handed to Command as usual, but command will do the right thing. The messages
-will be delivered to the recipient _with the gui mutex locked_, meaning updates can
-be done there and then in the message handler.
-
-Good points:
-* Cuts down on code lines
-* Most (all?) timercall()s eventually send a message to command in order to
- do something within The Big Mutex. This makes it easier and simpler code wise
-* Gets rid of Timers.
-* Hopefully gets rid of most postMessageFromOuterSpace calls
-
-Bad points:
-* Timers become gui only features. Solve this with a MessageReceiver interface and
- have command deliver messages straight to the recipients rather than through BoxStack.
-* Timer delivery accuracy becomes dependant on everything that uses The Big Mutex.
- It will become more important to not block The Big Mutex.
-* Cancelling timers... hmm
-
-If you have any comments about the new design, like, "It's just as flawed as the old one",
-then I'd appreciate hearing it before I start writing it all :)
+Fixed:
+
+The main problem was that timers only seemed to launch messages which went into The Big Mutex.
+This has been fixed a different way by implementing locking in BoxStack - meaning timercalls
+can now draw and update their displays without locking The Big Mutex. Problem solved. I think
+the whole program might move more towards classes keeping more mutexes and rely less on The
+Big Mutex.
+
+
+
+> Timers ... deprecated. Maybe.
+
+> This whole thing will be replaced with a timed-message idea. It will be possible
+> to send yourself (or whoever) a message with a delay, or delivery time. The message
+> will be handed to Command as usual, but command will do the right thing. The messages
+> will be delivered to the recipient _with the gui mutex locked_, meaning updates can
+> be done there and then in the message handler.
+
+> Good points:
+> * Cuts down on code lines
+> * Most (all?) timercall()s eventually send a message to command in order to
+> do something within The Big Mutex. This makes it easier and simpler code wise
+> * Gets rid of Timers.
+> * Hopefully gets rid of most postMessageFromOuterSpace calls
+
+> Bad points:
+> * Timers become gui only features. Solve this with a MessageReceiver interface and
+> have command deliver messages straight to the recipients rather than through BoxStack.
+> * Timer delivery accuracy becomes dependant on everything that uses The Big Mutex.
+> It will become more important to not block The Big Mutex.
+> * Cancelling timers... hmm
+
+> If you have any comments about the new design, like, "It's just as flawed as the old one",
+> then I'd appreciate hearing it before I start writing it all :)
*/
diff --git a/vaudioselector.cc b/vaudioselector.cc
index 97306ff..3315d73 100644
--- a/vaudioselector.cc
+++ b/vaudioselector.cc
@@ -249,7 +249,10 @@ VAudioSelector::~VAudioSelector()
int audioChannelListSize = acl.size();
for(int i = 0; i < audioChannelListSize; i++)
{
- delete acl[i]; // FIXME memory leak - nobody is deleting audio channel name?
+ // FIXME memory leak - nobody is deleting audio channel name? // try:
+ delete[] acl[i]->name;
+ Log::getInstance()->log("VAudioSelector", Log::DEBUG, "Deleted char[] on close");
+ delete acl[i];
}
acl.clear();
diff --git a/vchannellist.cc b/vchannellist.cc
index d0d0aa4..a663fcc 100644
--- a/vchannellist.cc
+++ b/vchannellist.cc
@@ -219,22 +219,10 @@ int VChannelList::handleCommand(int command)
if (chanList) chan = (Channel*)sl.getCurrentOptionData();
if (chan == NULL) return 2;
-// if (chan->type == VDR::VIDEO)
-// {
- VVideoLiveTV* v = new VVideoLiveTV(chanList, chan->number, this);
- boxstack->add(v);
- v->go();
-/*
- }
- else
- {
- VVideoLive* v = new VVideoLive(chanList, chan->type, this);
- v->draw();
- boxstack->add(v);
- boxstack->update(v);
- v->channelChange(VVideoLive::NUMBER, chan->number);
- }
-*/
+ VVideoLiveTV* v = new VVideoLiveTV(chanList, chan->number, this);
+ boxstack->add(v);
+ v->go();
+
return 2;
}
case Remote::BACK:
diff --git a/vconnect.cc b/vconnect.cc
index 8ad6f7d..9666156 100644
--- a/vconnect.cc
+++ b/vconnect.cc
@@ -120,8 +120,7 @@ void VConnect::threadMethod()
selectedServer = -1;
VServerSelect* vs = new VServerSelect(servers, this);
vs->draw();
- boxstack->add(vs); // FIXME - do this better - perhaps post message to Command
- // Otherwise it will be using BoxStack without the Command mutex locked
+ boxstack->add(vs);
boxstack->update(vs);
threadLock();
diff --git a/vdr.cc b/vdr.cc
index e612c9d..57ef492 100644
--- a/vdr.cc
+++ b/vdr.cc
@@ -689,13 +689,6 @@ ChannelList* VDR::getChannelsList(ULONG type)
return chanList;
}
-
-int VDR::streamChannel(ULONG number)
-{
- // FIXME radio
- return 0;
-}
-
int VDR::streamChannel(ULONG number, StreamReceiver* tstreamReceiver)
{
VDR_RequestPacket vrp;
diff --git a/vdr.h b/vdr.h
index 6c75dc4..a9eefe0 100644
--- a/vdr.h
+++ b/vdr.h
@@ -166,7 +166,6 @@ class VDR : public Thread_TYPE, public EventDispatcher
int deleteTimer(RecTimer* delTimer);
ChannelList* getChannelsList(ULONG type);
int streamChannel(ULONG number, StreamReceiver*);
- int streamChannel(ULONG number);
void getChannelPids(Channel* channel);
UCHAR* getBlock(ULLONG position, UINT maxAmount, UINT* amountReceived);
//get image blocks separate - we can do this in parallel
diff --git a/vradiorec.cc b/vradiorec.cc
index a028d77..f0d53cf 100644
--- a/vradiorec.cc
+++ b/vradiorec.cc
@@ -317,15 +317,7 @@ void VRadioRec::stopPlay()
{
Log::getInstance()->log("VRadioRec", Log::DEBUG, "Pre stopPlay");
- // FIXME work out a better soln for this
- // Fix a problem to do with thread sync here
- // because the bar gets a timer every 0.2s and it seems to take up to 0.1s,
- // (or maybe just the wrong thread being selected?) for the main loop to lock and process
- // the video stop message it is possible for a bar message to stack up after a stop message
- // when the bar message is finally processed the prog crashes because this is deleted by then
removeBar();
- //
-
player->stop();
vdr->stopStreaming();
delete player;
diff --git a/vvideorec.cc b/vvideorec.cc
index 909a35f..f2ee7c0 100644
--- a/vvideorec.cc
+++ b/vvideorec.cc
@@ -531,15 +531,7 @@ void VVideoRec::stopPlay()
{
Log::getInstance()->log("VVideoRec", Log::DEBUG, "Pre stopPlay");
- // FIXME work out a better soln for this
- // Fix a problem to do with thread sync here
- // because the bar gets a timer every 0.2s and it seems to take up to 0.1s,
- // (or maybe just the wrong thread being selected?) for the main loop to lock and process
- // the video stop message it is possible for a bar message to stack up after a stop message
- // when the bar message is finally processed the prog crashes because this is deleted by then
removeBar();
- //
-
player->stop();
vdr->stopStreaming();
delete player;
diff --git a/wprogressbar.cc b/wprogressbar.cc
index d61daa0..b025a88 100644
--- a/wprogressbar.cc
+++ b/wprogressbar.cc
@@ -42,8 +42,6 @@ void WProgressBar::draw()
if (area.w < 5) return;
if (area.h < 5) return;
- printf("progress bar: %u\n", percent);
-
// Hmm, can't draw two boxes because should not paint on areas
// not needing it - this class does not know the background colour
--
2.39.5