This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 142188 - gaim has no smiley faces in FC3 for MSN and AOL connections
gaim has no smiley faces in FC3 for MSN and AOL connections
Product: Fedora
Classification: Fedora
Component: gaim (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Reed
Depends On:
  Show dependency treegraph
Reported: 2004-12-07 19:09 EST by David Kaplan
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-08 16:58:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Kaplan 2004-12-07 19:09:27 EST
Description of problem:
In FC2, gaim had all sorts of smileys available, but when I use it
now, it says that "this theme has no available smileys".  I have tried
this for AIM and MSN connections, not sure about the rest.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.start gaim and open up an AIM or MSN connection
2.try to insert a smiley face.
Actual results:
none are available.

Expected results:
should have lots.

Additional info:
Comment 1 David Kaplan 2004-12-07 19:10:48 EST
I just noticed that there are no smiley themes and that you have to
enable them.  But why would the default be to disable them?
Comment 2 Luke Schierer 2004-12-07 20:16:21 EST
a bug in the upgrade code causes the default for an unspecified theme
to be "None" instead of the previous default. this is the most likely
cause of this bug. 
Comment 3 Warren Togami 2005-01-08 06:06:23 EST
Luke, is this something that can be fixed in upstream gaim, or should we just
close this bug WONTFIX?
Comment 4 Warren Togami 2005-01-08 16:58:55 EST
Luke said:

I'd close it as WONTFIX, because there really isn't any clean way to 
avoid this. the preference simply wasn't save (adequately) before, 
becuase it was identical to the default, so when the default changed, 
the users's experience was different, but from the point of view of 
reading the config file in and out, it was identical. 

we could insure this doesn't happen again on some future upgrade that 
changes the default theme, but we can't retroactively fix this to ensure 
current upgraders don't hit it. 

Note You need to log in before you can comment on or make changes to this bug.