Rainmeter and Circle Dock Proposal

[sgtevmckay]

One small point: When a skin is visible on multiple desktops, it will always be at the same position. This makes completely different layouts using the same skins difficult. Is this an acceptable limitation? It seems that with "!RainmeterMove" we could realize different skin positions on each desktop.

I have considered this long and hard. I figured this would come up.
I would consider this acceptable. For all Rainmeter can do and for all Dexpot can do, there is still limitations at this time.
That being said; if there is an instant solution we can find to adjust for this, then we can take a look at tackling the situation. If not, them this can be one of those things that we look at over time.
In this game; there are no over night solutions.

I have been reading and re-reading the path concepts and I think maybe I have posted in error.
The concept that I have is based on the portability of both Dexpot and Rainmeter. We also have users that install Rainmeter via Zip or installer, but ultimately Rainmeter can be installed anywhere, along with the Rainmeter.exe and the Rainmeter.ini.
What I was attempting to propose is that in Dexpot settings (via Add-on or whatever is decided on) the Path to the need Rainmeter files may have to be defined by the End User, so that Dexpot can find the various Rainmeter files.
Not that Rainmeter would be pointed at Dexpot, or a Dexpot Path needs to be identified to Dexpot. This will be done by skin designers as they build, and most likely; the will build skins via Execute commands utilizing Dexpot Command Line Parameters, at this time.
If, as in most circumstance. Rainmeter.exe and Rainmeter.ini are located as default install locations; Then no issue.
BUT; if a person is to Install Rainmeter and Dexpot to portable media, then Dexpot will be unable to look in the default locations. Dexpot will need to be told the Path to the appropriate Rainmeter folders. This also stands true for non-standard installation.

So any add-on, plugin, or core Options will need to have some user input.
Now all this may be a mute point if, as you propose, Rainmeter skins can be manipulate to the various Virtual Desktops similar to how Desktop Icons, Files, folders, and shortcuts are handled.

So at this point I assume we need a clear cut path to proceed in, so that we may concentrate our efforts. If other options present themselves, then we can work towards them on the future.
Unless we find that ONE ANSWER TO EVERYTHING solution

[dragonmage]

I wanted to set things up in a way that any skin created to interface with a VDM would work with any VDM, so that in the future if another VDM comes along that wants to support Rainmeter there is already a standard way of doing it. Meaning if someone created a skin now to control Dexpot, then VirtuaWin or some unknown player decides to support Rainmeter then that skin would work for them as well. It seems though that others think that it is unnecessary work now, and would rather deal with it in the future if it happens. Not the way I would go, but I guess if you guys want to go ahead and work out a method for Dexpot we can give testing and suggestion help.

[sgtevmckay]

I wanted to set things up in a way that any skin created to interface with a VDM would work with any VDM, so that in the future if another VDM comes along that wants to support Rainmeter there is already a standard way of doing it. Meaning if someone created a skin now to control Dexpot, then VirtuaWin or some unknown player decides to support Rainmeter then that skin would work for them as well. It seems though that others think that it is unnecessary work now, and would rather deal with it in the future if it happens. Not the way I would go, but I guess if you guys want to go ahead and work out a method for Dexpot we can give testing and suggestion help.

I fully agree. I would out off as little as possible.
The issue I see is on the Rainmeter side when it comes to skins.
I am working on a skin now that works purely on Dexpot Command Line.
I would presume that similar VDM have similar functionality along these lines.
That being the case; I am unclear on a one code skin fits all scenario.

I do have to agree that Patrick's concept of a method to properly see Virtual Desktops, so that any future VDM software can also work with Rainmeter is the way to proceed, but for Rainmeter to work with any other software, we have always had to build, or manipulate, a skin to work with it.
There has never been a one skins works with everything scenario (???)

Or am I completely understanding you wrong, and am off base???

I would also see that Rainmeter can communicate with as many platforms as possible, as this is our goal and ultimately part of the Rainmeter philosophy.

So if that Ground work can be laid here; Great.
It is not my intent to ignore the full potential and possibilities that Patrick and Sebastian have set down for us here.

[Patrick]

One small point: When a skin is visible on multiple desktops, it will always be at the same position. This makes completely different layouts using the same skins difficult. Is this an acceptable limitation?

I would consider this acceptable. For all Rainmeter can do and for all Dexpot can do, there is still limitations at this time.
That being said; if there is an instant solution we can find to adjust for this, then we can take a look at tackling the situation. If not, them this can be one of those things that we look at over time.

It would only be a matter of extending the proposed syntax to optionally include coordinates for each desktop. So instead of "VDesktop=1,2,4" you could have "VDesktop=1 (10;30), 2 (800;90), 4 (10;30)". Or maybe something less cryptic.
But you're right, it might be a good idea to concentrate on the essentials for now and leave this as a possible future extension.

What I was attempting to propose is that in Dexpot settings (via Add-on or whatever is decided on) the Path to the need Rainmeter files may have to be defined by the End User, so that Dexpot can find the various Rainmeter files.

I got that. It doesn't really solve the portability issue, due to changing drive letters of portable drives. Looking at the Rainmeter code, it appears it can take the location to the .ini file as a command line argument, so the file could be anywhere, literally. That's why I think my proposal of having an interface for third-party apps to ask a running instance of Rainmeter for the location of its .ini, would be the more elegant solution.

Now all this may be a mute point if, as you propose, Rainmeter skins can be manipulate to the various Virtual Desktops similar to how Desktop Icons, Files, folders, and shortcuts are handled.

No, we would still rely on the information in the Rainmeter.ini which configs to show on which desktop.

[Patrick]

I wanted to set things up in a way that any skin created to interface with a VDM would work with any VDM, so that in the future if another VDM comes along that wants to support Rainmeter there is already a standard way of doing it.

"Controlling virtual desktop managers through Rainmeter skins" to me appears to be a completely different problem than the one we're trying to solve, "having different Rainmeter skins on every desktop".

[dragonmage]

I wanted to set things up in a way that any skin created to interface with a VDM would work with any VDM, so that in the future if another VDM comes along that wants to support Rainmeter there is already a standard way of doing it.

"Controlling virtual desktop managers through Rainmeter skins" to me appears to be a completely different problem than the one we're trying to solve, "having different Rainmeter skins on every desktop".

Yes, it is a different issue. I was attempting to work out the full mechanics of bi-directional interaction between Rainmeter and VDMs. Others however expressed concerns to me about "cluttering up" Rainmeter.ini with keys that most of our users will likely not need. Which makes me consider the possibility of having the VDM plugin write a VDM.ini next to Rainmeter.ini this would leave the extra keys out of Rainmeter.ini so that only users that use a VDM will have the information. This would also allow easy access to the settings for Rainmeter skins to interact with, as well as allow the sharing of VDM settings with other users.

Code: Select all

[VDM]
Active=1

[Variables]
VDM=Dexpot
VDMPath=Path\to\dexpot.exe
VDMCMD=Pathto\Pluginthat\Recieves\commands.exe
VDMCount=4
VD1=DesktopName1
VD2=DesktopName2
VD3=DesktopName3
VD4=DesktopName4

[Gnometer\Bars]
VDesktop=*

[Gnometer\Clock]
VDesktop=1 (10;30), 2 (800;90), 4 (10;30)



This would make the Variables accessible to Rainmeter skins as an Include, and possibly in the future the Rainmeter context menu, if we decide that is a good idea. We also might be able to save this ini as a theme so that it is not necessary for your plugin to parse settings for unused skins. Any other VDM app that happens along will only need to change the Values in the [Variables] section. Then their plugin would need to accept the same commands that are set up in this one. That means that skins designed to work with Dexpot will work with other VDMs. If you guys find this acceptable I think it will please all sides without painting us into a corner as far as supporting multiple VDMs.

[Patrick]

I was attempting to work out the full mechanics of bi-directional interaction between Rainmeter and VDMs.

It's just that in one direction we only care about the most basic feature of all VDMs, the notion of multiple desktops, while in the other direction, skins might want to use features specific to a particular VDM. That makes a truly universal solution in the second direction a lot harder to find.

Which makes me consider the possibility of having the VDM plugin write a VDM.ini next to Rainmeter.ini this would leave the extra keys out of Rainmeter.ini so that only users that use a VDM will have the information. This would also allow easy access to the settings for Rainmeter skins to interact with, as well as allow the sharing of VDM settings with other users.

That seems reasonable. With a dedicated .ini file, we don't need to worry about cluttering things up, right? So let's make it more readable:

Code: Select all

[Gnometer\Clock]
VDesktop=1,2,4
VD1Position=10,30
VD2Position=800,90
VD4Position=10,30


That means that skins designed to work with Dexpot will work with other VDMs.

I don't see how. Maybe it's because I don't know what a Dexpot skin would actually do. Does it show which desktop you are currently on? Does it allow you to switch to another desktop?

[dragonmage]

It's just that in one direction we only care about the most basic feature of all VDMs, the notion of multiple desktops, while in the other direction, skins might want to use features specific to a particular VDM. That makes a truly universal solution in the second direction a lot harder to find.

I agree that the most basic function is having and navigating multiple desktops. I feel that the basic functions though, should be skin independent. Features specific to a particular VDM could be achieved through a plugin, but identifying and switching between desktops should be universal in my opinion.

!Execute ["#VDMCMD#" "switch" "2"]

would send the command to switch to desktop 2 to the app defined in VDMCMD= in the ini. If that is Dexpot or another VDM it would not make a difference the button you click in the skin will cause a switch to desktop 2. Other fancier functions could be triggered through a pluginbang to a particular VDM plugin.

I don't see how. Maybe it's because I don't know what a Dexpot skin would actually do. Does it show which desktop you are currently on? Does it allow you to switch to another desktop?

Yes, allow you to switch desktops and show which desktop you are on in a variety of ways. A series of little "screens" with the current one highlighted. A row of lights with the current one lit. A simple string displaying the name of the current desktop. A row of numbers with the current one larger than the others. I could keep going...

Thinking on it now though we'd probably need a Current=1 that would have to be updated on switch. If this is all more than you had in mind I can understand if you'd rather just do it your own way.

[Patrick]

!Execute ["#VDMCMD#" "switch" "2"] would send the command to switch to desktop 2 to the app defined in VDMCMD= in the ini. If that is Dexpot or another VDM it would not make a difference the button you click in the skin will cause a switch to desktop 2.

Oh, so it will only work for VDMs that actively support Rainmeter or have a plugin that does? Fair enough.

Thinking on it now though we'd probably need a Current=1 that would have to be updated on switch.

How would the skin know that a desktop switch occured?

If this is all more than you had in mind I can understand if you'd rather just do it your own way.

No, not at all. I rather like the idea of getting a skinnable interface for controlling Dexpot out of this "for free".

[dragonmage]

How would the skin know that a desktop switch occured?

Well there are a couple of ways we could do it currently.

1. DynamicVariables, a fairly new addition to Rainmeter which monitors a variable for changes on each update.
@Include=#SETTINGSPATH#VDM.ini
will get the variables into the skin.
and
DynamicVariables=1
on the meter that displays the info will update the skin when the variable changes.

2. Webparser could be used to parse the ini and return the value of Current= which could be used by inserting the MeasureName into the meter.

No, not at all. I rather like the idea of getting a skinnable interface for controlling Dexpot out of this "for free".

Yeah, Rainmeter is great for making "front ends" for controlling other apps as long as there are command line or window messages for the functions you want to trigger.

[Patrick]

Ok... do you think we're ready to draft a specification of the VDM.ini file format and the commands the "VDMCMD" has to support?

Any new insight on the "how to locate the .ini file" issue? If skins get to use a #SETTINGSPATH# variable, a cross-process communication variant of that for addons would only be fair...

[dragonmage]

Ok... do you think we're ready to draft a specification of the VDM.ini file format and the commands the "VDMCMD" has to support?

I think so. I have to head back to work now, should be home in 5-6 hrs.

Any new insight on the "how to locate the .ini file" issue? If skins get to use a #SETTINGSPATH# variable, a cross-process communication variant of that for addons would only be fair...

I'll talk to the devs and see what we can work out.

[dragonmage]

Any new insight on the "how to locate the .ini file" issue? If skins get to use a #SETTINGSPATH# variable, a cross-process communication variant of that for addons would only be fair...

We're going to have a little delay, but I'm pretty sure we can get you window message access to the path information. It will be sometime after the 1.2 release which is scheduled for tomorrow. I think we should make all the built-in variables accessible, they might be of use down the line somewhere.

I guess we can start the VDM.ini spec. I think what we have mentioned here so far is a good start. The question is how much information do we want in the ini. Should we go as far as what apps are on what desktop? It might make it possible to put some basic task management into Rainmeter, which some people have been looking for. Perhaps that is something to look at later and we should just concentrate on basic VDM functions for now.

So, desktop switching, identifying the the desktop count and the names of each, which Rainmeter skins appear on each desktop and their position. Are there any other "basic" functions that I as a non-VDM user might be overlooking? I may want to start testing Dexpot personally...

[Patrick]

We're going to have a little delay, but I'm pretty sure we can get you window message access to the path information.

Great! Can you keep us posted on the development? And congrats on the 1.2 release.

The question is how much information do we want in the ini. Should we go as far as what apps are on what desktop?

That seems like overkill. It's also information which frequently changes. Constantly writing it to a file, which then has to parsed again probably isn't the best solution from a performance aspect.

So, desktop switching, identifying the the desktop count and the names of each, which Rainmeter skins appear on each desktop and their position. Are there any other "basic" functions that I as a non-VDM user might be overlooking?

Quite a few VDMs (possibly Dexpot 1.6 as well) organize their desktops in a grid layout. So you actually have a number of rows and columns of desktops. If a skins represents the desktops graphically in some way, it might want to use the same layout. We could store this information in addition to the desktop count. Maybe a command to bring up the settings dialog of the virtual desktop manager? Other than that, I can't think of any more basic functions either.

[dragonmage]

Quite a few VDMs (possibly Dexpot 1.6 as well) organize their desktops in a grid layout. So you actually have a number of rows and columns of desktops. If a skins represents the desktops graphically in some way, it might want to use the same layout. We could store this information in addition to the desktop count.

You mean desktops would be listed as A1,A2,B1,B2?

[Patrick]

Within the ini file, they would still be numbered 1 through 4. Skins can of course call them whatever they want. The information would mainly be used for things like deciding whether to show 4 desktops in a single row or as a 2x2 grid.

Code: Select all

   _____   _____   _____   _____
  |     | |     | |     | |     | 
  |  1  | |  2  | |  3  | |  4  |
  |_____| |_____| |_____| |_____|

   vs.
   _____   _____
  |     | |     |
  |  1  | |  2  |
  |_____| |_____|
   _____   _____
  |     | |     | 
  |  3  | |  4  |
  |_____| |_____|


[dragonmage]

This may make skin building a bit more interesting. It may require multiple versions of the skin that are automatically switched depending on the value of a Grid= key. We may need this

Code: Select all

Grid=1
Columns=2
Rows=2


added to the ini. It should be fun trying to get a skin to automatically arrange meters to a grid that can be changed.

[Patrick]

Ha, maybe you have to integrate Rainmeter with some sort of scripting language first.

[dragonmage]

Ha, maybe you have to integrate Rainmeter with some sort of scripting language first.

Yeah, that has been discussed but no one has stepped up to try to implement it yet.

I think it can be done with a series of calc measures, but I haven't had time yet to really map it out.

[dragonmage]

Have you guys signed up at our forum yet? I'd like for you to have an account so I can give you access to our Forum Devs section where we post private test builds before releasing public betas.