Re: Proposal for branching policy towards KF5
On Friday 19 July 2013 17:42:14 Sebastian Kügler wrote:
>On Friday, July 19, 2013 00:21:21 David Faure wrote:
>> After more live discussion with Sebas and Marco plus Aaron over a video
>
>> chat, we came up with the following setup for the workspace repos (*) :
>[...]
>
>> (*) kde-workspace, plasma-frameworks, please complete this list if there
>> are more.
>
>The following also belong into the workspace category:
>
>* kdeplasma-addons
>* declarative-plasmoids
>* kde-runtime
>
>These ones I'm unsure about:
>* kdebase-artwork
>* kde-wallpapers
>* kmix
>* kscreen
>* libkscreen
>* bluedevil
>* libbluedevil
>* bluedevil
>* activitymanager
>* *libdbusmenu-qt (special case, since it comes from launchpad / bazaar)
>* lightdm-kde
>* nepomuk-core
>* nepomuk-widgets
>* share-like-connect
>* networkmanagement (+libs, need to ask Lamarque which repos those are
> exactly)
networkmanagement repository is deprecated. Now we have libmm-qt,
libnm-qt and plasma-nm repos.
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Moving libmm-qt and libnm-qt to kdereview
Hi all, I would like move libmm-qt and libnm-qt from playground to kdereview. How can I do that? The project pages are: https://projects.kde.org/projects/playground/base/libmm-qt https://projects.kde.org/projects/playground/base/libnm-qt I already fixed all krazy2 issues. Regards, -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Moving libmm-qt and libnm-qt to kdereview
Em Sunday 04 December 2011, Aaron J. Seigo escreveu: > On Saturday, December 3, 2011 17:48:17 Lamarque V. Souza wrote: > > https://projects.kde.org/projects/playground/base/libmm-qt > > https://projects.kde.org/projects/playground/base/libnm-qt > > i know its relatively late to bring this up, but better before a first > initial release to do so: is there any chance that these libraries could > get more descriptive names? > > there is already a "libmm" which is actually a shared memory helper, > unrelated to libmm-qt (though the name suggests otherwise). "mm" and "nm" > really don't say much about what these libraries do. the names are > ambiguous and stand a high chance of collision with other libraries. > > i know that the networkmanager project decided to call their library libnm, > but we don't need to repeat such errors ourselves, right? :) Well, the final goal is to move those two libraries to ModemManager and NetworkManager's repositories in the future. If I rename them now I will probably have to rename them back in the future. I think will have to ask this to NetworkManager guys now. What names do you suggest? libmodemmanager-qt and libnetworkmanager-qt? I do not see any other more descriptive name. Another suggestion is libQtModemManager and libQtNetworkManager, which follows Qt's library name convention. I think will stick to the latter. Just let me check with the NetworkManager guys if there is any problem using Qt's library name convention instead of NM"s. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Moving libmm-qt and libnm-qt to kdereview
Em Sunday 04 December 2011, Ben Cooksley escreveu: > On Sun, Dec 4, 2011 at 8:48 AM, Lamarque V. Souza wrote: > > Hi all, > > Hi Lamarque, > > > I would like move libmm-qt and libnm-qt from playground to kdereview. How > > > can I do that? The project pages are: > Unfortunately due to limitations in Redmine (namely, groups of 2000+ > members don't scale), you need to ask a Sysadmin to do this for you at > the moment. > I have now moved both into KDE Review. Thanks :-) > > > https://projects.kde.org/projects/playground/base/libmm-qt > > > > https://projects.kde.org/projects/playground/base/libnm-qt > > > > > > > > I already fixed all krazy2 issues. > > > > > > > > Regards, > > Regards, > Ben Cooksley > KDE Sysadmin > > > -- > > > > Lamarque V. Souza > > > > KDE's Network Management maintainer > > > > http://planetkde.org/pt-br -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Moving libmm-qt and libnm-qt to kdereview
Em Sunday 04 December 2011, Lamarque V. Souza escreveu:
> Em Sunday 04 December 2011, Aaron J. Seigo escreveu:
> > On Saturday, December 3, 2011 17:48:17 Lamarque V. Souza wrote:
> > > https://projects.kde.org/projects/playground/base/libmm-qt
> > > https://projects.kde.org/projects/playground/base/libnm-qt
> >
> > i know its relatively late to bring this up, but better before a first
> > initial release to do so: is there any chance that these libraries could
> > get more descriptive names?
> >
> > there is already a "libmm" which is actually a shared memory helper,
> > unrelated to libmm-qt (though the name suggests otherwise). "mm" and "nm"
> > really don't say much about what these libraries do. the names are
> > ambiguous and stand a high chance of collision with other libraries.
> >
> > i know that the networkmanager project decided to call their library
> > libnm, but we don't need to repeat such errors ourselves, right? :)
>
> Well, the final goal is to move those two libraries to ModemManager and
> NetworkManager's repositories in the future. If I rename them now I will
> probably have to rename them back in the future. I think will have to ask
> this to NetworkManager guys now.
>
> What names do you suggest? libmodemmanager-qt and libnetworkmanager-qt?
> I do not see any other more descriptive name. Another suggestion is
> libQtModemManager and libQtNetworkManager, which follows Qt's library name
> convention. I think will stick to the latter. Just let me check with the
> NetworkManager guys if there is any problem using Qt's library name
> convention instead of NM"s.
Dan Williams from NM does not mind the long names:
http://mail.gnome.org/archives/networkmanager-list/2011-December/msg00049.html
I will change them to match Qt's name convention:
libQtModemManager.0.5.0 and libQtNetworkManager.0.9.0 for the libraries and
/usr/include/{QtModemManager,QtNetworkManager} for the include directories. I
already have the patches for that. If nobody says anything against this change
I will push them tomorrow.
Thanks Aaron Seigo and Thomas Zander for commenting on this issue and
Ben Cooksley for moving the repositories to kdereview.
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: Review Request: Reset time format upon user request
Em Sunday 18 December 2011, David Faure escreveu: > On Sunday 18 December 2011 12:51:25 Lamarque Vieira Souza wrote: > > Another problem with this approach is that we cannot prevent anybody else > > from listening to > > KGlobalSettings::self()->emitChange(KGlobalSettings::SettingsChanged, > > KGlobalSettings::SETTING_LOCALE). > > What would be wrong with that? It would be the way to have a GUI that > reacts to changes in the locale settings. Every app and in particular > date/time widgets might want to listen to that and adapt. > Or did I misunderstand what this was about? You misunderstood what I meant. You removed that paragraph from the context of the first paragraph of my last e-mail. What I meant is that if we use something like KLocale::commit() then we should not let others use KGlobalSettings::self()>emitChange(KGlobalSettings::SettingsChanged, KGlobalSettings::SETTING_LOCALE). If we just add KGlobalSettings::SETTING_LOCALE to kglobalsettings.h then it is correct that everybody uses it. The problem with KGlobalSettings::SETTING_LOCALE is that is solves only half the problem. I am using a hack to force the local KLocale instance in the clock plasmoid to reload the configuration files. There is no API in kdelibs to reload KLocale's configuration files and that is why I suggested using something like KLocale::commit() when Aaron complained about my second review of this patch. > > I am trying to minimize the number of patches needed to fix bug #289094. > > If everyone only went for the "minimal lines of code" fix all the time, we > would have one hell of a mess by now... I am not familiar with this part of kdelibs and it is very clear it is a very sensible part of kdelibs. Anything wrong here will be noticed by everybody, that is why I am trying to do the minimum in this case. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: Make KGlobalSettings reread locale settings before calling settingsChanged().
Em Monday 19 December 2011, David Faure escreveu: > On Monday 19 December 2011 15:46:14 Lamarque Vieira Souza wrote: > > > On Dec. 19, 2011, 2:35 p.m., David Faure wrote: > > > > kdeui/kernel/kglobalsettings.cpp, line 886 > > > > <http://git.reviewboard.kde.org/r/103469/diff/2/?file=43867#file43867 > > > > lin e886>> > > > > > > > > > I like the idea (KGlobalSettings reparsing configuration), but > > > > not the implementation (setLanguage(langage)). Can't KLocale get > > > > a reparseConfiguration() (to reuse the KConfig naming) ? > > > > KLocale::reparseConfiguration() would be just a call to > > KLocalePrivate::initFormat(), but initFormat is protected. I will have to > > make it public to use it in KLocale::reparseConfiguration, wouldn't that > > break binary compatibility? > > Aeh? If it's called KLocalePrivate it's a private class, you can do > whatever you want with it. Well, it's called KLocalePrivate but it has a lot of protected methods that KLocale cannot access, initFormat is one of them: ../../kdecore/localization/klocale_p.h: In member function 'void KLocale::reparseConfiguration()': ../../kdecore/localization/klocale_p.h:81:18: error: 'virtual void KLocalePrivate::initFormat()' is protected ../../kdecore/localization/klocale.cpp:786:19: error: within this context -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: Make KGlobalSettings reread locale settings before calling settingsChanged().
Em Monday 19 December 2011, David Faure escreveu: > On Monday 19 December 2011 15:01:51 Lamarque V. Souza wrote: > > Em Monday 19 December 2011, David Faure escreveu: > > > On Monday 19 December 2011 15:46:14 Lamarque Vieira Souza wrote: > > > > > On Dec. 19, 2011, 2:35 p.m., David Faure wrote: > > > > > > kdeui/kernel/kglobalsettings.cpp, line 886 > > > > > > <http://git.reviewboard.kde.org/r/103469/diff/2/?file=43867#file4 > > > > > > 386 7 > > > > > > lin e886>> > > > > > > > > > > > > > I like the idea (KGlobalSettings reparsing configuration), > > > > > > but not the implementation (setLanguage(langage)). Can't > > > > > > KLocale get a reparseConfiguration() (to reuse the KConfig > > > > > > naming) ? > > > > > > > > KLocale::reparseConfiguration() would be just a call to > > > > KLocalePrivate::initFormat(), but initFormat is protected. I will > > > > have to > > > > make it public to use it in KLocale::reparseConfiguration, wouldn't > > > > that break binary compatibility? > > > > > > Aeh? If it's called KLocalePrivate it's a private class, you can do > > > whatever you want with it. > > > > Well, it's called KLocalePrivate but it has a lot of protected methods > > > > that KLocale cannot access, initFormat is one of them: > > > > ../../kdecore/localization/klocale_p.h: In member function 'void > > KLocale::reparseConfiguration()': > > ../../kdecore/localization/klocale_p.h:81:18: error: 'virtual void > > KLocalePrivate::initFormat()' is protected > > ../../kdecore/localization/klocale.cpp:786:19: error: within this context > > So make it public. As I said, it's a Private class, there's no possible BIC > issue with it. > > Of course I trust you that calling it directly is okay, I have no idea > about that, John Layt would be able to confirm that, though. Well, it works here and nothing has crashed so far :-) By the number of public and protected sections in KLocalePrivate either everybody is scared to organize them or there must be a really nasty bug in there that nobody dares to talk about because there is no comment explaining why it is like that. PS: There are 14 "public:" sections, 10 "protected:" and 2 "private:" in KLocalePrivate. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: Make KGlobalSettings reread locale settings before calling settingsChanged().
Hi all, Can I submit the review below? By the way, is kdelibs still closed to pushes? Em Monday 19 December 2011, Lamarque Vieira Souza escreveu: > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103469/ > --- > > (Updated Dec. 19, 2011, 10:15 p.m.) > > > Review request for kdelibs and Plasma. > > > Changes > --- > > Add KLocale::reparseConfiguration() and make KLocalePrivate::initFormat() > public. > > > Description > --- > > This is patch number 3 to fix bug #289094 (top bar time incorrectly > displays in 24 hour format). The other patches are against plasma-mobile > and kde-workspace (http://git.reviewboard.kde.org/r/103434), all three > patches must be applied to fix the bug. I think this is a much simpler > solution than the one I suggested in > http://git.reviewboard.kde.org/r/103434. > > > This addresses bug 289094. > http://bugs.kde.org/show_bug.cgi?id=289094 > > > Diffs (updated) > - > > kdecore/localization/klocale.h 3495431 > kdecore/localization/klocale.cpp 499bf11 > kdecore/localization/klocale_p.h 4ed8e3f > kdeui/kernel/kglobalsettings.h cb8f7e2 > kdeui/kernel/kglobalsettings.cpp 819b314 > > Diff: http://git.reviewboard.kde.org/r/103469/diff/diff > > > Testing > --- > > > Thanks, > > Lamarque Vieira Souza -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: ktouchpadenabler moved to kdereview
Em Wednesday 04 January 2012, Albert Astals Cid escreveu:
> El Dimecres, 4 de gener de 2012, a les 23:40:26, David Faure va escriure:
> > On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote:
> > > El Dimecres, 4 de gener de 2012, a les 01:53:13, Christoph Feck va
>
> escriure:
> > > > On Wednesday 04 January 2012 00:28:11 Albert Astals Cid wrote:
> > > > > My little kded daemon that listens to XF86XK_TouchpadToggle and
> > > > > enables disables the touchpad accordingly has been moved to
> > > > > kdereview.
> > > > >
> > > > > My plan is moving it to extragear, not really sure if -base or
> > > > > -utils.
> > > > >
> > > > > The code doesn't have a kcm or any kind of configuration since
> > > > > it
> > > > > is designed to "just work".
> > > > >
> > > > > I'd appreciate any review or suggestion over it.
> > > >
> > > > I cannot test it because I have no touchpad, but if it is supposed
> > > > to
> > > > "just work" without any UI, I suggest to just add it to "khotkeys"
> > > > or
> > > > "kaccel" daemon (whichever of them is used for global shortcuts), so
> > > > that we do not filter global X11 keyboard events twice.
> > >
> > > I don't really see any point in doing that, nothing can be shared
> > > between
> > > them and the existing ktouchpadenabler so instead of one simple
> > > codebase (166 lines with 20 of headers) you end up adding more
> > > complexity to existing programs (probably integrating the code in the
> > > existing programs
> > > would be more than 166 lines).
> >
> > IMHO this isn't about the number of lines of code, but about the runtime
> > performance (how many process to wake up when pressing a key).
>
> khotkeys is already a kded module, so there won't be no more processes
> waking up now than before by adding a new kded module.
>
> > kglobalaccel seems quite suitable indeed, no?
>
> It would, if Qt had a key for XF86XK_TouchpadToggle, as it doesn't i'd need
> to introduce a big "ignore all the workflow of kglobalaccel for this
> special key" since kglobalaccel only understands Qt keys (see
> KGlobalAccelImpl::grabKey).
In your blog (http://tsdgeos.blogspot.com/2011/12/sad-story-of-day-qt-
and.html) you said your patch against Qt was accepted. I thought your patch
would add XF86XK_TouchpadToggle support to Qt and then there would be no need
for this kded module. If we patch Qt we could add the support for a key as one
#define and one enumerate per key in kdelibs/kdeui/util/kkeyserver_x11.cpp
with no runtime overhead. I also created the patch for that, it works for me.
I have never sent my patch to Qt because the upstream bug
(https://bugreports.qt.nokia.com//browse/QTBUG-8956) has been ignored for
almost two years now, nobody seems to care about the bug.
My question is: since you know how to send patches to Qt's repository
wouldn't be better just send my patch upstream (it is here
https://bugs.kde.org/show_bug.cgi?id=182672) and just apply my second patch to
kdelibs? My second patch is attached.
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
diff --git a/kdeui/util/kkeyserver_x11.cpp b/kdeui/util/kkeyserver_x11.cpp
index 5a7d6d8..3e6e36f 100644
--- a/kdeui/util/kkeyserver_x11.cpp
+++ b/kdeui/util/kkeyserver_x11.cpp
@@ -334,6 +334,9 @@ static const TransKey g_rgQtToSymX[] =
#define XF86XK_TopMenu 0x1008FFA2
#define XF86XK_Suspend 0x1008FFA7
#define XF86XK_Hibernate 0x1008FFA8
+#define XF86XK_TouchpadToggle 0x1008FFA9
+#define XF86XK_TouchpadOn 0x1008FFB0
+#define XF86XK_TouchpadOff 0x1008FFB1
// end of XF86keysyms.h
,
{ Qt::Key_Back, XF86XK_Back },
@@ -453,6 +456,9 @@ static const TransKey g_rgQtToSymX[] =
{ Qt::Key_Bluetooth, XF86XK_Bluetooth },
{ Qt::Key_Suspend, XF86XK_Suspend },
{ Qt::Key_Hibernate, XF86XK_Hibernate },
+{ Qt::Key_TouchpadToggle, XF86XK_TouchpadToggle },
+{ Qt::Key_TouchpadOn, XF86XK_TouchpadOn },
+{ Qt::Key_TouchpadOff, XF86XK_TouchpadOff },
{ Qt::Key_Launch2,XF86XK_Launch0 },
{ Qt::Key_Launch3,XF86XK_Launch1 },
{ Qt::Key_Launch4,XF86XK_Launch2 },
Re: libmm-qt and libnm-qt still in KDE Review
Em Wednesday 04 January 2012, Ben Cooksley escreveu: > Hi all, > > Just doing a little spring cleaning of KDE Review and I noticed that > libmm-qt and libnm-qt are still there. What was the final decision on > where they are going to be moved? Good question. Does anybody object to moving it to extragear? -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: Port shutdown dialog to QML
Em Wednesday 04 January 2012, Alexander Neundorf escreveu:
> On Wednesday 04 January 2012, Lamarque Vieira Souza wrote:
> > > On Jan. 3, 2012, 9:38 p.m., Albert Astals Cid wrote:
> > > > ksmserver/CMakeLists.txt, line 57
> > > > <http://git.reviewboard.kde.org/r/103621/diff/1/?file=45363#file45363
> > > > li ne57>
> > > >
> > > > no variable for kdeclarative?
> > >
> > > Lamarque Vieira Souza wrote:
> > > There is one in shutdowndlg.cpp, in KSMShutdownDlg's constructor.
> > >
> > > Albert Astals Cid wrote:
> > > I mean cmake variable like ${SOMETHING_SOMETHING}
> >
> > I do not think so. All CMakeLists.txt throughout kde-workspace,
> > kde-runtime and plasma-mobile add the library name directly.
>
> libkdeclarative is from kdelibs/experimental/, right ?
Yes.
> So, it is not from within the same project.
> And I didn't find a place where libkdeclarative would install a
> KDeclarativeConfig.cmake file. Did I miss this somewhere ?
>
> If not, is there a FindKDeclarative.cmake somewhere ?
>
> If not, this is seriously messed up.
>
> It would mean that simply using "kdeclarative" means that cmake interprets
> this as name of a library and simply adds -lkdeclarative to the command
> line, without checking whether it actually exists nor in which directory.
I guest that is indeed what happens now.
> So, is there a FindKDeclarative.cmake or a KDeclarativeConfig.cmake file
> somewhere ?
locate /*Declarative*.cmake returned nothing here, so there is none in
my notebook.
> It seems kdeclarative is not checked in FindKDE4Internal.cmake, like all
> "regular" kdelibs libraries.
I think so.
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: ktouchpadenabler moved to kdereview
Em Thursday 05 January 2012, Albert Astals Cid escreveu: > El Dimecres, 4 de gener de 2012, a les 21:55:36, Lamarque V. Souza va > > escriure: > > Em Wednesday 04 January 2012, Albert Astals Cid escreveu: > > > El Dimecres, 4 de gener de 2012, a les 23:40:26, David Faure va escriure: > > > > On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote: > > > > > El Dimecres, 4 de gener de 2012, a les 01:53:13, Christoph Feck > > > > > va > > > > > > escriure: > > > > > > On Wednesday 04 January 2012 00:28:11 Albert Astals Cid wrote: > > > > > > > My little kded daemon that listens to > > > > > > > XF86XK_TouchpadToggle and > > > > > > > enables disables the touchpad accordingly has been moved > > > > > > > to > > > > > > > kdereview. > > > > > > > > > > > > > > My plan is moving it to extragear, not really sure if > > > > > > > -base or > > > > > > > -utils. > > > > > > > > > > > > > > The code doesn't have a kcm or any kind of configuration > > > > > > > since > > > > > > > it > > > > > > > is designed to "just work". > > > > > > > > > > > > > > I'd appreciate any review or suggestion over it. > > > > > > > > > > > > I cannot test it because I have no touchpad, but if it is > > > > > > supposed > > > > > > to > > > > > > "just work" without any UI, I suggest to just add it to > > > > > > "khotkeys" > > > > > > or > > > > > > "kaccel" daemon (whichever of them is used for global > > > > > > shortcuts), so that we do not filter global X11 keyboard > > > > > > events twice. > > > > > > > > > > I don't really see any point in doing that, nothing can be > > > > > shared > > > > > between > > > > > them and the existing ktouchpadenabler so instead of one simple > > > > > codebase (166 lines with 20 of headers) you end up adding more > > > > > complexity to existing programs (probably integrating the code > > > > > in the > > > > > existing programs > > > > > would be more than 166 lines). > > > > > > > > IMHO this isn't about the number of lines of code, but about the > > > > runtime performance (how many process to wake up when pressing a > > > > key).> > > > > > > khotkeys is already a kded module, so there won't be no more processes > > > waking up now than before by adding a new kded module. > > > > > > > kglobalaccel seems quite suitable indeed, no? > > > > > > It would, if Qt had a key for XF86XK_TouchpadToggle, as it doesn't i'd > > > need to introduce a big "ignore all the workflow of kglobalaccel for > > > this special key" since kglobalaccel only understands Qt keys (see > > > KGlobalAccelImpl::grabKey). > > > > In your blog (http://tsdgeos.blogspot.com/2011/12/sad-story-of-day-qt- > > > > and.html) you said your patch against Qt was accepted. I thought your > > patch would add XF86XK_TouchpadToggle support to Qt and then there would > > be no need for this kded module. If we patch Qt we could add the support > > for a key as one #define and one enumerate per key in > > kdelibs/kdeui/util/kkeyserver_x11.cpp with no runtime overhead. I also > > created the patch for that, it works for me. I have never sent my patch > > to Qt because the upstream bug > > (https://bugreports.qt.nokia.com//browse/QTBUG-8956) has been ignored for > > almost two years now, nobody seems to care about the bug. > > My patch patch was accepted in Qt5, noone is going to accept stuff like > that for Qt 4.8. As far as i can see my patch already includes your > changes. Ok then, I have heard "Qt 4 is done" from other sources as well. You should change ktouchpadenabler to something else since probably there are other keys that it can also handle. For example the other four keys mentioned in https://bugreports.qt.nokia.com//browse/QTBUG-8956. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: ktouchpadenabler moved to kdereview
Em Thursday 05 January 2012, Thomas Zander escreveu: > On Wednesday 04 January 2012 21.55.36 Lamarque V. Souza wrote: > > My question is: since you know how to send patches to Qt's > > > > repository wouldn't be better just send my patch upstream (it is > > here https://bugs.kde.org/show_bug.cgi?id=182672) > > Contributing to Qt is a simple matter; after a simple setup procedure that > takes a little time (with reading, and asking on irc, it was less than an > hour for me) you can get your patches in into Qt very quickly nowadays. > > Start here :) > http://wiki.qt-project.org/Setting_up_Gerrit Thanks, I will try it another time. I do not have Qt5 here to do test and since they will not accept patches against Qt4 there is no hurry for me yet. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: Port shutdown dialog to QML
Em Thursday 05 January 2012, Alexander Neundorf escreveu:
> On Thursday 05 January 2012, Lamarque V. Souza wrote:
> > Em Wednesday 04 January 2012, Alexander Neundorf escreveu:
> > > On Wednesday 04 January 2012, Lamarque Vieira Souza wrote:
> > > > > On Jan. 3, 2012, 9:38 p.m., Albert Astals Cid wrote:
> > > > > > ksmserver/CMakeLists.txt, line 57
> > > > > > <http://git.reviewboard.kde.org/r/103621/diff/1/?file=45363#file4
> > > > > > 53 63 li ne57>
> > > > > >
> > > > > > no variable for kdeclarative?
> > > > >
> > > > > Lamarque Vieira Souza wrote:
> > > > > There is one in shutdowndlg.cpp, in KSMShutdownDlg's
> > > > > constructor.
> > > > >
> > > > > Albert Astals Cid wrote:
> > > > > I mean cmake variable like ${SOMETHING_SOMETHING}
> > > >
> > > > I do not think so. All CMakeLists.txt throughout kde-workspace,
> > > > kde-runtime and plasma-mobile add the library name directly.
> > >
> > > libkdeclarative is from kdelibs/experimental/, right ?
> >
> > Yes.
> >
> > > So, it is not from within the same project.
> > > And I didn't find a place where libkdeclarative would install a
> > > KDeclarativeConfig.cmake file. Did I miss this somewhere ?
> > >
> > > If not, is there a FindKDeclarative.cmake somewhere ?
> > >
> > > If not, this is seriously messed up.
> > >
> > > It would mean that simply using "kdeclarative" means that cmake
> > > interprets this as name of a library and simply adds -lkdeclarative to
> > > the command line, without checking whether it actually exists nor in
> > > which directory.
> >
> > I guest that is indeed what happens now.
> >
> > > So, is there a FindKDeclarative.cmake or a KDeclarativeConfig.cmake
> > > file somewhere ?
> >
> > locate /*Declarative*.cmake returned nothing here, so there is none in
> >
> > my notebook.
>
> So, quick solution: write a simply FindKDeclarative.cmake file (mostly
> find_library(), find_path() and a find_package_handle_standard_args() call)
> and use this (but don't install it).
>
> Good solution: kdeclarative should install a KDeclarativeConfig.cmake file,
> so it will be found automatically. But this has to be done carefully.
I think the person to talk about this is Marco Martin. As far as I know
he is the one doing most of the work in kdeclarative. Kdeclarative is going to
be very important in Plasma 4.8, I think we should fix this properly before
the 4.8 final release.
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: ktouchpadenabler moved to kdereview
Em Thursday 05 January 2012, Albert Astals Cid escreveu: > El Dijous, 5 de gener de 2012, a les 21:35:18, Lamarque V. Souza va escriure: > > Em Thursday 05 January 2012, Albert Astals Cid escreveu: > > > El Dimecres, 4 de gener de 2012, a les 21:55:36, Lamarque V. Souza va > > > > > > escriure: > > > > Em Wednesday 04 January 2012, Albert Astals Cid escreveu: > > > > > El Dimecres, 4 de gener de 2012, a les 23:40:26, David Faure va > > > > escriure: > > > > > > On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote: > > > > > > > El Dimecres, 4 de gener de 2012, a les 01:53:13, > > > > > > > Christoph Feck > > > > > > > va > > > > > > > > > > escriure: > > > > > > > > On Wednesday 04 January 2012 00:28:11 Albert Astals Cid wrote: > > > > > > > > > My little kded daemon that listens to > > > > > > > > > XF86XK_TouchpadToggle and > > > > > > > > > enables disables the touchpad accordingly has > > > > > > > > > been moved > > > > > > > > > to > > > > > > > > > kdereview. > > > > > > > > > > > > > > > > > > My plan is moving it to extragear, not really > > > > > > > > > sure if > > > > > > > > > -base or > > > > > > > > > -utils. > > > > > > > > > > > > > > > > > > The code doesn't have a kcm or any kind of > > > > > > > > > configuration > > > > > > > > > since > > > > > > > > > it > > > > > > > > > is designed to "just work". > > > > > > > > > > > > > > > > > > I'd appreciate any review or suggestion over it. > > > > > > > > > > > > > > > > I cannot test it because I have no touchpad, but if > > > > > > > > it is > > > > > > > > supposed > > > > > > > > to > > > > > > > > "just work" without any UI, I suggest to just add it > > > > > > > > to > > > > > > > > "khotkeys" > > > > > > > > or > > > > > > > > "kaccel" daemon (whichever of them is used for > > > > > > > > global > > > > > > > > shortcuts), so that we do not filter global X11 > > > > > > > > keyboard > > > > > > > > events twice. > > > > > > > > > > > > > > I don't really see any point in doing that, nothing can > > > > > > > be > > > > > > > shared > > > > > > > between > > > > > > > them and the existing ktouchpadenabler so instead of one > > > > > > > simple > > > > > > > codebase (166 lines with 20 of headers) you end up > > > > > > > adding more > > > > > > > complexity to existing programs (probably integrating > > > > > > > the code > > > > > > > in the > > > > > > > existing programs > > > > > > > would be more than 166 lines). > > > > > > > > > > > > IMHO this isn't about the number of lines of code, but about > > > > > > the > > > > > > runtime performance (how many process to wake up when > > > > > > pressing a > > > > > > key).> > > > > > > > > > > khotkeys is already a kded module, so there won't be no more > > > > > processes waking up now than before by adding a new kded > > > > > module. > > > > > > > > > > > kglobalaccel seems quite suitable indeed, no? > > > > > > > > > > It would, if Qt had a key for XF86XK_TouchpadToggle, as it > > > > > doesn't i'd need to introduce a big "ignore all the workflow of > > > > > kglobalaccel for this special key" since kglobalaccel only > > > > > understands Qt keys (see KGlobalAccelImpl::grabKey). > > > > > > > > In your blog > > > >
Re: ktouchpadenabler moved to kdereview
Em Thursday 05 January 2012, Albert Astals Cid escreveu: > El Dijous, 5 de gener de 2012, a les 21:59:10, Lamarque V. Souza va escriure: > > Em Thursday 05 January 2012, Albert Astals Cid escreveu: > > > El Dijous, 5 de gener de 2012, a les 21:35:18, Lamarque V. Souza va > > > > escriure: > > > > Em Thursday 05 January 2012, Albert Astals Cid escreveu: > > > > > El Dimecres, 4 de gener de 2012, a les 21:55:36, Lamarque V. > > > > > Souza va > > > > > > > > > > escriure: > > > > > > Em Wednesday 04 January 2012, Albert Astals Cid escreveu: > > > > > > > El Dimecres, 4 de gener de 2012, a les 23:40:26, David > > > > > > > Faure va > > > > > > > > escriure: > > > > > > > > On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote: > > > > > > > > > El Dimecres, 4 de gener de 2012, a les 01:53:13, > > > > > > > > > Christoph Feck > > > > > > > > > va > > > > > > > > > > > > > > escriure: > > > > > > > > > > On Wednesday 04 January 2012 00:28:11 Albert Astals Cid > > wrote: > > > > > > > > > > > My little kded daemon that listens to > > > > > > > > > > > XF86XK_TouchpadToggle and > > > > > > > > > > > enables disables the touchpad > > > > > > > > > > > accordingly has > > > > > > > > > > > been moved > > > > > > > > > > > to > > > > > > > > > > > kdereview. > > > > > > > > > > > > > > > > > > > > > > My plan is moving it to extragear, not > > > > > > > > > > > really > > > > > > > > > > > sure if > > > > > > > > > > > -base or > > > > > > > > > > > -utils. > > > > > > > > > > > > > > > > > > > > > > The code doesn't have a kcm or any kind > > > > > > > > > > > of > > > > > > > > > > > configuration > > > > > > > > > > > since > > > > > > > > > > > it > > > > > > > > > > > is designed to "just work". > > > > > > > > > > > > > > > > > > > > > > I'd appreciate any review or suggestion > > > > > > > > > > > over it. > > > > > > > > > > > > > > > > > > > > I cannot test it because I have no touchpad, > > > > > > > > > > but if > > > > > > > > > > it is > > > > > > > > > > supposed > > > > > > > > > > to > > > > > > > > > > "just work" without any UI, I suggest to > > > > > > > > > > just add it > > > > > > > > > > to > > > > > > > > > > "khotkeys" > > > > > > > > > > or > > > > > > > > > > "kaccel" daemon (whichever of them is used > > > > > > > > > > for > > > > > > > > > > global > > > > > > > > > > shortcuts), so that we do not filter global > > > > > > > > > > X11 > > > > > > > > > > keyboard > > > > > > > > > > events twice. > > > > > > > > > > > > > > > > > > I don't really see any point in doing that, > > > > > > > > > nothing can > > > > > > > > > be > > > > > > > > > shared > > > > > > > > > between > > > > > > > > > them and the existing ktouchpadenabler so > > > > > > > > > instead of one > > > > > > > > > simple > > > > > > > > > codebase (166 lines with 20 of headers) you end > > > > > > > > > up > > > > > > > > > adding more > > > > > > > > > complex
Re: Review Request: Port shutdown dialog to QML
Em Tuesday 17 January 2012, Alexander Neundorf escreveu:
> On Friday 06 January 2012, Alexander Neundorf wrote:
> > On Friday 06 January 2012, Lamarque V. Souza wrote:
> > > Em Thursday 05 January 2012, Alexander Neundorf escreveu:
> > > > On Thursday 05 January 2012, Lamarque V. Souza wrote:
> > > > > Em Wednesday 04 January 2012, Alexander Neundorf escreveu:
> > > > > > On Wednesday 04 January 2012, Lamarque Vieira Souza wrote:
> > > > > > > > On Jan. 3, 2012, 9:38 p.m., Albert Astals Cid wrote:
> > > > > > > > > ksmserver/CMakeLists.txt, line 57
> > > > > > > > > <http://git.reviewboard.kde.org/r/103621/diff/1/?file=45363
> > > > > > > > > #f il e4 53 63 li ne57>
> > > > > > > > >
> > > > > > > > > no variable for kdeclarative?
> > > > > > > >
> > > > > > > > Lamarque Vieira Souza wrote:
> > > > > > > > There is one in shutdowndlg.cpp, in KSMShutdownDlg's
> > > > > > > > constructor.
> > > > > > > >
> > > > > > > > Albert Astals Cid wrote:
> > > > > > > > I mean cmake variable like ${SOMETHING_SOMETHING}
> > > > > > >
> > > > > > > I do not think so. All CMakeLists.txt throughout kde-workspace,
> > > > > > > kde-runtime and plasma-mobile add the library name directly.
> > > > > >
> > > > > > libkdeclarative is from kdelibs/experimental/, right ?
> > > > >
> > > > > Yes.
> > > > >
> > > > > > So, it is not from within the same project.
> > > > > > And I didn't find a place where libkdeclarative would install a
> > > > > > KDeclarativeConfig.cmake file. Did I miss this somewhere ?
> > > > > >
> > > > > > If not, is there a FindKDeclarative.cmake somewhere ?
> > > > > >
> > > > > > If not, this is seriously messed up.
> > > > > >
> > > > > > It would mean that simply using "kdeclarative" means that cmake
> > > > > > interprets this as name of a library and simply adds
> > > > > > -lkdeclarative to the command line, without checking whether it
> > > > > > actually exists nor in which directory.
> > > > >
> > > > > I guest that is indeed what happens now.
> > > > >
> > > > > > So, is there a FindKDeclarative.cmake or a
> > > > > > KDeclarativeConfig.cmake file somewhere ?
> > > > >
> > > > > locate /*Declarative*.cmake returned nothing here, so there is
> > > > > none
> >
> > in
> >
> > > > > my notebook.
> > > >
> > > > So, quick solution: write a simply FindKDeclarative.cmake file
> > > > (mostly find_library(), find_path() and a
> > > > find_package_handle_standard_args() call) and use this (but don't
> > > > install it).
> > > >
> > > > Good solution: kdeclarative should install a KDeclarativeConfig.cmake
> > > > file, so it will be found automatically. But this has to be done
> > > > carefully.
> > >
> > > I think the person to talk about this is Marco Martin.
> >
> > Still, if you are a user of kdeclarative, you have an interest in having
> > a FindKDeclarative.cmake file.
> > Have a look at some of the simpler find-files, e.g. FindJPEG.cmake coming
> > with cmake, and write a FindKDeclarative.cmake file similar to it.
> > This won't take you long.
>
> Any progress ?
No, I am too busy with other implemenations in Plasma Active and I am
going to be even busier until next month (at least) :-/ If nobody takes this
task it will be postponed indefinitely. All my work in Plasma NM is already
postponed too :-/
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: hard-dep for Qt 4.8
Em Thursday 19 January 2012, Martin Gräßlin escreveu: > On Wednesday 18 January 2012 12:53:25 Dario Freddi wrote: > > Let's try to move the issue another way > > round: can we think of a way in which we can safely make master depend > > on new stuff without the risk of hurting these categories? > > Yes of course. First of all we have to think whether we introduce problems > at all. Let's consider translators: they currently work on the branch > anyway, so no problem. I hope that they don't waste their time by > following master. So whether a Qt 4.8 dependency matters is a question for > the time around the string freeze. > > The next question is whether translators and designers should waste their > time on compiling master or if there are better ways to test master. What > comes to my mind is for example Project Neon for all Debian based systems > installing current master snapshots in a separate directory. I as a > developer used it more than once to actual do testing. Another option > would be to use susestudio to build a always up to date live cd. I did not > find something but this is probably a good idea to create. > > Last but not least there is the question who could not install Qt 4.8 right > now. So let's see: > * Fedora: Qt 4.8 in last release > * Debian: package in experimental > * openSUSE: > http://download.opensuse.org/repositories/KDE:/Qt48/openSUSE_Factory/ > * Arch: seems to be included > * Kubuntu: https://launchpad.net/~kubuntu-ppa/+archive/experimental Strangely that Gentoo does not include an ebuild (package) for Qt 4.8. Anyone here uses Slackware and can tell us if it includes Qt 4.8? Actually, I am in favor of making Qt 4.8 required. I am just wondering if there are other distributions late on providing up to date Qt packages. > So personally I don't see a problem here with requiring Qt 4.8. It is not > difficult to get those packages (please don't argument now that you still > use Kubuntu 10.04 and for that the package does not exist. Wanting to work > on the lastest stack requires the latest stack). > > Cheers > Martin -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: hard-dep for Qt 4.8
Em Thursday 19 January 2012, Giorgos Tsiapaliwkas escreveu: > On 19 January 2012 13:28, Lamarque V. Souza wrote: > > Strangely that Gentoo does not include an ebuild (package) for Qt 4.8. > > No,it does. You just have to add the qting-edge overlay. > > http://gitorious.org/gentoo-qt/qting-edge/trees/master/x11-libs/qt-gui I am wondering if the kde overlay already exists why bother to create another overlay just for Qt? Not that Qt-only apps do not exist but this overlay thing looks too fragmented sometimes. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: Port shutdown dialog to QML
Em Friday 02 March 2012, Laszlo Papp escreveu: > > On Feb. 6, 2012, 9:38 p.m., Alexander Neundorf wrote: > > > Good from my POV (cmake stuff). > > > > Christoph Feck wrote: > > UI-wise looks also fine. Was there anything else we needed to do? If > > not, merge to master. Thanks, you rock! > > Alex, we need this FindKdeclarative.cmake in kdelibs, and not in this > repository since it is used by almost every single KDE Mobile Applications > in theory (one common use case is the localization)... Are you fine with > this "quick" solution, if I push it against KDE/4.8 ? I do not personally > have time for learning this *Config.cmake, and we would not like to hard > code "kdeclarative" into the target_link_libraries either. If someone felt > like volunteering with a proper config file, I would be happy. :-) I am working on creating the *Config.cmake configuration. I send it to reviewboard when it's ready. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Boudewijn Rempt escreveu: > On Wednesday 14 March 2012 Mar, Daniel Nicoletti wrote: > > > No. There should be color management by default in KDE, that's really > > > > > > important; and there should be only one solution by default. We > > > shouldn't let distributions, or even worse, users decide which > > > solution they use. That way madness lies. KDE's Color management > > > solution shouldn't be in extragear. > > > > > > As to which one is selected, there are a couple of ways to decide. > > > > > > The first is, first come, first go. Kolormanager has been in > > > development for quite some time now, and colord is an upstart, > > > gnome-derived technology. Integration of colord in kde was only > > > started very recently. Everyone is free to start a competing project, > > > even inside KDE, but to make that project block a pre-existing project > > > isn't the way to go. > > > > I'm not talking about blocking pre-existing projects, I'm really looking > > forward a solution where the two could live. > > Well, I am really not looking forward to that situation. Sometimes having a > choice is a bad thing. Sometimes starting a new project instead of helping > out an existing project is not the right thing to do. I agree. > > Sure we don't want users/distributions to > > decide but they do. > > > > > The second way to decide would be on technical merits. I'm not going to > > > go into that discussion; I've seen too many tiresome discussions > > > already, and I don't feel really competent anyway. > > > > > > For me as an application developer, life sucks anyway, since I have to > > > support Linux, Windows and OSX, so for the time being, the application > > > will offer its own way to select profiles, in addition to using the > > > X11 display atom that both colord and kolormanager support. (And I > > > don't want to think about printing anyway.) > > > > Well if we go into the merits discussion I really think we will get > > nowhere, as we didn't sort this first we won't sort this out now, KDE > > and GNOME primary goals is Linux, so I really don't think supporting > > platforms where they already have good solutions for this is a way to > > go. > > No, Gnome's primary goal is Gnome, while KDE offers a framework for > building applications on many platforms next as well as desktop > environment. My own desktop environment is KDE's plasma, but my goal for > Krita is to have it run everywhere, not just on the plasma desktop. > > In fact, until Gnome 3 and Unity drove them away, most of my users were on > Gnome... And that was fine, because colord and oyranos both set the > relevant X11 atom, so Krita is fine, as long as I explicitly don't care > about scanners and printing. > > > So how do we go into the merit discussion without creating yet another > > flame war? > > I don't know. I don't know of a extensive comparison between colord and > oyranos. And I'm not sure it's possible anymore to find anyone who can do > that competently, honestly and impartially. Personally, what I think is really important is a community (not ony one person) commited to maintain the software. We already have problems with KDE software that lost the maintainer or nobody is willing to develop it anymore, those software are fated to disappear when we move to Qt 5. > Realistically speaking, we'll have colord on Linux as the "standard" > whether we want it or not, because it's in Fedora, and whatever Redhat > puts in Fedora will be the "standard" for Linux. Of course other > distributions will package it, because they will want to package gnome. > Even if we had been faster to the finish line and had had kolor-manager > ready for KDE 4.6 or 4.7, no way colord would not have replaced our own > work. Yes, I think oyranos needs more support from distributions or at least be easier to install. Of course, by the features oyranos includes there must be scenarios where colord does not help. The fact that colord is going to be the standard also does not mean we should drop oyranos. As long as oyranos team maintain the software and the KDE support in it we are ok. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Kai-Uwe Behrmann escreveu: > Am 14.03.12, 06:01 -0700 schrieb Daniel Nicoletti: > >>> I'm actually targeting KDE SC 4.9 as gnome-color-manager is very > >>> mature and I am pretty much just rewriting it with Qt/KDE libs. > >> > >> > >> OpenICC colour experts have then a different view of maturity. > >> > >> > >>> > >> > >> 1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colo > >> rd-kde/ > >> That including your later blog post shows a sub feature set of what is > >> implemented in KolorManager / Oyranos. > > > > It's totally clear from my message that this is a work in progress thing, > > if you want to demerit my work by saying yours is better this shouldn't > > be the kind of thing to discuss in kde-core-devel. Please let's try to > > not offend each others work. I do not read a demerit of your work the words above. Unless you are talking about something Kai-Uwe Behrmann wrote outside this mailling list I think we should not be that agressive in a response. > I welcome anyone, who works on Linux CM in a open minded way, including > you. > > But you used GCM as a reference for your own project and surely know > the controversial issues around colord. My answere was in response to the > later. And you should also help make things calm, ok? > > About your opinion on maturity I'm talking as a developer which sees > > colord as technology and still I'm really not comparing that to yours. That is partially wrong. A KDE developer is already working on the project that your project is meant to replace, you must really talk about why you want that in technical terms. Kai-Uwe is right about your work is controversional by nature and also because you do not even consulted the KDE developer that is already working on color management in KDE. That is at least impolite in my oppinion. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Sune Vuorela escreveu: > On 2012-03-14, Boudewijn Rempt wrote: > > It's easy enough to package -- the opensuse packages I use work perfectly > > fine, so I cannot imagine that there are any real and relevant problems > > for other distributions. > > Sure it can be done. but it is just useless churn if it doesn't really > provide anything that matters to the end user that colord doesn't. You are talking as if colord is the default standard and well used in KDE and then out of a suden comes oyranoes trying to replace it. Colord is not wide used in KDE and since oyranos includes a wider feature set I guess it is more usefull for a wider range of users. As said in other e-mails colord is required in Gnome3, so why not add oyranos to kdegraphics since other KDE software already work with it? > I could package oyranos and the weird things it requires. but in the > same time I_could probably fix 20 small annoyances for all users and > package the new nice nepomuk ioslaves. What is the best use of my time? You devide what is the best use of your time. I still commit patches to Kopete from time to time even though I know it is going to fade away once we move to Qt 5 (Kopete still uses Qt3Support in several places). -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Sune Vuorela escreveu: > On 2012-03-14, Lamarque V. Souza wrote: > > You are talking as if colord is the default standard and well used in > > > > KDE and then out of a suden comes oyranoes trying to replace it. Colord > > is not wide used in KDE and since oyranos includes a wider feature set I > > guess it is > > No. colord seems to be the default standard for linux. unless we have a > good reason, I don't see why we should go for anything else. I should stop working in Plasma NM then since for distributions that ships Gnome as default desktop nm-applet is the standard. If colord has a small dependency set and Dantii created the kcm is a couple of weeks, why not add support to colord in kolor-manager and add oyranos to kdegraphics. You already talked about that to Kai-Uwe and he ageed with that. I usually in favor of the most versatile project, that is why I started to use KDE in the first place. Oyranos seems more versatile than colord, although I am also not an expert in color management. > > more usefull for a wider range of users. As said in other e-mails colord > > is required in Gnome3, so why not add oyranos to kdegraphics since other > > KDE software already work with it? > > erm. kolor-manager is currently the only tool working with oyranos as I > understood it. so we should add it because it is already there? Krita too as says the other guy in the list. We do not know who is using oyranos, if oyranos is importnat to big part of KDE users then I am in favor of adding it to kdegraphics and since there is willingness to add support to colord in kolor-manager then why not? -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Thomas Zander escreveu: > On Wednesday 14 March 2012 16.59.55 Lamarque V. Souza wrote: > > Colord is not wide used in KDE and since oyranos includes a wider feature > > set I guess it is more usefull for a wider range of users. > > This assumption seems to not be supported by the documentation. The > specific set of user-groups also speaks against this assumption. Which documentation and which user-groups? > > As said in > > other e-mails colord is required in Gnome3, so why not add oyranos to > > kdegraphics since other KDE software already work with it? > > I'm not following this sentence; becaues gnome uses X, kde should not use > X. If thats what you are saying, I want to say I disagree. > > Could you explain what you mean with the > "since other KDE already works with it" > part? > AFAIK there is no KDE software that would function better with oyranos than > with colord. Which means there is no clear advantage on that basis. Am I > missing some piece of software? I meant that there are other KDE software that works with oyranos. I did not mean they have it as dependency. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Thomas Zander escreveu: > On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote: > > > Hi! > > > Colord - just to mention that - is also not a GNOME project, it's a > > > FreeDesktop project. (Doesn't mean it's "standard", but does mean that > > > it's not GNOME) > > > > Well, no, having something on freedesktop.org doesn't mean it's not a > > gnome project; > > Little semantic confusion here :) > He said it *IS* a freedesktop project. Which means it is not a gnome > project, which seems to me to be true. That controversional. Do you know how freedesktop is working in the last years? If you did then you would not say that. > > it is a gnome project, and it's widening its scope. The > > reason it's used at all is that is is used inside gnome. > > Projects should be judged on merit, irregardless of who pushes it. > If gnome is using it and that makes it grow acceptance, thats a good thing > in my book. Why; *because* acceptance is growing. I don't care if its > gnome or any other player pushing it. > > That said; Cups also depends on colord. And IMO that has a bigger impact > than the gnome components that pull it in. I use cups here and no colord. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Sune Vuorela escreveu: > On 2012-03-14, Lamarque V. Souza wrote: > > I should stop working in Plasma NM then since for distributions that > > > > ships Gnome as default desktop nm-applet is the standard. > > erm. you are aware that colord better can be compared to NetworkManager > than to Plasma NM ? I am not comparing colord to Plasma NM, I am comparing oyranos to Plasma NM. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Alexander Neundorf escreveu:
> On Wednesday 14 March 2012, Lamarque V. Souza wrote:
> > Em Wednesday 14 March 2012, Thomas Zander escreveu:
> > > On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
> > > > > Hi!
> > > > > Colord - just to mention that - is also not a GNOME project, it's a
> > > > > FreeDesktop project. (Doesn't mean it's "standard", but does mean
> > > > > that it's not GNOME)
> > > >
> > > > Well, no, having something on freedesktop.org doesn't mean it's not a
> > > > gnome project;
> > >
> > > Little semantic confusion here :)
> > > He said it *IS* a freedesktop project. Which means it is not a gnome
> > > project, which seems to me to be true.
> >
> > That controversional. Do you know how freedesktop is working in the last
> >
> > years? If you did then you would not say that.
>
> I agree.
> Stuff which is needed for Gnome is put on xdg, and because it doesn't link
> to libgnome or something like this they say it is independent from gnome.
It was not that I was refering to.
> Just the same way as all the other stuff coming from RedHat for the desktop
> is independent from Gnome ;-)
What happens if the stuff does not please RedHat?
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Daniel Nicoletti escreveu: > 2012/3/14 Kai-Uwe Behrmann : > > CUPS is a cross platform solution. It works with colour management on osX > > fine. IMO that recommendation on Debian has to do with colord in Gnome > > and that colord needs compiled in support inside CUPS. No more no less. > > This sentence is hard to read but Recommends in Debian means recommends, > it is not required to run, so no there is no linking, no link by CUPS to > colord and no link by colord to CUPS. All DBus magic. Debian applies a patch to add colord support to cups, that is what Kai- Uwe is talking about. Cups itself does not require colord, so it cannot be used in favor of colord. > >> Notice that colord allows components to use it without linking it in at > >> startup using the dbus interface for instance. > > > > That is non relevant to the fact, that CUPS vendor colour management > > works since years and without colord. > > It is indeed relevant because now we have a central place to configure it. As long as you patch cups and all other applications to use. Oyranos is also a central place to do color management as far as I know, this argument is valid for both. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Daniel Nicoletti escreveu: > >As long as you patch cups and all other applications to use. Oyranos is > >also a central place > > > > to do color management as far as I know, this argument is valid for both. > > It is valid once it's written, once there is a line of code doing it's job. > Or we can just play politics. You say you want the best one, have you > tried them both? So you are saying your original argument is not valid anymore? I said I wanted the most versatile, which means one that satisfies my needs *and* somebody else's needs. You are completey ignoring the fact that there are people using oyranos too, it has been developed for years, do you think it's fair to drop all that work now? I am in favor of adding support to both colord and oyranos in kdegraphics. One way of doing that is adding support to colord to kolor-manager, which talks has already started. And no, I have not tested either of them and how computer color management is supposed to work for a daltonian (like me)? Even if I had tested by what everybody already said here, nobody is an expert in color managament to judge the merits of either project, so let's add support to both. As I wrote before, as long as the project has a community to maintain it, I do not see why not use it. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Daniel Nicoletti escreveu: > > So you are saying your original argument is not valid anymore? > > Where is the Oyranos CUPS patch? All I see is a planning since as > far as I can tell he didn't decide the best way to do it, OTOH we have > something that already works for a bunch of people. Oyranos were against the patch, Kai-Uwe already said that and explained why. The fact that there is patch does not mean it is the correct way to do things. The fact that it is not integrated upstream can also mean cups developers to do not like it. Do you know what they think about the patch? > > I said I wanted the most versatile, which means one that satisfies my > > needs *and* somebody else's needs. You are completey ignoring the fact > > that there are people using oyranos too, it has been developed for > > years, do you think it's fair to drop all that work now? I am in favor > > of adding support to both colord and oyranos in kdegraphics. One way of > > doing that is adding support to colord to kolor-manager, which talks has > > already started. > > Tell me, who is using besides Cine Paint? I was talking about people using oyranos, not programs. I think people matters more than programs (that is what the rebranding of "KDE" to mean the community was all about). I do not how many programs use oyranos, I am very new to this color management world. I know Krita can use it, then so far two programs. Not counting compiz because most KDE users (people) use kwin instead. I really think oyranos should integrate better with cups and kwin, which I think are the most used programs that can benefit from it. > I never said a word on dropping Oyranos development, but I do believe from > a technological point of view it hasn't succeed in all these years. We now > have telepathy. Who will be willing to keep kopete which has far more years > than even Oyranos in favor of a nicer user experience? Or even dolphin why > stop using konqueror file management when a file driven experience has come > in place? What do you think is going to happen if Oyranos lose support from all major desktops? That is a dead end for any user-oriented opensource project. I still commit patches to Kopete, but I already know and said that its fate is to disappear. OBS: I am going to use Kopete until there is no metacontact implementation in telepathy-kde :-P or until I can keep it working. By the way, telepathy-kde was meant to be a KDE 4 project. Before KDE 4.0.0 was released most Kopete developers tried to implement a KDE telepathy client and failed. I do not know if that was the cause of Kopete developers lose interest in Kopete but that for sure made Kopete 4.0.0 sub-par to 3.5.10 feature wise speaking. That was why I started to commit patches to Kopete, I wanted to implement the missing features from 3.5.10, that was in 2009. I do not use file managers, so I did not try to make Konqueror still work :-D but I am in charge of Plasma NM, which has less features than nm-applet. If I followed your examples I would be using MacOS or even Windows by now instead of helping develop KDE sofware. > > And no, I have not tested either of them and how computer color > > management is supposed to work for a daltonian (like me)? Even if I had > > tested by what everybody already said here, nobody is an expert in color > > managament to judge the merits of either project, so let's add support > > to both. As I wrote before, as long as the project has a community to > > maintain it, I do not see why not use it. > > Surely even daltonians would like to see on their computers colors more > close to reality, I don't see why this have to be different if you are > daltonian or not. I don't believe anyone needs to be a color expert to > tell which is best, we are developers we know development if you need to > maintain a piece of software what matters is your development skills. I > can't maintain a complex piece of software few people understand. You tell me, I do not know how to test color management. How did you test colord for instance? You are saying colord is best based on your personal use of color management (and the number of colord users, which is mandatory for Gnome3 by what I know). Have you ever considered that your personal use is not what other users of color management software need? I am maintaining a complex piece of software few people (fully) understand. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Matthias Klumpp escreveu: > Speaking of project activity: > => https://www.ohloh.net/p/colord > => https://www.ohloh.net/p/oyranos > Of course there metrics are unfair to both projects (metrics always > are), but they might provide some information about activity, > contributors and codebase. Ok > (although I don't think we should pay too > much attention on these) ^^^ ??? Have you ever used google trends with kde and gnome words? We should stop using KDE software. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Wednesday 14 March 2012, Daniel Nicoletti escreveu: > >Oyranos were against the patch, Kai-Uwe already said that and explained > >why. The fact that there is patch does not mean it is the correct way to > >do things. The fact that it is not integrated upstream can also mean cups > >developers to do not like it. Do you know what they think about the > >patch? > > If you follow the news you'd now how CUPS is driven, Apple doesn't like > Linux, they are currently removing all non-OSX filters, which is why a > fork idea is surrounding us. So yes, they won't accept patches for Linux > only things. I did not know about that problem with Apple. That's going to be a big problem for Linux users. > >> > I said I wanted the most versatile, which means one that satisfies my > >> > needs *and* somebody else's needs. You are completey ignoring the fact > >> > that there are people using oyranos too, it has been developed for > >> > years, do you think it's fair to drop all that work now? I am in favor > >> > of adding support to both colord and oyranos in kdegraphics. One way > >> > of doing that is adding support to colord to kolor-manager, which > >> > talks has already started. > >> > >> Tell me, who is using besides Cine Paint? > > > > > >I was talking about people using oyranos, not programs. I think people > >matters more than programs (that is what the rebranding of "KDE" to mean > >the community was all about). I do not how many programs use oyranos, I > >am very new to this color management world. I know Krita can use it, then > >so far two programs. Not counting compiz because most KDE users (people) > >use kwin instead. I really think oyranos should integrate better with > >cups and kwin, which I think are the most used programs that can benefit > >from it. > > Well PackageKit, upower, NM all integrates well in KDE all of them are FDO > and you even help one of these with a frontend, I myself help PackageKit > and now colord since Dario is already doing awesome work with upower. > (except from NM, colord, packagekit and upower comes from Richard). Like I also help with Wicd support in KDE, Kopete, and other areas of interests for KDE users. I do not use Wicd, but I help KDE users of Wicd even before I was the Network Management maintainer. By the way, I am not driven by FDO interests. We are using upower/udisks because there is no other choice in Linux, hal is unmaintained as you probably know. That is why I think we should have a community to maintain the software we depend upon. > >You tell me, I do not know how to test color management. How did you test > >colord for instance? > > First you need to build the software or use the packaged version, see how > things work, now I started a replacement for system-config-printer because > it has authentication problems and is written in python. when I go to > Oyranos I found a bunch of tech I don't like, not just I don't like but > many developers don't, so who will maintain those technologies if few > people like/use it? That's too personal oppinion and you sound like nobody likes oyranos. > sytem-config-printer is better than print-manager but no one fixed the > authentication bug till today, and will likely never do, print-manager in > a few months got real acceptance. > > I don't want to kill Oyranos but I do think the choices based on wrong use > cases might lead to an end, a good project done with a wrong design won't > succeed. Take smart for example, PackageKit in a few years was able to do > what they tried for many years, and stop saying that Gnome or Red Hat is > pushing it, you can have Gnome without it, FDO also plays by it's own > rules, let's focus on what really matters which is the code. No user will > help you maintain a line of code, they will use what we best choose to > them. I have never used PackageKit and said nothing about it. Are you talking about PakcageKit or colord here? If it is about Gnome without colord I am not sure if that is possible, anyway, why would they patch cups to add support to colord if it is not going to be used in the desktops? Users can help with patches from time to time, that is important, and I was only a Knetworkmanager user before I started to contribute. Your statement is completely wrong in an opensource world. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Thursday 15 March 2012, Daniel Nicoletti escreveu: > >Like I also help with Wicd support in KDE, Kopete, and other areas of > >interests for KDE users. I do not use Wicd, but I help KDE users of Wicd > >even before I was the Network Management maintainer. By the way, I am not > >driven by FDO interests. We are using upower/udisks because there is no > >other choice in Linux, hal is unmaintained as you probably know. That is > >why I think we should have a community to maintain the software we depend > >upon. > > Right so which community you are talking about, because > Kai likes KDE, it seems that you are putting FDO/Gnome as things we should > get away, instead of actually looking at how maintainable these two > things are and yet share code which is really important. The community that develops and maintains the software in question. In the sentence above it was hal's community, in this thread are the oyranos and colord's communities. > >> First you need to build the software or use the packaged version, see > >> how things work, now I started a replacement for system-config-printer > >> because it has authentication problems and is written in python. when I > >> go to Oyranos I found a bunch of tech I don't like, not just I don't > >> like but many developers don't, so who will maintain those technologies > >> if few people like/use it? > > > > > >That's too personal oppinion and you sound like nobody likes oyranos. > > It's a personal opinion indeed but this doesn't mean nobody likes Oyranos, > it simply means that looking at the code there won't be much devs willing > to maintain that. The deps speak for themselves. Maybe, that is something that needs to be discussed with oyranos' community. By what I read in this thread elektra is still maintained and is optional, not sure about fltk. > >> I don't want to kill Oyranos but I do think the choices based on wrong > >> use cases might lead to an end, a good project done with a wrong design > >> won't succeed. Take smart for example, PackageKit in a few years was > >> able to do what they tried for many years, and stop saying that Gnome > >> or Red Hat is pushing it, you can have Gnome without it, FDO also plays > >> by it's own rules, let's focus on what really matters which is the > >> code. No user will help you maintain a line of code, they will use what > >> we best choose to them. > > > > > >If it is about Gnome without colord I am not sure if that is possible, > >anyway, why would they patch cups to add support to colord if it is not > >going to be used in the desktops? > > Gnome works pretty much the same way as KDE we have modules, so the do, > you can just remove/disable and Gnome will run without it, but why remove > a cool feature? It's non sense, it's obvious that every distro would push > because they want the missing feature, if Oyranos was there first maybe > colord didn't had to exist. Maybe, maybe not. > >I have never used PackageKit and said nothing about it. Are you talking > >about PakcageKit or colord here? Users can help with patches from time to > >time, that is important, and I was only a Knetworkmanager user before I > >started to contribute. Your statement is completely wrong in an > >opensource world. > > You don't get it, I'm giving an example of how good projects dies because > from a technical point of view they become unmaintainable. > Sure, pretty much everyone is first an user then a developer but this > doesn't mean you can expect from users of a software to maintain that, > otherwise most of these projects wouldn't go into an end. You mean the oppositte in the last sentense, right? I still disagree, users can do a lot to help maintaining a software, that's called community. For extremelly technical parts there will be less users able to help, but still if you are not a user of the software why would you bother to help maintaining it? Sure the most experient users take the technical decisions, that is what we are do here in k-c-d for KDE for example. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
Em Thursday 15 March 2012, Thomas Zander escreveu: > On Wednesday 14 March 2012 20.31.30 Lamarque V. Souza wrote: > > I said I wanted the most versatile, which means one that > > satisfies > > > > my needs and somebody else's needs. > > The requirement for 'most versatile' doesn't follow in that sentence. > You are making a logic error, or at least taking the biggest car and > hoping it will get you there fastest. No, I choose a car that carries my and my family's luggage in a reasonable speed. Most of the time I can drive alone, but it is still usefull to have a reasonable sized trunk to carry something for me or someone of my family. Or do you think I should always buy a moto and never a car just because I prefer driving fast? > If you want to satisfy your needs, try it for a while and see if it works. > > > You are completey ignoring the fact > > that there are people using oyranos too, it has been developed for years, > > do you think it's fair to drop all that work now? > > Hmm, you pose lots of questions that are completely off-topic here. > And jumping to weird conclusions about dropping work is just unhelpful. I think dropping work must be carefully decided, if nobody uses the code so drop it. I am ready to drop Kopete once telepathy-kde fullfills my needs and I have already dropped features from Plasma NM that nobody used. If there are people using oyranos I think that must be taking into account. > > I am in favor of adding > > support to both colord and oyranos in kdegraphics. > > I strongly disagree with that. > KDE is not a support group where lonely software goes to get more > recognition. This community works based on choosing solutions that > work best. Your suggestion to not choose is therefore not helpful. That was not my suggestion, somebody else suggested that in #kde-devel and I agree because I think that fullfills the needs of most KDE users. > > And no, I have not tested either of them > > Then I'm sorry to say, your opinion is just that, one uninformed opinion. Like everybody else's opinion in this thread. > At minimum read this; > http://www.freedesktop.org/software/colord/intro.html > And tell us if there is any reason to say that this product does *not* > satisfy your needs (when the KDE stuff is finished) I do not have a need for color management nowadays, which does not mean I cannot help fullfill somebody else's needs. I do not always do things for myself only. > Basic design of system color management is that each input (scanner > etc) and each output (monitor, printer) has to have assigned a > personal color profile. > Applications that are capable of doing color management have to have > access to those profiles so they can use them in combination with a > library like lcms to do the right thing. How that is different from oyranos? > Colord embraces that concept and provides all we need. > > Oyranos makes things ... complicated. See; >http://www.oyranos.org/doc_alpha/index.html By reading the front page of both web pages I cannot judge which one is more complicated. I do not have time to read all pages in both projects now too. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Need suggestion on how to fix the common crash in plasma-desktop (kdelibs related)
Hi,
There is a crash in WeatherEngine (kde-workspace) triggered by the fact
that Plasma::DataEngineManager::self() (kdelib) is invalid when
plasma-{desktop,device} are exiting. WeatherEngine::~WeatherEngine() calls
WeatherEngine::unloadIons(), which tries to use the invalid
Plasma::DataEngineManager::self(). The crash only happens if there is
something using WeatherEngine when plasma-{desktop,device} exit, of course.
There are several bug report about this crash:
https://bugs.kde.org/show_bug.cgi?id=223622
https://bugs.kde.org/show_bug.cgi?id=241509
https://bugs.kde.org/show_bug.cgi?id=261610
And counting. The reports were closed as upstrem but think we can
prevent the crash by adding a method to Plasma::DataEngineManager to check if
it is still valid. Using "if (Plasma::DataEngineManager::self()) {}" also
triggers the crash because of the way Plasma::DataEngineManager::self() is
implemented.
What do you think about adding a Plasma::DataEngineManager::valid()
method?
OBS: That crash is in WeatherEngine since it entered kde-workspace in 2009.
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: Need suggestion on how to fix the common crash in plasma-desktop (kdelibs related)
Em Tuesday 20 March 2012, Thomas Lübking escreveu:
> Tried to connect to QCoreApplication::aboutToQuit()?
It is already done but that does not cover the case where WeatherEngine
is unloaded without plasma-{desktop,device} exiting. The Ions must be unloaded
in that case or we will have a memory leak.
> Am 21.03.2012, 02:31 Uhr, schrieb Lamarque V. Souza :
> > Hi,
> >
> > There is a crash in WeatherEngine (kde-workspace) triggered by the fact
> >
> > that Plasma::DataEngineManager::self() (kdelib) is invalid when
> > plasma-{desktop,device} are exiting. WeatherEngine::~WeatherEngine()
> > calls
> > WeatherEngine::unloadIons(), which tries to use the invalid
> > Plasma::DataEngineManager::self(). The crash only happens if there is
> > something using WeatherEngine when plasma-{desktop,device} exit, of
> > course.
> > There are several bug report about this crash:
> >
> > https://bugs.kde.org/show_bug.cgi?id=223622
> > https://bugs.kde.org/show_bug.cgi?id=241509
> > https://bugs.kde.org/show_bug.cgi?id=261610
> >
> > And counting. The reports were closed as upstrem but think we can
> >
> > prevent the crash by adding a method to Plasma::DataEngineManager to
> > check if
> > it is still valid. Using "if (Plasma::DataEngineManager::self()) {}" also
> > triggers the crash because of the way Plasma::DataEngineManager::self()
> > is
> > implemented.
> >
> > What do you think about adding a Plasma::DataEngineManager::valid()
> >
> > method?
> >
> >
> > OBS: That crash is in WeatherEngine since it entered kde-workspace in
> > 2009.
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: Need suggestion on how to fix the common crash in plasma-desktop (kdelibs related)
Em Wednesday 21 March 2012, Thomas Lübking escreveu: > hook on QObject::destroyed() for the dataenginemanager (and flag > yourself "dontTry")? Didn't try it Unfortunately it also did not work :( WeatherEngine did not receive the signal, at least not before the crash. Thanks anyway. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Need suggestion on how to fix the common crash in plasma-desktop (kdelibs related)
Em Wednesday 21 March 2012, David Faure escreveu:
> On Tuesday 20 March 2012 22:31:57 Lamarque V. Souza wrote:
> > WeatherEngine::~WeatherEngine() calls
> > WeatherEngine::unloadIons(), which tries to use the invalid
> > Plasma::DataEngineManager::self().
>
> Since DataEngineManager uses K_GLOBAL_STATIC internally, just use the
> isDestroyed() method to know if it has already been destroyed, before
> calling self().
I thought about doing that, but I would like to prevent an overhead
that
is needed only when plasma-{desktop,device} are exiting.
> More precisely, either add a isDestroyed method to the public class, which
> calls the one in the K_GLOBAL_STATIC, or let self() return 0 when
> privateDataEngineManagerSelf.isDestroyed().
The Plasma::DataEngineManager::valid() I suggested is exactly returning
the negation of privateDataEngineManagerSelf.isDestroyed(). I just wanted to
know if there were other options. Ok, let's add a
Plasma::DataEngineManager::isDestroyed(). Can I backport that to 4.8? Wrong
question, I will have to it to 4.8 so that somebody forward ports it to
master, duh.
> On a more philosophical note: this is exactly why "intelligent destructors"
> are to be avoided at all costs. All this wouldn't happen if the
> WeatherEngine destructor didn't call methods that do stuff.
At least stuff with other object's pointer.
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: Need suggestion on how to fix the common crash in plasma-desktop (kdelibs related)
Em Wednesday 21 March 2012, Aaron J. Seigo escreveu:
> On Tuesday, March 20, 2012 22:31:57 Lamarque V. Souza wrote:
> > There is a crash in WeatherEngine (kde-workspace) triggered by the fact
> >
> > that Plasma::DataEngineManager::self() (kdelib) is invalid when
> > plasma-{desktop,device} are exiting. WeatherEngine::~WeatherEngine()
> > calls WeatherEngine::unloadIons(), which tries to use the invalid
> > Plasma::DataEngineManager::self(). The crash only happens if there is
>
> this happens only when the application uncleanly exits. if you notice in
> the bug reports you linked to there was a problem elsewhere (e.g. an
> xioerror, an uncaught exception, etc.) and that caused an abort of the
> process with an unclean exit which then triggers this problem. the cause
> of the crash was never the WeatherEngine itself, but rather a crash in
> WeatherEngine was triggered while the application was otherwise closing
> down due to an error elsewhere that was itself bringing down the
> application.
a simple killall plasma-device suffices to make WeatherEngine hit the
invalid Plasma::DataEngineManager::self(). I know that there is kquitapp,
which I have just checked and it avoids the crash, but not everybody uses it.
> DataEngines created by DataEngineManager *must* be released prior to
> application exit. and normally this happens except in such cases where the
> application is brought down by an abnormal situation.
I do not consider a TERM signal an abnormal situation. Could we add a
signal handler to plasma-{desktop,device} to re-route the TERM signal to the
code kquitapp triggers in plasma-{desktop,device}?
> so while you can make the changes David suggests, it will only change the
> backtraces in those bug reports but not actually solve anything in the real
> world. the aborts will still happen as a result of the underlying error.
The crash does not happen if WeatherEngine's dtor is changed to do not
use Plasma::DataEngineManager::self().
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: Need suggestion on how to fix the common crash in plasma-desktop (kdelibs related)
Em Wednesday 21 March 2012, Lamarque V. Souza escreveu:
> Em Wednesday 21 March 2012, Aaron J. Seigo escreveu:
> > On Tuesday, March 20, 2012 22:31:57 Lamarque V. Souza wrote:
> > > There is a crash in WeatherEngine (kde-workspace) triggered by the
> > > fact
> > >
> > > that Plasma::DataEngineManager::self() (kdelib) is invalid when
> > > plasma-{desktop,device} are exiting. WeatherEngine::~WeatherEngine()
> > > calls WeatherEngine::unloadIons(), which tries to use the invalid
> > > Plasma::DataEngineManager::self(). The crash only happens if there is
> >
> > this happens only when the application uncleanly exits. if you notice in
> > the bug reports you linked to there was a problem elsewhere (e.g. an
> > xioerror, an uncaught exception, etc.) and that caused an abort of the
> > process with an unclean exit which then triggers this problem. the cause
> > of the crash was never the WeatherEngine itself, but rather a crash in
> > WeatherEngine was triggered while the application was otherwise closing
> > down due to an error elsewhere that was itself bringing down the
> > application.
>
> a simple killall plasma-device suffices to make WeatherEngine hit the
> invalid Plasma::DataEngineManager::self(). I know that there is kquitapp,
> which I have just checked and it avoids the crash, but not everybody uses
> it.
>
> > DataEngines created by DataEngineManager *must* be released prior to
> > application exit. and normally this happens except in such cases where
> > the application is brought down by an abnormal situation.
>
> I do not consider a TERM signal an abnormal situation. Could we add a
> signal handler to plasma-{desktop,device} to re-route the TERM signal to
> the code kquitapp triggers in plasma-{desktop,device}?
Just to make it clear. Signal TERM (kill -15, 15 is the default signal
for the kill command) means "please, save your data and close yourself". It
does not mean "abruptly killing the process", that is signal KILL. What I am
asking for here is to support the Unix way of gently terminating a process and
only that (support only signal TERM, not all other signals). The name "kill"
for the command to send signals to process is misleading, not all signals mean
something wrong happened. Signal SIGUSR1 for instance is commonly used to tell
the process to re-read its configuration. Today we have dbus to send messages
to processes, which I guess is what kquitapp uses, but not all programs
support dbus, so I do not see why not support this Unix way of sending
messages to a process.
> > so while you can make the changes David suggests, it will only change the
> > backtraces in those bug reports but not actually solve anything in the
> > real world. the aborts will still happen as a result of the underlying
> > error.
>
> The crash does not happen if WeatherEngine's dtor is changed to do not
> use Plasma::DataEngineManager::self().
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: [REVIEW]: plasma-mobile repositories
Em Monday 26 March 2012, Albert Astals Cid escreveu: > El Divendres, 23 de març de 2012, a les 12:01:04, Aaron J. Seigo va escriure: > > hi everyone ... > > > > the repositories holding the Plasma Active code have been moved into > > kdereview as plasma-mobile and plasma-mobile-config so as to go through > > the usual 2 week review period before moving to their permanent home. > > Lamarque says plasma-mobile-config is still Work In Progress stuff. Please > move it back to some playground. Hey, I wrote "work in progress" in the sense that no Plasma Active image ships with it yet. I do not see why withdraw the review request for it. It is includes only configuration files. There is no compiled code, not even QML code, in it. > Albert > > > if there are any question or queries, input or feedback, please don't > > hesitate > > > > :) -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Review Request: fix for some typos
Em Monday 25 June 2012, Jaime escreveu: > 2012/6/23 Lamarque Vieira Souza > > >This is an automatically generated e-mail. To reply, visit: > > http://git.reviewboard.kde.org/r/105278/ > > > > On June 16th, 2012, 4:15 p.m., *Lamarque Vieira Souza* wrote: > > kdeui/actions/kaction.cpp<http://git.reviewboard.kde.org/r/105278/diff/ > > 1/?file=68027#file68027line408> (Diff > > > > revision 1) > > > > void KAction::setAuthAction(KAuth::Action *action) > > > > 408 > > > > //delete d->authAction; > > > > 408 > > > > delete d->authAction; > > > > Well, commit 3d789c9dcda0179aac40e2bcf58df06cccf84ed5 is the one that > > commented this line, but Dario did not give any reason why not delete > > the action. > > > > I think you should have asked Dario why he did this change in the first > > place, also you should not commit a patch without a "ship it" from > > another developer. > > > > Hi, I'm sorry. > > Saturday was, for me, one of those days where one should stay in bed. > Almost everything I did on Saturday was wrong :-(. Yesterday I was in > quarantine, I did not touch any computer at all. > I've been using reviewboard in the right way since I did a wrong file svn > commit long time ago, except: > * last saturday, sigh > * trivial commits of prefix ++ vs postfix ++ Well, just wait for the "ship it" next time. It can take a while to come but it will come. Dario, can you answer why did you comment line 408 of kdelibs/kdeui/actions/kaction.cpp? The one with "delete d->authAction;" in method KAction::setAuthAction(KAuth::Action *action). Does it solve any bug? > - Lamarque Vieira > > > On June 16th, 2012, 3:37 p.m., Jaime Torres Amate wrote: > > Review request for kdelibs. > > > > By Jaime Torres Amate. > > > > *Updated June 16, 2012, 3:37 p.m.* > > Description > > > > 1. Do not want to check m_startDate.isValid() twice and > > m_endDate.isValid() none. 2. why do not want to delete d->authAction if > > it is nulled after that. 3. Is really the code after the break unwanted > > code? > > 4. if ok is not initialized, sometimes while(ok) could do nothing. > > > > Testing > > > > 6 months or more with it locally. > > > > Diffs > > > >- kdecore/date/kcalendarera.cpp (0a21e37) > >- kdeui/actions/kaction.cpp (309cf82) > >- kio/kfile/kpropertiesdialog.cpp (feb0c9e) > >- sonnet/unicode/parseucd/parseucd.cpp (1c9b90e) > > > > View Diff <http://git.reviewboard.kde.org/r/105278/diff/> -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Question about the shutdown dialog's reboot list implementation
Em Friday 06 July 2012, Konstantinos Smanis escreveu: > Hi, Hi, > I am working on a patch for bug #297209 > (https://bugs.kde.org/show_bug.cgi?id=297209) and couldn't help but > notice that since the Shutdown Dialog was QMLified, the code that > shows the reboot list (when long-clicking the Reboot button) has been > moved in the QML code of the theme > (http://lxr.kde.org/source/kde/kde-workspace/ksmserver/themes/default/main. > qml#319), which means that every theme should duplicate this code. I have a > proper fix for the above mentioned bug written in C++ (generate a > proper QMenu with submenus) which applies perfectly on the 4.8 branch > (which is C++ only), so I was thinking maybe generate the menu in the > C++ part of the code and pass it on to the QML theme? Being a total > QML newbie I don't know if that's possible, plus after a quick search > I can't figure out how to implement submenus for the context menu in > QML (it uses a custom ContextMenu component). > > I wouldn't like to dig in QML just for this and I think it makes more > sense if the list was centrally generated and not in every theme. > Still, if the code should reside in the theme, I would appreciate any > pointers as to how implement submenus in the context menu. I am the one that implemented the QML shutdown menu. I moved the code that creates the reboot menu to QML to give the possibility to create different QML themes that do not necessarily need to handle all the options ksmserver implements or to show the reboot entries using any QML component available (not necessarily a menu). It's not possible to use QMenu (or other QWidgets subclasses) in QML as far as I know. I think we can implement submenus in the default theme (in QML). For a quick fix you can try passing the correct grub index to the rebootOptions context variable (this must be done in shutdowndlg.cpp) and then assign it to variable itemData["itemIndex"] in main.qml. That should make it select the correct boot option. The menu will still be linear (without submenus), we can fix that later. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Question about the shutdown dialog's reboot list implementation
Em Friday 06 July 2012, Konstantinos Smanis escreveu: > On Sat, Jul 7, 2012 at 1:02 AM, Lamarque V. Souza wrote: > > Em Friday 06 July 2012, Konstantinos Smanis escreveu: > >> Hi, > > > > Hi, > > > >> I am working on a patch for bug #297209 > >> > >> (https://bugs.kde.org/show_bug.cgi?id=297209) and couldn't help but > >> > >> notice that since the Shutdown Dialog was QMLified, the code that > >> > >> shows the reboot list (when long-clicking the Reboot button) has been > >> > >> moved in the QML code of the theme > >> > >> > >> (http://lxr.kde.org/source/kde/kde-workspace/ksmserver/themes/default/ma > >> in. > >> > >> qml#319), which means that every theme should duplicate this code. I > >> have a > >> > >> proper fix for the above mentioned bug written in C++ (generate a > >> > >> proper QMenu with submenus) which applies perfectly on the 4.8 branch > >> > >> (which is C++ only), so I was thinking maybe generate the menu in the > >> > >> C++ part of the code and pass it on to the QML theme? Being a total > >> > >> QML newbie I don't know if that's possible, plus after a quick search > >> > >> I can't figure out how to implement submenus for the context menu in > >> > >> QML (it uses a custom ContextMenu component). > >> > >> > >> > >> I wouldn't like to dig in QML just for this and I think it makes more > >> > >> sense if the list was centrally generated and not in every theme. > >> > >> Still, if the code should reside in the theme, I would appreciate any > >> > >> pointers as to how implement submenus in the context menu. > > > > I am the one that implemented the QML shutdown menu. I moved the code > > that creates the reboot menu to QML to give the possibility to create > > different QML themes that do not necessarily need to handle all the > > options ksmserver implements or to show the reboot entries using any QML > > component available (not necessarily a menu). > > > > > > > > It's not possible to use QMenu (or other QWidgets subclasses) in QML as > > far as I know. I think we can implement submenus in the default theme > > (in QML). For a quick fix you can try passing the correct grub index to > > the rebootOptions context variable (this must be done in > > shutdowndlg.cpp) and then assign it to variable itemData["itemIndex"] in > > main.qml. That should make it select the correct boot option. The menu > > will still be linear (without submenus), we can fix that later. > > > > > > > > -- > > > > Lamarque V. Souza > > > > KDE's Network Management maintainer > > > > http://planetkde.org/pt-br > > It already works fine without even touching the ksmserver stuff (my > only modifications are in kdm's parsing) but it looks quite ugly > without submenus: http://i50.tinypic.com/96bw35.png > In the screenshot above, the root menu should only contain 4 items, > the second of which should be a submenu. > > As I mentioned, I have already implemented the transformation from a > linear list to a menu with levels, but it is in C++ if that's going to > be of any help at all. > > PS: The 'nested test' submenu in the screenshot is in fact 'ne&sted > test' in the config file (for my testing purposes). I guess the > ampersand is erroneously treated as an accelerator while it shouldn't. > Needs to be fixed as well. Ok, so it's a GUI only problem now. I need to figure out how to create submenus with the custom contextmenu component or use the one from kde-runtime if it supports submenus. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: RFC: Enabling -DKDE4_BUILD_TESTS=ON by default
Em Monday 08 October 2012, Àlex Fiestas escreveu: > Anything to make developers (including myself) more unit test aware, > I'm all for it, even if it helps only a little bit. +1 -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Cleaning house: KDE Review
Em Thursday 01 November 2012, Ben Cooksley escreveu: > Hi everyone, Hi, > The following projects which are in KDE Review appear to have been > there for more than 2 weeks: > - appmenu kded module (kded-appmenu) > - KIMToy (kimtoy) Please move the two projects below to extragear: > - Qt Wrapper for ModemManager (libmm-qt) > - Qt Wrapper for NetworkManager (libnm-qt) -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Cleaning house: KDE Review
Em Thursday 01 November 2012, Christoph Feck escreveu:
> On Thursday 01 November 2012 22:19:03 Lamarque V. Souza wrote:
> > Em Thursday 01 November 2012, Ben Cooksley escreveu:
> > > Hi everyone,
> >
> > Hi,
> >
> > > The following projects which are in KDE Review appear to have
> > > been there for more than 2 weeks:
> > > - appmenu kded module (kded-appmenu)
> > > - KIMToy (kimtoy)
> >
> > Please move the two projects below to extragear:
> > > - Qt Wrapper for ModemManager (libmm-qt)
> > > - Qt Wrapper for NetworkManager (libnm-qt)
>
> extragear/base
> extragear/libs
> extragear/network
>
> ?
Good question. networkmanagement is extragear/base, I think they should
stay in the same place.
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: Cleaning house: KDE Review
networkmanagement is in extragear/base too. Em Thursday 01 November 2012, Daniel Nicoletti escreveu: > Hmm dont you think network is a better place? I think base would be the > last place Id look for > > Em 01/11/2012 19:48, "Lamarque V. Souza" escreveu: > > ** > > > > Em Thursday 01 November 2012, Christoph Feck escreveu: > > > On Thursday 01 November 2012 22:19:03 Lamarque V. Souza wrote: > > > > Em Thursday 01 November 2012, Ben Cooksley escreveu: > > > > > Hi everyone, > > > > > > > > Hi, > > > > > > > > > The following projects which are in KDE Review appear to have > > > > > > > > > > been there for more than 2 weeks: > > > > > > > > > > - appmenu kded module (kded-appmenu) > > > > > > > > > > - KIMToy (kimtoy) > > > > > > > > Please move the two projects below to extragear: > > > > > - Qt Wrapper for ModemManager (libmm-qt) > > > > > > > > > > - Qt Wrapper for NetworkManager (libnm-qt) > > > > > > extragear/base > > > > > > extragear/libs > > > > > > extragear/network > > > > > > > > > > > > ? > > > > Good question. networkmanagement is extragear/base, I think they should > > stay in the same place. > > > > > > > > -- > > > > Lamarque V. Souza > > > > KDE's Network Management maintainer > > > > http://planetkde.org/pt-br > > > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > > > > unsubscribe << -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Cleaning house: KDE Review
What kind of things should go to extragear/base then? networkmanagement is four things: a plasmoid, a kded module, a kcmshell module and a standalone application for adding new connections. I think the retionale for networkmanagement be in extrager/base is because of the old kdebase and everything that used to belong to kdebase should not depend on other modules (network, pim, etc) except kdelibs. Em Thursday 01 November 2012, Albert Astals Cid escreveu: > El Dijous, 1 de novembre de 2012, a les 20:05:46, Lamarque V. Souza va > > escriure: > > networkmanagement is in extragear/base too. > > Yes, you already said that once. But networkmanagement is an application > (or plasmoid or whatever) while libmm-qt and libnm-qt are not, to be > honest libs or network makes much more sense to me, though i don't really > care. > > Cheers, > Albert > > > Em Thursday 01 November 2012, Daniel Nicoletti escreveu: > > > Hmm dont you think network is a better place? I think base would be the > > > last place Id look for > > > > > > Em 01/11/2012 19:48, "Lamarque V. Souza" escreveu: > > > > ** > > > > > > > > Em Thursday 01 November 2012, Christoph Feck escreveu: > > > > > On Thursday 01 November 2012 22:19:03 Lamarque V. Souza wrote: > > > > > > Em Thursday 01 November 2012, Ben Cooksley escreveu: > > > > > > > Hi everyone, > > > > > > > > > > > > Hi, > > > > > > > > > > > > > The following projects which are in KDE Review appear to have > > > > > > > > > > > > > > been there for more than 2 weeks: > > > > > > > > > > > > > > - appmenu kded module (kded-appmenu) > > > > > > > > > > > > > > - KIMToy (kimtoy) > > > > > > > > > > > > Please move the two projects below to extragear: > > > > > > > - Qt Wrapper for ModemManager (libmm-qt) > > > > > > > > > > > > > > - Qt Wrapper for NetworkManager (libnm-qt) > > > > > > > > > > extragear/base > > > > > > > > > > extragear/libs > > > > > > > > > > extragear/network > > > > > > > > > > > > > > > > > > > > ? > > > > > > > > Good question. networkmanagement is extragear/base, I think they > > > > should stay in the same place. > > > > > > > > > > > > > > > > -- > > > > > > > > Lamarque V. Souza > > > > > > > > KDE's Network Management maintainer > > > > > > > > http://planetkde.org/pt-br > > > > > > > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > > > > > > > > unsubscribe << -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Cleaning house: KDE Review
Em Thursday 01 November 2012, Albert Astals Cid escreveu: > El Dijous, 1 de novembre de 2012, a les 21:35:45, Lamarque V. Souza va > > escriure: > > What kind of things should go to extragear/base then? > > Things that would go to kdebase^Wkde-runtime, kde-workspace, kde-baseapps. > > > networkmanagement is four things: a plasmoid, a kded module, a kcmshell > > > > module and a standalone application for adding new connections. I think > > the retionale for networkmanagement be in extrager/base is because of > > the old kdebase and everything that used to belong to kdebase should not > > depend on other modules (network, pim, etc) except kdelibs. > > Yes, i am in no way arguing about networkmanagement being in extragear/base > or not, what i am saying is that i don't see libmm-qt and libnm-qt to fit > in there. > > Question: Does networkmanagement depend in libmm-qt/libnm-qt? networkmanagement master depends on both. > Cheers, > Albert > > > Em Thursday 01 November 2012, Albert Astals Cid escreveu: > > > El Dijous, 1 de novembre de 2012, a les 20:05:46, Lamarque V. Souza va > > > > > > escriure: > > > > networkmanagement is in extragear/base too. > > > > > > Yes, you already said that once. But networkmanagement is an > > > application (or plasmoid or whatever) while libmm-qt and libnm-qt are > > > not, to be honest libs or network makes much more sense to me, though > > > i don't really care. > > > > > > Cheers, > > > > > > Albert > > > > > > > Em Thursday 01 November 2012, Daniel Nicoletti escreveu: > > > > > Hmm dont you think network is a better place? I think base would be > > > > > the > > > > > last place Id look for > > > > > > > > > > Em 01/11/2012 19:48, "Lamarque V. Souza" escreveu: > > > > > > ** > > > > > > > > > > > > Em Thursday 01 November 2012, Christoph Feck escreveu: > > > > > > > On Thursday 01 November 2012 22:19:03 Lamarque V. Souza wrote: > > > > > > > > Em Thursday 01 November 2012, Ben Cooksley escreveu: > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > The following projects which are in KDE Review appear to > > > > > > > > > have > > > > > > > > > > > > > > > > > > been there for more than 2 weeks: > > > > > > > > > > > > > > > > > > - appmenu kded module (kded-appmenu) > > > > > > > > > > > > > > > > > > - KIMToy (kimtoy) > > > > > > > > > > > > > > > > Please move the two projects below to extragear: > > > > > > > > > - Qt Wrapper for ModemManager (libmm-qt) > > > > > > > > > > > > > > > > > > - Qt Wrapper for NetworkManager (libnm-qt) > > > > > > > > > > > > > > extragear/base > > > > > > > > > > > > > > extragear/libs > > > > > > > > > > > > > > extragear/network > > > > > > > > > > > > > > > > > > > > > > > > > > > > ? > > > > > > > > > > > > Good question. networkmanagement is extragear/base, I think they > > > > > > should stay in the same place. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Lamarque V. Souza > > > > > > > > > > > > KDE's Network Management maintainer > > > > > > > > > > > > http://planetkde.org/pt-br > > > > > > > > > > > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > > > > > > > > > > > > unsubscribe << -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Cleaning house: KDE Review
Em Saturday 03 November 2012, Ben Cooksley escreveu: > On Fri, Nov 2, 2012 at 12:55 PM, Albert Astals Cid wrote: > > El Dijous, 1 de novembre de 2012, a les 21:52:20, Lamarque V. Souza va > > > > escriure: > >> Em Thursday 01 November 2012, Albert Astals Cid escreveu: > >> > El Dijous, 1 de novembre de 2012, a les 21:35:45, Lamarque V. Souza va > >> > > >> > escriure: > >> > > What kind of things should go to extragear/base then? > >> > > >> > Things that would go to kdebase^Wkde-runtime, kde- workspace,195.211.51.74 > >> > kde-baseapps. > >> > > >> > > networkmanagement is four things: a plasmoid, a kded module, a > >> > > kcmshell > >> > > > >> > > module and a standalone application for adding new connections. I > >> > > think the retionale for networkmanagement be in extrager/base is > >> > > because of the old kdebase and everything that used to belong to > >> > > kdebase should not depend on other modules (network, pim, etc)195.211.51.74 > >> > > except kdelibs. > >> > > >> > Yes, i am in no way arguing about networkmanagement being in > >> > extragear/base > >> > or not, what i am saying is that i don't see libmm-qt and libnm-qt to > >> > fit in there. > >> > > >> > Question: Does networkmanagement depend in libmm-qt/libnm-qt? > >> > > >> networkmanagement master depends on both. > > > > I think libs would be a much better place then. > > Agreed. Based on the above, I have now moved libnm-qt and libmm-qt to > extragear/libs. Agreed. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: New lockscreen
Em Friday 11 January 2013, Martin Sandsmark escreveu: > On Fri, Jan 11, 2013 at 10:32:38AM +0100, Marco Martin wrote: > > 311188 since i don't have a a multiscreen setup at the moment > > Me neither, unfortunately. :( > > > difference between 312427 and 311033 (but then he confirmed that he had > > xscreensaver enabled as well so they're actually duplicates) > > Thanks for fixing it. :D > > > in 36 here works in the case a screensaver is enabled (ie esc shows > > the screensaver again) > > Yes, I tested this briefly yesterday, and it seemed to work, but not > always. I'll test more when I get home again. > > > this i can reproduce, i don't know much yet how to fix: > > 310611 (accelerators) > > The code from Elias won't work? Actually, that code belongs to basysKom (I mean the copyright) and I wrote it for them when I worked in basysKom's Contour project. Anyway, after some time researching I came to the conclusion that QML does not implement the concept of accelerators, so I had to emulate it in the QML shutdown dialog. The problem with that implementation is how to list all buttons in a given window and only on that window so buttons in different windows but with the same accel key are not triggered at the same time. In QML shutdown dialog the list is hardcoded so this was not a big deal, to implement something similar in Plasma Components we need something better. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Buy Sprint tickets !
Em Saturday 02 March 2013, Àlex Fiestas escreveu: > Just a reminder that we should buy the plane tickets ASAP so we can get the > cheaper deals. The sprint is only 40 days away. > > See you in Brno ! I already bought mine a couple of weeks ago :-) See you in Brno. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
