Skip to content
  • js's avatar
    c2eb4b5a
    Completely remove OTR. · c2eb4b5a
    js authored
    Sorry, it just wasn't maintainable. The problem is the current libotr
    API. I'm sick of working around the strange libotr API, sick of getting
    HTML messages, sick of losing messages. The final argument for
    completely removing it was that we can't get the message ID of a sent
    msg anymore - which we need. I tried to work around this as well, but
    there seems to be no way to wait for a signal in glib the way I would
    need it for the workaround (I wanted to emit a signal in inject_message
    and then wait for it after the call to otr_message_fragment_and_send
    so the signal can pass us the message id). And the last reason is that
    we're heading towards a new release and thus want to stabilize the code,
    thus don't have time to work around even more libotr API strangeness.
    I will give feedback to the libotr developers, who are currently
    planning a new API, so that we can hopefully see OTR support once again
    as soon as libotr4 is released.
    
    Kjell already announced that he will continue his branch:
    https://code.launchpad.net/~afflux/gajim/otr
    
    I really hope the libotr devs will provide a sane API with libotr4 so
    we can integrate OTR support again.
    
    Oh, and I added one more try/except block for OS X.
    c2eb4b5a
    Completely remove OTR.
    js authored
    Sorry, it just wasn't maintainable. The problem is the current libotr
    API. I'm sick of working around the strange libotr API, sick of getting
    HTML messages, sick of losing messages. The final argument for
    completely removing it was that we can't get the message ID of a sent
    msg anymore - which we need. I tried to work around this as well, but
    there seems to be no way to wait for a signal in glib the way I would
    need it for the workaround (I wanted to emit a signal in inject_message
    and then wait for it after the call to otr_message_fragment_and_send
    so the signal can pass us the message id). And the last reason is that
    we're heading towards a new release and thus want to stabilize the code,
    thus don't have time to work around even more libotr API strangeness.
    I will give feedback to the libotr developers, who are currently
    planning a new API, so that we can hopefully see OTR support once again
    as soon as libotr4 is released.
    
    Kjell already announced that he will continue his branch:
    https://code.launchpad.net/~afflux/gajim/otr
    
    I really hope the libotr devs will provide a sane API with libotr4 so
    we can integrate OTR support again.
    
    Oh, and I added one more try/except block for OS X.
Loading