Re: [Kde-finance-apps] Review request
On Monday 27 December 2010 08:45:06 Thomas Baumgart wrote: [libalkimia] There is a problem in the list of installed files: -- Installing: /local/kde4/lib/libalkimia.so.4.3.0 -- Installing: /local/kde4/lib/libalkimia.so The file libalkimia.so.4 is missing. Christoph Feck (kdepepo)
Re: Review Request: KIOSlave implementing computer: protocol
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6207/
---
(Updated 2011-01-01 14:04:10.460100)
Review request for kde-windows, kdelibs, Peter Penz, Pino Toscano, Fredrik
Höglund, David Faure, and Patrick Spendrin.
Summary
---
A simple computer kioslave, showing the drive letters on /, and redirecting
to file otherwise.
Additionaly this patch substitutes root on Konqueror sidebar, by computer,
also this changes the places panel (see below).
(as reviewboard only supports single patches) additional patch for the places
panel on trunk/KDE/kdelibs:
Index: kfile/kfileplacesmodel.cpp
===
--- kfile/kfileplacesmodel.cpp (revision 1209174)
+++ kfile/kfileplacesmodel.cpp (working copy)
@@ -120,40 +120,9 @@
Network, I18N_NOOP2(KFile
System Bookmarks, Network),
KUrl(remote:/),
network-workgroup);
#ifdef Q_OS_WIN
-// adding drives
-foreach ( const QFileInfo info, QDir::drives() ) {
-#ifndef _WIN32_WCE
-uint type = DRIVE_UNKNOWN;
-#endif
-QString driveIcon = drive-harddisk;
-#ifndef _WIN32_WCE
-QT_WA({ type = GetDriveTypeW((wchar_t
*)info.absoluteFilePath().utf16()); },
- { type =
GetDriveTypeA(info.absoluteFilePath().toLocal8Bit()); });
-// qDebug() drive info.absoluteFilePath() type:
type;
-switch (type) {
-case DRIVE_REMOVABLE:
-driveIcon = drive-removable-media;
-break;
-case DRIVE_FIXED:
-driveIcon = drive-harddisk;
-break;
-case DRIVE_REMOTE:
-driveIcon = network-server;
-break;
-case DRIVE_CDROM:
-driveIcon = drive-optical;
-break;
-case DRIVE_RAMDISK:
-case DRIVE_UNKNOWN:
-case DRIVE_NO_ROOT_DIR:
-default:
-driveIcon = drive-harddisk;
-}
-#endif
-KFilePlacesItem::createSystemBookmark(d-bookmarkManager,
- info.absoluteFilePath(),
info.absoluteFilePath(),
-
KUrl(info.absoluteFilePath()), driveIcon);
-}
+KFilePlacesItem::createSystemBookmark(d-bookmarkManager,
+ Computer, I18N_NOOP2(KFile
System Bookmarks, Computer),
+ KUrl(computer:), Computer);
#else
KFilePlacesItem::createSystemBookmark(d-bookmarkManager,
Root, I18N_NOOP2(KFile System
Bookmarks, Root),
This addresses bugs 163448 and 169628.
https://bugs.kde.org/show_bug.cgi?id=163448
https://bugs.kde.org/show_bug.cgi?id=169628
Diffs
-
trunk/KDE/kdebase/apps/konqueror/sidebar/default_entries/CMakeLists.txt
1209179
trunk/KDE/kdebase/apps/konqueror/sidebar/default_entries/computer.desktop
PRE-CREATION
trunk/KDE/kdebase/runtime/kioslave/CMakeLists.txt 1209179
trunk/KDE/kdebase/runtime/kioslave/computer/CMakeLists.txt PRE-CREATION
trunk/KDE/kdebase/runtime/kioslave/computer/Messages.sh PRE-CREATION
trunk/KDE/kdebase/runtime/kioslave/computer/computer.protocol PRE-CREATION
trunk/KDE/kdebase/runtime/kioslave/computer/kio_computer.h PRE-CREATION
trunk/KDE/kdebase/runtime/kioslave/computer/kio_computer.cpp PRE-CREATION
Diff: http://svn.reviewboard.kde.org/r/6207/diff
Testing
---
Tested using MSVC 2008 on a windows 7 machine
Screenshots
---
Konqueror with sidebar
http://svn.reviewboard.kde.org/r/6207/s/589/
Dolphin
http://svn.reviewboard.kde.org/r/6207/s/590/
Thanks,
Andrius
Re: Suspending mailinglists due to lack of moderators.
- Original Message - Note that if you object, you are volunteering for taking over moderation. 42 quanta 32 quanta-devel Make me the admin/moderator of these two please. Done. Thanks. -- Tom Albers KDE Sysadmin
Re: Git Scratch-Pads for every identity.kde.org account (not only developers)
On 1/1/2011 10:28 PM, Milian Wolff wrote: Is this how it should be? How was this in SVN times? Did people also start new work somewhere else and waited for the time it was kde-review-able to merge it into KDE? The policy to get a KDE developer account (- write access to all of SVN, and now also git) hasn't changed in a very long time. You are required to state a convincing reason for why you want the account and can optionally name an existing dev account as a supporter, who is then automatically asked by mail to verify his support. When it comes to determining whether the stated reason is convin- cing a huge factor is citing any prior successful contributions. The point is that KDE is team work, so we look for evidence that the holder of the new dev account has already gathered some ex- perience working with others in KDE and so has gotten an idea of the social etiquette and processes involved (having a supporter goes a long away towards proving this and thus the quality of the written reason becomes less important at that point). That's in their interest as much as the project's as it either avoids someone unknown suddenly committing to your codebase, or if someone is committing to your codebase who is indeed unknown to you you can at least expect that he has a certain level of familiarity with how things work in KDE. It's also a mechanism to ensure that stuff served up under a *.kde.org domain name isn't random crap (this issue is relevant to your proposal, btw; if you want to see anything like it done, please come up with a solid plan in this area that can be im- plemented with the available manpower). Sometimes dev accounts are also granted for the purpose of comit- ting entirely new works to playground even without naming a supporter, but only when the written reason is really solid and indicates someone who knows what he's doing and appears respon- sible. Notably that's a much lower barrier to entry than in probably most other FOSS projects (which I think is a good thing, btw). -- Best regards, Eike Hein
Re: Git Scratch-Pads for every identity.kde.org account (not only developers)
Eike Hein, 01.01.2011: On 1/1/2011 10:28 PM, Milian Wolff wrote: Is this how it should be? How was this in SVN times? Did people also start new work somewhere else and waited for the time it was kde-review-able to merge it into KDE? The policy to get a KDE developer account (- write access to all of SVN, and now also git) hasn't changed in a very long time. You are required to state a convincing reason for why you want the account and can optionally name an existing dev account as a supporter, who is then automatically asked by mail to verify his support. When it comes to determining whether the stated reason is convin- cing a huge factor is citing any prior successful contributions. The point is that KDE is team work, so we look for evidence that the holder of the new dev account has already gathered some ex- perience working with others in KDE and so has gotten an idea of the social etiquette and processes involved (having a supporter goes a long away towards proving this and thus the quality of the written reason becomes less important at that point). That's in their interest as much as the project's as it either avoids someone unknown suddenly committing to your codebase, or if someone is committing to your codebase who is indeed unknown to you you can at least expect that he has a certain level of familiarity with how things work in KDE. It's also a mechanism to ensure that stuff served up under a *.kde.org domain name isn't random crap (this issue is relevant to your proposal, btw; if you want to see anything like it done, please come up with a solid plan in this area that can be im- plemented with the available manpower). Sometimes dev accounts are also granted for the purpose of comit- ting entirely new works to playground even without naming a supporter, but only when the written reason is really solid and indicates someone who knows what he's doing and appears respon- sible. Notably that's a much lower barrier to entry than in probably most other FOSS projects (which I think is a good thing, btw). Sorry but how is this related to my proposal? I didn't ask for give developer access to anyone, but only for *scratchpad* repos for everyone. There is a huge difference here, don't you see that? I think you should reread my mail ;-) Bye -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Git Scratch-Pads for every identity.kde.org account (not only developers)
Eike Hein, 02.01.2011: On 1/1/2011 11:37 PM, Milian Wolff wrote: Sorry but how is this related to my proposal? I didn't ask for give developer access to anyone, but only for *scratchpad* repos for everyone. There is a huge difference here, don't you see that? You asked a question about how the KDE contribution process worked in the SVN times, specifically if it was also this way before (see the part of your mail I quoted). By de- scribing what developer access entails and what the barriers to getting it are I'm answering your question: Yes, it was this way before also, because there was no class of just upload whatever you want access in the above. The paragraph on gaining access to place entirely new works in playground even without naming a supporter is as close to your proposal as it got/gets. I think you should reread my mail ;-) And you should probably reread mine, since it seems you didn't read it too closely. I reread it, twice. And my conclusion is I was unclear and you didn't get what I meant initially. Let me sum it up again: - all accounts on identity.kde.org can create new scratch pad repos (i.e. with clones or new repos) - only dev accounts have commit access to anything but their own scratchpad repo. I see how this was not possible (probably?) in SVN, but now with git each project is it's own repo. Special casing the commit rights to scratch pads shouldn't be hard (I hope). One of the paragraphs included some homework for you if you want your proposal to go anywhere. See above, this is nothing I ever wanted to change. I only speak about scratchpad (or what was playground). Hope this makes it clear that most of your email is just not relevant. Bye -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
