Just submitted Pull Request

I just submitted a small pull request to improve the click handling of the tray icon. There is no Jira ticket number associated with this improvement. The improved code now checks to see if the roster is minimized when the tray icon is clicked and, if so, restores it and brings it to front instead of just hiding the minimized window. This targets usability on Windows 7 & 8 in cases where the roster and a chat window are grouped together on the taskbar; in that situation repeated clicks on the tray icon could appear to have no effect.

Also, accepting this patch would move us off of build #666



edit Actually, it seems that this addresses the issue described in SPARK-1526, but in a different way than suggested in the ticket.

Message was edited by: Will Dimmit

Hey, thanks for the patch. I will try to get Konstantin’s attention on that, so it could be merged.Then i will give it a test. Yeah, it looks different than i thought for SPARK-1526 but it can still solve the problem (i can rename that ticket).

This patch can be a bigger incentive for me to push an update to my network (previous one with the url fix was not so critical). And i was hesitant to push the 666 update

Merged by Konstantin. I have tested it now and it works as supposed. Though it can still be confusing. Your fix targets only the minimized state.

Say i have on chat window open and no roster window. I click on systray icon. Roster window appears. Then i open Word fullscreen window and Spark’s roster window is hidden, but still up (not minimized). If then i want to bring Spark window up again, i click on systray icon. But it only closes/hides the roster window and i have to click again to bring it up. Wonder if Spark could check if its window is in the front or not when the systray icon is clicked.

Thanks for helping to get that merged so quickly! The previous minimized state behaviour was a personal pet-peeve of mine - but I was initially planning to address the problem you’re describing as well. In the bit of research I did on that, I was unable to come up with a sane way to determine if the roster was actually visible to the user. I am, however, fairly new to Java development, my background is C#. Lots of things are similar, but the UI implementation is worlds different - so I may have missed something. I’ll take another pass at it next time I’m in the code.

It might be that Konstantin saw your pull request before he got my message even If any, PM system here is a bit weird. Anyway, still thanks for the current implementation. I think it will make it less confusing for our users. I will close the ticket and if you’ll find a code to tune it further, we can reopen it or file a new one.

Thinking about this problem a little further and talking to a few users, one potential solution to this issue would be to change the tray icon action a little more significantly. My “user research” and personal experience tells me that nobody clicks on the tray icon to hide the roster; if the roster is open and they want it to go away, it is easier to simply close it directly. If we work from that, a more reasonable behavior for the tray icon might be to simply show the roster AND bring it to front on click. Further clicks wouldn’t hide the roster. This way, no matter what the state of the roster is, a click in the systray presents the user with the roster on top. No confusion.

One other possibility might be: one click shows the roster (on top) and a double-click hides the roster. Right now single and double clicks are handled as the same event.

What do you think?

I think second option would be too much confusing for users who are used to use single click or double click.

I tend to lean towards the first option (no hiding with a click). I like that you can quickly open and hide roster window, though i use it very rarely. Most of the users will only benefit from that. But we can piss off a few power users who actually use it to quickly glance at their roster and hide it without having to move a mouse to click the X button. I hate to introduce another option. But maybe this is a better way. We have Preferences > Login:

“Use single click in system tray to bring spark to front”

We can have there something like “Clicking in system tray never hides spark window” or “Clicking in system tray always brings spark to front” and it can be even enabled by default, so power users would only have to uncheck it. More work (adding new line to i18n file and option code), but maybe more liberal.

I will ask Konstantin too. We can have a poll on the start page about it, but from my experience only a few people care to vote

I think the behaviour change with the additional preference is a good idea. I haven’t worked in Spark’s preference handling code yet, so I’ll get to learn something new. Thanks for thinking through this with me.

Btw, Will, i think in 666 build you have fixed url links behavior. Wonder if SPARK-1597 is similar and maybe easy fix?

That’s a good question. From what I remember of that code, it certainly seems plausible that my fix could be extended. I’ll look into it.