Skip to content
Snippets Groups Projects
  1. Jun 13, 2008
  2. Jun 12, 2008
  3. Jun 11, 2008
  4. Jun 10, 2008
  5. Jun 09, 2008
  6. Jun 08, 2008
    • jimpp's avatar
      -Set General and Observer group directly in contact instance, instead of calculating it each time · f9c981df
      jimpp authored
      -When creating self-contact contact instance, store it with group 'self_contact', so it never goes in General
      -Make general group not be seen visible because of self contact even if self.regroup
      -Remove the self contact instance itself too when WE deconnect or when IT deconnect, so we will
      not see it as offline if refilling roster (regroup account for example)
      f9c981df
    • js's avatar
      d0b15bf5
    • js's avatar
      * Fix passing of message ID. · 593ed0c6
      js authored
      * Don't asnwer to receipt requests from users not in roster.
      593ed0c6
    • js's avatar
      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
    • jimpp's avatar
      Don't act like if self contact is in group General. See #4000. · 0d645437
      jimpp authored
      Don't make General group visible when we have self contact.
      0d645437
    • jimpp's avatar
      [modelfilter]Fix row behind that expand when moving contact problem. · 40e360d1
      jimpp authored
      This code seems not necessary. But why does that created that problem ?
      It seems for some reason, path is not good. Probably the iter itself is not good. So expand act on the wrong
      group (I can proove that).
      40e360d1
    • js's avatar
    • js's avatar
      Be more specific on excepts. · 03d68c0d
      js authored
      03d68c0d
  7. Jun 07, 2008
    • js's avatar
      * Start X11 automatically on OS X if not running. · 0551c9dd
      js authored
      * Moved one import in osx/__init__.py. If that import fails, we still
        got the few functions defined we need, even if the rest of that file
        doesn't work due to missing deps.
      0551c9dd
    • js's avatar
      Make Gajim work on OS X again. · 8def8de5
      js authored
      Someone completely broke it by trying to port it to native GTK.
      However, that person didn't only break it with X11 GTK, with
      native GTK it wasn't working correctly either.
      Fixed it by adding lots of try/except blocks. Someone definitely
      deserves to be slaughtered for completely breaking it on OS X…
      8def8de5
    • js's avatar
      Comment options. · 8fefd0ed
      js authored
      8fefd0ed
    • js's avatar
      Initial XEP-0184 support. · a495d090
      js authored
      TODO:
       * Implement section 5.
       * Think of a way to show in GUI
          Possible way: Grey out the sent msg until we receive a <received/>,
          but only if we know the other end supports XEP-0184.
       * Maybe implement section 6?
      a495d090
  8. Jun 05, 2008
  9. Jun 04, 2008
  10. Jun 03, 2008
  11. Jun 02, 2008
Loading