Circle Dock integration
Posted: 13.06.2010 12:50:23
From my perspective, as Circle Dock's principal developer, I am quite happy to have any interaction between Circle Dock and Dexpot in the form of Windows messages. Whilst it's a little more work for me, the end result will be far quicker and smoother.
Let's take a simple example, switching Dexpot's active desktop. The Sarge envisages a Dock Item whose target would be the Dexpot executable with the command line parameter "-w 1" (in the case of switching to the first desktop). This actually gives Circle Dock - and Windows - quite some processing to do as Circle Dock has to create and fill a new process structure and then tell Windows to start the process. It also requires more processing on Dexpot's part than is truly necessary.
This is how I envisage Circle Dock handling this. Circle Dock would check for a Registry entry (that Dexpot sets when it is loaded and running) and if that entry equates to Dexpot running, it would allow for a whole new category of Dock Items to be created and used - Dock Items that cover all the Dexpot command line parameters plus any others that Dexpot's developers wish to add. I would suggest that the Registry entry be the Window Handle for Dexpot's "main" Window (or set to zero if Dexpot is not running). When our user clicks on a Dock Item, to switch Dexpot's active Desktop, Circle Dock simply does a SendMessage(DexpotMainHandle, DEXPOT_SWITCHDESKTOP, 1) (again, in the case the user wants to switch to the first desktop).
This closer integration with Dexpot will make for a more pleasing user experience as the commands will be executed with considerably less processing time and thus be (almost) immediate.
By the same token, Circle Dock will need to be informed of certain Dexpot changes and these include: when Dexpot's active desktop changes (preferably with the new Desktop number) and also when Dexpot is about to close and has started. I suggest that in such cases, Dexpot broadcasts messages such as this: SendMessage(0xffff, DEXPOT_SWITCHINGDESKTOP, 2) (note the difference from above!) and SendMessage(0xffff, DEXPOT_CLOSING, 0) and SendMessage(0xffff, DEXPOT_ACTIVE, {CurrentActiveDesktopNumber}). The last of these messages (DEXPOT_ACTIVE) would be very useful in cases where Dexpot is loaded after Circle Dock. Also, the SWITCHINGDESKTOP message should be cancellable since there may be instances where Circle Dock (or RainMeter) is displaying a dialog and switching desktops is not desirable.
If this schema is accepted and codified, I can then add an additional field to the Dock Items' records whereby the user can specify whether individual Dock Items should be visible for all Dexpot desktops or only certain desktops (by number). This would permit the user to categorize his desktops by task-type and only see those Dock Items that relate directly to the task-type: eg Internet, Office tasks, development, etc., etc.
Food for thought.
Mark
Let's take a simple example, switching Dexpot's active desktop. The Sarge envisages a Dock Item whose target would be the Dexpot executable with the command line parameter "-w 1" (in the case of switching to the first desktop). This actually gives Circle Dock - and Windows - quite some processing to do as Circle Dock has to create and fill a new process structure and then tell Windows to start the process. It also requires more processing on Dexpot's part than is truly necessary.
This is how I envisage Circle Dock handling this. Circle Dock would check for a Registry entry (that Dexpot sets when it is loaded and running) and if that entry equates to Dexpot running, it would allow for a whole new category of Dock Items to be created and used - Dock Items that cover all the Dexpot command line parameters plus any others that Dexpot's developers wish to add. I would suggest that the Registry entry be the Window Handle for Dexpot's "main" Window (or set to zero if Dexpot is not running). When our user clicks on a Dock Item, to switch Dexpot's active Desktop, Circle Dock simply does a SendMessage(DexpotMainHandle, DEXPOT_SWITCHDESKTOP, 1) (again, in the case the user wants to switch to the first desktop).
This closer integration with Dexpot will make for a more pleasing user experience as the commands will be executed with considerably less processing time and thus be (almost) immediate.
By the same token, Circle Dock will need to be informed of certain Dexpot changes and these include: when Dexpot's active desktop changes (preferably with the new Desktop number) and also when Dexpot is about to close and has started. I suggest that in such cases, Dexpot broadcasts messages such as this: SendMessage(0xffff, DEXPOT_SWITCHINGDESKTOP, 2) (note the difference from above!) and SendMessage(0xffff, DEXPOT_CLOSING, 0) and SendMessage(0xffff, DEXPOT_ACTIVE, {CurrentActiveDesktopNumber}). The last of these messages (DEXPOT_ACTIVE) would be very useful in cases where Dexpot is loaded after Circle Dock. Also, the SWITCHINGDESKTOP message should be cancellable since there may be instances where Circle Dock (or RainMeter) is displaying a dialog and switching desktops is not desirable.
If this schema is accepted and codified, I can then add an additional field to the Dock Items' records whereby the user can specify whether individual Dock Items should be visible for all Dexpot desktops or only certain desktops (by number). This would permit the user to categorize his desktops by task-type and only see those Dock Items that relate directly to the task-type: eg Internet, Office tasks, development, etc., etc.
Food for thought.
Mark
No, we would of course appreciate a collaboration between our two project, and we'd be happy to provide all the assistance needed to make this work.
).
