Re: [Licq-devel] Qt5
On Saturday, 2014-10-04, 10:27:12, Anders Olofsson wrote: Good! I had a quick look and the only thing I don't like is that you remove the kde-gui. Do you know if KDE will move to Qt5 as well before Jessie releases? It is unlikely that Jessie will include the Qt5 based version of KDE Plasma, the workspace product, if that is what you mean with KDE. Cheers, Kevin signature.asc Description: This is a digitally signed message part.
Re: [Licq-devel] Announcing D-Bus plugin for Licq
Am Sonntag, 2013-10-13, 22:17:42 schrieb Anders Olofsson: Each of these can be described in a separate XML file, each interface can be applicable to one or more object paths. I guess the first two are for a single object each, while the latter two apply to multiple objects. Yes, that is correct. But the only syntax I've seen is the introspect data which includes object paths. Could you point to an example for how the files should look if I only define interfaces without object paths? The name attribute on the top level node element can be omitted. Or you set it to /, it will usually be ignored anyway. See for example org.freedesktop.UPower.Device which all device nodes of UPower implement independent of their actual object path: http://cgit.freedesktop.org/upower/plain/src/org.freedesktop.UPower.Device.xml Although I'm slightly skeptic to having another file describing the API. Right now there are three copies: The implemented code, the introspect response in the code, and the examples in the README file. Adding XML files as well would be a fourth copy which is at least one too many to expect all of them to stay in sync. Hmm. I haven't thought about that. Usually the XML file is the source and the implementation is generated by the respective binding's tools. Have you considered using the C++ bindings? http://dbus-cxx.sourceforge.net/quick_start_example_xml.html Another option for reduction of redunancies might be to include the XML file into the binary at build so it can be served as the runtime introspection data. Not sure how to best do that, usually also taken care of by the binding :-/ I had a better look at the implementation now and I think it would improve maintainablity and extendability if handling of each interface were delegated to a respective implementation. E.g. something like an interface similar to DbusCallback but as a base for each interface implementation: And then registering an instance of each with the DbusCallback implementor such that it only needs to do a lookup based on iface and then delegate. This would require the plugin to instantiate objects for every contact in Licq which would make the plugin much larger (both code and memory usage). No, sorry, I probably wasn't clear. I meant having one instance of each interface handler, e.g. one for org.licq.Core, one for org.licq.ContactList, one for org.licq.Contact and so on. Each interface's callback entry points would still get the object path and retrieve the respective C++ object just like you do now. Flow would be like this call to path=/some/contact/path iface=org.licq.Contact member=GetName comes in - main interface does a lookup, e.g. in a std::mapstring, DbusAbstractInterface* - if !found = error - else delegate to found object, pass path and member and other args - uses internal pointer to main interface to respond. Cheers, Kevin signature.asc Description: This is a digitally signed message part.
Re: [Licq-devel] Announcing D-Bus plugin for Licq
On Saturday, 2013-10-12, Anders Olofsson wrote: It should just be a matter of implementing org.freedesktop.DBus.Introspectable. I think it should be pretty easy to add. I'll give it a try. It is usually also a good idea to provide a D-Bus introspection XML file as part of the sources, potentially even installing it. It is a way of documenting which interfaces are available as public API as opposed to D-Bus being used for an internal purpose (private API) or still experimental features (unstable API). Cheers, Kevin /Anders On 2013-10-12 12:30, Erik Johansson wrote: Nice work! I would be nice if you could add the features needed to make it possible to browse available licq methods using e.g. qdbusviewer. // Erik On Sat, Oct 12, 2013 at 11:34 AM, Anders Olofsson fl...@licq.org mailto:fl...@licq.org wrote: I've just pushed the first version of a D-Bus interface plugin for Licq. I mainly created this as a way to display notifications from Licq, like the osd plugins but in a separate process instead of having it as a plugin to Licq. I also added support for method calls to request information or control Licq in the hopes that others will be able to find further use for this plugin. The current API is very limited but should be relatively easy to extend depending on which use cases we want to support. More features or suggestions on what should be included are welcome. I'm not experienced with making D-Bus interfaces, so if anyone has better ideas for how the API should look please let me know. /Anders -- --- You received this message because you are subscribed to the Google Groups Licq Development group. To unsubscribe from this group and stop receiving emails from it, send an email to licq-dev+unsubscribe@__googlegroups.com mailto:licq-dev%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/__groups/opt_out https://groups.google.com/groups/opt_out. -- Erik Johansson Home Page: http://ejohansson.se/ PGP Key: http://ejohansson.se/erik.asc signature.asc Description: This is a digitally signed message part.
Re: [Licq-devel] Announcing D-Bus plugin for Licq
On Saturday, 2013-10-12, Anders Olofsson wrote: On 2013-10-12 15:15, Kevin Krammer wrote: On Saturday, 2013-10-12, Anders Olofsson wrote: It should just be a matter of implementing org.freedesktop.DBus.Introspectable. I think it should be pretty easy to add. I'll give it a try. It is usually also a good idea to provide a D-Bus introspection XML file as part of the sources, potentially even installing it. It is a way of documenting which interfaces are available as public API as opposed to D-Bus being used for an internal purpose (private API) or still experimental features (unstable API). It sounds like a good idea, but I have put all the contacts in the object tree so it's not a fixed structure and the examples I have seen for the introspective data is for a static structure only. Is it possible to describe a runtime dynamic tree in a static text file? I guess the interfaces could be documented but I haven't seen any example on how to write it. I am not sure I fully understand you so please correct me if I am wrong :) As far as I can tell after a quick look into the code is that you have the following interfaces: org.licq.Core org.licq.ContactList org.licq.Contact org.licq.Account Each of these can be described in a separate XML file, each interface can be applicable to one or more object paths. I guess the first two are for a single object each, while the latter two apply to multiple objects. Both usages are fine, you don't have to document all possible object paths. It helps client developers to mention object path patterns though, e.g. Contact objects implement the org.licq.Contact interface and can be found on object paths /org/licq/ContactList/protocol/contactId or even ...and can be listed by calling org.licq.ContactList.GetAccounts() Cheers, Kevin signature.asc Description: This is a digitally signed message part.
Re: [Licq-devel] Announcing D-Bus plugin for Licq
On Saturday, 2013-10-12, Anders Olofsson wrote:
I've just pushed the first version of a D-Bus interface plugin for Licq.
I mainly created this as a way to display notifications from Licq, like
the osd plugins but in a separate process instead of having it as a
plugin to Licq. I also added support for method calls to request
information or control Licq in the hopes that others will be able to
find further use for this plugin.
The current API is very limited but should be relatively easy to extend
depending on which use cases we want to support.
More features or suggestions on what should be included are welcome.
I'm not experienced with making D-Bus interfaces, so if anyone has
better ideas for how the API should look please let me know.
I had a better look at the implementation now and I think it would improve
maintainablity and extendability if handling of each interface were delegated
to a respective implementation.
E.g. something like an interface similar to DbusCallback but as a base for
each interface implementation:
class DbusAbstractInterface
{
public:
explicit DbusAbstractInterface(DbusInterface *conn);
virtual in dbusMethod(const char *path, const char *member ...);
..
protected:
DbusInterface *const m_conn;
};
And the implementations like
class DbusCoreInterface : public DbusAbstractInterface
{
};
And then registering an instance of each with the DbusCallback implementor
such that it only needs to do a lookup based on iface and then delegate.
I think it would also be good to have GetAccounts() return an array of object
paths, i.e. D-Bus type ao.
That allows clients to treat the values as opaque identifiers, allowing you
to change the scheme, e.g. have them as a flat list instead of grouped by
protocol, etc.
At some point it might be worthwhile to think about bulk notifications, e.g.
a signal ContactsStatusChanged with D-Bus signature a{s(us)}.
I.e. a map, where the key (first s) would be the contact identifier (or object
path if contacts are addressable individually) and the value would be the
status value and status text.
That might be benefitial if for example an accounting changing offline/online
status results in a whole set of contacts changing their status (only one
signal to send, only one signal to process on the client side).
Not sure if your plugin interface enables you to detect that though.
Cheers,
Kevin
P.S.: a bonus of having introspection XML files is that you can test how code
generators like qdbusxml2cpp or gdbus-codegen deal with them. If they fail to
produce valid code it would be an indication that there is something that
could be improved.
signature.asc
Description: This is a digitally signed message part.
[Licq-devel] Re: What will happen with Licq in 2009?
On Tuesday 06 January 2009, Anders Olofsson wrote: I've looked around a bit for library implementations of ICQ and MSN protocol and I didn't find much. It seems most other IM clients have there own implementations for these protocols. The main exception is libpurple but there's not much documentation so I'm not sure how much it does, but it looks like it contains more that just the protocol implementation so if we use it we'll probably end up loosing more of our daemon. However it seems libpurple compiles to make a separate sub library for each protocol. If these have a standard interface, we could get support for all those protocols with just one api. (If someone knows more about libpurple, please correct me or fill in.) We could of course make a library ourselves in the hope that other (future) applications will also use it and help maintain it. However I think for this to happen we will have to have a good implementation that's up to date. Also if we're not careful we might end up with a library interface that isn't usable for anything but Licq. Another way would be to find another IM client to cooperate with and make a library together. This way we could take the best parts from both sides and then maintain it together. For MSN I guess it would mostly be a matter of convincing another project to move their code to a library. I don't have my hopes very high on this though since it would be asking another group to do a lot of work that will (in the short term) mostly be only for our benefit. Some of the other clients are either being rebased on or getting support for protocol implementations provided through Telepathy [1] services. However, since Qt4 has a bit more desktop handling functions than Qt3 we actually have most of the Kde3-gui features in the Qt4-Gui without compiling it for Kde. What we're missing (that I know of) is spell checking and integration with the kde address book. I would like to see a non-kde spell checker it Qt4-Gui, I can live without the address book sync and then the difference will just a matter of using kde widgets to get the kde look and feel. At the Qt Dev Days 2008 Qt Software (formerly Trolltech) indicated that they would increase work on platform integration, i.e. detecting which environment they are running in and dynamically loading specific backend implementations for certains aspects, e.g. dialogs. So the need to a KDE GUI variant will probably become less relevant as Qt progresses on that mission. Additionally quite some KDE features are actually provided by desktop session services and KDE Libs only provide convenience API for accessing them, i.e. a Qt-only GUI could potentially still access the same features through the services' D-Bus APIs. As for spellchecking: KDE's spell checking API is mainly an abstraction over the handful of spell checking libraries, i.e. using one of them as a hard dependency might be viable instead. Cheers, Kevin [1] http://telepathy.freedesktop.org/wiki/ -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
[Licq-devel] Re: Qt4-GUI application icon
On Wednesday 21 November 2007, Arne Schmitz wrote: Am Freitag, 16. November 2007 19:51:32 schrieb Eugene Paskevich: I would like to set the default application icon for Qt4-GUI. I have another variant of this, see the attached files. The SVG was made with Inkscape. This is not very beautiful yet, but a starting point for more talented people. :-) BTW, what is the standard for application icon size? KDE 4 will have SVG support, but Qt 4 seems to have no SVG icon engine in it yet. So I would use something between 16x16 and 64x64 as the default size. The windowmanager can resize the icon anyway. For example, my KDE taskbar uses 24x24 and the task switcher uses 32x32. KDE now uses SVG as sources for the icons but PNGs get installed. IIRC because the Qt SVG renderer doesn't do all the effects yet which the artists wanted to have and I think also because it is faster to load and display a PNG than to render the SVG. My guess is that at a future state the SVG source will be installed as well and be used for rendering sizes where no pre-rendered PNG could be found. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
