Re: Moving libkfacebook to extragear
On Monday, 2012-10-29, Martin Klapetek wrote: > On Sun, Oct 28, 2012 at 8:03 PM, Kevin Krammer wrote: > > > This is for the parsing purposes - the library uses QJson > > > parser/mapper, which automagically maps the received json data to > > > qobjects, otherwise there would have to be manual parsing everywhere > > > (and the facebook jsons are huge), which means more code, more error > > > possibilities, more maintaining requirement and worse readability > > > (compared to two lines > > > > QJson > > > > > mapper). So I'd like to leave this one as is. > > > > I haven't had a look at the QJson library internals (yet), but from its > > usage > > it looks like that it is only using instances of those QObject classes to > > provide a convenient mapper of map keys to conversion functions (the > > property > > setters). > > > > This would make them an internal implementation detail, something more > > convenient than manually writing a mapping of string to function pointer > > but > > also just private. > > > > As I said I'll have a look into QJson, but unless I am gravely mistaken > > it only needs such QObjects as a generic accessor API, not as the actual > > data object. > > Thanks. I fixed all the issues you pointed out except this one. I think you can remove m_accessToken, m_path and m_queryItems from FacebookJob. Access token and path are already set on m_url and addQueryItem can be implemented to just call m_url.addQueryItem(). Also, virtual void start() = 0 is already part of KJob's API, so not needed again. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: QActions in QML
Sebas,
This just worked:
http://paste.kde.org/584660/
Where QAction is
http://paste.kde.org/584672/
Cheers,
Daker Fernandes Pinheiro
http://codecereal.blogspot.com
2012/10/28 Sebastian Kügler
> On Thursday, October 25, 2012 20:00:25 Aaron J. Seigo wrote:
> > not automatically, no. but QActions are QObjects, so you can attach to
> their
> > signals in the QML.
>
> And it's quite wonky, for example offering a list of QActions
> (QDeclarativeListProperty or QList, even with the payload casted to
> QObjects)
> does not seem to work. There's one, corrupt and therefore unusable entry in
> the returned data in the best case, no data at all in the worst.
>
> A workaround I've found is to send a list of QActions (.name()) in a
> QStringList to the runtime, and offer a Q_INVOKABLE QAction*
> action(QString);
> accessor which returns a QAction* to the runtime.
>
> Your button has the following:
>
> property QtObject action
>
> onClicked: action.trigger()
>
> Then, in your delegate, you retrieve the action via the key you get in your
> "listmodel":
>
> delegate: ActionButton {
> action: cpppluginthing.action(modelData)
> }
>
> Not the most beautiful thing in the world, but it seems to work at least.
> I'm
> of course open to better solutions.
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> ___
> Plasma-devel mailing list
> plasma-de...@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
Re: Moving libkfacebook to extragear
On Mon, Oct 29, 2012 at 8:28 AM, Kevin Krammer wrote: > > I think you can remove m_accessToken, m_path and m_queryItems from > FacebookJob. > Access token and path are already set on m_url and addQueryItem can be > implemented to just call m_url.addQueryItem(). > > Also, virtual void start() = 0 is already part of KJob's API, so not needed > again. > Good points, all fixed. Cheers -- Martin Klapetek | KDE Developer
Re: Moving libkfacebook to extragear
On Monday, 2012-10-29, Martin Klapetek wrote: > On Mon, Oct 29, 2012 at 8:28 AM, Kevin Krammer wrote: > > I think you can remove m_accessToken, m_path and m_queryItems from > > FacebookJob. > > Access token and path are already set on m_url and addQueryItem can be > > implemented to just call m_url.addQueryItem(). > > > > Also, virtual void start() = 0 is already part of KJob's API, so not > > needed again. > > Good points, all fixed. Almost :) FacebookJob::m_queryItems is still there. can probably also remove the typedef for QueryItem. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving libkfacebook to extragear
On Mon, Oct 29, 2012 at 11:44 AM, Kevin Krammer wrote: > > > Good points, all fixed. > > Almost :) > FacebookJob::m_queryItems is still there. can probably also remove the > typedef > for QueryItem. > Damn, overlooked. Fixed now. Also heads up - the latest changes somehow broke the akonadi resource (the one in patch for kdepim-runtime on reviewboard), I'm on it, will keep you posted. -- Martin Klapetek | KDE Developer
Re: Moving libkfacebook to extragear
On Mon, Oct 29, 2012 at 11:52 AM, Martin Klapetek wrote: > > Also heads up - the latest changes somehow broke the akonadi resource (the > one in patch for kdepim-runtime on reviewboard), I'm on it, will keep you > posted. > All fixed. If you're testing this, please update both your libkfacebook and the facebook resource patch against kdepim-runtime found at [1]. [1] - https://git.reviewboard.kde.org/r/107021/ Cheers -- Martin Klapetek | KDE Developer
Re: Moving libkfacebook to extragear
On Sunday, 2012-10-28, Kevin Krammer wrote:
> On Sunday, 2012-10-28, Martin Klapetek wrote:
> > On Sat, Oct 27, 2012 at 6:05 PM, Kevin Krammer wrote:
> > > - the *Info classes seem to be normal data classes, IMHO they don't
> > > need to be
> > > QObjects but rather "value types"
> >
> > This is for the parsing purposes - the library uses QJson parser/mapper,
> > which automagically maps the received json data to qobjects, otherwise
> > there would have to be manual parsing everywhere (and the facebook jsons
> > are huge), which means more code, more error possibilities, more
> > maintaining requirement and worse readability (compared to two lines
> > QJson mapper). So I'd like to leave this one as is.
>
> I haven't had a look at the QJson library internals (yet), but from its
> usage it looks like that it is only using instances of those QObject
> classes to provide a convenient mapper of map keys to conversion functions
> (the property setters).
I've checked QJson and its QObjectHelper indeed only uses the passed object as
a setter/getter interface.
Those "info" classes can therefore easily be made non-public/non-exported and
a single instance of each class to operate on respective instance of a proper
value-type data class.
E.g.
// appinfo.h
class LIBKFACEBOOK_EXPORT AppInfo
{
public:
// if applications do not need to set this, AppInfoParser could also be
// a friend, etc
void setId( const QString &id );
QString id() const;
// ...
private:
class Private;
QSharedDataPointer d;
};
// appinfoparser_p.h
class AppInfoParser : public QObject
{
Q_OBJECT
Q_PROPERTY( QString, id READ id WRITE setId )
public:
void setData( const AppInfo &appInfo ) { m_appInfo = appInfo; }
AppInfo data() const { return m_appInfo; }
void setId( const QString &id ) { m_appInfo.setId( id ); }
QString id() const { return m_appInfo.id() }
private:
AppInfo m_appInfo;
};
Usage e.g. in PostInfo::setApplication(
void PostInfo::setApplication( const QVariantMap &application )
{
AppInfoParser parser; // could be also be a member, etc
QJSon::QObjectHelper::qvariant2qobject( application, &parser );
m_application = parser.data();
}
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
Re: Introducing a plugin loading approach inside of the KWallet convenience API
Have not read anything since i'm ultra busy, so please disregard my message if it is off topic Can we please please plase be sure this time it works? Don't want to repeat the fiasco we had with ksecretservice that was introduced in 4.8 and then removed in 4.9 since it wasn't really working. Cheers, Albert El Diumenge, 28 d'octubre de 2012, a les 19:42:29, Valentin Rusu va escriure: > Hello, > > After quite a while of being busy with some other, "real world", tasks, > I managed to finish the plugin loading logic inside the KWallet API. > > :-) > > ** The context ** > Be able to switch from KWallet to KSecretsService, which is an > implementation of the freedesktop.org secret service [1] > This is quite a complex task to do, as existing applications must not be > affected. > > In order to do that, it was proposed [2] to introduce a plugin loading > approach inside the KWallet logic. > > ** The news ** > First of all, I created a branch named "ksecretsservice" in kdelibs. All > the preparatory work was (and will) be done inside that branch. I also > merged the master branch into that branch from time time so today it's > in sync with it. > > The Wallet logic was modified: > - load a default plugin when first called, > - all the Wallet API calls now delegate to the loaded plugin, excepting > the following methods: > * LocalWallet, > * NetworkWallet, > * PasswordFolder, > * FormDataFolder. > - some extra, internal, methods were added to the API to let the plugin > trigger wallet signals [3]: > * emitWalletOpened() > * emitWalletClosed() > * emitFolderUpdated(const QString&) > * emitFolderListUpdated() > * emitFolderRemoved(const QString&) > - a new KDE service type was defined "KWallet/Plugin" via > kdeui/util/kwallet-plugin.desktop > * this is the type that the future wallet plugins should declare > - new header was added : kdeui/util/kwalletplugin.h > * this holds a base class named WalletPlugin that all wallet > plugins must implement > > kdelibs/kwalletdefaultplugin was introduced : > - it gets the original org.kde.KWallet.xml file from kdeui/util, > - it gets the original code from kdeui/util/kwallet.cpp, > - as it's name suggests, it's loaded by default when applications access > KWallet API. > > I'm currently using this setup on my computer without problems. > KWalletManager functions as usual, and the network manager plasmoid is > continuing to load my wifi password, to only mention these applications. > > I also did a full rebuild of my KDE setup (94 kdesrc-build components), > holding my kdelibs version, to ensure no issues were introduced into > kwallet.h > > ** Next moves ** > Any thoughts about this? > > The current ksecretsservice branch should now be merged with kdelibs > master in order to bring in the plugin logic. I marked the commit that > should be merged to master with the tag "plugin.ready". > How should that be done? What would be the next steps to accomplish > that? Who can help with that? > > Cheers, > > [1] http://standards.freedesktop.org/secret-service/ > [2] http://mail.kde.org/pipermail/kde-utils-devel/2011-November/000705.html > [3] This is the only way I managed to do that. Connecting signals did > not work as some forum threads suggest.
Re: Review Request: Jar archives also uses the zip protocol.
> On May 28, 2011, 9:26 a.m., David Faure wrote: > > Does this break running .jar files with a .desktop file that says > > "Exec=java -jar %f"? > > > > Maybe the "more advanced" use case of viewing a .jar like a .zip should be > > a servicemenu (i.e. RMB / Actions / ...) Running .jar files with .desktop files works for me. (With and without the patched zip.protocol file) - Emmanuel --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101455/#review3561 --- On May 27, 2011, 11:06 p.m., Matthias Fuchs wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101455/ > --- > > (Updated May 27, 2011, 11:06 p.m.) > > > Review request for KDE Runtime and David Faure. > > > Description > --- > > nt > > > This addresses bug 188989. > http://bugs.kde.org/show_bug.cgi?id=188989 > > > Diffs > - > > kioslave/archive/zip.protocol ce7c54b > > Diff: http://git.reviewboard.kde.org/r/101455/diff/ > > > Testing > --- > > > Thanks, > > Matthias Fuchs > >
Re: Introducing a plugin loading approach inside of the KWallet convenience API
On 10/29/2012 07:07 PM, Albert Astals Cid wrote: Can we please please plase be sure this time it works? Don't want to repeat the fiasco we had with ksecretservice that was introduced in 4.8 and then removed in 4.9 since it wasn't really working. Well, this time I'll do things more carefully, on a step-by-step basis. I cannot afford another "remove" step :-) This step is the first one, as decided at the time when we backed-up - see the link [2] below. It only takes the existing kwallet code in put it into a plugin. I'm currently running with this setup with no issues, on my system. Cheers, Albert Cheers, El Diumenge, 28 d'octubre de 2012, a les 19:42:29, Valentin Rusu va escriure: [2] http://mail.kde.org/pipermail/kde-utils-devel/2011-November/000705.html -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
