pidgin-devel — DO NOT USE. See https://pidgin.im/cgi-bin/mailman/listinfo/devel

Re: [Gaim-devel] Usability issue and suggestion: remote file transfer requests

[Ethan B. <ebl...@cs...>]

Andy spake unto us the following wisdom:
> The thing is, gaim is a Gnome app and should be configurable to work
> well within that environment.=20

Gaim is not, and never has been, a Gnome application.

Ethan

--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

Re: [Gaim-devel] Usability issue and suggestion: remote file transfer requests

[Richard L. <rl...@wi...>]

On Fri, 2007-03-23 at 08:50 +1030, Andy wrote:
> The thing is, gaim is a Gnome app

No, it's not.

>  and should be configurable to work
> well within that environment.=20

Gaim should Just Work. If the environment is causing this breakage, then
the environment is at fault and we should not work around it. (I'm not
saying it is or isn't in this case, as I don't know. And for the record,
I use GNOME.)

Richard

Re: [Gaim-devel] Usability issue and suggestion: remote file transfer requests

[Andy <spi...@in...>]

Etan S. C. Reisner wrote:
> The fact that Gnome/metacity manages windows so poorly as to fail to
> notify users of new windows that pop up that Gnome/metacity
> *intentionally* prevents them from seeing is not a flaw that gaim
should
> really be required to work around. Gnome/metacity really needs to be a
> *much* more useful window manager for people if it expects people to
not
> get annoyed at it. Unless they expect everyone to play by their rules
> which they probably do and is something I don't much like, since
> applications should Just Work (tm).

Granted. The decision to go this way was made a few years ago where the
general consensus was that requesters stealing focus was a bad idea.
Especially those (like windows and KDE) who take [space] to mean the
user's accepted something. People were often dismissing important
requesters without knowing as they were typing at the time to requesters
stole focus. But the not getting focus idea doesn't really work either.
I commented on the gnome-usability list back in 2004 that neither
solution is particularly good. I suggested a requester notifier in the
panel where it wouldn't bother users until they were ready to interface
with it.

The thing is, gaim is a Gnome app and should be configurable to work
well within that environment. 

> This is more complicated and not nearly as likely to be accepted,
> personally I think overloading the tray icon with this sort of stuff
is
> just asking for confusion.

Gaim already can be configured to flash the tray icon and play a sound
when a message comes in, all I'm suggesting is for it to notify the user
of an incoming file transfer in the same manner, instead of a popup
requester.

> Even given the changes above the request would still not be 'in' the
> conversation window and putting it there would be interesting, I'm not
> sure there's a good place for it and having a file transfer request
create
> a conversation isn't good and neither is having a popup sometimes and
an
> in-conversation item other times.

Again, gaim already can be configured to open a new conversation window
on incoming messages.

As Stephen Elilert mentioned, this is apparently already a feature of
some other IM clients. From your objections, I'm unsure if you
understand my proposal. I'm suggesting that popups be abandoned
altogether. In their place any file transfer requests be written to the
conversation window with a button (or clickable text) for the user to
accept the transfer. Along with tray icon and audio notification
options. - In exactly the same way an incoming message is handled. So
the ability is already in code, it just needs to be moved to the
conversation window.


Richard Laager wrote:
> Look at gaim_xfer_request() in ft.c. We're already doing this. If it's
> not happening in a specific case, that's a bug, IMO.

Yes it does print to the window text along the lines of "Soandso wants
to send you file-x". I meant that the entire notification and somewhere
for the user to accept the request should appear there. Not in a popup
requester at all.

--

As I said, at the very least it would be handy if a sound event could be
assigned so there's some kind of notification.

[Gaim-devel] Yet another maemo-port

[Gabriel S. <ni...@go...>]

Hi!

I have based my port on gaim's SVN trunk as of a few weeks ago. I
maintain a set of patches against the trunk. Everything is in a Debian
repository at

http://idefix.go-nix.ca/nix/gaim-dist

or

deb http://idefix.fo-nix.ca/nix/gaim-dist /

in Debian sources.list parlance.

I have tried my utmost to make my modifications non-destructive. That
is, gaim should build and behave everywhere just as before even with the
patches applied.

Here's what I've done so far:

Patch 000:
- Add --enable-hildon configure flag, that adds
  - Hildon CFLAGS and LIBS
  - USE_HILDON preprocessor switch (to allow non-destructive code mods)
  - USE_HILDON Makefile conditional (to allow non-destructive build 
    mods)
- Modify default install path for gaim's icon and .desktop file to suit 
  Hildon desktop conventions
- Move hildon.desktop.in to hildon.desktop.in.in, because it now 
  contains an AC_SUBST variable, in addition to being subject to the 
  libintl rule for .desktop files. Of course, I have added it to 
  AC_OUTPUT to compensate for the extra .in and to perform the 
  substitution

Patch 010:
- Turn gaim's toplevel windows from GtkWindow objects to HildonWindow 
  objects, and set their wmclass names and classes to "gaim" (this 
  causes the desktop to recognize them as belonging to the same group)
- Remove all menu bars and turn them into GtkMenu objects
- Remove typing notification icon that is normally packed next to the 
  menu bar
- Set/unset urgency hint on conversation windows

Patch 020:
- Add tap-and-hold support to buddy list (in lieu of right-click)
- Move "Quit" from "Buddies" to "/" (since main menu is now a GtkMenu)
- Double-left click issues "row-activated" (should happen by itself)

Patch 030:
- Pack contents of notebook tabs into GtkScrolledWindow objects, 
  because there are too many widgets to fit on the small screen - for 
  both the preferences dialog, as well as the account details dialog

Patch 040:
- Get sound working by building a Gstreamer pipeline manually, rather 
  than using "playbin". Here's the pipeline:
  gnomevfssrc location=file://%s ! wavparse ! audioconvert ! dsppcmsink
  currently, this ignores the volume setting

Unfortunately, I am still not very familiar with the codebase, so I'm
running into some problems that I'm hoping to find the solution to on
this list.

I have noticed that the tree view widgets in Gaim do not behave
particularly well:

- Buddy list row-activated does not seem to happen
- When I collapse a group of buddies in the buddy list and I click on 
  the group heading, it briefly uncollapses but then recollapses the 
  group. The opposite also happens if the group is initially collapsed
- Repeated single-left-clicking on an idle buddy causes the text to be 
  painted gray (non-theme colour) - that is, the row hilight remains, 
  but the text is painted as though the entry were not hilighted
- Check boxes in the list of sound events do not reflect the state of 
  the underlying GtkTreeModel

Another strange thing I've noticed is that combo boxes in the
preferences dialog are rendered particularly badly rendered.

I will try to hack on these problems some more and hopefully get gaim up
to par on Internet tablets as well.

If anybody is interested in helping, please let me know!

Thanks for your attention,



Gabriel

Re: [Gaim-devel] Usability issue and suggestion: remote file transfer requests

[Richard L. <rl...@wi...>]

On Fri, 2007-03-23 at 00:56 +1030, Andy wrote:=20
> 1. The file request notification should be written to the chat window.
> Either inline with the conversation text or as a part of the edit
> toolbox.

Look at gaim_xfer_request() in ft.c. We're already doing this. If it's
not happening in a specific case, that's a bug, IMO.

Richard

Re: [Gaim-devel] Usability issue and suggestion: remote file transfer requests

[Stephen E. <spe...@gm...>]

On 3/22/07, Andy <spi...@in...> wrote:
> Hi list, :)
>
> I've been testing the 2.0 beta since the beginning. It's been
> progressing well and relatively bug free. Great job everyone involved!
>
> I have a couple of usability issues with the file transfers interface.
>
> Currently when a remote contact requests to send a file, Gaim pops up a
> requester and waits for the user to accept the file and choose its
> target file location. This means that the requester can go unnoticed if
> it pops up behind another window (Gnome users can have this problem with
> the do not steal focus option on, which is default). The transfer times
> out at the remote end and is missed.
>
> At the very least the option to set a sound or other alert would be
> useful. It would be best if the file transfer requester did not pop up
> at all. Instead:
>
> 1. The file request notification should be written to the chat window.
> Either inline with the conversation text or as a part of the edit
> toolbox.
> 2. A sound event should be able to be set to alert the user to the
> incoming file request.
> 3. The tray icon should flash as per the configurable user alert for
> incoming messages.
> 4. When the user returns to the conversation window they can click on
> the request and select the target file location as per usual.
>
> I believe this would be a vast improvement on most chat clients out
> there who often miss these little usability points. I hope that the
> developers consider it.

Indeed, that's how the official MSN client works. As does Google Talk,
but it goes as far as showing a preview, if the file transfer is a
picture.

I believe there's some sort of agreement that popups are bad, see the
new buddy list notifications. I do think that file transfers belong to
the specific conversation window.

The file transfer progress dialog is nice, though.


Stephen

Re: [Gaim-devel] Usability issue and suggestion: remote file transfer requests

[Salvatore B. <em...@gm...>]

On 3/22/07, Andy <spi...@in...> wrote:
>
> At the very least the option to set a sound or other alert would be
> useful. It would be best if the file transfer requester did not pop up
> at all. Instead:
>
> 1. The file request notification should be written to the chat window.
> Either inline with the conversation text or as a part of the edit
> toolbox.


I'm not a developer, but I totally agree with this.


> Thanks for your time.
> Andy.


Salvo.

-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel
>



-- 
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer and Telecommunications Engineering
University of Messina (Italy)
www.messinalug.org

skype:emitrax
icq:299985329

No to global warming!
http://www.climatecrisis.net/
http://www.stopglobalwarming.org/

Siti di vera informazione Italiana
www.beppegrillo.it

Please do not send me any word, excel or power point file
http://www.gnu.org/philosophy/no-word-attachments.html

[Gaim-devel] Usability issue and suggestion: remote file transfer requests

[Andy <spi...@in...>]

Hi list, :)

I've been testing the 2.0 beta since the beginning. It's been
progressing well and relatively bug free. Great job everyone involved!

I have a couple of usability issues with the file transfers interface.

Currently when a remote contact requests to send a file, Gaim pops up a
requester and waits for the user to accept the file and choose its
target file location. This means that the requester can go unnoticed if
it pops up behind another window (Gnome users can have this problem with
the do not steal focus option on, which is default). The transfer times
out at the remote end and is missed.

At the very least the option to set a sound or other alert would be
useful. It would be best if the file transfer requester did not pop up
at all. Instead:

1. The file request notification should be written to the chat window.
Either inline with the conversation text or as a part of the edit
toolbox.
2. A sound event should be able to be set to alert the user to the
incoming file request.
3. The tray icon should flash as per the configurable user alert for
incoming messages.
4. When the user returns to the conversation window they can click on
the request and select the target file location as per usual.

I believe this would be a vast improvement on most chat clients out
there who often miss these little usability points. I hope that the
developers consider it.

Thanks for your time.
Andy.

Re: [Gaim-devel] tray icon

[Casey H. <cas...@gm...>]

Sean Egan wrote:
> On 3/20/07, Casey Harkins <cas...@gm...> wrote:
>> I'm the guilty one[1]. I removed the old wingaim tooltips when I added
>> tooltips for all platforms displaying details of unread messages. It
>> should be trivial to add a default tooltip in other situations
>> identifying gaim.
> 
> So it was an accidental removal?
> 

No, it was intentional. I thought behavior should be the same between 
platforms. Probably should have included the wingaim tooltips on x11 
rather than removing wingaim's tooltips.

The following change on gtkdocklet.c:170 will set "Gaim" to the default 
tooltip:

-               ui_ops->set_tooltip(NULL);
+               ui_ops->set_tooltip("Gaim");


The tooltip block of code could be moved beneath the status checking 
code, so the default tooltip could be set conditionally based on the 
status. If a patch is desired I could whip one up quickly.


-casey

Re: [Gaim-devel] tray icon

[Sean E. <sea...@gm...>]

On 3/20/07, Casey Harkins <cas...@gm...> wrote:
> I'm the guilty one[1]. I removed the old wingaim tooltips when I added
> tooltips for all platforms displaying details of unread messages. It
> should be trivial to add a default tooltip in other situations
> identifying gaim.

So it was an accidental removal?

-s.

Re: [Gaim-devel] tray icon

[Casey H. <cas...@gm...>]

Sean Egan wrote:
> I noticed that the Gaim tray icon is the only one in my tray that
> doesn't identify itself in a tooltip (unless there are pending
> messages). Daniel mentioned that we used to do it, but someone removed
> it for some reason.
> 
> What was the reason?
> 

I'm the guilty one[1]. I removed the old wingaim tooltips when I added 
tooltips for all platforms displaying details of unread messages. It 
should be trivial to add a default tooltip in other situations 
identifying gaim.

-casey

[1] http://gaim.svn.sourceforge.net/viewvc/gaim?view=rev&revision=14781

Re: [Gaim-devel] Student Developer

[Eric P. <al...@gm...>]

i'm trying to get a good handle on how the event handling works with
gaim-text.  i've done quite a bit of event handling with Java, but not
much with Gtk+.style events. so a few questions follow:

1.  where do the events get mapped to their callback functions?  the
only place i've seen anything is gntui.c::gnu_ui_init where the
actions get mapped.  so I see how those are mapped to the wm.  but how
are the events triggered?  how does the gtk thread know to send
"Accounts" when I select that option in the menu?

2.  all the special hotkeys that are mapped to move windows around and
whatnot...where are those events caught?

3.  when libgnt/gntmain.c::g_main_loop_run starts, where does control
transfer to?  i'm tempted to think that it just goes into a wait state
waiting for events to trigger callbacks, but there are several things
i think that remain to be initialized still.

4.  lastly, when does libgnt/gntwm.c::gnt_wm_init get called?

as i was writing this i came across g_signal_connect and think that
might answer some of these questions.  but if you have something to
add, i would muchly appreciate it.

i know it sounds like i've never worked with event driven before, i
assure you, i know the concept, i'm just a little new to Gtk+ style
event handling, and am excited about learning how it works so i can
get on to the more important things involved in working with
gaim-text.  some of which involve improving the wm.

On 3/19/07, Adil <ad...@ya...> wrote:
>
> --- Eric Polino <al...@gm...> wrote:
>
> > i'm doing some research here and get caught up with the
> > gm_main_loop_run() calls in gnt_main() in libgnt/gntmain.c  i can't
> > find those funtions anywhere in all the source.  i'm guessing it's a
>
> g_main_loop_run starts the main event-loop in GLib, which manages the
> events, signals, timeouts and the whole lot. The documentation for that is
> at
> http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html
>
> Sadrul
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>


-- 
"Every man dies, not every man really lives."
  --- William Wallace

Re: [Gaim-devel] Student Developer

[Adil <ad...@ya...>]

--- Eric Polino <al...@gm...> wrote:

> i'm doing some research here and get caught up with the
> gm_main_loop_run() calls in gnt_main() in libgnt/gntmain.c  i can't
> find those funtions anywhere in all the source.  i'm guessing it's a

g_main_loop_run starts the main event-loop in GLib, which manages the
events, signals, timeouts and the whole lot. The documentation for that is
at
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html

Sadrul

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Gaim-devel] Student Developer

[Eric P. <al...@gm...>]

i'm doing some research here and get caught up with the
gm_main_loop_run() calls in gnt_main() in libgnt/gntmain.c  i can't
find those funtions anywhere in all the source.  i'm guessing it's a
libgnt call of some sort.  it seems to be where the control is given
to the event manager where all the event are fired off from.  where
might i find documentation on how all that is setup?

On 3/14/07, Adil <ad...@ya...> wrote:
>
> --- Eric Polino <al...@gm...> wrote:
>
> > My name is Eric Polino and I'm a Computer Science/Math student who is
> > planning on participating in Google's Summer of Code.  I have been
> > using Gaim for years and really like what it has to offer.  I have
> > recently started using Gaim-text and saw that it has come a long way
> > and has a lot of features implemented, but is still a long way from
> > completion...whatever "completion" means.  I was wondering if we could
> > work together a list of projects I could work on over the summer.  I
> > have some experience with curses and some experience with chatting
> > applications.  None of which are on the scale of Gaim-text, but still,
> > they aren't completely foreign ideas to me.
> >
> > So anyways, if someone could let me know what's up that'd be great, or
> > where I could go for more direction.  Google's SOC applications are
> > due in 11days.
> >
>
> Hi. There are a few things that I think would be good additions to
> gaim-text (and libgnt: the widget toolkit used):
>
> * A new window manager (or improvements to the existing ones). For
> example, a tiling window manager would be super awesome.
>
> * Improve the widget-packing in a container (GntBox), may be even have a
> grid like container.
>
> * Implement plugin-pref-ui using the request-api.
>
> * Have python (or some other) bindings for libgnt. This would allow
> creating functional/useful dbus clients with gnt ui.
>
> * Add some more items in the buddy-list menu. Copy the gstreamer,
> auto-reconnection etc. code from gtk-gaim into gaim-text.
>
> * Have a spell checker, which would add some way of indicating spelling
> errors, suggesting possible corrections etc.
>
> There could be some other more interesting features you could think of.
> These are a few that comes to my mind. It excites me that you are willing
> to contribute to gaim-text. An SOC project would be a very good way of
> getting started.
>
> Note: Some of the ideas I mentioned are semi-trivial. So you may want to
> bundle a number of them for an SOC application. :)
>
> Sadrul
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>


-- 
"Every man dies, not every man really lives."
  --- William Wallace

[Gaim-devel] ICQ oscar protocol differences

[ageorgo <ag...@us...>]

Hi,

I am trying to use Gaim as my primary ICQ client but I discovered some issues
related to the oscar protocol features. I have several people in my contact
list that did not authorized me - i chat with them daily. If I use Miranda
client on windows, or some other linux client (e.g., centericq, kopete, sim) I
can see also  status of unauthorized buddies. Unfortunately in Gaim, they are
shown as "Non Authorized" and behave like other off-line buddies.

I did some "research" in the communication and source code and probably found
out the reason. The other clients send somewhere within the logon phase the
SNAC(03,04) CLI_BUDDYLIST_ADD command with UINs of the users. ??I think this
command was previously used for client side contact list?? Unfortunately if I
just put this command (with real UIN of course) in oscar.c:

 3590:  aim_buddylist_addbuddy(od, conn, "123456789");
 3591:  aim_clientready(od, conn);

In return I get only the: SNAC Error: Incorrect SNAC format (0x000e). I went
trough my tcpdumps, but the command CLI_BUDDYLIST_ADD seems to be sent alright
so I do not know where is the real problem. My idea is that it has something
with configured (negotiated) capabilities of the protocol but maybe I am
completely wrong.
Maybe someone knows the solution or can give me an advice.

Thanks,

Georgo

Re: [Gaim-devel] REQ: FAQ for Gaim-vv

[Salvatore B. <em...@gm...>]

I obviously agree ;-)

Devs could also suggest how to possibly divide the problem into smaller one.

Salvo.

On 3/19/07, Phil Hannent <ph...@ha...> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello,
>
> Can I suggest an FAQ be added for the reason behind the delay in video and
> voice
> being added to Gaim.  While those of us that have watched the whole thing
> know
> the technical reasons why it is not possible yet, I think that new
> developers
> and users probably haven't read the list archives and it would help them
> to
> understand.


Regards
> Phil Hannent
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
>
> iD8DBQFF/mLfIdVDbqU9AOQRCjZ/AJ4u6mN2GMre+9kwycTDSpBAtX8Y9QCgyV9G
> 05MnmOdF1fumVa7aLm2c6BE=
> =OIuZ
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel
>



-- 
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer Engineering and Telecommunications
University of Messina (Italy)
www.messinalug.org

skype:emitrax
icq:299985329

No to global warming!
http://www.climatecrisis.net/
http://www.stopglobalwarming.org/

Siti di vera informazione Italiana
www.beppegrillo.it

Please do not send me any word, excel or power point file
http://www.gnu.org/philosophy/no-word-attachments.html

Re: [Gaim-devel] MSN Protocol Update as GSoC2007 Project

[Ka-Hing C. <ga...@hx...>]

On Mon, 2007-03-19 at 19:57 +0200, Mohammed Gamal wrote:
> Great,
> So what exactly is needed in order to get MSNP13 support upstream? Is
> it simply some code fixes?
> What about MSNP15 as well, do you think it'd be a good idea to add
> support for that?

I think there are 2 main problems with the current MSNP13 code, once we
fix those it should be HEAD ready:

1) reverse list isn't cached, so all of your buddies show up as "Has
you: no"
2) the general code quality isn't so great, to say it in a gentle way

There are also other minor problems:

1) big printf blocks for SOAP requests, manually parse each SOAP
response. I looked around for a SOAP library that we can use, but
couldn't find any. I think it can at least be abstracted a little more
betterly
2) I think file transfer is broken, I haven't used it much so I am not
too sure. It's a minor problem for me but may be more important for
others
3) Received offline messages don't have timestamp

Not that those are the only problems, but they are the ones that I can
think of right now. I also use a very small subset of MSN, so my view on
the readiness may differ from others. MSNP15 added some roaming features
and changed the authentication method, those aren't anything that I
personally care about.

-khc

Re: [Gaim-devel] MSN Protocol Update as GSoC2007 Project

[Ka-Hing C. <ga...@hx...>]

On Mon, 2007-03-19 at 10:44 -0500, Mark Doliner wrote:
> I'm sure there are features of MSNP13 that haven't been implemented yet, so I
> guess I'd say it was not "completed."  But I believe the patch DOES allow Gaim
> to use the MSNP13 protocol.  I don't know if the patch includes any MSNP14 or
> MSNP15 features.

The only thing in MSNP14 that's not in MSNP13 is yahoo compatibility,
which I remember seeing a commit email from Ma Yuen that it works.

-khc

Re: [Gaim-devel] MSN Protocol Update as GSoC2007 Project

[Mark D. <ma...@ki...>]

On Sun, 18 Mar 2007 09:58:23 +0200, Mohammed Gamal wrote
> Hello everyone,
> I am interested in improving Gaim's compatibility with MSN. I've seen
> in last year's GSoC that there was a project to include MSNP13 
> support in Gaim. Was that project completed?
> 
> Also I'd like to know if Gaim includes support for MSNP14 and MSNP15?
> In other words, how's the MSN protocol support status currently?

The changes in the MSNP13 branch have not been applied to Gaim trunk yet.  You
can follow the current progress at
http://sourceforge.net/tracker/index.php?func=detail&aid=1621854&group_id=235&atid=300235

I'm sure there are features of MSNP13 that haven't been implemented yet, so I
guess I'd say it was not "completed."  But I believe the patch DOES allow Gaim
to use the MSNP13 protocol.  I don't know if the patch includes any MSNP14 or
MSNP15 features.

It would probably be best if any summer of code proposals relating to our MSN
protocol plugin list specific features that you hope to implement.

-Mark

[Gaim-devel] REQ: FAQ for Gaim-vv

[Phil H. <ph...@ha...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello,

Can I suggest an FAQ be added for the reason behind the delay in video and voice
being added to Gaim.  While those of us that have watched the whole thing know
the technical reasons why it is not possible yet, I think that new developers
and users probably haven't read the list archives and it would help them to
understand.

Regards
Phil Hannent
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFF/mLfIdVDbqU9AOQRCjZ/AJ4u6mN2GMre+9kwycTDSpBAtX8Y9QCgyV9G
05MnmOdF1fumVa7aLm2c6BE=
=OIuZ
-----END PGP SIGNATURE-----

[Gaim-devel] tray icon

[Sean E. <sea...@gm...>]

I noticed that the Gaim tray icon is the only one in my tray that
doesn't identify itself in a tooltip (unless there are pending
messages). Daniel mentioned that we used to do it, but someone removed
it for some reason.

What was the reason?

-s.

Re: [Gaim-devel] gaim-vv support

[Ethan B. <ebl...@cs...>]

Salvatore Benedetto spake unto us the following wisdom:
> I do understand that is probably complex to implement, and definetely
> not an easy task. I also understand that students that apply for such
> as project might not have enough knowledge to design on their own the
> API needed, but why not taking in consideration valid students, that
> are willing to work all summer (and maybe more), locked in their room
> (as somebody said in the channel ;-) ) , on this project? Maybe not on
> the whole thing, but the project I think could be modularized, so that
> students could produce useful code by the end of the summer. I don't
> think it would be a totally waisting of time.

I don't think anyone is saying that Gaim-vv would not be *considered*
as a SoC project.  However, experience tells us that any but the most
prepared and organized student is not likely to be successful in this
topic, and we want students to be successful.  Due to this experience,
a proposal to work on gaim-vv type topics would have to stand out as a
powerful application that really showed that the student knew the
scope of the project he/she was getting into, and had some plan for
how to tackle it.

In other words, the application bar is simply higher.  This isn't
because we think it's a bad idea, but because we know it's a hard
problem.  As you said, clearly defining a subset of the problem and
presenting a plan for resolving that subset is probably a good tactic
to take, if your heart is really set on -vv functionality.

Ethan

--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

[Gaim-devel] Gaim-text GSoc

[Eric P. <al...@gm...>]

i'm here trying to get this compiled on my gentoo box and i'm having
issues.  btw, i'm not refering to compiling it via emerge.  i've
downloaded the source and am compiling it manually.  though i have
also installed gaim-text via emerge previously.

i've got it compiled and it runs.  but the hotkeys don't work.  i'm
going ot be looking into the code to see maybe why it's happening, but
if anyone has any idea why this could be happening let me know.  the
version that i've installed with emerge works fine and continues so.

$gcc -v
gcc version 4.1.1 (Gentoo 4.1.1-r3)

$cat /proc/version
2.6.12-gentoo-r6 (gcc version 3.3.6)

ncurses 5.5

-- 
"Every man dies, not every man really lives."
  --- William Wallace

Re: [Gaim-devel] gaim-vv support

[Salvatore B. <em...@gm...>]

On 3/17/07, Peter Lawler <spa...@si...> wrote:
>
> Tim,
> Heh, I think we both score well in in the lack of time and motivation.
> Good to hear from you. It'd seem to me that it's still the old story
> that people requesting these features don't realise how complex and time
> consuming it is. I'm contemplating joining the fray again after 2.0 is
> out and Sean commits. 10/10 to Sean for sticking with it in any shape or
> form. It's definitely one of the more thankless tasks in gaim
> development from the user-land request point of view.
>
> Regards,
>
> Pete.


I do understand that is probably complex to implement, and definetely not an
easy task.
I also understand that students that apply for such as project might not
have enough knowledge to
design on their own the API needed, but why not taking in consideration
valid students, that are willing
to work all summer (and maybe more), locked in their room (as somebody said
in the channel ;-) ) , on this
project? Maybe not on the whole thing, but the project I think could be
modularized, so that students could
produce useful code by the end of the summer. I don't think it would be a
totally waisting of time.

Salvo.


-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel
>



-- 
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer Engineering and Telecommunications
University of Messina (Italy)
www.messinalug.org

skype:emitrax
icq:299985329

No to global warming!
http://www.climatecrisis.net/
http://www.stopglobalwarming.org/

Siti di vera informazione Italiana
www.beppegrillo.it

Please do not send me any word, excel or power point file
http://www.gnu.org/philosophy/no-word-attachments.html

[Gaim-devel] MSN Protocol Update as GSoC2007 Project

[Mohammed G. <m.g...@gm...>]

Hello everyone,
I am interested in improving Gaim's compatibility with MSN. I've seen
in last year's GSoC that there was a project to include MSNP13 support
in Gaim. Was that project completed?

Also I'd like to know if Gaim includes support for MSNP14 and MSNP15?
In other words, how's the MSN protocol support status currently?

Thanks,