Ok, I am in the process of checking the latest and greatest theme stuff.
This check in *will* break the linux build as threatened in the last
conference call. Sorry Isaac. Themes are now uncompressed and parsed from
.fat files each time freeamp loads/reloads.

These things need to get done in order to bring things back up to speed:

1) Implement a ThemeManager for win32. I didn't bother creating an abstract
base class for the ThemeManager since they will have the same functions for
both OSes, and they really share no common code. So, just implement
ThemeManager.cpp with the given ThemeManager.h header.

2) Implement VulcanMindMeld in the GTKWindow. What, you need more info on
that?

Lemme go back and explain where this problem arose that led to the
VulcanMindMeld solution:

When the theme ui brings up the preference dialog, the theme ui is the
parent to the preferences dialog. When the user changes the theme and
applies it, the theme should reload. In my previous implementation I just
shut down that window and created a new one with the new theme. However,
among some thread issues, windows doesn't like having its parent window go
away.

So, I had to implemented Theme reloading and window switching in a different
manner. I really don't like this solution, but its the only workable one I
could find:

When a theme starts up:
1. The theme creates a dummy window (m_pWindow)
2. It parses the .xml file and creates and arraw of windows (as defined in
the XML file)
3. Given a window name (e.g. MainWindow) it takes the appropriate record
from the array of windows and performs a VulcanMindMeld between window in
the array and the dummy window.
4. The VulcanMindMeld function copies all the pertinent data (controls,
name, rect, etc) from one window class to another window class.
5. Now the dummy window is really like one of the windows in the parsed
window array.
6. This window is now 'Run' to bring it up on the screen and initialize all
the OS specific windowing data members.

In order to reload the theme this happens:
1. The new theme .xml is parsed
2. The appropriate window from the newly parsed window array is MindMelded
into the dummy window (m_pWindow)
3. The old bitmaps, fonts and controls are tossed.
4. The OS depedent functions make the necessary changes to change the window
shape and redraw everything to make the new theme the current theme.

In order to switch a window:
1. Do a VulcanMindMeld between m_pWindow and the new window to switch to.
2. The OS depedent functions make the necessary changes to change the window
shape and redraw everything to make the new theme the current theme.

The dummy window that I keep talking about is marked as a
'VulcanMindMeldHost', which means that it never actually deletes any of its
data members to prevent accidental deletion of resources that belong to a
'true' window in the window array.

Scary thing is that it works and that themes properly update. (Altough the
apply button in the preferences still does not work. But, that's a minor
detail compared to all this crap above)

So, Isaac, you need to override the VulcanMindMeld function in the
GTKWindow(). Please check out what the Win32Window does VulcanMindMeld:

Error Win32Window::VulcanMindMeld(Window *pOther)
{
    HRGN     hRgn;
    Error    eRet;
    Rect     oRect;

    eRet = Window::VulcanMindMeld(pOther);
    if (IsError(eRet))
       return eRet;

    m_pCanvas->GetBackgroundRect(oRect);
    SetWindowPos(m_hWnd, NULL, 0, 0, oRect.Width(), oRect.Height(),
                 SWP_NOZORDER|SWP_NOMOVE);

    hRgn = ((Win32Canvas *)m_pCanvas)->GetMaskRgn();
    if (hRgn)
        SetWindowRgn(m_hWnd, hRgn, false);

 InvalidateRect(m_hWnd, NULL, false);
    UpdateWindow(m_hWnd);

    return kError_NoErr;
}

It just makes sure that the window shape is correct and properly redrawn.
That *should* be it.

Sigh. I'm taking the rest of the day off to smoke some more crack. After
re-reading this message, I've come to the conclusion that I need more crack
in my life. :-)


--ruaok         Freezerburn! All else is only icing. -- Soul Coughing

Robert Kaye -- [EMAIL PROTECTED]  http://moon.eorbit.net/~robert

Reply via email to