powered by Jive Software

Spark Main Window Size On Startup

When Spark is used on laptop with a small screen in combination with a docking station and larger screen in the office, depending on the shutdown condition there can be a Spark main window size problem when the laptop is subsequently used off the docking station and no external screen is attached.

The scenario is as follows:

The PC is on the docking station, the Spark main window is showing on the external screen at a relatively large size, bigger that the internal screen, then the PC is shutdown.

On PC start-up the Spark main window may be bigger, from top to bottom, than the laptop internal screen. As a result the Spark menu and window controls are off screen. Some Windows 7 users have problems in that they do not know how to get the Spark main window controls back in focus and visible on screen.

This is a work around for this problem on a Windows 7 PC:

When the main Spark window is larger than the display screen, open a chat window to a contact, this results in two open Spark windows, then left click on the task bar Spark group to show the two small selection Spark windows just above the task bar group, then right click the small selection main Spark window and select move, use the keyboard arrow keys to move the main Spark window to a point where the Spark menu and main form window controls are visible, finally use the mouse to complete the move. Easy if you know how but not for everyone and there may be an easier way do this same thing.

Apart from the description above, the main Spark window does not have the normal Windows move an size options when right click on the title bar.

Is it in the roadmap to, 1) add back move and resize control to the main window, 2) to automatically ensure that the Spark window opens onscreen resized to the maximum screen size if previously closed at some large size from an external screen ?

Thanks for the detailed report. It is always a pleasure to see such a report with a well detailed sequence of reproduction. It looks that Wolf has already done a fix for this before i even managed to file this http://issues.igniterealtime.org/browse/SPARK-1357

You can test this fix with a test build from here http://bamboo.igniterealtime.org/browse/SPARK-INSTALL4J-387/artifact/Install4j

This version update does resolve the described problem, i.e. the main spark window opens on the PC internal screen with the window controls visible when no external screen is attached at startup.


A report has come in regarding the Spark screen opening where the windows controls are not visible on screen, this user has the corrected version of Spark installed.


When testing this nightly build we may have found a new bug in file transfer, this problem did not happen with build 354.

When sending a file if the person recieving the file does not accept the file transfer offer immediately although the file will transfer OK when they do decide to accept the file transfer, the person sending the file will not see the file transfer progress nor will they see the file transfer completed message.

Filed as SPARK-1362. There was a file size restrictions introduced, as well as showing transfer speed recently. Some of those changes probably caused this regression.

Maybe this extra bit of information is relevant, the users experiencing this problem are all using an individual personal VPN connection to the OpenFire Server, i.e. their PCs will all have at least two IP addresses.

Try the latest build

Tested Spark version 433 to confirm the off screen Spark main window controls bug fix, unfortunately the main Spark window off screen controls problem still exists.

This is a summary of th problem again:

The notebook PC has a large external screen, larger than the internal screen. The Spark main window is showing on the large external screen where the top to bottom size of the Spark window is larger than the notebook internal screen, the PC is then shut down and the external screen is removed.

On startup the external screen is not connected, the windows desktop is shown on the notebook internal screen. After login the Spark main window opens at size and position that the windows controls, minimize maximize and close, and the top bar of the window are off screen and not visible.

AFAIK, Wolf is no longer participating in Spark project, so maybe Holger (another developer) will find time to look into this. Though i know that they both will stop working on Spark soon. Then we will have to wait for someone else to fix that. And this can take a long time. Thinking about workarounds, what about using smaller Spark window size, so it would fit on both screens? Or it doesn’t matter and it stretches out of bounds anyway?

This is a minor problem for most ICT people, there is a workaround described earlier unfortunately this problem and the workaround is more difficult for regular users. Users who have static workstations will not see this problem, presumably they will be the majority of typical Spark users.

i implemented a check to see if the mainwindow size is bigger than the desktopsize, and if so, it will rezise to desktopsize-200

so you should be able to use the corners of the window to resize it

else you can modify layout.settings in %APPDATA%/spark/





on a side note, i will still help with releasing 2.6.1

Your explanation makes it clear how you intend the solution to work and the code fragment is useful, thanks.

AjsAjs, can you try the latest build and confirm file transfer confirmation bug is still happening for you? http://bamboo.igniterealtime.org/browse/SPARK-INSTALL4J-609/artifact/JOB1/Instal l4j/

Overlooked your question until now, sorry about that.

We have been using 609 for some time (since the week after it became available). File transfer appears to be Ok with this version.

There are still some MUC issues with 609 and we had connection problems when we tried version 614, we are happy to provide feedback, is there another suitable thread for this feedback?

Thanks for your reply. Closing the file transfer bug ticket.

My company is now on 610 version and it seems to work ok. The only major change from 609 is integration of the newest Smack version (3.3.1), the underlying library. Which should actually improve things and fix memory leaks. I don’t remember any recent posts about connection issues or MUC issues, so maybe you should start a new thread.