jabberfox-devel Mailing List for JabberFoX

■□・‥…────────────────┐
│            優しいインターネットガイド│‥‥‥‥
└────────────────────
□ 2006 年 3 月 28 日 発行

http://china-freemail.com/gui/
問）
hua...@ya...

明日から始まる素敵なラブストーリーを今日ゲットしよう！
http://zheshishenme.net/9j85/
衝撃の夜、クリスマスイブ前夜。
http://zheshishenme.net/9j85/
たった一度の出会いが俺の人生をピンク色に染めた。
http://zheshishenme.net/9j85/
問）
club_ktv_2006＠yahoo,com,cn

Call out Gouranga be happy!!!
Gouranga Gouranga Gouranga ....
That which brings the highest happiness!!

Hi jab...@li..., <br>
<br>
If you're looking for not expensive high-quality software,<br>
we might have just what you need.<br>
Our site can give you full sotwftare solutions, like cheap 100=
% original <br>
software. If you enter now you can enjoy very low prices. <br>
<br>
<a href=3D"http://www.dmbkgn.info/OE017/?affiliate_id=3D233992&campaign_id=
=3D601">Windows XP Professional 2002 </a>............. $50<br>
<a href=3D"http://www.dmbkgn.info/OE017/?affiliate_id=3D233992&campaign_id=
=3D601">Adobe Photoshop 7.0</a> ...................... $60<br>
<a href=3D"http://www.dmbkgn.info/OE017/?affiliate_id=3D233992&campaign_id=
=3D601">Microsoft Office XP Professional 2002</a> .... $60<br>
<a href=3D"http://www.dmbkgn.info/OE017/?affiliate_id=3D233992&campaign_id=
=3D601">Corel Draw Graphics Suite 11</a> ............. $60<br>
<br><br>
<a href=3D"http://www.dmbkgn.info/OE017/?affiliate_id=3D233992&campaign_id=
=3D601">and lots more...</a><br>

<br>
<br>
rally cliche botulin sidesaddle bibliophile tamale priscilla schumann grom=
met fecund anecdote rutty lucre elastomer german asphalt spinster maidserv=
ant wendell blasphemy beatrice eben freer democracy cease toluene quartzit=
e tide duopolist corps conservator abbot escritoire rudyard caraway nevada=
 profession springtime calibre veterinarian=20
<br>
<a href=3D"http://www.dmbkgn.info/OE017/diamondtron.php?affiliate_id=3D233=
992&campaign_id=3D601&ema...@li..."> stop=
 getting our updates </a>

Hi, I made some  modifications to the user chat window so it will=20
display different background colors for incoming and outgoing messages.=20=

Do you think its a good idea? It still needs more work but here is a=20
preview of what I done so far.
http://edav.united.net.kg/screenshot.png

Just for the record, I'm completely new with cocoa or programming for=20
that matter so it probably has bugs. I did it with the jabberfox2 module=20=

at sourceforge cvs.

--
Erik =C1lvarez
JabberID - ed...@mi...

I just thought I'd share this with you.  It's a protocol I'm designing 
similar to your XMLNode.  I pushed most of the functionality into 
categories to keep the protocol as simple as possible.  It gives you a 
lot of control over how the XML is output this way.

I'm probably also going to write an XMLMutableElement protocol as well.  
I'll put the implementation online when it's done.  I'll probably also 
create an NSObject category to add support for your XMLNode protocol.

- Edwin


@protocol XMLElement <NSObject>
- (NSString *)XMLName;        /* Could be different from the object's 
name. */
- (NSDictionary *)XMLAttributes;        /* Could be different from the 
object's attributes. */
- (NSArray *)XMLContents;        /* Array of <XMLElement> or NSString 
objects. */
@end

@interface NSDictionary (XMLAttributes)
- (NSArray *)XMLAttributeStringArray;        /* An array of each 
attribute as a string. */
- (NSString *)XMLAttributesString;        /* Joins 
XMLAttributeStringArray with a space between. */
@end

@interface NSArray (XMLContents)
- (NSArray *)XMLContentStringArray;        /* An array of each content 
as a string. */
- (NSString *)XMLContentsString;        /* Joins XMLContentStringArray 
with nothing between. */
- (NSString *)XMLEscapedContentsString;        /* Joins 
XMLAttributeStringArray with an return between. */
@end

@interface NSObject (XMLNodeAdditions)
- (NSString *)XMLElementString;        /* Joins the XMLName, 
XMLAttributesString, and XMLContentsString. */
- (NSString *)escapedXMLElementString;        /* Joins the XMLName, 
XMLAttributesString, and XMLEscapedContentsString. */
@end

At 17:04 Uhr -0400 20.06.2002, Edwin Zacharias wrote:
[...]
>I'm not planning on implementing it either.  Apple isn't yet done 
>integrating AppleEvents into Cocoa, so it would be too much of a 
>pain.  I will be working on a BSD sockets and SSL framework, though. 
>Then hopefully a low level Jabber client framework similar 
>python-jabber.  Hopefully I'll be able to use a lot of JabberFox 
>code and contribute a lot back as well. (BSD license)

Sounds good!


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

On Thursday, June 20, 2002, at 04:44  PM, Max Horn wrote:

> At 15:37 Uhr -0400 20.06.2002, Edwin Zacharias wrote:
>> Just a warning.  FZBase is not threadsafe.  gethostbyname isn't 
>> threadsafe, and FZBase doesn't do anything to protect against this. 
>> OmniNetworking actually creates a new task for each host lookup to 
>> keep it threadsafe.  I guess that's the safest way to do it, but I'm 
>> planning to just use a lock.
>>
>
> Uhm... how would that affect us, since we only would use one thread 
> that uses gethostbyname?

Right now, no chance.  If JabberFox supports OOB transfers it's possible 
but unlikely.  Or if JabberFox supports multiple connections at the same 
time.

>> Since a component architecture seems like a goal in JabberFox, why not 
>> build the actual client into a command line program that manages the 
>> session and sends the packets to other apps over DO or Apple Events. 
>> That way people have to possibility of writing whole new apps as well 
>> as plugins for the main JabberFox client.
>
> Because I don't see any advantage in this, for the purposes of 
> JabberFoX. I.e that's not at all the goal of JabberFoX. FoX is meant as 
> a Jabber client. Point. Nothing more. If you need to write specialied 
> Jabber applications; i would recommend against using JabberFoX as a 
> foundation for that, except maybe re-using a few classes from it. In 
> fact, I personally would just scrap the whole FoX source base and write 
> a new client from scratch if I had the time for it. There are are quite 
> some things I don't like at all in it. Like the plugin system, which is 
> horribly confusiing the way it's done now. Or the callback mechanism 
> which is not optimal. Or the network code. Or many other things :-)
>
> What you suggest would amount to a major rewrite of a fairly big part 
> of the code. It would take a lot of resources to design, implement and 
> test. Which means I certainly won't do it :-) However, JabberFoX is 
> open source, and you are welcom to do this if you like.

I'm not planning on implementing it either.  Apple isn't yet done 
integrating AppleEvents into Cocoa, so it would be too much of a pain.  
I will be working on a BSD sockets and SSL framework, though.  Then 
hopefully a low level Jabber client framework similar python-jabber.  
Hopefully I'll be able to use a lot of JabberFox code and contribute a 
lot back as well. (BSD license)

- Edwin

Oh but before we get a misunderstanding: IMHO replacing the current 
JFoX socket code would definitly be a very good things to do! If you 
want to work on this, Edwin, you are most welcome. And you can choose 
how you do it, i.e. I didn't want to suggest you should use FZBase, 
only wanted to mention it as a possibility. Roll your own, use yet 
another class, all fine by me :-)


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

At 15:37 Uhr -0400 20.06.2002, Edwin Zacharias wrote:
>Just a warning.  FZBase is not threadsafe.  gethostbyname isn't 
>threadsafe, and FZBase doesn't do anything to protect against this. 
>OmniNetworking actually creates a new task for each host lookup to 
>keep it threadsafe.  I guess that's the safest way to do it, but I'm 
>planning to just use a lock.
>

Uhm... how would that affect us, since we only would use one thread 
that uses gethostbyname?


>Since a component architecture seems like a goal in JabberFox, why 
>not build the actual client into a command line program that manages 
>the session and sends the packets to other apps over DO or Apple 
>Events. That way people have to possibility of writing whole new 
>apps as well as plugins for the main JabberFox client.

Because I don't see any advantage in this, for the purposes of 
JabberFoX. I.e that's not at all the goal of JabberFoX. FoX is meant 
as a Jabber client. Point. Nothing more. If you need to write 
specialied Jabber applications; i would recommend against using 
JabberFoX as a foundation for that, except maybe re-using a few 
classes from it. In fact, I personally would just scrap the whole FoX 
source base and write a new client from scratch if I had the time for 
it. There are are quite some things I don't like at all in it. Like 
the plugin system, which is horribly confusiing the way it's done 
now. Or the callback mechanism which is not optimal. Or the network 
code. Or many other things :-)

What you suggest would amount to a major rewrite of a fairly big part 
of the code. It would take a lot of resources to design, implement 
and test. Which means I certainly won't do it :-) However, JabberFoX 
is open source, and you are welcom to do this if you like.



>That adds a lot of complexity, and security would be a nightmare. 
>Also, Jabber already supports multiple clients logged in at once,

You mean: "multiple clients logged in at aonce wiht the same account" 
I guess. :-)

>  but as far as I know there's no way to have all of them receive the 
>same message.  I may work one something like this.

Then you should work on the server, not a client. Note that 
broadcasting is already possible for admins, but AFAIK not for users.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

Just a warning.  FZBase is not threadsafe.  gethostbyname isn't 
threadsafe, and FZBase doesn't do anything to protect against this.  
OmniNetworking actually creates a new task for each host lookup to keep 
it threadsafe.  I guess that's the safest way to do it, but I'm planning 
to just use a lock.


Since a component architecture seems like a goal in JabberFox, why not 
build the actual client into a command line program that manages the 
session and sends the packets to other apps over DO or Apple Events.  
That way people have to possibility of writing whole new apps as well as 
plugins for the main JabberFox client.

That adds a lot of complexity, and security would be a nightmare.  Also, 
Jabber already supports multiple clients logged in at once, but as far 
as I know there's no way to have all of them receive the same message.  
I may work one something like this.

- Edwin



On Thursday, June 20, 2002, at 04:34  AM, Max Horn wrote:

> At 22:56 Uhr -0400 19.06.2002, Edwin Zacharias wrote:
>> Hi,
>>
>> I have two quick questions about Jabber.  First, why aren't sockets 
>> threaded?  Doesn't this lag on large transfers?
>
> Not really that bad, the sockets are used in async mode after all. But 
> yeah a a threaded socket class might (or might not...) give some speed 
> boost, alas, there are a lot of things that have to be handled very 
> careful that way.
>
> I was recently made aware of http://www.fozztexx.com/FZBase/ which has 
> a threaded socket class, BTW.
>
> In any case, I agree that our socket code sort of stinks, to many 
> things are not properly checked, and due to some non-standard behaviour 
> in OS X it's not even possible to detecet a global system disconnect 
> from the new (sometimes I hate Apple). If you like to rewrite it and 
> submit a patch, due so, but:
>
>   * make sure that connects still can time out
>   * you might want to make sure DNS lookups can do so, too
>   * make sure it'll be possible to hook in SSL code
>
> Note that FZSocket seems to fit the bill quite nicely.
>
>
> Cheers,
>
> Max
> -- -----------------------------------------------
> Max Horn
> Software Developer
>
> email: <mailto:ma...@qu...>
> phone: (+49) 6151-494890

At 22:56 Uhr -0400 19.06.2002, Edwin Zacharias wrote:
>Hi,
>
>I have two quick questions about Jabber.  First, why aren't sockets 
>threaded?  Doesn't this lag on large transfers?

Not really that bad, the sockets are used in async mode after all. 
But yeah a a threaded socket class might (or might not...) give some 
speed boost, alas, there are a lot of things that have to be handled 
very careful that way.

I was recently made aware of http://www.fozztexx.com/FZBase/ which 
has a threaded socket class, BTW.

In any case, I agree that our socket code sort of stinks, to many 
things are not properly checked, and due to some non-standard 
behaviour in OS X it's not even possible to detecet a global system 
disconnect from the new (sometimes I hate Apple). If you like to 
rewrite it and submit a patch, due so, but:

   * make sure that connects still can time out
   * you might want to make sure DNS lookups can do so, too
   * make sure it'll be possible to hook in SSL code

Note that FZSocket seems to fit the bill quite nicely.


Cheers,

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

At 23:51 Uhr -0300 19.06.2002, Arthur Petry wrote:
>Le mercredi 19 juin 2002, =E0 04:10 AM, Max Horn a =E9crit :
>
>>
>>>And perhaps I will start the Presence Plugin, because I and some
>>>friends really need the auto-away stuff...
>>
>>Somebody worked on auto-away already. Anyway, if you say "Presence
>>Plugin", what do you have in mind exactly?
>
>Moving the stuff about presence handling (from @implementation 
>FoXController (Presence) ) to a JabberFox Plugin.
>
>I think we need somewhere where our status is displayed  (in 
>particular if we implement auto-away). Why not at top (toolbar ?) or 
>bottom of the buddy list, or in the Dock, or with a new menu (I 
>don't know how apple call that by I am talking here about menu in 
>menubar always available like the clock). BTW I think that at one 
>time JabberFox had such menu, but I don't see it anymore...

I scratched it in favor of a dock menu. NSStatusItems just are buggy 
and kinda useless for non-FBAs

We could display the current status in the dock by overlying a status 
icon onto the FoX head. Shouldn't be too hard to implement, once we 
have a way to query what the current status *is*. Which could easily 
be foiled by the user, BTW, but then it's their own problem if they 
shoot their own foot by sending custom raw XML presence messages.


>I've also an idea for visually show we are going auto-away very soon 
>(perhaps simpler than the slider that have been talken about here) :
>  why not a flashing icon between available and away (green/Yellow) 
>just before going to away.
>I think it will be easy to do that with a NSTimer.
>
>Endly, if someone is working on auto-away, he should annonce it 
>here, just to show that this mailing list is alive  ;-)

Implementing auto-away is trivial, and can be done in only a few 
lines of code. Implementiing it right is harder.

See, the main reasons I suggested a presence plugin in the past are:

  * a central place to set the own presence
  * hence a central place that *knows* our own presence!!!
    -> this is vital for proper auto-away handling, and also for any 
kind of display of the current status
  * current status should at least be displayed via a checkmark in the 
status menu (which is BTW also available in the dock menu)
  * full custoizability of the status menu - i.e. allow the user to 
define custom status items, which can have arbitrary 
show/status/priority values, e.g. you could define a "Dinner" item 
that is away/"I am at dinner"/2 for example.

The last item is the least important, though. The first two are the 
most important.


Cheers,

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

On Wed, 2002-06-19 at 20:56, Edwin Zacharias wrote:
> Hi,
> 
> I have two quick questions about Jabber.  First, why aren't sockets 
> threaded?  Doesn't this lag on large transfers?

I don't entirely remember, I think originally it was my lack of
knowledge and lack of documentation surrounding threads with
Objective-C/Cocoa. As for lagging on long transfers, the typical message
is tiny, so you don't really notice(Of course we don't implement the OOB
parts of the protocol, which could be large chunks of data) (Is it still
called OOB?)

> 
> Second, can someone please describe the design of the plugin system.  I 
> looked at it briefly, but I can't quite understand it.  Is it just to 
> make certain functions easily replaceable or does it support adding 
> functionality to Jabber?

As Arthur explained there are two types of plugins. The first are the JP
plugins, JP being Jabber Protocol. These allow a person to add protocol
functionality and not have it all build it all into the core
application. It also opens the door for someone to have alternative
implementations/multiple implementations of specific part of the
protocol. For instance, you can have a two protocols receive the
presence specific message, where the first would handle actually
displaying the roster, and the second could do something like the
history of all your friends availablity. 

The second kind of plugin is the JFP, or JabberFoX Plugin. This class is
setup to give standard entry points to external libraries which are
plugins. So, when you JabberFoX loads a JFP plugin, it knows that there
is an instance of one of these classes which it can call upon to handle
initialization and attachment of JP plugins if it has any. These can
actually contain more than one JP plugin, and can handle multiple kinds
of messages, but it's just good practice to separate them into their own
plugin.

> 
> Finally, I'm going to be creating a framework to support a Jabber 
> client.  I'm not planning on creating a generic client, just a few 
> specialized ones to run as daemons.  I'm going with a threaded 
> implementation using NSConnection to update objects with the status.  
> Hopefully when it's done it will use the new NSSocketPort, but for now 
> it uses a custom BSD sockets wrapper.  I think this could be of benefit 
> to JabberFox so I thought I'd keep you posted as to how it's going.
> 
Well as long as the license of the code permits it, I'm sure we're all
happy to have anything that improves JabberFoX.

- Jason

Le mercredi 19 juin 2002, =E0 04:10 AM, Max Horn a =E9crit :

>
>> And perhaps I will start the Presence Plugin, because I and some
>> friends really need the auto-away stuff...
>
> Somebody worked on auto-away already. Anyway, if you say "Presence
> Plugin", what do you have in mind exactly?

Moving the stuff about presence handling (from @implementation=20
FoXController (Presence) ) to a JabberFox Plugin.

I think we need somewhere where our status is displayed  (in particular=20=

if we implement auto-away). Why not at top (toolbar ?) or bottom of the=20=

buddy list, or in the Dock, or with a new menu (I don't know how apple=20=

call that by I am talking here about menu in menubar always available=20
like the clock). BTW I think that at one time JabberFox had such menu,=20=

but I don't see it anymore...

I've also an idea for visually show we are going auto-away very soon=20
(perhaps simpler than the slider that have been talken about here) :
  why not a flashing icon between available and away (green/Yellow) just=20=

before going to away.
I think it will be easy to do that with a NSTimer.

Endly, if someone is working on auto-away, he should annonce it here,=20
just to show that this mailing list is alive  ;-)

Le mercredi 19 juin 2002, =E0 11:56 PM, Edwin Zacharias a =E9crit :

> Hi,
>
> Second, can someone please describe the design of the plugin system.  =
I=20
> looked at it briefly, but I can't quite understand it.  Is it just to=20=

> make certain functions easily replaceable or does it support adding=20
> functionality to Jabber?

Hi,
I can only try to answer the second point.
For what I have understand, there are two kinds of plugin in jabberfox :=20=

JabberPlugin and JabberFoxPlugin.

The first one are denoted by the letters JP  (see JPVersion for example)=20=

and the second one by JFP (see JFPAgent).

The first one are well described in Documentation/Service Plugins.html=20=

and are call JabberService plugins.
It is a easy we to handle a particular message from the server (you=20
choose the kind of msg you receive).

The second one are real plugin for Jabber Fox.
So as most functions are handled by plugin there are easily=20
replaceable : you can create a new JFPRoster to show in a different way=20=

the Roster for example..

To make a JabberFox plugin you simply subclass JFoXPlugin.

The name of present plugins show you what you can do with this plugins.=20=

(you have access to the JabberService, so you can send msg, or attach a=20=

JabberPlugin, you have also access to some menus to make available some=20=

action).

But If you wait a litlle, I'm sure some else (Max ?) will answer better,=20=

and cover also the other points of your question.

But I'm very happy do see some activity in this list ;-)

Hi,

I have two quick questions about Jabber.  First, why aren't sockets 
threaded?  Doesn't this lag on large transfers?

Second, can someone please describe the design of the plugin system.  I 
looked at it briefly, but I can't quite understand it.  Is it just to 
make certain functions easily replaceable or does it support adding 
functionality to Jabber?

Finally, I'm going to be creating a framework to support a Jabber 
client.  I'm not planning on creating a generic client, just a few 
specialized ones to run as daemons.  I'm going with a threaded 
implementation using NSConnection to update objects with the status.  
Hopefully when it's done it will use the new NSSocketPort, but for now 
it uses a custom BSD sockets wrapper.  I think this could be of benefit 
to JabberFox so I thought I'd keep you posted as to how it's going.

Thanks,
Edwin

At 17:54 Uhr -0300 12.06.2002, Arthur Petry wrote:
>Le mardi 11 juin 2002, =E0 07:29 PM, Max Horn a =E9crit :
>>I will look at it during JabberConf starting tomorrow, and if the 
>>code is OK will check it in. Sorry for the looong delay, but I had 
>>many other things to work on.
>>
>>Then I can also add you, however, please talk to me before making 
>>any checkins right now, as the code is in flux. Also, no matter 
>>what you do: *never* check in new directories w/o first asking. The 
>>point is that in the old CVS repository we had a lot of pain caused 
>>by directories that were checked in at some point and cluttered the 
>>repository - you can't easily remove dirs again when using CVS.
>
>Hi Max,
>
>Ok, and if you can check in your code about the Drag&drop in the 
>outline View, I could try to merge it with my modifications
>(I have a buddy list with drag&drop working, but with only one item 
>per buddy, no-duplicate item in different groups)

Sure, look at it.


>And if you are in JabberConf, perhaps you will see how we can deal 
>with buddy without group.
>For me, there is a problem with buddy without group, because you 
>cannot copy it to a group, so the behaviour of a drag cannot be the 
>same... (I'm not sure you will understand, but I think, I have made 
>a better explanation in a previous mail...)

Yes I know all these issues, I spent a lot of time thinking about the 
drag&drop issues months ago :-) There are quite some things one can 
do. The same applies to handling groups at all. Like what happens if 
the user has set FoX to only show online contacts, and hence group 
"Foo" is not visible cause it contains only offline contacts. So he 
wants to move a user to that group... conclusion -> he should be able 
to make "new" groups, even if these groups already exist and are just 
invisible. But these new groups will initially be empty, which is not 
possible with the jabber roster. One way out is to use a special 
dummy roster item that is put into these empty groups. Advantage: 
these groups are now persistent over sessions. Drawback: other client 
will display the fake dummy roster item. And it's not truly persisten 
either cause during the next program run, we again don't know (when 
we are in "show only online" mode) which groups to show even though 
they contain no online contacts. In fact, we probably don't want to 
make this information persisten for this reason.
Hence, I probably would only display "new" groups in the GUI, and 
they are only created once a contact is moved into them.


Oh, and what happens if the user deletes a group...
  * just remove that group from all the contacts in it
  * all contacts in it are removed
  * all contacts in it thar are not in another group are removed
  * only the visible contacts are removed (in show-online-only mode)
  * ...

>And perhaps I will start the Presence Plugin, because I and some 
>friends really need the auto-away stuff...

Somebody worked on auto-away already. Anyway, if you say "Presence 
Plugin", what do you have in mind exactly?


>Of course I will discuss here before check-in, if you add me to the project=
=2E..
>I think I could use CVL.app because I'm never sure what Project 
>Builder did when it use CVS...

I never use these, I do all my CVS handling via the command line, 
much faster anyway :-)


>
>And about the registration agent, I have not work on it since the 
>last time, because it worked for me, but it's not ready for a public 
>release I think ;-)
>
>And thanks that you did not forget this project, I have seen you 
>have a lot of projects (in particular you seem to be very involved 
>in the fink project thanks a lot for that !!).
>

Yes I am the Fink project lead, takes quite some time, too :-)


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

Le mardi 11 juin 2002, =E0 07:29 PM, Max Horn a =E9crit :
> I will look at it during JabberConf starting tomorrow, and if the code=20=

> is OK will check it in. Sorry for the looong delay, but I had many=20
> other things to work on.
>
> Then I can also add you, however, please talk to me before making any=20=

> checkins right now, as the code is in flux. Also, no matter what you=20=

> do: *never* check in new directories w/o first asking. The point is=20
> that in the old CVS repository we had a lot of pain caused by=20
> directories that were checked in at some point and cluttered the=20
> repository - you can't easily remove dirs again when using CVS.

Hi Max,

Ok, and if you can check in your code about the Drag&drop in the outline=20=

View, I could try to merge it with my modifications
(I have a buddy list with drag&drop working, but with only one item per=20=

buddy, no-duplicate item in different groups)

And if you are in JabberConf, perhaps you will see how we can deal with=20=

buddy without group.
For me, there is a problem with buddy without group, because you cannot=20=

copy it to a group, so the behaviour of a drag cannot be the same...=20
(I'm not sure you will understand, but I think, I have made a better=20
explanation in a previous mail...)

And perhaps I will start the Presence Plugin, because I and some friends=20=

really need the auto-away stuff...

Of course I will discuss here before check-in, if you add me to the=20
project...
I think I could use CVL.app because I'm never sure what Project Builder=20=

did when it use CVS...

And about the registration agent, I have not work on it since the last=20=

time, because it worked for me, but it's not ready for a public release=20=

I think ;-)

And thanks that you did not forget this project, I have seen you have a=20=

lot of projects (in particular you seem to be very involved in the fink=20=

project thanks a lot for that !!).

At 0:09 Uhr -0300 14.05.2002, Arthur Petry wrote:
>You can get my modifications here :
>http://homepage.mac.com/arth/
>
>It is not finished, but it works !
>
>I will try to improve the things a bit, before check-in, and Max can 
>you add me on the sourceforge project (ar...@sf...) or do you prefer 
>to check this code by yourself ?

I will look at it during JabberConf starting tomorrow, and if the 
code is OK will check it in. Sorry for the looong delay, but I had 
many other things to work on.

Then I can also add you, however, please talk to me before making any 
checkins right now, as the code is in flux. Also, no matter what you 
do: *never* check in new directories w/o first asking. The point is 
that in the old CVS repository we had a lot of pain caused by 
directories that were checked in at some point and cluttered the 
repository - you can't easily remove dirs again when using CVS.


Thanks for your contribution,

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

You can get my modifications here :
http://homepage.mac.com/arth/

It is not finished, but it works !

I will try to improve the things a bit, before check-in, and Max can you 
add me on the sourceforge project (ar...@sf...) or do you prefer to 
check this code by yourself ?

Hi Arthur,

At 20:20 Uhr -0300 07.05.2002, Arthur Petry wrote:
>Oups, I just read the ChangeLog and saw:
>* JContactLink: new class which sits between JGroups and the 
>JContacts they contain.
>       This simplifies drag and drop code a lot, since it's clear 
>from which group we
>       dragged a particular contact.
>
>Perhaps I should have start by reading the Changelog ;-)
>
>So Max, you already have gone trough all the problems I mention in my mail !
>
>But this is not used in the OutlineViewDatasource,  have you an 
>other version of the datasource ?
>
>Or do I continue to work on that point ?

I do have some code sitting here which was never checked in that 
enables the use of JContactLink. I begun working on some drag & drop 
code but then had no time anymore. I will try to look over my local 
changes, to get them into CVS, then you can use that to do proper 
drag&drop if you like :-)


>I'm now investigating how we can register with an agent (eg: 
>icq.myjabber.net).

You might want to look at some of the code I already wrote for 
PLugins/Agents - it's barely nothing, though. Also, you might want to 
discuss some of the design issues of this - i.e. how to best 
integrate this into the UI.


Cheers,

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

Oups, I just read the ChangeLog and saw:
* JContactLink: new class which sits between JGroups and the JContacts 
they contain.
       This simplifies drag and drop code a lot, since it's clear from 
which group we
       dragged a particular contact.

Perhaps I should have start by reading the Changelog ;-)

So Max, you already have gone trough all the problems I mention in my 
mail !

But this is not used in the OutlineViewDatasource,  have you an other 
version of the datasource ?

Or do I continue to work on that point ?

I'm now investigating how we can register with an agent (eg: 
icq.myjabber.net).

Ok, if we put :

- (unsigned int)outlineView:(NSOutlineView*)outlineView validateDrop:(id 
<NSDraggingInfo>)info proposedItem:(id)item proposedChildIndex:(int)index
{
     return NSDragOperationPrivate;
}

- (BOOL)outlineView:(NSOutlineView*)outlineView acceptDrop:(id 
<NSDraggingInfo>)info item:(id)item childIndex:(int)index
     // This method is called when the mouse is released over an outline 
view that previously decided to allow a drop via the validateDrop 
method.  The data source should incorporate the data from the dragging 
pasteboard at this time.
{
     JGroup	*group;
     JabberID *jid;

     if ((item !=nil) &&(![item isKindOfClass:[JGroup class]]))
         return NO;

     group = item;

     jid = [[JabberID jidWithString:[[info draggingPasteboard] 
stringForType:NSStringPboardType]] baseJID];

     if (item == nil)
     {
         [roster addUser:jid withName:nil toGroups:nil];
     }
     else
     {
         [roster addUser:jid withName:nil toGroups:[NSArray 
arrayWithObject:[group itemName]]];
     }
      return YES;
}

It works !

But assuming that there is no-multiple contact ;-(


(for accepting Drop from textedit too, which is very cool, we have to 
do :
     [rosterTreeView registerForDraggedTypes:[NSArray 
arrayWithObjects:RosterItemPboardType,NSStringPboardType,nil]];
in RosterController

and put in the subclass of the OutlineView something like that :

- (unsigned int)draggingSourceOperationMaskForLocal:(BOOL)flag
{
     if (flag)	// local
         return NSDragOperationMove;
     else
         return NSDragOperationCopy;
}

)



But I don't see how to make possible multiple-groups for a contact until 
Apple doesn't provide the parent of the item which is dropped from an 
OutlineView.
Or the solution is to change the item provided in the OutlineView to 
include for each item, its parents, but it is a lot of work...
(Making a new class, with contact + group).

So what shall we do ?

Is someone seeing something else ?
Something I miss in the OutlineView Drag&Drop documentation ?
An hidden Feature in cocoa ?
Wait for 10.2 and hope there will be a new way to do that ;-)


Perhaps I will try to ask in some general-cocoa-dev-mailing list...

Le samedi 4 mai 2002, =E0 12:07 PM, Arthur Petry a =E9crit :

> But I'm not sure that we can have multiple copies of a contact (in=20
> several groups), I don't see that in any Jabber Client.
> If it is possible what is the xml code ??


Ok I have tried and it works, if we send :

<iq type=3D"set">
<query xmlns=3D"jabber:iq:roster">
	<item jid=3D"te...@ja..."/>
		<group>test</group>
		<group>test 2</group>
		<group>test 3</group>=09
</query></iq>

We've got 3 times the same contact in 3 group, but I don't know how to=20=

do that for having one in the stragler...

And for now, I really don't know how we can know from wich group a drag=20=

comes !