Hi Akash,
Sorry about missing you earlier. IRC is usually pretty active during the
daylight and night hours of EST and CET.
The key to reacting to changes within Mixxx is a set of classes called
ControlObjects. This is a control system that allows us to abstract the
control of Mixxx across keyboard, GUI, and hardware controllers (but
they're really glorified global variables ;). They let you automatically
hook and react to events that happen across Mixxx.
The visual_playposition control is a control that decks and samplers have
(generally things that load a file) that indicates the position of the
player in the song.
In a class of yours (assuming it is in the main thread, which the GUI
widgets are), you could hook up the visual_playposition control like this
in its constructor:
ControlObject* pVisualPlaypos =
ControlObject::getControl(ConfigKey("[Channel1]", "visual_playposition"));
m_pVisualPlayposCOTM = new ControlObjectThreadMain(pVisualPlaypos);
connect(m_pVisualPlayposCOTM, SIGNAL(valueChanged(double)),
this, SLOT(myVisualPlayposHandler(double)));
then in the slot "myVisualPlayposHandler":
void MyClass::myVisualPlayposHandler(double newPlaypos) {
qDebug() << "new playposition is" << newPlaypos;
}
The key to using this as Owen proposed would be that you know
visual_playpos is only updated at a rate that doesn't over-load the GUI
with updates (approx 10 times per second).
visual_playpos is not really that great of a control to hook for doing
marquee scrolling because they only update when the player is moving. So if
all the players are stopped then the marquee animation will also be
stopped.
I haven't responded to the bug yet but I think that a QTimer approach might
be fine to stick with for now.
We have a global ~40fps timer that is used to update the waveforms. It is
created in src/waveformviewerfactory.cpp. Code-plumbing wise, it will be a
little tricky/ugly to get this timer and hook it to widgets other than
waveforms. Furthermore, to support marquee scrolling of any widget, we
would need to connect this high-ish speed timer to every widget. I'm not
sure that's a good thing CPU-wise because it means that every widget will
run some handler code (even if it's a no-op) at 40fps. So for now, I'd
rather not play with trying to hook this up.
I'd be happy to give you more of the low-down on how to use COs on IRC
since you end up having to use them no matter what part of Mixxx you work
on. The wiki is sorely lacking in detail on this topic so I'm sorry you had
a lot of trouble learning about it.
Cheers,
RJ Ryan (rryan on IRC)
On Wed, Jan 4, 2012 at 3:03 PM, Akash Shetye <shetyeak...@gmail.com> wrote:
> Hey all,
>
> I am the newest guy on the bandwagon and I hope I will get some mentoring
> on the development front. I need your help. I had sent out a mail earlier
> about the same thing, I am at it again now.
>
> I have been trying to make the marquee scrolling text for the track titles
> that are too long. The bug is
> here<https://bugs.launchpad.net/mixxx/+bug/681009>,
> thanks to Matt Miller I have atleast some code to try and understand how
> Mixxx works. Matt has provided a patch
> here<https://launchpadlibrarian.net/86846018/bug681009_unloadFix.patch>which
> uses a QTimer. I am trying to use the ClockControl::process(...)
> method that keeps getting executed, to increment a counter which will then
> be used to scroll the text.
>
> I tried poking around the IRC for some time, but no one replied or I did
> not receive any replies for my queries. Is there some Standard Time
> developers are on IRC? Hope I will atleast come up with a patch.
>
> In the comments that follow the bug, Owen William hints to some
> visual_playposition can someone help me find it, I have been after this
> visual playposition thing since a week now. Please guide me or else I will
> end up giving up on this bug. Should I start with smaller simpler bus? Did
> I bite off more than I could chew?
>
> What I want to know is that, are there any other approached to this
> problem? Should I be looking at some other Classes? A possible course of
> actions or something. Am I duplicating efforts?
>
> Thanks,
> Akash Shetye.
>
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Mixxx-devel mailing list
> Mixxx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
>
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
