Re: [kopete-devel] Common emoticon specification
On Thursday 02 November 2006 04:17, Matt Rogers wrote: My personal opinion is to remove the protocol element and add a protocol attribute to both the string and image elements to do per-protocol emoticons. How are per-proto emoticons implemented? Is it possible that e.g. : ) in MSN yields another image than in ICQ? Or is it just that the ascii devilish grin } : - in MSN should be coded as ( 6 ) ? If the latter then you only need the attribute per-string and not per-proto. I do agree to make proto an attr rather than element though. Or rather, without having read the gaim-devel mailing list for the reasoning behind it, fail to see why that should be necessary ;-) Also, a long-standing wish that I eventually wanted to implement in Kopete back when I was still working on it was to allow the engine to do more sophisticated markup as well, like changing *bold* to bbold/b and /italic/ to iitalic/i, or even to support '/me' again. If we make the icon spec a shared standard (yes please! :) ) we have to keep in mind any ideas like that. Either we decide to handle those outside the .xml, we decide to not implement them at all, or we need to provide the necessary hooks for extensibility. -- Martijn Do not mistake an intelligent argument for a correct argument. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136697] New: ICQ connection problem - no connection got, but no timeout or any other error seen
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136697 Summary: ICQ connection problem - no connection got, but no timeout or any other error seen Product: kopete Version: unspecified Platform: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general AssignedTo: kopete-devel kde org ReportedBy: radzimir freenet de Version: 0.12.3 (using KDE 3.5.5, Debian Package 4:3.5.5a.dfsg.1-2 (testing/unstable)) Compiler: Target: i486-linux-gnu OS:Linux (i686) release 2.6.18 Kopete tries to connect to ICQ network but connection process never ends. No error message is displayed. The problem exists since two or three days, so I suppose it may be a problem with ICQ network too. In any case connection is not working. Connection with other networks is ok, telnet to login.oscar.aol.com 5190 works to. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136698] New: ICQ connection problem - no connection got, but no timeout or any other error seen
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136698 Summary: ICQ connection problem - no connection got, but no timeout or any other error seen Product: kopete Version: unspecified Platform: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general AssignedTo: kopete-devel kde org ReportedBy: radzimir freenet de Version: 0.12.3 (using KDE 3.5.5, Debian Package 4:3.5.5a.dfsg.1-2 (testing/unstable)) Compiler: Target: i486-linux-gnu OS:Linux (i686) release 2.6.18 Kopete tries to connect to ICQ network but connection process never ends. No error message is displayed. The problem exists since two or three days, so I suppose it may be a problem with ICQ network too. In any case connection is not working. Connection with other networks is ok, telnet to login.oscar.aol.com 5190 works to. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136697] ICQ connection problem - no connection got, but no timeout or any other error seen
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136697 kde bugs jan ritzerfeld net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From kde bugs jan ritzerfeld net 2006-11-02 11:17 --- *** This bug has been marked as a duplicate of 136566 *** ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136566] Connecting to ICQ doesn't work anymore
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136566 kde bugs jan ritzerfeld net changed: What|Removed |Added CC||radzimir freenet de --- Additional Comments From kde bugs jan ritzerfeld net 2006-11-02 11:17 --- *** Bug 136697 has been marked as a duplicate of this bug. *** ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136698] ICQ connection problem - no connection got, but no timeout or any other error seen
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136698 kde bugs jan ritzerfeld net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From kde bugs jan ritzerfeld net 2006-11-02 11:43 --- *** This bug has been marked as a duplicate of 136566 *** ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 128954] MSN file transfers (receiving) from Gaim 2.0 beta 3 client fail at 100%
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=128954 --- Additional Comments From m.vime libero it 2006-11-02 11:52 --- I have the same problem. And I'm pretty sure that the bug was present also receiving files from Gaim 1.x Kopete SVN ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136390] Yahoo duplicate login causes NULL pointer dereference
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136390 --- Additional Comments From andre duffeck de 2006-11-02 13:23 --- basically yes. but you'd have to recompile kopete with debug enabled (./configure --enable-debug=full) in order to make it produce helpful information. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: [kopete-devel] Common emoticon specification
On Thursday 02 November 2006 04:05, Martijn Klingens wrote: On Thursday 02 November 2006 04:17, Matt Rogers wrote: My personal opinion is to remove the protocol element and add a protocol attribute to both the string and image elements to do per-protocol emoticons. How are per-proto emoticons implemented? Is it possible that e.g. : ) in MSN yields another image than in ICQ? People will want this, so that they can make their emoticons per protocol look like the ones from the original clients. Or is it just that the ascii devilish grin } : - in MSN should be coded as ( 6 ) ? People will want this too, well, at least I do. :) If the latter then you only need the attribute per-string and not per-proto. I do agree to make proto an attr rather than element though. Or rather, without having read the gaim-devel mailing list for the reasoning behind it, fail to see why that should be necessary ;-) IIUC, the patch on the tracker is just a proposal. While i'm sure that some discussion on gaim-devel took place, I don't read gaim-devel (i'm on enough MLs) so I am not aware of what they discussed Also, a long-standing wish that I eventually wanted to implement in Kopete back when I was still working on it was to allow the engine to do more sophisticated markup as well, like changing *bold* to bbold/b and /italic/ to iitalic/i, or even to support '/me' again. If we make the icon spec a shared standard (yes please! :) ) we have to keep in mind any ideas like that. Either we decide to handle those outside the .xml, we decide to not implement them at all, or we need to provide the necessary hooks for extensibility. I like the idea of hooks better, personally. Thanks -- Matt ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 135397] Connecting to IRC: have to connect/disconnect many times
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=135397 --- Additional Comments From frans.englich telia com 2006-11-02 14:58 --- Created an attachment (id=18367) -- (http://bugs.kde.org/attachment.cgi?id=18367action=view) A second crash Another crash. Looks like it crashes in the same function, although it's called from a different path in this trace. Yes, the backtraces could be more useful.. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: [kopete-devel] Common emoticon specification
On Thursday 02 November 2006 14:29, Matt Rogers wrote:
Is it possible that e.g. : ) in MSN yields another image than in ICQ?
People will want this, so that they can make their emoticons per protocol
look like the ones from the original clients.
Thinking about this more, in case of conflicting emoticons that even makes
sense. Having this just to have 5 slightly different looking :) faces for the
sake of being the same as the native client is silly IMNSHO. I fully expect
people to want it though ;) (And it doesn't hurt to support it in any case.)
Or is it just that the ascii devilish grin } : - in MSN should be coded
as ( 6 ) ?
People will want this too, well, at least I do. :)
Me too :)
IIUC, the patch on the tracker is just a proposal. While i'm sure that some
discussion on gaim-devel took place, I don't read gaim-devel (i'm on enough
MLs) so I am not aware of what they discussed
Hmm, would be interesting to know though.
Also, a long-standing wish that I eventually wanted to implement in
Kopete back when I was still working on it was to allow the engine to do
more sophisticated markup as well, like changing *bold* to bbold/b
and /italic/ to iitalic/i, or even to support '/me' again.
If we make the icon spec a shared standard (yes please! :) ) we have to
keep in mind any ideas like that. Either we decide to handle those
outside the .xml, we decide to not implement them at all, or we need to
provide the necessary hooks for extensibility.
I like the idea of hooks better, personally.
Ok, with that in mind, a stab at such hooks...
I see two possible extension points here:
1. Replace text with markup rather than an image
2. Allow variable parts (regexp?) in the pattern, e.g. _([^\s])+_ for
underlining text.
Examples (using regexp syntax):
* ^-{5,}\$ -- hr / to insert a horizontal line if more than 5 dashes
are typed on an otherwise empty line
This is an example of only #1.
* _([^\s])+_ -- ul\1/ul to underline text.
This is an example of #1 and #2.
* o O ( [^)])+ ) -- an image of a thought balloon with text inside
This is (somewhat) an example of #1 and #2.
I can't think of an example of just #2 (i.e. variable pattern, but only an
image as result).
Item #2, however, is more easy to implement by adding a new element markup/
next to emoticon/. It's also easy to gracefully fail on implementations
that don't support it by simply ignoring the element. So as long as clients
don't try to do a DTD or schema validation on the unsupported element
the .xml is even downwards compatible.
Item #1 is harder, since it also affects existing elements. Instead of a
file= attribute we need another attribute or child element. Perhaps
markup= ? Graceful fallback is hard to achieve with this though.
As I said, I can't think of a case where we want a variable pattern, but only
an image as replacement. If we accept that we can limit the extension hook to
just a new element markup / and implement it all there.
More stuff that's needed in any case:
- versioning on the root element messaging-emoticon-map /, so old and new
themes can be distinguished
- consideration of KMail and possibly other apps who also use the themes
- adding of variables in the replacement markup, ideally Adium
style-compatible to lower learning curve. Otherwise /me cannot be
implemented, since it needs the user's display name.
Thoughts? If this is about it we can think about a formal syntax for
markup/, otherwise it's back to the drawing board :)
--
Martijn
Abandon the search for truth: settle on a good fantasy.
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel
Re: [kopete-devel] New kdelibs/kutils/kpluginselector
On Wednesday 01 November 2006 14:12, Rafael Fernández López wrote: All issues that happened on the old class have been fixed. I've improved the user experience, through: May I give some comment from a user-interface point of view? - The indent of the tree structure (the dotted lines at the left of the checkboxes) doesn't seem needed. I think its clear enough without and if you could remove them it would be great. reason: Less clutter. - The 'No item selected' should never be visible. Make it a single-select list and keep at least one item selected. This will have the effect that the label to the right will be This plugin is not configurable which has the advantage that its clear that its about plugins and config options. - Please top-align the message label. - you added a double margin around your list-widget. I can see too much space is on the top and left of the widget. Cheers! -- Thomas Zander pgprwhHn8tI4g.pgp Description: PGP signature ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136193] Automatic Spell Checking not working
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136193 --- Additional Comments From luis6674 yahoo com 2006-11-02 17:55 --- Not sure if it's the same case, but here it's not working correctly either (same Kopete and KDE versions, but using Arch Linux). Under the ICQ protocol automatic spell check should work, since it doesn't use rich text. In fact, if I right-click on an ICQ contact and select Send single message the spelling checker works fine. But it I click Start Chat... it doesn't work. In Yahoo protocol, if I disable rich text, it works fine, though. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136717] New: Kopete does not connect to ICQ
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136717 Summary: Kopete does not connect to ICQ Product: kopete Version: unspecified Platform: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: ICQ and AIM Plugins AssignedTo: kopete-devel kde org ReportedBy: Jan_Kassens web de Version: 0.12.3 (using KDE 3.5.5, Kubuntu (edgy) 4:3.5.5-0ubuntu3) Compiler: Target: i486-linux-gnu OS:Linux (i686) release 2.6.17-10-generic If I press connect to ICQ Kopete stucks on the state Connecting If I try it again i get the message: Sie haben sich mehrfach mit der selben UIN angemeldet, der Zugang my UIN wurde abgemedet. Translatet by me: You connected multiply times with the same UIN. The Connection my UIN was disconnected. The next try to connect then again results in the stucking Connecting... state. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136718] New: Mistake in german translation
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136718 Summary: Mistake in german translation Product: kopete Version: unspecified Platform: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Main Application AssignedTo: kopete-devel kde org ReportedBy: Jan_Kassens web de Version: 0.12.3 (using KDE 3.5.5, Kubuntu (edgy) 4:3.5.5-0ubuntu3) Compiler: Target: i486-linux-gnu OS:Linux (i686) release 2.6.17-10-generic There is a wrong word in the config menu. Detailed description in german, because i think that the translator will speak german :) Unter Einstellungen - Einrichten - Verhalten - Allgemein steht in dem Kasten Die Kontrollleiste Mit ausgeblendetem Hauptfenster startenStart das Start am Ende ist wohl überflüssig. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: [kopete-devel] Common emoticon specification
For those of you that don't know me, I'm the Gaim developer to whom the Gaim XML smiley theme patch is assigned. I brought the proposal of a unified smiley theme to #kopete some time ago. I finally got around to following up with mattr again (sorry, been a busy summer at work!), and here we are. :) On Thu, 2006-11-02 at 15:42 +0100, Martijn Klingens wrote: On Thursday 02 November 2006 14:29, Matt Rogers wrote: Is it possible that e.g. : ) in MSN yields another image than in ICQ? People will want this, so that they can make their emoticons per protocol look like the ones from the original clients. Indeed. I consider it an absolute requirement to support both protocol-independent and per-protocol smileys. When resolving a smiley, the per-protocol list for that protocol should be checked first, then the global list. IIUC, the patch on the tracker is just a proposal. While i'm sure that some discussion on gaim-devel took place, I don't read gaim-devel (i'm on enough MLs) so I am not aware of what they discussed Hmm, would be interesting to know though. I don't really recall any discussion about this on gaim-devel, and a quick search through my archives yields nothing. I don't know what that comment on the patch was all about. The patch is something proposed by a random contributor. I like the general idea for the following reasons (in no particular order): 1) Integrating an XML smiley theme would improve our support of smileys with spaces in the text -- *THUMBS UP*, for example. Currently, in the 2.0.0 line, we support those with \ escaping, but that's messy. 2) The XML smiley theme would allow us to have mouse-over descriptions for smileys. 3) We use XML for our other files, and so XML is the logical choice for a standardized smiley theme format. 4) A standardized smiley theme would increase the number of smiley themes accessible to users and make it easier on people (and distros, if any of them care about smileys) looking to create a smiley theme. Also, a long-standing wish that I eventually wanted to implement in Kopete back when I was still working on it was to allow the engine to do more sophisticated markup as well, like changing *bold* to bbold/b and /italic/ to iitalic/i, or even to support '/me' again. I'm clearly biased, since Gaim handles the /me case different, but I don't see how this is directly related to a smiley theme *format*. (In Gaim at least,) I'd rather see these implemented as UI, core, or plugin features independent of smileys. We currently have a text replacement plugin that does arbitrary, user-definable corrections (usually of typos and the like). If we're going to settle on a format that allows for text - markup transformations, well, we might as well throw that into the mix as well, since it's just a text - text transformation. If you really want to go there, I'd suggest we do a definition for smiley themes, then a separate text - markup format specification, so they can be implemented independently. If the text - markup specification isn't excessively complex, I'd definitely be willing to extend the text replacement plugin to handle those cases, and use the new format we design for its data storage. More stuff that's needed in any case: - versioning on the root element messaging-emoticon-map /, so old and new themes can be distinguished I agree. - consideration of KMail and possibly other apps who also use the themes I'm not a GNOME developer, but it looks like Evolution just has a few pre-defined smileys. If they decide to support the theme, I don't think we'll have a problem there. If anything, they can just have a special protocol like e-mail or something. Richard signature.asc Description: This is a digitally signed message part ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136717] Kopete does not connect to ICQ
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136717 kde bugs jan ritzerfeld net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From kde bugs jan ritzerfeld net 2006-11-02 18:25 --- *** This bug has been marked as a duplicate of 136566 *** ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136566] Connecting to ICQ doesn't work anymore
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136566 kde bugs jan ritzerfeld net changed: What|Removed |Added CC||Jan_Kassens web de --- Additional Comments From kde bugs jan ritzerfeld net 2006-11-02 18:25 --- *** Bug 136717 has been marked as a duplicate of this bug. *** ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136718] Mistake in german translation
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136718 kde bugs jan ritzerfeld net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From kde bugs jan ritzerfeld net 2006-11-02 18:27 --- *** This bug has been marked as a duplicate of 135556 *** ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 136566] Connecting to ICQ doesn't work anymore
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136566 --- Additional Comments From mr.bucket gmx at 2006-11-02 20:31 --- same problem: recieve messages in icq, but can't send, kopete are not able to connect! i'new to linux and not really good in installing programms!! is there any other possibility to solve this? ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: [kopete-devel] Common emoticon specification
On Thu, 2006-11-02 at 18:45 +0100, Martijn Klingens wrote: 2) The XML smiley theme would allow us to have mouse-over descriptions for smileys. I wonder what XML has to do with that though, probably specific for Gaim's implementation? Yeah, our current implementation isn't very extensible. Extensible is XMLs middle...err, first ;) name. * Security. Make sure code injection is not possible, and no external URLs will be fetched. Only relevant to the markup part, not the 'plain' emoticons. * Define how much of HTML is allowed in markup. Full (x)html will inevitably lead to compatibility issues in presentation across IM clients because of different rendering backends. Perhaps we should follow whatever rule is already implicitly imposed by the Adium theming engine, as we have to support that anyway. * URLs in markup should be normalized somehow, so angry.png is not fetched from $CWD, but instead from /usr/share/emoticon-themes/... * The markup engine should be BiDi-aware, so RTL-locales like Hebrew and Arabic work correctly, as well as bidirectional themes like iChat. This is especially important for supporting stuff like thought clouds. I think the complexity of all of these issues is a great reason that we should worry about just smileys first, and then optionally worry about markup later. :) The theme format from the Gaim patch looks like this: theme version=1.0 name=Default desc=Emoticons from each protocol's official client. icon=smile.png author=Various protocol name=default smiley hide=true imageluke.png/image descLuke/desc codeC:-)/code codeC:)/code /smiley ... /theme The current Kopete format, from my previous comment on that tracker item, looks like this: messaging-emoticon-map emoticon file=emblem-favorites string(L)/string string(l)/string /emoticon ... /messaging-emoticon-map I'd like to maintain as much compatibility with existing smiley themes as possible. Since Gaim doesn't have an XML format, this means Kopete wins by default. We agree that we need a version. I like the idea of dropping the extension and allowing the application to resolve different possibilities at run-time. This would allow, for example, shipping both .svg and .png, and allowing the application to determine at run-time which it wants. I think we might want to suggest a default format. Therefore, what about something like this? --- Begin Basis of Specification An emoticon map package shall consist of an emoticon map definition and one or more image files. messaging-emoticon-map version=2.0 emoticon protocol=msn file=love hidden=false description xml:lang=enA loving heart/description string(L)/string string(l)/string /emoticon ... /messaging-emoticon-map The version attribute is OPTIONAL, but MUST exist for version 2.0 (the new format we're describing) or higher emotion maps. The lack of a version attribute indicates a 1.0 emotion map (i.e. the existing Kopete format). The format of the version number is MAJOR.MINOR. The major number SHALL be increased when backwards compatibility is broken. In other cases of format changes, such as the addition of optional elements, the minor number shall be increased. The OPTIONAL protocol attribute to the emoticon element specifies that an emoticon applies to a specific protocol. If the attribute is ommitted, the emoticon applies to all protocols. If two emoticons with the same string exist, the following rules apply: 1) If the emoticons apply to different protocols, they SHALL each be applied for the respective protocol. 2) If one emoticon applies to a specific protocol, and another applies to all protocols, the specific one SHALL override the global for its protocol, and the global icon SHALL be used for all other protocols. 3) If the emoticons are for the same protocol or are both global, the map definition is invalid; applications SHOULD reject such definitions. The REQUIRED file attribute to the emoticon element describes a path, relative to the emotion map file, to the name of image to be used for this emotion. The application shall determine by file extensions which, if any, of the available images of that name to use. The emoticon map package SHOULD provide a .png file for each emoticon. The OPTIONAL hidden attribute to the emoticon element provides a boolean value indicating if the emotion SHOULD be hidden from the user, when presenting a list of emoticon choices. If omitted, it defaults to false. NOTE: It would be contradictory and useless to omit a string element and specify hidden=true at the same time. If a theme does this, the hidden attribute takes precedence. The OPTIONAL description element provides a textual description of the emoticon, suitable for showing to the user (e.g. in a tooltip). The description element SHOULD have an xml:lang attribute specifying the language.
[kopete-devel] [Bug 136566] Connecting to ICQ doesn't work anymore
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=136566 --- Additional Comments From robert.penz outertech com 2006-11-02 22:50 --- Following packages fix the problem for dapper standard, dapper kde 3.5.5 and edgy: http://ubuntu.lnix.net/misc/kopete-fix/ ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: [kopete-devel] New kdelibs/kutils/kpluginselector
Hi, I agree with you with the dotted lines. Maybe we can say something to the Qt people, since they have such method for the root, why haven't it for the rest of the items. I cannot do it here since this is not a delegate. I would like to get out those lines. The no item selected should exist for various reasons: 1. At start, what plugin do you select. Why to select a plugin at first ? The window could be resized with no point, and would be something like a flicker. If the window resizes because a user clicked on a plugin is OK, but no when loading the dialog. 2. When hiding a category and your selected item is in there, you lose your selection, again, where do you put your selection ? And what happens if all categories are collapsed ? I think about putting a contextual menu with Expand all and Collapse all, you couldn't select any plugin if they are all collapsed !!! What message label do you refer to ? Bye, Rafael Fernández López. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
[kopete-devel] [Bug 135448] Frozen Kopete blocks other applications (via KWallet?)
--- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=135448 kde-contrib msquadrat de changed: What|Removed |Added AssignedTo|konq-bugs kde org |kopete-devel kde org Status|REOPENED|NEW --- Additional Comments From kde-contrib msquadrat de 2006-11-03 08:27 --- *grmf* changing the package doesn't reassign the bug... ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
