* SPARK-2182 Fix logic
In session i see correct Resource, but i think we should save resource in spark.properties
* SPARK-2182 Fix logic
In session i see correct Resource, but i think we should save resource in spark.properties
* SPARK-2214 Replace depricated method
Renamed Flat*Laf.install() methods to Flat*Laf.setup() to avoid confusion
with UIManager.installLookAndFeel(LookAndFeelInfo info). The old
Flat*Laf.install() methods are still there, but marked as deprecated. They
will be removed in a future version.
https://github.com/JFormDesigner/FlatLaf/releases/tag/1.2
* rename method
The method should also be called "setup"
If you install Spark over old versions of Spark (2.6.3, 2.7.7, etc.), then old plugins remain in the user profile that are not in the new version. Because of this, errors appear in the logs. We have to do something with these obsolete plugins, for example, remove them.
Since starting from Spark 3.0.0 IBB is disabled by default due to this bug https://igniterealtime.atlassian.net/browse/SPARK-2209 . But after updating the Smack library to version 4.4.X, I cannot reproduce this bug with the IBB setting. Perhaps some administrators may want to manage IBB settings via ClientControl plugin Openfire for their clients.
Currently "Contact List Font Size" setting affects only names of the contacts, but groups names stay the same, which can be too small for some users. This setting should be applied to names of the groups as well.
1.OCSP should be disabled by default.
2.We have to handle the exception "Certificate does not specify OCSP responder"
I'm confused, maybe I should drop OCSP and remove it. How do you think?
These methods are not used and use reflection.
This raises a warning for Java 11-15.Due to the strong encapsulation introduced starting from jdk 16 some non-public classes, methods and fields of the java.* package are no longer available via reflection.
In the ‘Bookmarks’ drop down menu, all bookmarks are shown by their name.
Bookmarks set by some other clients (like Conversations) do not have a name. This causes the bookmark to show as an empty text.
If this happens, Spark should use another value, like the localpart of the room JID.
Swing event handling code runs on a special thread known as the event dispatch thread. Most code that invokes Swing methods also runs on this thread. This is necessary because most Swing object methods are not "thread safe": invoking them from multiple threads risks thread interference or memory consistency errors. Some Swing component methods are labelled "thread safe" in the API specification; these can be safely invoked from any thread. All other Swing component methods must be invoked from the event dispatch thread. Programs that ignore this rule may function correctly most of the time, but are subject to unpredictable errors that are difficult to reproduce.
It's useful to think of the code running on the event dispatch thread as a series of short tasks. Most tasks are invocations of event-handling methods, such as ActionListener.actionPerformed. Other tasks can be scheduled by application code, using invokeLater or invokeAndWait. Tasks on the event dispatch thread must finish quickly; if they don't, unhandled events back up and the user interface becomes unresponsive.
Spark should make clear what code is, and what code is not supposed to be executed on the Event Dispatch thread. This will help reduce instances where the UI seems frozen for prolonged periods of time, or otherwise behaves in an unexpected manner.
This commit adds comments to various methods (particularly around the login sequence) that define if the method is to be executed on the Event Dispatch Thread. Also, when ran in debug mode, code-checks will fail-fast, if such methods are executed differently. This will help spot problems.
