Gajim-devel May 2008

gajim-devel@gajim.org

11 participants
7 discussions

"Fixing Broken Windows"
by Stephan Erb 07 Jun '08

07 Jun '08

While thinking about testability I also wondered about what we shall do with code that is not just a little bit buggy but worse. Think of a house that was once nice and tidy and is now totally rotten. A window was smashed and nobody repaired it. It is the same with code and we have to fix broken windows when they occur. A broken window is everything that nobody understands, doesn't work properly or simply is implemented in a very ugly fashion. I propose to remove such code for now and to come back on it in a later release cycle (maybe as a plugin). Of course this is not always possible but we should really consider it, IMHO. When I look at gajim, I see the following broken windows: - OSX integration - OTR-Encryption - GPG-Encryption Nobody should feel accused or attacked, it is not meant personally but I only want you all think about what we have at the moment and what we really want or what our goals should be. And hey, never forget, I smashed the biggest window - the roster.... What do you think? Best, steve

11 37

Testing Gajim?
by Brendan Taylor 07 Jun '08

07 Jun '08

Has anybody given thought to an automated test suite for Gajim? It would make it a lot easier to refactor parts of the code without introducing bugs that require a lot of manual testing to find. Getting to a point where the suite is complete enough to be useful will be difficult, but even the process of making Gajim testable would help reduce some of the coupling between modules. I think the best way to start is find a place in the code that it would be easy to write tests for and work out from there. Is there any interest in this? Any suggestions about a good place to start writing tests against?

3 6

Architecture
by Stephan Erb 05 Jun '08

05 Jun '08

Hi, me again... I would like us think about Gajim's architecture and where we see room for improvements. For more, please refer to our wiki [1]. steve [1] http://trac.gajim.org/wiki/ArchitectureOverhaul

1 2

Gajim API docs [and thoughts on coding standards and testing]
by Mateusz Biliński 05 Jun '08

05 Jun '08

Hi all. I'm organizing my development environment for GSoC (and of course coding in parallel ;) ), so basically what I do is: 1. Writing code. As the base I use these coding standards: http://trac.gajim.org/wiki/CodingStandards Although, I not necessarily agree with all statements [i.e. max length of line equal to 80 chars (pretty 'oldish' in modern times, 100 or even more would be probably more reasonable here )] but I'll try to use them to keep code consistent. 2. Writing tests. bct has created new directory and already put some testing files in there for sessions. I've written some simple test file for PluginManager and probably I'll commit it to my branch very soon. It would be great to write standards here, too, and/or some kind of common module (with 'init' function). In example, I use the same code as bct to update paths (which is required to tests work properly from this new 'test/' directory). So, this 'paths updating' would be our common code for starters. It's not much, but maybe later we'll find more common code to put there. 3. Documenting code [aka 'API docs'] I haven't found any official API docs for Gajim, so I've started generating them on my own. Here are basic effects: http://kernel.agh.edu.pl/~vardo/gajim/apidocs/ Maybe it doesn't look pretty, but is very handy and we can fine-tune it (CSS is our friend). The biggest advantage here is that we see what is NOT documented. There's also source code browsing. Imports of modules are also there. So this may help on generating UML diagrams and other documents related to Gajim architecture. What I used to generate docs is *Epydoc*: http://epydoc.sourceforge.net/ This is probably the best docs-generator available for Python. Config file used to create docs linked above is here: http://kernel.agh.edu.pl/~vardo/gajim/epydoc.conf Generally, to generate api docs, in main Gajim's directory, execute: # epydoc --conf=epydoc.conf And, that's it. Docs will be in 'apidocs/' directory. If we decide to document code more, we'll have to choose from three possible markups: * epytext: http://epydoc.sourceforge.net/epytextintro.html * reStructuredText: http://epydoc.sourceforge.net/manual-othermarkup.html * Javadoc: http://epydoc.sourceforge.net/manual-othermarkup.html (bottom of page) Available fields described here: http://epydoc.sourceforge.net/fields.html Generally, I would opt for epytext (this is default markup) as this is probably the best implemented one in Epydoc and very similar to Javadoc, which is probably known to most of us. Or we could use Javadoc itself. This way, we will be able to use other doc-generators, like Doxygen. Of course there's also pydoc, which we might also consider, if it suits our needs (it's not very sophisticated): http://docs.python.org/lib/module-pydoc Here's a comparison of doc-generators: http://en.wikipedia.org/wiki/Comparison_of_documentation_generators Maybe someone will spot something potentially useful. Summarizing, the questions is: how should I document my code? :) Thanks for answers in advance. -- Mateusz Biliński

6 8

Re: [Gajim-devel] Gajim API docs [and thoughts on coding standards and testing]
by Yann Leboulanger 30 May '08

30 May '08

replying to the list Mateusz Biliński wrote: > On Fri, May 30, 2008 at 5:02 PM, Yann Le Boulanger <asterix(a)lagaule.org> wrote: >> Yes please, it's really easier when coding in console. > > OK. So I'll stick to it :) > >> I haven't looked at that code yet, but having common code for all test >> program sounds a must. > > OK. I'll just write my tests separately and we'll figure out 'common > parts' later. > >> Great, I'll add that to website ! > > Generally, we could add 'epydoc.conf' to trunk, so that users could > easily generate apidocs on their own. > > I've also thought of putting 'epydoc ---conf=epydoc.conf' to CRON on > gajim.org server (once a day?), so that we have up-to-date API docs > on-line. I can do it on my server - no problem, but gajim.org domain > seems more appropriate :) Yep it's what I thought to do: a cron job. >>> Summarizing, the questions is: how should I document my code? :) >> I would vote for epydoc syntax. If we really need doxygen one day it seems >> easy to switch to javadoc. > > OK. So I'll use epytext syntax. :) Switching to Javadoc later seems to > be rather 'automatic'. > nice, and we should all do the same from now -- Yann

1 0

Re: [Gajim-devel] "Fixing Broken Windows"
by Nikos Kouremenos 26 May '08

26 May '08

noone talks about buggy release. Nothing new should be added, no refactoring (refactoring means a lot of changes so new bugs). What should happen is let the code mature (features freeze) and yea if a feature wasn't ready to be merged, then it should be left out of the release. But Gajim must release soon. Else we're Debian.. On Mon, May 26, 2008 at 1:11 PM, Jonathan Schleifer <js(a)webkeks.org> wrote: > Am 26.05.2008 um 10:42 schrieb Nikos Kouremenos: > >> imHo Gajim should release a good version this summer else it's likely >> it will lose users to other clients. >> And that means no refactoring it just means Release early, release often > > IMO, a buggy release is far more worse than an old release. When the users > consider a client buggy, they'll change more likely than they will if > there's just no new release. Stability is far more important that adding new > features. > > -- > Jonathan >

1 0

changes in message_window.glade
by Henning Oschwald 10 May '08

10 May '08

Hi guys, First I want to mention that I'm a lucky Gajim user (gaim-svn on Debian). Thanks for this cool software. however: ------------------------------------------------------------------------ r9571 | js | 2008-05-04 22:47:51 +0200 (So, 04 Mai 2008) | 2 lines Redesign the chat window GUI. Should be more userfriendly now. ---------- It isn't, at least for me. :-( I must say first that I'm blind, so i'm using a screen reader software (Orca), using the keyboard exclusively (no mouse.) The old 'actions' context menu (alt+a) was quite accessible for me to access functions such as buddy information or sending files. After the change the context menu hass been replaced by some buttons which are currently not accessible via the keyboard and don't provide shortcuts. I'ld definitely vote for the old message window style. cheers Henning

4 7

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Gajim-devel May 2008