search

qdot / systray-rs

Allows rust applications to show a platform specific system tray icon and menu.
BSD 3-Clause "New" or "Revised" License
171 stars 66 forks source link

Figure out how resource (icon) embedding will work on windows #1

Closed qdot closed 7 years ago

qdot commented 8 years ago

From #rust: https://gitlab.com/DanielKeep/wui/blob/master/wui-build/src/lib.rs#L55-73

qDot: You should give it a try, use `rc.exe` on foo.rc to get foo.res, then rename it to foo.lib and tell cargo to link dylib=foo
daniel-abramov commented 7 years ago

What about include_bytes!()? Would this make a trick? The user can place the icon somewhere inside the project folder (like the user would have to do in case of using resources), then this image is loaded on compile time using include_bytes!() macro. After that we can use those bytes to set up the icon image and apply it to the window.

qdot commented 7 years ago

Hmm, yeah, that's totally a possibility, thanks! I'll take a look at that.

daniel-abramov commented 7 years ago

Oh, I've already solved this issue in the fork. As you did not replied in the beginning, I thought that you do not maintain the project anymore, so I made a fork and made the fixes to make it compilable. After that I implemented the requested behavior.

Here is the commit: https://github.com/snapview/systray-rs/commit/2a7a597118e88f82ae83701a4594e72584f85d1e

qdot commented 7 years ago

@application-developer-DA Oh, sorry. :( I had to move houses over the past couple of months which meant my participation dropped to zero and I started missing bugs. If you want to put in a pull request, I'd be happy to integrate your patches and put up a new crate version.

daniel-abramov commented 7 years ago

@qdot I can do that, but the problem is that we have a different list of dependencies. My fork relies on forks of winapi-rs, I've made quite a few changes in winapi-rs, for each of them I made a pull request to the winapi-rs, they were accepted by the maintainer for the new generation winapi-rs. Since the 0.3 version of winapi-rs is not production ready at the moment, I still have to use the patched "old" winapi-rs which currently resides inside my fork of winapi-rs.

Here is how the Cargo.toml looks like in my fork: https://github.com/snapview/systray-rs/blob/master/Cargo.toml

qdot commented 7 years ago

Yeah, we'll have to do a bit of commit surgery to get this to work, but it shouldn't be too bad. In order to get systray on crates.io, I went the other route and brought in my winapi patches into the windows module here. Not my preferred option, but I was waiting for winapi-rs 0.3 when I first started this project, and it looked like things hadn't moved at all on the 0.2 branch, so this is a stop gap. Once 0.3 lands, I'll just remove my additions and update the dependencies.

So, if you'd like, I can just pull your commits over, merge them and fix the dependencies for now. Saves you having to do the work, since this is me being hacky anyways. :)

qdot commented 7 years ago

@application-developer-DA Ok. Check out

https://github.com/qdot/systray-rs/commits/winicon-merge

I merged your changes (usually I'd rebase but I'll make an exception in this instance :) ), and did a little bit of conflict resolution in the merge. Only big change was the dependencies in the cargo file. Things seem to compile fine for me.

If everything looks good to you, let me know and I'll merge this to mainline and publish a v0.1.1 to crates.io.

daniel-abramov commented 7 years ago

@qdot Looks fine for me.

Given that you used merge, I guess that I'll have to use merges as well (for the future contributions). I'm also planning to add a mac implementation soon (I saw that you have some plans for that too).

qdot commented 7 years ago

@application-developer-DA From here on out, you can just rebase. The only reason I merged this time around is because we weren't really synced up when you first made the patches and rebasing would've meant changing your code, and I try not to do that if I don't know the contributor well.

As for the mac implementation, just a heads up... I've got core API changes coming into the linux-core branch that moves the callback/menu idx/etc management up to the top level of the library (see #7), so platform code should be much simpler. It wasn't supposed to be that way in the first place, I just got interrupted in the middle of development which is why the API used direct window access up until now. It's pretty much done, just finishing the linux core now then will fix up the windows code.

Other than that, not sure if you saw in #4, but we've got permission to port rs-barfly, so there's starter code there if you're interested.

qdot commented 7 years ago

Closing out (forgot to put the fixes tag in my conflict commit). Reference commit 183319e4f412802dd59c715be647f5a6dd819b1e