Can’t reproduce. For me “bring to front” works as it should.
So it brings it to the front even when the window is “up”, but behind another window? I have tried on multiple machines with both XP and 7 on them. And it only “bring it to fron” when the chat window is minimized.
I was testing locally with two clients. So when i was typing in another client, Spark window was in background. You can give a try to this installer (the most recent version from the svn) http://bamboo.igniterealtime.org/browse/SPARK-INSTALL4J-545/artifact/JOB1/Instal l4j
I’ve just done a new install of Openfire / Spark on Win7Pro and I’m finding precisely the same results as the OP. I have selected pref Bring Window to Front. If the chat is minimised to tray, then everything works as expected and the windows is brought to top. However if it is just hiding behind another window, it does not get brought to the foreground - or at least, not reliably. It does seem to behave every once in a while but these are rare and I can’t see a pattern.
This is an important requirement in corporate environments where the messaging is somewhat time-critical. In our health clinic context, the need is for the front desk to convey an important message to the specialist, who could be examining the patient and therefore miss the temporary Roar/Toast notifications. And they may not be observant or tech-savvy enough to notice the task bar flashing. To be honest my ideal scenario would be that the message sender could designate a particular message as requiring a user acknowledgement, in which case the window to Bring to Front AND Stay on Top until the message is acknowledged (i.e. click OK). From my googling, I am not alone in having this requirement.
But if Bring Window to Front worked, it would help in 95% of situations so that would make the deployment worthwhile.
I can provide a screen capture video showing the issue if that would help.
Happy to perform any kind of required diagnostics.
EDIT:
I figured this out. It is due to a registry setting called ForegroundLockTimeout that sets the time after user activity that windows can grab foreground control. Meant to stop apps from interfering with active users I suspect. Leaving the target computer idle for 200 seconds prior to sending the IM allowed the window to pop up in foreground.Setting the registry value to 0 as outlined here:
made the window pop-up in foreground every time, without the idle user requirement.
At least I understand why it is behaving as it is now.
Message was edited by: micro
1 Like
Good finding. After playing around with two clients (one of them Win7 x64) i have noticed that this timeout function only kicks in if you are interacting with other applications. E.g. you get a message and a window jumps in front. If you close it or minimize it, then next message will still bring it up in front even without waiting 200 seconds. But if instead you click some other app, say browser, then new messages will just blink in the taskbar without bringing the window up in front. Then after 200 seconds of idle new message will bring the window up again.
All of which leaves me with the following comments:
- The behaviour makes me wonder how Roar can seemingly override the registry parameter, as it is always brought to foreground regardless of recent user activity, and whether this can be applied to the chat window Bring to Front functionality.
- In looking more closely at the Roar settings, it is nicely configurable and will basically meet the requirement I outlined in my previous post, by putting say a 30 minutes (= 1800000 ms) in Spark -> Preferences -> ROAR -> Duration in ms). Now the notification will persist for 30 minutes providing ample opportunity for our specialist to glance at the screen and action the request (generally it is just to temporarily release a patient record so the front desk can update client details in preparation for invoicing). Of course I may have to revisit this if it drives everyone nuts, but I think we can avoid that with usage tips/policies.
- It would be nice if ROAR could be configured to leave the popup on-screen indefinitely, perhaps by configuring Duration in ms = 0. In other words, the window would persist until the user clicks the popup. How it works right now: if you configure Duration = 0, save and re-enter preferences, the parm has been reset to 3000 ms. While this is not a terribly important option in my context, I can see how it would be very useful for others and it seems like it would be fairly easy to implement (famous last words).
- More important, however, would be the ability for the message sender to mark only particular messages as requiring user acknowledgement or a long notification period. Alternatively, the admin or the recipient could set notifications from a particular room or user(s) to be different to others. An example might help, following on from the scenario I mentioned above: notifications from the front desk would receive priority notifications, i.e. ROAR for 30 minutes. However a chat room message would just do a normal toast popup as it would be chat, not an action-is-required scenario. Right now I plan to limit our use of Openfire/Spark to the urgent notification paradigm, as that is our greater business need, but ideally I would also be able to also use chat in a more collaborative way. Yes, I want to have my cake and eat it too.
Anyway those are my thoughts. Happy to post suggestions elsewhere if there is a more appropriate place.
Openfire/Spark is a FOSS at its best - I am impressed and grateful to the dev and wider community.
This is the appropriate place to post suggestions.
-
Roar is probably using some other window style (popup, tooltip), so the timeout option doesn’t apply to it. Not sure if it can be used for the chat window. But i’m not a developer myself. Looking through the Roar’s source i see RoarPanel.popupWindow function used.
-
As a workaround you can set it to say 30000000 and it would stay almost indefinitely. Though i haven’t tested, but it saves such a value. Of course, having it using a 0 for this would be more convenient/understandable. SPARK-1595. Though Roar’s developer is not active in the community/project anymore, so i can’t say when/whether anyone will look into this.
-
This sound too complex for a simple chatting program and a popup plugin (and even above the xmpp specifications: sending additional type information with the message). Having different settings for group chat and general chats sounds reasonable. SPARK-1596
i created a patch and issued a pull request
Hi, Wolf. Nice to hear from you wonder who will approve the pull. Walter is still assigned as a lead, but i’m not sure if he still doing this and an approves requests. Btw, which ticket is your patch for? Or both?
if you set roar time to 0 it will stay until clicked
so not fixing the bring-to-front problem 
wonder who will approve the pull.
That’s indeed a problem. Spark currently has no assigned maintainer. No one is taking care of it.
Walter is still assigned as a lead, but i’m not sure if he still doing this and an approves requests.
Haven’t heard from him in months.
Wolf’s PR merged by Konstantin Spark - INSTALL4J 666: Build result summary - Atlassian Bamboo
I know it has been a while since you created requirements SPARK-1595 and SPARK-1596 on my behalf. First of all: thank you for listening.
SPARK-1595 speaks for itself and thanks to Wolf for acting on it.
SPARK-1596 however, I think could perhaps benefit from reconsideration. You see - I had an idea that I believe could help create a rather clever solution to the problem. First let me reiterate the business issue in a very generic sense: some users might want some messages to be notified more prominently than others. I can think of all kinds of corporate contexts for that generic need. I appreciate, however, that in the IM world it must be difficult to agree on implementations that require code changes on both the sender’s and receiver’s device. Therefore I propose that this be handled entirely within the receiver’s client (in my case Spark). Here is how it could work:
- The receiver has a standard notification configured as it currently works. This would be the non-urgent case. For example, ROAR might not be used for most messages.
- However, there is also a configuration setting to specify a string in the message that would trigger a different notification. For example, if the receiver sets this string to be #URGENT# then whenever this string is included in the message text by the sender (which is simply a corporate procedure, not anything built into their IM client per se) then the ROAR notification is triggered.
To me it seems elegant and hopefully not too difficult to implement. It seems easier and more useful to me than the current reading of SPARK-1596. With this approach I do get to have my cake and eat it: users can participate in non-intrusive conversations, but urgent notifications are available on an exception basis. It also does not rely on a distinction between group vs individual chat, and realistically urgent notification could be useful in both contexts.
That’s my suggestion.
Regards
micro
Ok, i have filed another ticket https://igniterealtime.org/issues/browse/SPARK-1599 . I hope nobody will ask for a custom popup based on a time of a day
Hi wr00t
I assume your comment about SPARK-1599 is a bit tongue-in-cheek which is good, we all need a sense of humour. But really my point was that SPARK-1596 should be closed in favour of the approach laid out in SPARK-1599, which I believe represents a more versatile and easier to develop solution.
Is there any opportunity to fund the development of this requirement? Depending on the required investment level I would certainly consider it.
Regards
micro
I was joking, yes I have left the first ticket open, because i think they both may have a usage case (some users might want a custom popup just for the group chats).
Is there any opportunity to fund the development of this requirement? Depending on the required investment level I would certainly consider it.
Unless you will find a Java developer yourself and pay him to make a patch. There are no active Spark developers here for some time (it’s an open source project without much traction). I doubt you will find someone in these forums. It will probably be faster to find someone in your local area or via an online search. Roar plugin shouldn’t have huge source base, so it should be relatively easy to dig into a code and modify it.
Hi wroot
Thanks for your advice. Finding a java dev doesn’t sound too hard but will they be able to check in any changes they make, or are you suggesting that we just use the source and compile our own custom client? My preference, if we develop this, would be to give it back to the community but I notice that the change made by Wolf earlier has not made it into a release so maybe this is not possible? Please forgive my ignorance regarding open source dev processes.
Regards
micro
That’s ok. There is no defined default dev process for all open source projects. Everyone has their own processes.
As Spark’s and its plugins’ code is publicly available via igniterealtime/Spark · GitHub it is best to do changes in Git repository in your personal branch and then do a pull request to the master branch. Then someone will apply the changes (ideally it would also need a review, but currently there is no developer to do this, so quality assurance will be only testing after building).
As there is no team or at least a project lead behind Spark currently, there were no official releases for years. But every change is incorporated by the automatic build system. Wolf’s change is in the 2.7.0 #666 build Spark - INSTALL4J 666: Build result summary - Atlassian Bamboo . You can download this particular build by going into Artifacts > Install4J and select 2_7_0_666.exe (not the online one). Or you can go to this project’s home page and download the latest build (#668 at the moment) Spark - INSTALL4J: Plan summary - Atlassian Bamboo . I’m using 667 build in my network currently (668 had a minor fix for the building, so not worth upgrading and it should work the same as 667). Actually i suggest using 667 as it has a neat fix for the systray icon behavior.
Ah, I see. Thanks for explaining that - very useful! I’ll download the latest build for my deployment here.
I will explore development of this enhancement in due course but it may take a little while to works its way to the top of the priority list.
If anyone still cares, Wolf has just submitted a patch for both [SPARK-1596] Different settings for group chat Roar popups - IgniteRealtime JIRA and [SPARK-1599] Add an option for custom Roar popup based on a keyword - IgniteRealtime JIRA. It has been applied and can be tested in the latest test build (Windows, with Java): http://www.igniterealtime.org/builds/spark/dailybuilds/spark_2_7_7_811.exe
Keyword settings only apply when single-user chat popups are disabled. I think it should work with them enabled also. Have commented on that here Roar updates by wolfposd · Pull Request #130 · igniterealtime/Spark · GitHub
Aside from that it seems to be working perfectly