Re: what I am missing for kdeclative
Kevin Krammer wrote: Hi Guy, On Friday, 2012-11-02, guy-kde wrote: Hello again! Using https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/ entry/experimental/libkdeclarative/kdeclarative.h I think kdelibs/master is currently unused (not updated). Try branch KDE/4.10 Yesterday I asked David to merhe 4.10 to master exactly for this reason. Apparently, for 4.11 master kdelibs will be like before, a real master. Andras
Re: Google Code-in tasks needed
On Tue, Oct 23, 2012 at 3:01 PM, Lydia Pintscher ly...@kde.org wrote: Heya folks :) Sorry for mass-mailing but this concerns pretty much everyone. Google Code-in applications have started. I just submitted our application. To be successful we now need to add tasks to this list: http://community.kde.org/GoogleCodeIn/2012/Ideas Please only add tasks you are willing to mentor (or if you know someone else is)! A few things to keep in mind: * this is not just about code. We also need other tasks (likely even more than coding tasks) * we need at least 5 tasks in each category * a task should take a normal KDE contributor about 2 hours (This is to give you some idea of how much work a task should be. If you have doubts/questions please come to me.) * there are no translation tasks this time * there are no easy/normal/hard tasks - all the same this time * we get to choose 2 grand-price winners among our best kids. This means students are much more likely to stick with one org this time. * the kids don't get money this time * Google expects a turn-around time on tasks of less than 36 hours. I'd like to us try to get to less than 24 hours if at all possible. * check the timeline (http://www.google-melange.com/gci/events/google/gci2012). If you're not available to approve and review tasks for some of that time please add that to the task description We need this list finished latest by November 5th but earlier would be a lot better. Please spread the word to everyone who's not yet aware of it but should be. Cheers and thanks for your help Lydia PS: Please CC me on replies as I am not subscribed to all lists. Hey :) Just a quick reminder that tasks that will be considered to decide if KDE takes part or not need to be on the wiki by Monday. Please make sure you have as many of your tasks there as possible by the deadline. Thanks to everyone who already added tasks. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE Community Working Group / KDE e.V. board member http://kde.org - http://open-advice.org
Re: kdereview: bodega
El Dimecres, 24 d'octubre de 2012, a les 22:07:10, Aaron J. Seigo va escriure: hi :) (x-posting between core-devel and -devel as this is (hopefully) of general interest and because we also are supposed to announce new kdereview modules.) So ... what is this Bodega thing I speak of? snip If you are interested, please check out the repositories which are now in kdereview: kde:bodega-client and kde:bodega-server and/or ask questions which I'll do my best to answer Won't have time to give it a use test, but some things grep and friends told me ** bodega-client ** i18n is messed up * the primavera/ folder has i18n but no Messages.sh * the ./activeclient/src/Messages.sh extracts to a catalog named active- addons that doesn't seem to be used * You have a ki18n(), not sure what you expect people to translate there ;-) Both primavera and activeclient have this option options.add(opengl, ki18n(use a QGLWidget for the viewport)); options.add(opengl, ki18n(use a QGLWidget for the viewport)); which to be honest not sure the value they have to the end user There's a few foreach missing const The foreach loop in qScriptValueFromTags is unnecessary slow (doing keys + values) (it's ok if the length of tags is never high) ** bodega-server ** assetimporters/projectgutenberg/src/lcc.cpp has no copyright in the header assetimporters/projectgutenberg/src/lcc.cpp has QObject::tr calls, what's the deal with those, are you expecting a translation? If so you'll need a Message.sh, if not, do we need them? There's a few foreach missing const Cheers, Albert
Re: Moving libkfacebook to extragear
El Dissabte, 27 d'octubre de 2012, a les 11:00:42, Martin Klapetek va escriure: Hi, I'd like to move libkfacebook, the foundation for akonadi-facebook resource, into extragear. It's been in use for a while, lots of distro ship it bundled with akonadi-facebook resource, which is now becaming part of kdepim-runtime for 4.10 with libkfacebook as optional compile-time dependency. I'd like to ask for a review of this library, currently in kdereview - https://projects.kde.org/projects/kdereview/libkfacebook You don't seem to be using d-pointers, can you please fix that? My moc complains about postinfo.h:46: Warning: Property declaration from has no READ accessor function. The property will be invalid. postinfo.h:54: Warning: Property declaration properties has no READ accessor function. The property will be invalid. postinfo.h:60: Warning: Property declaration application has no READ accessor function. The property will be invalid. notificationinfo.h:46: Warning: Property declaration from has no READ accessor function. The property will be invalid. notificationinfo.h:47: Warning: Property declaration to has no READ accessor function. The property will be invalid. notificationinfo.h:52: Warning: Property declaration application has no READ accessor function. The property will be invalid. Cheers, Albert Thanks
Re: Moving libkfacebook to extragear
On Sat, Nov 3, 2012 at 1:59 PM, Albert Astals Cid aa...@kde.org wrote: You don't seem to be using d-pointers, can you please fix that? Yes, I'm halfway done together with Kevin's suggestions to get rid of QObjects, but I didn't have time to finish it yet, sorry. Will update once done. Cheers -- Martin Klapetek | KDE Developer
Re: Moving ktouchpadenabler to kdebase^Wkde-workspace
2012/10/13, Aaron J. Seigo ase...@kde.org:
On Saturday, October 13, 2012 22:37:05 Albert Astals Cid wrote:
Back when I moved ktouchpadenabler to extragear-base Christoph mentioned
he'd like to see it in kdebase[1], we don't have a kdebase anymore
though.
Anyway i'd like to move it to a more central place, I guess kde-workspace
would be the place for this kind of stuff?
yes, it makes sense in kde-workspace. it can go in as a top-level directory
(someday i need to do a round of organization in there to collect things
like
kded modules together, etc) and in the CMakeLists.txt it should be added in
the if(${KDE_PLATFORM_PROFILE} STREQUAL Desktop) group
I have imported ktouchpadenabler.git into a top-level
ktouchpadenabler/ directory in the master branch of
kde-workspace.git. I leave it to y'all to fix the buildsystem :)
--
Nicolás
Re: Moving ktouchpadenabler to kdebase^Wkde-workspace
El Dissabte, 3 de novembre de 2012, a les 13:14:49, Nicolás Alvarez va
escriure:
2012/10/13, Aaron J. Seigo ase...@kde.org:
On Saturday, October 13, 2012 22:37:05 Albert Astals Cid wrote:
Back when I moved ktouchpadenabler to extragear-base Christoph mentioned
he'd like to see it in kdebase[1], we don't have a kdebase anymore
though.
Anyway i'd like to move it to a more central place, I guess kde-workspace
would be the place for this kind of stuff?
yes, it makes sense in kde-workspace. it can go in as a top-level
directory
(someday i need to do a round of organization in there to collect things
like
kded modules together, etc) and in the CMakeLists.txt it should be added
in
the if(${KDE_PLATFORM_PROFILE} STREQUAL Desktop) group
I have imported ktouchpadenabler.git into a top-level
ktouchpadenabler/ directory in the master branch of
kde-workspace.git. I leave it to y'all to fix the buildsystem :)
buildsystem fixed
Cheers,
Albert
Re: KDEREVIEW: share like connect and plasmate
Hi, Alle giovedì 1 novembre 2012, Aaron J. Seigo ha scritto: This is to inform everyone that the plasmate and share-like-connect repositories have been moved into KDE Review so that, if all goes according to plan, we can move them to their more permanent homes in a couple of weeks. Most of the apps in the plasmate repo have actually been in past SC releases; it's just the main app, plasmate, that is still fairly new. Regarding plasmate: I fixed earlier a number of i18n issues (ugh...), and the layout of two .ui files. On the other hand, there are still the following issues I found looking around: - there are some dialogs being done as QDialog: what about converting them to KDialog, for a common look'n'feel with the rest of KDE apps, and a bit less layouting code? - PasswordAsker sounds like could be implemented on top of KPasswordDialog - BranchDialog sounds like could be replaced with KInputDialog::getText with a custom validator - CommitDialog, other than being a KDialog, should better be use layouts instead of placing widgets manually - a numer of .ui files sets bold/bigger texts, but using a qt rich text which forces a font size (and in few cases also the font face) - metadata.ui has an error message whose color is forced as red; please use KMessageWidget or at least use KColorScheme to get the fore-/back- ground colors for errors - RemoteInstaller uses /var/tmp/plasmaremoteinstaller/ as destination directory, which is a bit too generic (at least appending the user name and chmod'ing it 600 would help); also there is a race between the KIO exists and the mkdir calls - TimeLine::loadTimeLine does a funky job in putting translated bits among the git output; a better way would be parsing the output extracting the various details, and composing a new ad-hoc string (and the date would need localization, as the FIXME say) - main installs a message handler which makes MainWindow emit a signal... which is caught by itself: why not just put it in main.cpp, and in case there is a main window notify it to write to the konsole widget? also, such handler currently writes to /var/tmp/plasmatepreviewerlog.txt, which is not a good thing to do... - StartPage::saveNewProjectPreferences saves the status of all the js/py/etc radio buttons separately... saving the index or the name of the active one would be much easier - EditPage::showTreeContextMenu uses the internalPointer() of the model, which makes it prone to break if the model changes implementation internally - KonsolePreviewer (ab)uses /var/tmp/plasmatepreviewerlog.txt as temporary file name, please use KTemporaryFile - wrt Publisher::doCMake: - should check that `cmake` exists (see KStandardDirs::findExe) prior to do all the work - $KDEDIRS is not set by default by KDE, but only by the user - check the return value of a command invocation, before starting the next command - when commands fail, instead of a generic failure error, what about showing the output+error log? - SigningDialog::validateParams could use some already existing email validation method (iirc there is a basic one in kdelibs and a better one in kdepimlibs) - why ImageLoader::run forces the formats? - KConfigXtEditor writes/replaces XML by hand... is that really a good thing to do (think about proper escaping, etc)? consider just using QDom/QXml for the job - why KConfigXtWriter writes kcfg prologue/epilogue by hand? - TextEditor::modifyToolBar does a big no-no job in looking for actions (never ever compare to translated strings, especially when coming from other components) I think that's enough for now. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: KDEREVIEW: share like connect and plasmate
On Saturday, 2012-11-03, Pino Toscano wrote: - RemoteInstaller uses /var/tmp/plasmaremoteinstaller/ as destination directory, which is a bit too generic (at least appending the user name and chmod'ing it 600 would help); also there is a race between the KIO exists and the mkdir calls I guess KStandardDirs could handle that, using resource type tmp Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving ktouchpadenabler to kdebase^Wkde-workspace
2012/11/3, Nicolás Alvarez nicolas.alva...@gmail.com:
2012/10/13, Aaron J. Seigo ase...@kde.org:
On Saturday, October 13, 2012 22:37:05 Albert Astals Cid wrote:
Back when I moved ktouchpadenabler to extragear-base Christoph mentioned
he'd like to see it in kdebase[1], we don't have a kdebase anymore
though.
Anyway i'd like to move it to a more central place, I guess
kde-workspace
would be the place for this kind of stuff?
yes, it makes sense in kde-workspace. it can go in as a top-level
directory
(someday i need to do a round of organization in there to collect things
like
kded modules together, etc) and in the CMakeLists.txt it should be added
in
the if(${KDE_PLATFORM_PROFILE} STREQUAL Desktop) group
I have imported ktouchpadenabler.git into a top-level
ktouchpadenabler/ directory in the master branch of
kde-workspace.git. I leave it to y'all to fix the buildsystem :)
The original ktouchpadenabler repository has now been deleted.
--
Nicolás
Re: merging development branch into master
* I guess once the branch is merged it should be closed for business: fixes go into master and new features go into new branch, right? yup, well. assuming that we are at/past the feature freeze at that point. thing is...was this added to the feature page? (if not it cannot be merged this cycle) http://techbase.kde.org/Schedules/KDE4/4.10_Release_Schedule#Thursday.2C_October_25.2C_2012:_KDE_SC_4.10_Soft_Feature_Freeze additionally, shouldn't we do this on reviewboard so everyone can check it out? i realize it's a bit a pain with big old branches, but would be the best. -- Shaun Reich, KDE Software Developer (kde.org)
Re: merging development branch into master
Yes, it's in feature list for 4.10 I can try to submit it to review if I have time tomorrow, but wouldn't it be a bit too late? Thanks, Andriy On Nov 4, 2012 12:17 AM, Shaun Reich sre...@kde.org wrote: * I guess once the branch is merged it should be closed for business: fixes go into master and new features go into new branch, right? yup, well. assuming that we are at/past the feature freeze at that point. thing is...was this added to the feature page? (if not it cannot be merged this cycle) http://techbase.kde.org/Schedules/KDE4/4.10_Release_Schedule#Thursday.2C_October_25.2C_2012:_KDE_SC_4.10_Soft_Feature_Freeze additionally, shouldn't we do this on reviewboard so everyone can check it out? i realize it's a bit a pain with big old branches, but would be the best. -- Shaun Reich, KDE Software Developer (kde.org)
Re: merging development branch into master
well, you've got until november 8th (4 days according to my clock) until hard feature freeze which blocks even those on the planned feature list. so, as my procrastinating self would say you've got plenty of time ;) -- Shaun Reich, KDE Software Developer (kde.org)
