Michael Marley [Mon, 24 Feb 2014 14:12:27 +0000 (14:12 +0000)]
Allow for clients to negotiate whether compression is used
Previously, streaming compression would always be used for the
datastream protocol and never for the legacy protocol, regardless
of whether the client set the compression bit during the handshake.
This patch enables negotiation of compression support and also
allows for streaming compression when using the legacy protocol
with the new handshake.
As is, this patch prevents clients with streaming compression
support but without this patch from connecting to cores with this
patch. This problem occurs because the above-mentioned clients
never set the compression bit during the handshake, which didn't
cause a problem before because both sides unconditionally enabled
compression. However, when connecting to a core with this patch,
such a client will request no compression and the core will
disable compression. However, the client will still enable the
compression anyway, causing the connection to fail.
Daniel Albers [Fri, 21 Feb 2014 12:13:21 +0000 (13:13 +0100)]
update quassel.pot
Daniel Albers [Fri, 21 Feb 2014 12:13:03 +0000 (13:13 +0100)]
adapt translations to previous change
Daniel Albers [Fri, 21 Feb 2014 11:58:16 +0000 (12:58 +0100)]
move © years out of translatable text in aboutDlg
Daniel Albers [Fri, 21 Feb 2014 11:55:56 +0000 (12:55 +0100)]
remove old static versionLabel text
Manuel Nickschas [Wed, 19 Feb 2014 22:14:37 +0000 (23:14 +0100)]
Silence yet another warning
I have no clue why neither gcc nor clang throw a -Wsign-compare for me
there, but do for some other people, so... *sigh*
Manuel Nickschas [Wed, 19 Feb 2014 21:41:41 +0000 (22:41 +0100)]
Fix -Wundef warning
Was thrown on 32 bit, should be #ifdef instead of #if because the attribute
is only defined on 64 bit machines.
Manuel Nickschas [Wed, 19 Feb 2014 20:19:32 +0000 (21:19 +0100)]
Use system zlib if available
Only fall back to miniz if we don't find zlib on the system. Distro
packagers like this much more, and we use code that has seen much
more testing. Incidentally, we've already had one case where miniz was
really slow on a 32 bit box.
Still keeping miniz as fallback for the rare platform/build box that
doesn't ship zlib, since waiting a few seconds for compressing the
backlog is still probably better than transmitting a few MB of extra
data...
Manuel Nickschas [Wed, 19 Feb 2014 18:47:52 +0000 (19:47 +0100)]
Silence one more warning in miniz.c
Building on 32 bit machines causes some warnings related to undefined
macros; -Wno-undef silences that.
Daniel Albers [Tue, 18 Feb 2014 23:57:54 +0000 (00:57 +0100)]
update quassel.pot
Daniel Albers [Mon, 25 Nov 2013 04:00:37 +0000 (05:00 +0100)]
Update translations from Transifex
24961 translated messages
Many thanks to:
- es: Adolfo Jayme Barrientos <fitoschido@ubuntu.com>
- fi: Larso <larso@gmx.com>
- hi: libregeekingkid <rajuvindane@gmail.com>
- nl: Simon Philips <simon.philips@gmail.com>
- pa: A S Alam <apreet.alam@gmail.com>
- tr: volkangezer <volkangezer@gmail.com>
- uk: Yuri Chornoivan <yurchor@ukr.net>
- zh_CN: leonfeng <chaofeng111@gmail.com>
Daniel Albers [Mon, 25 Nov 2013 00:27:34 +0000 (01:27 +0100)]
i18n: add some statistics to commit messages
Manuel Nickschas [Tue, 18 Feb 2014 22:40:06 +0000 (23:40 +0100)]
Bump version.inc for release
Manuel Nickschas [Tue, 18 Feb 2014 22:28:52 +0000 (23:28 +0100)]
Update ChangeLog
Manuel Nickschas [Tue, 18 Feb 2014 22:14:02 +0000 (23:14 +0100)]
Update AboutDlg
Chris H [Sun, 16 Feb 2014 02:26:05 +0000 (21:26 -0500)]
Use a unicode string instead of the escaped version.
Compiling with MSVC Doesn't like unicode literals here.
Deniz Türkoglu [Thu, 13 Feb 2014 11:44:21 +0000 (12:44 +0100)]
Disable webpreview to avoid user interactaction
If the user interacts with the webview, for instance click a button
or type text in it, it crashes the client.
Disable the webview so we still get the previews but can't interact
with them.
Patrick von Reth [Tue, 21 Jan 2014 11:29:41 +0000 (12:29 +0100)]
Use new snore api and a bug fix
Adam Harwood [Sat, 21 Dec 2013 17:31:13 +0000 (17:31 +0000)]
Add option to include read messages in chat monitor
When the show backlog option is used, give users the option to include previously read messages.
Awad Mackie [Sat, 24 Mar 2012 15:54:22 +0000 (15:54 +0000)]
Add option for chat monitor to look in the backlog
See #734. Thanks to Adam Harwood for rebasing this. ~Sput
Pete Beardmore [Wed, 28 Aug 2013 10:42:36 +0000 (11:42 +0100)]
Add option to enable linewrap mode
Implements #1081.
Chris Le Sueur [Thu, 23 Jan 2014 00:29:04 +0000 (00:29 +0000)]
Add CoreFeatures guard for hiding inactive networks
Chris Le Sueur [Wed, 15 May 2013 22:44:26 +0000 (23:44 +0100)]
Add a setting to hide inactive networks in buffer views
Manuel Nickschas [Mon, 17 Feb 2014 22:24:20 +0000 (23:24 +0100)]
PeerFactory is not a QObject
warnings--
Manuel Nickschas [Mon, 17 Feb 2014 22:22:17 +0000 (23:22 +0100)]
Fix CFLAGS for miniz
... and make sure KDE doesn't overwrite them with something that
makes miniz not compile (apparently it's not C89 compliant...)
Manuel Nickschas [Mon, 17 Feb 2014 21:21:29 +0000 (22:21 +0100)]
Enable the DataStream protocol by default
Now that compression works, let's use the DataStream protocol
by default if both sides claim support for it.
Manuel Nickschas [Mon, 17 Feb 2014 21:18:39 +0000 (22:18 +0100)]
Implement streaming compression support
This leverages miniz in order to DEFLATE the data stream between
client and core. This is the standard format supported by zlib.
Note that streaming compression currently is unconditionally enabled
for the DataStream protocol, and unconditionally disabled for the
legacy protocol. We'll make them honor the handshake negotiation
later.
Manuel Nickschas [Mon, 17 Feb 2014 21:13:18 +0000 (22:13 +0100)]
Add miniz, a drop-in replacement for (parts of) zlib
miniz is a single-file drop-in replacement for most of zlib's
functionality. Having this bundled is quite convenient for us, so we
can rely on compression even on platforms where zlib is not readily
available.
miniz allows disabling unneeded functionality at compile time, by changing
some #defines, so we just compile the parts we really need (namely, the
basic DEFLATE routines).
We may use zlib proper in the future if we find it at compile time, though.
Manuel Nickschas [Sun, 16 Feb 2014 21:28:21 +0000 (22:28 +0100)]
Hook the Compressor into RemotePeer
Instead of reading from/writing to the socket directly, RemotePeer now
goes through a Compressor instance. At this time, no actual compression
will happen though.
Note that the legacy protocol does not support streaming compression, which
is why it sets a compression level of NoCompression.
Manuel Nickschas [Sun, 16 Feb 2014 21:22:52 +0000 (22:22 +0100)]
Introduce basic (not-yet-compressing) implementation of Compressor
This class is intended to encapsulate the streaming compression between
the socket and the rest of RemotePeer; however, actual compression is
not yet implemented.
The Compressor class sits on top of the socket, providing a rudimentary API
for reading and writing data, and will transparently handle the (de)compression
once it's finished.
Manuel Nickschas [Sun, 16 Feb 2014 16:29:28 +0000 (17:29 +0100)]
Move all socket handling into RemotePeer
Previously we had the RemotePeer subclasses reading from and writing to
the socket themselves, resulting in code duplication and also making it
hard to have a single point for implementing compression support later.
We assume that any protocol we may come up with will send the size of
a datagram followed by the datagram itself, thus there's no need to
implement that part in the individual peers. And if we ever come up
with something else, we can always make some methods virtual and
override them for the special case.
We avoid using QDataStream in RemotePeer, as we are only reading/writing
QByteArrays anyway. That way, we can also replace the direct calls to
the socket by the layer implementing compression later, without it being
a proper QIODevice.
Manuel Nickschas [Sat, 15 Feb 2014 20:58:46 +0000 (21:58 +0100)]
Don't select the DataStream protocol by default for now
Until we have streaming compression implemented, using the DataStream
is not such a brilliant idea compared to the legacy protocol which
at least individually compresses messages. Thus, we should not select
the DataStream protocol by default.
Clients wanting to play around with the new protocol are still free to
negotiate this during handshake.
Manuel Nickschas [Sat, 15 Feb 2014 20:55:30 +0000 (21:55 +0100)]
Remove the STORED attribute from Q_PROPERTY declarations
Due to some lack of documentation reading and consequential misunderstanding
of what the STORED=false attribute means for a QProperty, we still had some
really old headers wrongly declaring those.
I'm not aware of any effect on anything that having those has, but better
to just clean those up.
Manuel Nickschas [Sat, 15 Feb 2014 20:49:59 +0000 (21:49 +0100)]
Output the chosen protocol type on connect
Just some debug messages showing which protocol has been selected.
Manuel Nickschas [Sat, 15 Feb 2014 20:40:45 +0000 (21:40 +0100)]
DataStreamPeer: Optimize IrcUsersAndChannels init data
This is the only occasion where we change the actual message contents
for the DataStream protocol, as opposed to the legacy protocol.
However, it's worth it, because the init data for IrcUsers is the single
biggest offender in terms of data usage during sync, and we were wasting
lots of space by sending potentially thousands of identically-structured
QVariantMaps (one per IrcUser), each of which contains an indentical set
of key names. The same was true for IrcChannels in that same message,
although the data set tends to be smaller for that one.
We've now changed that by sending the init data for all the users and
channels as lists of attributes, which are then reassembled into individual
initData maps after receiving them. Our benchmarks show space savings
around 56%, which can amount to several megabytes in the uncompressed case,
provided you are in lots of busy channels. With compression it's less
impressive, but we can still save a few hundred kilobytes.
The legacy protocol gains a pair of translation methods for this special case,
thus there are no changes in the legacy format.
Manuel Nickschas [Wed, 29 Jan 2014 00:36:49 +0000 (01:36 +0100)]
DataStreamPeer: Optimize the InitData message
Since an InitData message consists of the usual message header
(serialized as a QVariantList) followed by a QVariantMap, we can
do what we did in a few other places already; transform the map
into a list of key-value pairs, the keys being UTF-8 strings (as
QByteArrays) instead of QStrings, and append that list to the
rest of the message.
This is just a small optimization, but straightforward to do without
changing protocol semantics or introspecting payloads. And
since we send lots of InitData messages, saving even a few bytes
per message may be worth it.
Manuel Nickschas [Tue, 28 Jan 2014 23:08:34 +0000 (00:08 +0100)]
DataStreamPeer: Optimize message serialization format
The legacy protocol serializes all messages as QVariant-in-a-QByteArray.
Except with compression, then it is QVariant-in-a-compressed-
QByteArray-in-a-QByteArray. While the actual messages either
comes as a QVariantList or a QVariantMap which is encapsulated
in above QVariant-in-a-mess.
In other words, this seems a bit excessive and causes unneeded overhead.
So for the DataStreamPeer, we're simplifying this. As all post-handshake messages
are structured as a QVariantList, we're now making this the on-wire format
as well. Since we need to know the message size for deserialization, we
first send the total message size as a quint32, followed by the number of items
as a quint32, followed by the QVariants. [1]
Since handshake messages are QVariantMaps, and we want to avoid over-nesting things,
we now send those as such a QVariantList as well, where the items are key-value
pairs - the key as UTF-8 string (as a QByteArray), and the value as a QVariant.
[1] This happens to be the same format as a QByteArray containing a QVariantList,
so the code for that gets rather simple.
Manuel Nickschas [Fri, 24 Jan 2014 22:58:51 +0000 (23:58 +0100)]
DataStreamPeer: Send QDateTime instead of QTime in heartbeat messages
This allows the lag detection to work correctly even during a day change.
Manuel Nickschas [Fri, 24 Jan 2014 22:54:25 +0000 (23:54 +0100)]
DataStreamPeer: Use UTF-8 QByteArrays instead of QString for message headers
This affects the objectName in SyncMessage, InitRequest and InitData.
While the savings should be rather small in particular with compression
enabled, we shouldn't skip this opportunity; while introspecting all
serialized data for QStrings would be too invasive, we can easily do
it for those clearly defined message fields.
Manuel Nickschas [Fri, 24 Jan 2014 22:52:17 +0000 (23:52 +0100)]
DataStreamPeer: Remove per-message compression
With the new handshake, we're going to use streaming compression, which
is negotiated and initiated before the peer is instantiated.
Manuel Nickschas [Fri, 24 Jan 2014 22:50:59 +0000 (23:50 +0100)]
DataStreamPeer: Remove obsolete stuff
Manuel Nickschas [Fri, 24 Jan 2014 22:15:02 +0000 (23:15 +0100)]
Introduce the DataStreamProtocol
This is going to be a streamlined version of the LegacyProtocol, still
using QDataStream serialization, but with some of the overhead removed
from the message formats and not supporting stuff that's deprecated.
The DataStreamProtocol will be automatically selected if both client
and core support it.
This commit simply adds a copy of the LegacyProtocol with the necessary
changes to make it compile. The optimizations are going to be in separate
commits so that the changes can be easier tracked by others implementing
it.
Manuel Nickschas [Fri, 24 Jan 2014 22:01:12 +0000 (23:01 +0100)]
Make LegacyPeer::writeSocketData() private
No longer used outside of this class.
Manuel Nickschas [Wed, 29 Jan 2014 20:54:25 +0000 (21:54 +0100)]
There won't ever be a Qt 4.9...
... and this should actually have been a check for Qt 4.7+.
Manuel Nickschas [Wed, 29 Jan 2014 19:27:48 +0000 (20:27 +0100)]
Make CTCP PING report the correct millisecond round-trip time
If we want to display latency in milliseconds, we should also make sure
our payload is set in milliseconds.
Unfortunately, millisecond resolution for QDateTime appeared only in
Qt 4.7, so it'll stay in seconds for cores built against older Qt versions.
Bas Pape [Mon, 1 Aug 2011 08:11:02 +0000 (10:11 +0200)]
Use milliseconds for CTCP PING
Manuel Nickschas [Thu, 23 Jan 2014 21:34:39 +0000 (22:34 +0100)]
Use PeerFactory instead of creating LegacyPeer directly
This means that legacypeer.h needs be included by peerfactory.cpp only,
and we can remove all references to it elsewhere.
Manuel Nickschas [Thu, 23 Jan 2014 21:30:59 +0000 (22:30 +0100)]
Have the PeerFactory provide the list of supported protocols
... and make use of that in ClientAuthHandler, instead of hardcoding
the available protocols there.
Manuel Nickschas [Thu, 23 Jan 2014 21:15:18 +0000 (22:15 +0100)]
More typedef, less typing
Manuel Nickschas [Thu, 23 Jan 2014 19:36:43 +0000 (20:36 +0100)]
Implement protocol detection
This introduces a new initial handshake for negotiating the supported
protocols and connection features on both sides. It is completely
backwards compatible with older releases, in which case we go into
fallback mode.
Arguably, we could've used a nice, verbose, text-based handshake, but
that would've introduced questions around string formats, parsing and so
on. Also I felt like doing some bitbanging, so now the probing only
exchanges a few bytes which are described in the wiki [1]. If we ever
plan to use a more verbose or different format, changing the magic that
starts the whole shebang will be sufficient to indicate a new format.
Immediately after probing, if both core and client support the new format
(and a protocol other than the legacy one),we'll enable SSL and compression [2]
as appropriate, instead of doing it somewhat later in the middle of the legacy
handshake.
To retain compatibility, the magic number sent by the client is designed such
that older cores will immediately close the connection; we'll then reconnect
in compatibility mode. The other way round, if an older client connects to
a new core, we'll figure out that there's no magic being sent and switch to
legacy mode as well.
The unchanged legacy protocol is also the last resort even if both ends speak
the new handshake as long as we don't have an alternative to offer. So for now,
we'll probe for protocol support, get back the legacy protocol as only choice,
and use that as before. This also disables early SSL and compression mentioned above.
This means that 3rd party clients could already implement the handshake in
preparation for the future without changing anything else. Note that they should
also implement the detection of older cores in order to stay compatible with them -
simply detect a disconnect after the first few bytes sent and reconnect again
in compat mode.
[1] http://bugs.quassel-irc.org/projects/quassel-irc/wiki/Doc_quassel_protocols
[2] Not implemented yet.
Manuel Nickschas [Thu, 23 Jan 2014 19:32:25 +0000 (20:32 +0100)]
Allow overriding of socket handling methods
This is primarily needed for ClientAuthHandler, which does not want
to throw error messages to the outside during protocol detection.
Manuel Nickschas [Thu, 23 Jan 2014 00:47:50 +0000 (01:47 +0100)]
Add PeerFactory
This factory creates an instance of a RemotePeer subclass based on the
given protocol type and peer-specific features. If given a list, it will
select the preferred one (generally the first one that matches an available
peer which accepts the given peer-specific features).
For now, we just have the LegacyPeer (which does not have specific
features, so that value is ignored).
Manuel Nickschas [Thu, 23 Jan 2014 00:17:46 +0000 (01:17 +0100)]
Let RemotePeer(s) tell their protocol type and features
Knowing a peer's supported procotol type will come in handy once we
support more than one protocol. Also, peers may support specific
features which they can now report via the new accessor.
Manuel Nickschas [Thu, 23 Jan 2014 00:05:29 +0000 (01:05 +0100)]
Handle the readyRead() signal in RemotePeer instead of LegacyPeer
That way, the RemotePeer subclasses don't all need to connect to the
signal themselves; also, we can make sure in a central place that
socket data is processed even the socket was handed over to the peer
with unhandled data still in its buffer.
Instead of handling the signal directly, RemotePeer subclasses need
to implement the onSocketDataAvailable() method.
Manuel Nickschas [Wed, 22 Jan 2014 19:47:04 +0000 (20:47 +0100)]
Update AboutDlg
Michael Kedzierski [Fri, 17 Jan 2014 12:52:15 +0000 (23:52 +1100)]
Change ifdefs around Main ToolBar fix to target mac only.
Michael Kedzierski [Fri, 17 Jan 2014 11:45:49 +0000 (22:45 +1100)]
Save Main ToolBar state when not built against KDE. Fixes #1116
Manuel Nickschas [Sun, 19 Jan 2014 02:29:57 +0000 (03:29 +0100)]
Fix signedness
This should actually be unsigned.
Manuel Nickschas [Sun, 19 Jan 2014 02:27:14 +0000 (03:27 +0100)]
Remove unused
Thanks Clang.
Manuel Nickschas [Sun, 19 Jan 2014 02:11:39 +0000 (03:11 +0100)]
Fix header guard
Thanks Clang.
Manuel Nickschas [Sat, 18 Jan 2014 18:06:06 +0000 (19:06 +0100)]
Encapsulate socket state in AuthHandler, properly handle disconnects
The actual state of the socket used to connect to the core should be
kept internal to AuthHandler (and RemotePeer), in particular because
we want to handle the detection of legacy cores transparently later.
Also, it does not make sense to handle individual socket states outside
of the classes actually dealing with the socket; handling errors and
disconnection is sufficient. Both AuthHandler and Peer now emit
statusMessage() signals for displaying the socket state in the UI.
Because it was never used nor is it needed, this commits also removes
the AuthHandler::State enum.
While doing this, I also stumbled over the most likely reason for the
problem that the client would sometimes not reconnect to a core even
though it would claim to be disconnected:
QTcpSocket will only emit disconnected() when it had already reached
the Connected state, i.e. not if it was still connecting. While
CoreConnection would detect the socket go back to UnconnectedState,
and set its own state to Disconnected, it would never do its internal
clean-up which was tied to the socket's disconnected() signal, unless
the socket would also emit an error (which it apparently doesn't do
in all cases...). As a result, reconnecting was not possible in these
situations.
With these changes, CoreConnection relies solely on AuthHandler's
disconnected() signal, which is properly emitted even if establishing
the connection fails.
Manuel Nickschas [Tue, 14 Jan 2014 00:10:41 +0000 (01:10 +0100)]
Update AboutDlg
Chris H (Shade / Zren) [Thu, 22 Aug 2013 22:25:51 +0000 (18:25 -0400)]
Implement issue #1219: Update the marker line when quassel loses focus
Solves issue #1219 on bugs.quassel-irc.org.
We now listen for QEvent::WindowDeactivate in the main window. This
should pickup on window closing/minimizing/losing focus. We also change
view->setMarkerLine() to Client::setMarkerLine which will send an event
to the syncher, and eventually arrives at ChatView::markerLineSet, which
moves the marker line for us.
Manuel Nickschas [Mon, 13 Jan 2014 23:35:33 +0000 (00:35 +0100)]
Socket options require Qt 4.6+
Daniel Albers [Mon, 6 Jan 2014 14:27:12 +0000 (15:27 +0100)]
set SO_KEEPALIVE on client sockets
Michael Marley [Wed, 11 Dec 2013 21:15:58 +0000 (21:15 +0000)]
Improve reliability of SSL connections
First, this fixes a bug similar to Bug #1249 except for SSL
connections. If the TCP connection fails but isn't
actually closed before the SSL handshake is complete,
Quassel will become stuck and never attempt to reconnect.
The solution is to start the ping timeout even earlier,
before the connection is established at all.
Second, this fixes the issue where multiple presses of the
"Disconnect" button and long waits were required to close
certain broken SSL connections (where SSL negotiation was
not yet complete, as above). The solution is to call
socket.abort() instead of socket.disconnectFromHost(),
which will ensure that the socket is closed immediately.
Additionally, in case that fails for some reason, the
socketCloseTimer is no longer a single-shot timer, so
if the first abort doesn't work, it will keep trying.
(Probably?) fixes bug #1005
Manuel Nickschas [Mon, 13 Jan 2014 23:00:35 +0000 (00:00 +0100)]
Use a different icon for web search
Chris H (Shade / Zren) [Wed, 3 Apr 2013 00:52:02 +0000 (20:52 -0400)]
Search the web with selected text.
Add context menu option when selecting text in order to search the web for the selection.
The url used in web search configurable in the ChatView settings panel.
Uses the zoom-in icon until it gets it's own icon.
Manuel Nickschas [Wed, 1 Jan 2014 22:25:47 +0000 (23:25 +0100)]
Happy New Year!
Manuel Nickschas [Wed, 1 Jan 2014 22:11:03 +0000 (23:11 +0100)]
Make DCC support opt-in for now
As support for DCC is unfinished, untested and potentially dangerous
(i.e. one could spam your desktop with millions of dialog boxes), disable
it by default.
People really wanting to play around with this may start the core
with --enable-experimental-dcc, but you have been warned.
Manuel Nickschas [Wed, 1 Jan 2014 22:02:42 +0000 (23:02 +0100)]
Remove unused slots
Manuel Nickschas [Wed, 1 Jan 2014 21:54:23 +0000 (22:54 +0100)]
First working version of DCC Receive
This finally allows accepting a file via DCC and storing it on the client side.
Note that this is still a very basic implementation, in particular missing
* Proper status messages (still claiming to receive unknown CTCP, for example)
* Proper error handling
* Proper testing
* Any kind of configuration
* Any kind of UI besides the simple dialog on incoming files
* No queuing or any form of transfer management
* Things like DCC REVERSE
However, it serves as a nice proof-of-concept for the general approach of
passing data directly to a particular client using the usual sync mechanism
(i.e. no special protocol support or additional connections needed). First
client to accept the transfer will get the file.
Note that the *core* is the one handling the DCC connection itself, so things
like port forwarding or firewall support need to be done core-side.
Manuel Nickschas [Wed, 1 Jan 2014 21:51:25 +0000 (22:51 +0100)]
MainWin should get a ClientTransfer pointer
Just listening to the appropriate signal makes more sense if we
actually want to use client-side functions later.
Manuel Nickschas [Sat, 28 Dec 2013 21:26:27 +0000 (22:26 +0100)]
Refactor the transfer stuff
Well, sometimes refactorings come sooner than usual. While thinking
about the next steps, I decided to handle the actual transfer logic
inside Transfer rather than TransferManager - now that we can have
selective (peer-based) sync calls as well, that makes more sense than
outsourcing that to TransferManager. Thus, it now makes lots of sense
to have ClientTransfer and CoreTransfer, as the logic will be quite
different.
I also took the opportunity to clean up the accessors and make them
safer; you can now get a non-const CoreTransfer pointer, for example,
but still only a const ClientTransfer pointer.
Also, some useful signals have been added.
Manuel Nickschas [Sat, 28 Dec 2013 19:35:51 +0000 (20:35 +0100)]
Add handler for DCC-SEND
This adds a basic handler for incoming DCC-SEND requests. Note that not
all features are supported yet, there are no settings and no way to disable
it. Also, the EventStringifier hasn't been adapted yet, so there will be
a warning about an unknown event in the status buffer...
Manuel Nickschas [Sat, 28 Dec 2013 17:55:20 +0000 (18:55 +0100)]
Add a very rudimentary UI for accepting a transfer
This is just a temporary solution for being able to accept or
reject an incoming transfer. We just display a little dialog and offer
a way to specify a path for saving.
This lacks many features and will be replaced by a proper transfer manager
widget later.
Manuel Nickschas [Sat, 28 Dec 2013 17:49:54 +0000 (18:49 +0100)]
Make the Transfer::accept() and ::reject() machinery work
This adds the necessary stuff to be able to accept/reject a transfer
on the client side, syncing it on the core side and setting the
necessary signals. The core also receives a PeerPtr, so it can keep
track of which peer actually accepted the transfer.
Manuel Nickschas [Sat, 28 Dec 2013 16:56:36 +0000 (17:56 +0100)]
Add missing accessors to TransferManager
Nice to be able to access the list of transfers.
Manuel Nickschas [Sat, 28 Dec 2013 16:53:19 +0000 (17:53 +0100)]
Transfer needs a nick attribute
So we can show who sent us a file, which may be a nice thing to know.
Manuel Nickschas [Sat, 28 Dec 2013 16:49:28 +0000 (17:49 +0100)]
Delete the TransferManager on disconnect
Makes sense, doesn't it...?
Manuel Nickschas [Fri, 27 Dec 2013 20:24:43 +0000 (21:24 +0100)]
Make the PeerPtr trick work with sync calls as well
The mechanics for replacing a PeerPtr as first argument by the
sending peer (and using it as a filter for the other direction)
are already in place; with just some tweaks we can also make it
work for sync calls in addition to RPC calls, which allows for
selectively calling methods in your sync partner.
Manuel Nickschas [Thu, 26 Dec 2013 19:57:34 +0000 (20:57 +0100)]
Basic infrastructure for file transfers
This introduces the Transfer class as well as TransferManager and the
specialized versions for client and core. It also adds the needed accessors
in Client and CoreSession as well as the SyncableObject stuff to make it all
work together.
To make something happen, a Transfer needs to be created on the core side with
the appropriate attributes; it needs then to be synchronized and handed over
to CoreTransferManager::addTransfer(). This will trigger the creation of the
appropriate Transfer object on the client side, adding this to the
ClientTransferManager as soon as synchronization is complete (meaning, the
transferAdded() signal will be fired with a fully synchronized Transfer object).
Note that the list of transfers is not synchronized (yet?), so there won't be a
transfer history on re-sync.
Manuel Nickschas [Sun, 10 Nov 2013 22:25:07 +0000 (23:25 +0100)]
Allow peer-specific sending and receiving of remote signals
For file transfers and possibly other use cases, it is important to know
which peer has received a specific signal, and to allow sending remote
signals only through a particular peer rather than multicasting to all connected
clients.
For this reason, we now treat attached signals/slots specially if their first
argument is a PeerPtr (a typedef for Peer *):
* An attached slot will have a pointer to the peer which received the signal in
its first argument
* An attached signal on the core side will be relayed only through the peer that
is given as the first argument (and the receiving slot will have a pointer to
the client-side peer in this argument)
* The peer argument for an attached signal on the client side will be ignored,
as clients only have one peer anyway
Manuel Nickschas [Sun, 22 Dec 2013 23:48:45 +0000 (00:48 +0100)]
Fix fullscreen mode
In some setups, the FullScreen action would get out of sync with
the actual window state and thus kick Quassel into an endless loop
and finally a crash when toggling full screen mode.
Turns out reading the docs for KToggleFullScreenAction helped doing
this properly (avoiding this and other bugs when using QWidget's methods).
Thanks to yofel and hays for reporting, and apachelogger for putting
me on the right track for fixing this.
Fixes #1153, fixes #1258.
Patrick von Reth [Wed, 4 Dec 2013 10:17:32 +0000 (11:17 +0100)]
code style
Patrick von Reth [Mon, 25 Nov 2013 13:33:16 +0000 (14:33 +0100)]
removed debug output
Patrick von Reth [Mon, 25 Nov 2013 11:46:02 +0000 (12:46 +0100)]
code style in snore backend, and a more user friendly config widget
Martin Sandsmark [Tue, 17 Dec 2013 15:26:39 +0000 (16:26 +0100)]
Fix notifications when minimized.
QWidget::isVisible() just checks if the widget has been explicitly
hidden, not if it is minimized, covered, or whatnot.
Fixes #1240
Manuel Nickschas [Thu, 28 Nov 2013 00:45:43 +0000 (01:45 +0100)]
Make sys includes POSIX-compliant
We're using <sys/resources.h> in quassel.cpp for the backtrace generation
stuff. Documentation for that header indicates that <sys/time.h> shall also
be included (even though it doesn't seem to be needed for our usage).
Additionally, compiling started to fail in recent FreeBSD versions, because
we lacked the <sys/types.h> include, which seems to be mandated by POSIX
(but not on Linux, although it won't hurt to have it).
tl;dr: This should make Quassel compile on recent versions of FreeBSD again.
Manuel Nickschas [Tue, 26 Nov 2013 21:25:25 +0000 (22:25 +0100)]
Update ChangeLog
We had to postpone the release by a day.
Daniel Albers [Mon, 25 Nov 2013 00:08:25 +0000 (01:08 +0100)]
update quassel.pot
Daniel Albers [Sun, 24 Nov 2013 23:41:10 +0000 (00:41 +0100)]
transifex.net → .com
Daniel Albers [Sat, 26 Oct 2013 23:28:58 +0000 (01:28 +0200)]
tx-sync.sh: try to pull first
Daniel Albers [Fri, 25 Oct 2013 09:45:34 +0000 (11:45 +0200)]
mark string untranslatable
Daniel Albers [Sat, 12 Oct 2013 03:00:37 +0000 (05:00 +0200)]
Update translations from Transifex
Many thanks to:
- cs: Vít Pelčák <vit@pelcak.org>
- da: furyfire <frazzer@hotmail.com>
- de: m4yer <m4yer+quassel@minad.de>, ToBeFree <tobias@freiwuppertal.de>, Heffer <felix@fetzig.org>
- eo: cordata <tiffypet@yahoo.com>
- fi: Larso <larso@gmx.com>
- fr: Dorian <munto@free.fr>, GrecKo <gr3cko@gmail.com>
- gl: Condex <elgomaisa@gmail.com>
- hi: libregeekingkid <rajuvindane@gmail.com>
- hu: ulysses <ulysses@kubuntu.org>
- mr: libregeekingkid <rajuvindane@gmail.com>
- nl: simonphilips <simon.philips@gmail.com>
- oc: Cedric31 <cvalmary@yahoo.fr>
- pl: derpella <matwa@poczta.pl>
- pl: Marcin Jabrzyk <marcin.jabrzyk@gmail.com>
- pt_BR: Pad <pedroaraujo@colorlesscube.com>
- ro: roentgen <arthur.titeica@gmail.com>
- sr: JovanJ <jovanjojkic@gmail.com>
- tr: volkangezer <volkangezer@gmail.com>, zeugma <sunder67@hotmail.com>
- uk: Yuri Chornoivan <yurchor@ukr.net>
- zh_CN: leonfeng <rainofchaos@gmail.com>
Manuel Nickschas [Sun, 24 Nov 2013 16:39:32 +0000 (17:39 +0100)]
Update ChangeLog
Manuel Nickschas [Sun, 24 Nov 2013 16:29:07 +0000 (17:29 +0100)]
Update AboutDlg
Some new contributors deserve mentioning.
Manuel Nickschas [Sun, 24 Nov 2013 19:07:24 +0000 (20:07 +0100)]
Add separator after "Copy Selection" context menu
This went away with the commit fixing the menu for selections on
clickables, and is now being brought back.
Manuel Nickschas [Sun, 24 Nov 2013 18:55:00 +0000 (19:55 +0100)]
Fix context menu not being restored properly
When showing a context menu on a clickable, we used to hide existing
context menu item to avoid confusing the user. However, those actions
were never unhidden again. This resulted in the context menu not showing
most options ever again in subsequent invocations.
Instead of hiding the actions, we now just clear the menu.
Jerome Leclanche [Fri, 18 Oct 2013 15:41:27 +0000 (16:41 +0100)]
Add the "Copy Selection" context menu item after checking for chat items
When right clicking a channel, Quassel will drop all other items from
the context menu.
We work around this by checking for a selection after everything else
has been added to the menu, and make sure to add the Copy Selection item
at the top.
Fixes issues #1031 and #1048