Questions about Galaxium's internal workings

[Jury]

Ok, since IRC and MSN are dead ends, I'll post my questions here.

I've noticed two things. (Actually many more, but those don't concern
me now)
a) Session#Connect () needs to run a thread in order to not freeze
interface.
b) OnLoginCompleted and OnLoginProgress are not thread safe.

Is there some reason for the fact connecting is not threaded by itself
and that it runs in a GUI thread?

[Jiří Zárevúcký]

There is a GtkUtility.CheckThreading () method. How come it is not
used anywhere? It would certainly make life easier to see every unsafe
point in the log.

2009/2/3 Jury <zarevuc...@gmail.com>:

[Jiří Zárevúcký]

Just to be clear... Is anyone even reading this list?

[André Igor]

I am!
=)
But I don't know so much about programing and all these things...
I just wanted to know how could I help in the project translating the interface to Brazilian Portuguese, but... no answers until now.
=/
Is it really alive?

2009/2/6 Jiří Zárevúcký <zarevuc...@gmail.com>

Just to be clear... Is anyone even reading this list?

--
André Igor Oliveira Prado

Estudante de Farmácia da UFPI
Coletivo "Nosso Sonho não Faz Silêncio"
CORDEL - Coletivo Regional de Debates e Estudos Livres
"Quando calamos o que pensamos, matamos nossos sonhos."

[Jury]

Hopefully it can be. The original devs have very little time for
Galaxium lately, but I have began work on *real* XMPP support and I'll
fix some bugs, too, when I'm in it. I guess I can add support for
translations sometime, but I don't quite like the idea of being the
only one in this. Galaxium badly needs more active contributors.

On Feb 6, 11:50 pm, André Igor <carbo...@gmail.com> wrote:
> I am!
> =)
> But I don't know so much about programing and all these things...
> I just wanted to know how could I help in the project translating the
> interface to Brazilian Portuguese, but... no answers until now.
> =/
> Is it really alive?
>

> 2009/2/6 Jiří Zárevúcký <zarevucky.j...@gmail.com>

[Phil Durand]

Hey all, really sorry about that. I am not trying to be a jerk. There is just so much going on right now for me. All this recession stuff and I'm losing my job in 17 days etc. yadi yada.

 

the project isnt dead, its just cold... :P

[Phil Durand]

Well, this call will significantly reduce performance. We use it when we are
troubleshooting something specific trying to find freezing the in the GUI
that should not happen. Needless to say, working with GTK and threading is
no fun.

Are you experiencing a freeze that you are trying to find?

Draek

--------------------------------------------------
From: "Jirí Zárevúcký" <zarevuc...@gmail.com>
Sent: Wednesday, February 04, 2009 6:04 PM
To: "Galaxium" <gala...@googlegroups.com>

Subject: Re: Questions about Galaxium's internal workings

>

[Phil Durand]

You would be really surprized what can happen to a project once even 1
developer gets working and doing updates. it encourages change and things
usually pick up.

Don’t worry, it wont always be this way. We do need more contributors
though...

Draek

--------------------------------------------------
From: "Jury" <zarevuc...@gmail.com>
Sent: Friday, February 06, 2009 4:07 PM

To: "Galaxium" <gala...@googlegroups.com>
Subject: Re: Questions about Galaxium's internal workings

>

[Ben Motmans]

The threading "issues" are by design

* The reason you experience (a) is probably because the connection
inside your session assumes to run on a separate thread

* All implementations based on "Galaxium.Protocol.TcpConnection" use
async socket calls, meaning the actual network transmissions are
executed on a different thread.
Generally speaking, callbacks would be executed on the same background
thread as the network transmission, but by design we choose to
dispatch the code to the GUI thread.

* If you really want, you can manage your own thread, but then you
will have to implement IConnection, instead of extend TcpConnection

* (b): If you find any parts of the Galaxium core that are not thread-
safe, feel free to create a patch, I will review it ASAP.

P.S. I will try to get more active again, but I'm pretty busy until
the end of June, the general rule is: Keep posting, nagging,
complaining, ... A LOT, and you will get my attention :)
(and that isn't sarcastic, I really mean it)

-- Ben

[Jiří Zárevúcký]

Ah... I see... I'm not an expert in the performance area... thanks for
pointing that out :) I was experiencing a lot of freezing until I
figured out I have to dispatch all the callbacks to the GUI thread.
So... I guess I'm adding lightning-fast locking mechanism and
thread-safe Gtk# to my personal Mono wishlist.

2009/2/6 Phil Durand <dra...@gmail.com>:

[Jiří Zárevúcký]

I guess my problem is I'm using a separate library. Though it's my
own, I want to keep it independent of the Galaxium.

2009/2/7 Ben Motmans <ben.m...@gmail.com>:

[Ben Motmans]

Using a separate library is not a problem, you just need to write a
"wrapper"

For an example, have a look at Galaxium.Protocol.Jabber, which uses
agsXmpp (a library) internally (or Galaxium.Protocol.AIM, which uses
OscarLib)

On Feb 7, 11:22 pm, Jiří Zárevúcký <zarevucky.j...@gmail.com> wrote:
> I guess my problem is I'm using a separate library. Though it's my
> own, I want to keep it independent of the Galaxium.
>

> 2009/2/7 Ben Motmans <ben.motm...@gmail.com>:

[Jiří Zárevúcký]

Yep, already doing that.

2009/2/7 Ben Motmans <ben.m...@gmail.com>:

[Jiří Zárevúcký]

So... there is another question...

The AbstractEntity class contains uniqueIdentifier, displayName and
nickname... uniqueIdentifier and displayName I understand, but what is
the nickname for? Nickname is generally a part of contact's
information, alongside real name, address, occupation and that kind of
things. It is therefore a very protocol-specific. Protocol doesn't
even need to support it. Hence the question, I don't understand the
reason of including it in such generic class.

[Jiří Zárevúcký]

Also, AbstractContact has a lot of settings, that would make much
better sense, if they were only settable globally.
Is it really useful for anyone to set account image / contact image /
personal message / toolbars displaying contact-wise?

2009/2/10 Jiří Zárevúcký <zarevuc...@gmail.com>:

[Philippe Durand]

The idea here is to have both actually.

If you notice in the interface, you can right click someone and suppress
their information. This is useful if you do not want to see a specific
friend's obscene display image, or display message. But not have to turn off
everything.

See what I mean?

--------------------------------------------------
From: "Jiří Zárevúcký" <zarevuc...@gmail.com>
Sent: Tuesday, February 10, 2009 3:16 PM
To: <gala...@googlegroups.com>

Subject: Re: Questions about Galaxium's internal workings

>

[Jiří Zárevúcký]

Yeah... that can make sense, in some situations. But still, pure
interface settings such as toolbars are IMO not the least useful to
disable per-contact. Isn't that just cluttering menu?

2009/2/11 Philippe Durand <dra...@gmail.com>:

[Jiří Zárevúcký]

2009/2/10 Jiří Zárevúcký <zarevuc...@gmail.com>:

So what about this?

Another thing... In AbstractActivity, what are Handled and Requested
properties for? I've searched the code and it seams they are never
assigned to.

[Philippe Durand]

Alright, well first off the Nickname is a.k.a Alias. So it gives the
user the ability to rename a contact while NOT using their email address
(unique identifier) OR the display name.

As you can see, this "suppression" theme is across the board on contact
information. At least that's how we want it to be, if there is something
missing we should be able to suppress it too. The user should never be
forced to see the information chosen by other users.

As for the Handled and Requested, i'm sure that I was in the middle of
fixing something and may have added those for that reason. I know I make
a check for Requested, so perhaps i was not yet done. Unusual that I
commit it halfway, i usually finish stuff. May have been a mistake.

I'm sure that whatever its purpose will become clear at some point if we
keep looking. Or perhaps we remove it. who knows..

What is the question for? Are you needing to make a change or were you
just wondering?

[Jiří Zárevúcký]

Then I understood it wrong, because of the difference in protocols. In
XMPP, nickname is a contact-specified name that is in practice never
displayed in the list. Also, it is not part of the core protocol
stack. It's rather part of an extension for publishing contact's
vCard. The user-specified name is referred to as the "handle". That's
where the confusion comes from. Perhaps we should change these names
to something more obvious.

As for the activities, I was wondering whether it is possible to
define a protocol-specific notifications.

2009/2/15 Philippe Durand <dra...@gmail.com>: