Re: Review Request: Do not terminate threads
On Sunday 14 August 2011 23.05.41 Albert Astals Cid wrote: #2 Your patch has several issues i mentioned there I noticed those too, and I wanted to just say that I'd trust David and Thiago on these concepts any day. Maybe we can just use the structure they suggested (and Albert coded) and move on?
Re: [Kde-pim] One Free N900 (Re: Kontact Touch went 2nd place in Contest, one N900 to be given away)
Am Samstag, 13. August 2011 17:18:22 schrieb Marc Deop Argemí: On Friday 12 August 2011 15:02:48 Bernhard Reiter wrote: We have not gotten any suggestions for people to receive the phone. So if you had written a simple: I want it, you would have been the one. Well, i do want one, specially after mine going to the graveyard recently. Follow the instructions cited in my email to send an application. The thing is that I do not deserve it. Give your best reason, why we should give it to you. I rather have it given to any random KDE developer :) (or even you Bernhar!) Without KDE - this great community - we could not have created Kontact Touch. So you all enabled us to win in this competition, so we* want to give this phone as another sign of appreciation to someone from the fellow community. That excludes us of course! * we means everybody from the Komo3 team, listed here http://userbase.kde.org/Kontact_Touch/About And we still do not have it. Of course if Nokia fails to ship it, we cannot give it away. That doesn't seem like a problem yet as we do not know who to give it to, right? Let's hope they keep their word an Nokia ships the device (or maybe even an N950 instead! hehehe dream...uh? It would make sense to keep the N950 if we would get one, but I am pessimistic. We have tried getting an N950 in the last extended community program hinting that we were in their second place Contests, but this did not help. There were too many applicants and it was filled up too fast. Bernhard -- Managing Director + Owner: www.Intevation.net - A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part.
Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/15 Albert Astals Cid aa...@kde.org: You do not use d pointers in any of your classes thus maintaining Binary Compatibility is going to be almost impossible if you need to expand them. How about adding a QMapQString, QVariant m_ext; to *Info classes, so that I can store additional variables there? Most (but not all) *Job classes are unlikely to be expanded later, because they perform very simple operations. If I'll add just a forward declaration like class NoteInfoPrivate; and a NoteInfoPrivate *p; into the NoteInfo class, will it be OK? I'd also like if you used KCatalogLoader to load your translation catalog. Done. -- Alexander Potashev
Review Request: Dolphin renaming functionality to include user choice in starting index number
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102328/
---
Review request for KDE Base Apps and Peter Penz.
Summary
---
This patch applies to dolphin/src/views/renamedialog.cpp and
dolphin/src/views/renamedialog.h. It is built on the current master
branch of kde-baseapps repository.
It replaces the current renaming functionality of Dolphin for multiple
files. The functionality gives user a little more control over how to
rename their files. It asks the user for the starting point of the
sequence of number instead of starting it always from 1. Renaming 3
files by doing FILE##.txt gives us FILE01.txt, FILE02.txt, FILE03.txt.
If we have to rename these 3 files to FILE04.txt, FILE05.txt,
FILE06.txt, we need 6 files for the operation. We cannot rename files
starting from a random number. Also, we cannot rename file with
different extensions in a sequence. Though this patch does not yet solve
this problem, what it does is to give the user a choice to start the
sequence from wherever he/she wants it to.
I have used parenthesis '(', ')' instead of '#' as placeholder. For the
above example, we have to rename the files by doing FILE(04).txt and it
will rename the files as required.
Diffs
-
dolphin/src/views/renamedialog.h 8d8b73da56c6675b4e81d94f7467e5a52e440c11
dolphin/src/views/renamedialog.cpp c0c6ad58c1153daed7c15b3f7be661fb39bffb4d
Diff: http://git.reviewboard.kde.org/r/102328/diff
Testing
---
Thanks,
Chirag
Re: Review Request: Dolphin renaming functionality to include user choice in starting index number
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102328/
---
(Updated Aug. 15, 2011, 1:16 p.m.)
Review request for KDE Base Apps and Peter Penz.
Changes
---
Added KIntSpinBox to the RenameDialog.
So that user can decide where to start the renaming sequence for multiple
files. As taking '#' as the replacement string is proven to be stable, we just
pass the value of the KIntSpinBox to the index variable.
Based on the discussion with Peter Penz on the kde-devel mailing list (SUB:
[PATCH] Modified Dolphin multiple files renaming functionality)
Summary
---
This patch applies to dolphin/src/views/renamedialog.cpp and
dolphin/src/views/renamedialog.h. It is built on the current master
branch of kde-baseapps repository.
It replaces the current renaming functionality of Dolphin for multiple
files. The functionality gives user a little more control over how to
rename their files. It asks the user for the starting point of the
sequence of number instead of starting it always from 1. Renaming 3
files by doing FILE##.txt gives us FILE01.txt, FILE02.txt, FILE03.txt.
If we have to rename these 3 files to FILE04.txt, FILE05.txt,
FILE06.txt, we need 6 files for the operation. We cannot rename files
starting from a random number. Also, we cannot rename file with
different extensions in a sequence. Though this patch does not yet solve
this problem, what it does is to give the user a choice to start the
sequence from wherever he/she wants it to.
I have used parenthesis '(', ')' instead of '#' as placeholder. For the
above example, we have to rename the files by doing FILE(04).txt and it
will rename the files as required.
Diffs (updated)
-
dolphin/src/views/renamedialog.h 8d8b73da56c6675b4e81d94f7467e5a52e440c11
dolphin/src/views/renamedialog.cpp c0c6ad58c1153daed7c15b3f7be661fb39bffb4d
Diff: http://git.reviewboard.kde.org/r/102328/diff
Testing
---
Thanks,
Chirag
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Wed, 2011-08-10 at 13:47 +0200, todd rme wrote: On Wed, Aug 10, 2011 at 1:42 PM, Richard Hughes hughsi...@gmail.com wrote: On 4 August 2011 07:27, George Spelvin li...@horizon.com wrote: I think what is needed is a series of more specific alternate names in a .desktop file, with more levels than the current GenericName and Name. I think the KDE system settings desktop file just needs an addition of: OnlyShowIn=KDE; Richard. It has already been explained why this is not sufficient. System settings is needed to configure many aspects of KDE programs. Doing this will leave Gnome users unable to configure any KDE programs they use. I already pointed out a solution that makes it System Settings in KDE and KDE System Settings in other desktops. The KDE developers seemed to agree to this. The problem is solved. Please let's end this thread and get back to writing great free software. Thanks, Shaun
Re: Re: playground-libs/libkvkontakte has moved to kdereview
A Dilluns, 15 d'agost de 2011, Alexander Potashev vàreu escriure: 2011/8/15 Albert Astals Cid aa...@kde.org: You do not use d pointers in any of your classes thus maintaining Binary Compatibility is going to be almost impossible if you need to expand them. How about adding a QMapQString, QVariant m_ext; to *Info classes, so that I can store additional variables there? Most (but not all) *Job classes are unlikely to be expanded later, because they perform very simple operations. Why not simply use a d-pointer like it is explained in techbase? If I'll add just a forward declaration like class NoteInfoPrivate; and a NoteInfoPrivate *p; into the NoteInfo class, will it be OK? I guess you mean using a d-pointer, yes, that's the suggested way of dealing with this kind of issue. I'd also like if you used KCatalogLoader to load your translation catalog. Done. Great. Albert -- Alexander Potashev
Re: Review Request: Dolphin renaming functionality to include user choice in starting index number
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102328/#review5722
---
Ship it!
Thanks for the update, looks good! I've pushed your patch to master and only
did a minor adjustment regarding the layout, so that the box is aligned beside
the text.
- Peter
On Aug. 15, 2011, 1:16 p.m., Chirag Anand wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102328/
---
(Updated Aug. 15, 2011, 1:16 p.m.)
Review request for KDE Base Apps and Peter Penz.
Summary
---
This patch applies to dolphin/src/views/renamedialog.cpp and
dolphin/src/views/renamedialog.h. It is built on the current master
branch of kde-baseapps repository.
It replaces the current renaming functionality of Dolphin for multiple
files. The functionality gives user a little more control over how to
rename their files. It asks the user for the starting point of the
sequence of number instead of starting it always from 1. Renaming 3
files by doing FILE##.txt gives us FILE01.txt, FILE02.txt, FILE03.txt.
If we have to rename these 3 files to FILE04.txt, FILE05.txt,
FILE06.txt, we need 6 files for the operation. We cannot rename files
starting from a random number. Also, we cannot rename file with
different extensions in a sequence. Though this patch does not yet solve
this problem, what it does is to give the user a choice to start the
sequence from wherever he/she wants it to.
I have used parenthesis '(', ')' instead of '#' as placeholder. For the
above example, we have to rename the files by doing FILE(04).txt and it
will rename the files as required.
Diffs
-
dolphin/src/views/renamedialog.h 8d8b73da56c6675b4e81d94f7467e5a52e440c11
dolphin/src/views/renamedialog.cpp c0c6ad58c1153daed7c15b3f7be661fb39bffb4d
Diff: http://git.reviewboard.kde.org/r/102328/diff
Testing
---
Thanks,
Chirag
Re: KDE 5, Qt 5 and QML - What is advised for writing new (KDE) applications in the long term?
On Friday 12 August 2011, Mark wrote: Hi, Times are interesting right now! - Qt is focusing heavily on Qt5. - KDE is focusing on KDE 5 (plasma 2 and making modules mainly) - QML is the new big thing! Now for application developers like me, and probably everyone reading this list, some uncertainty is popping up. At least for me. This is specifically with QML and Qt code for KDE applications. An example. Right now I've written a small application in QML and C++ for managing todo items. In QML i display everything, apply fancy effects and such. In C++ i manage the data model and fill it from an external source. The questions i have here is what is the right approach these days for making an application that in time could be targeted for KDE SC inclusion? Note: the above example is just that, an example! 1. Write the application in Qt mostly and use kdelibs where needed? 2. Same as 1. but make the GUI in QML like i did in the example above? 3. Skip C++ altogether and make in in QML only? .. more options? The goal for Qt5 is to stay as close as possible to 100% source compatible to Qt4, so no changes required there. For the KDE frameworks, we try to do the same, but e.g. due to some things getting merged into Qt we may not reach the 100%. IOW, no major changes required in any KDE applications due to the transition from monolithic kdelibs to modular KDE frameworks. Alex
Re: Review Request: New Date/Time Widgets in kdelibs/kdeui
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101575/#review5719 --- Any progress? - Torgny On June 10, 2011, 9:18 p.m., John Layt wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101575/ --- (Updated June 10, 2011, 9:18 p.m.) Review request for kdelibs, KDEPIM, KPhotoAlbum, Skrooge, Zanshin, Kevin Ottens, and David Jarvie. Summary --- [Sorry this is a post-commit review and took so long to remember to post. Bad coder, no cookie for you!] This review is for some new replacement widgets for the popular KDEPIM KDateEdit and KTimeEdit widgets which were copied into a number of other projects. These new widgets are clean rewrites (the original widgets have history back to KDE2 days) with slightly changed api but otherwise should replicate the same functionality with a couple of new features. They will be available for use by any apps using kdelibs 4.7. The 3 new widgets are: KDateComboBox: A date entry widget derived from KComboBox, the drop-down menu can display a date picker and list of fancy dates to choose from. The list of dates can be configured. KTimeComboBox: A time entry widget derived from KComboBox, the drop-down menu can display a list of times to choose from. The list of times can be configured. KDateTimeEdit: A KDateTime entry widget combining KDateComboBox and KTimeComboBox with optional combo's to select the calendar system and time spec as well. This widget should only be used if you want time spec aware data entry. All widgets can accept a null or invalid input, it is up to the coder to check for validity of input using isValid() if required. All feature options of the widgets can be configured. All widgets can optionally display a warning box on focus out if the entry is invalid. All widgets can be used in Qt Designer. I'm particularly looking for input on the api, and what QWidget event virtual methods I should be reimplementing to make the classes BIC future-proof. Diffs - kdeui/CMakeLists.txt 1e8b259 includes/KDateComboBox PRE-CREATION includes/KDateTimeEdit PRE-CREATION includes/KTimeComboBox PRE-CREATION includes/CMakeLists.txt 7a8bc5c kdeui/tests/CMakeLists.txt c7b8026 kdeui/tests/kdatecomboboxtest.h PRE-CREATION kdeui/tests/kdatecomboboxtest.cpp PRE-CREATION kdeui/tests/kdatetimeedittest.h PRE-CREATION kdeui/tests/kdatetimeedittest.cpp PRE-CREATION kdeui/tests/ktimecomboboxtest.h PRE-CREATION kdeui/tests/ktimecomboboxtest.cpp PRE-CREATION kdeui/widgets/kdatecombobox.h PRE-CREATION kdeui/widgets/kdatecombobox.cpp PRE-CREATION kdeui/widgets/kdatetimeedit.h PRE-CREATION kdeui/widgets/kdatetimeedit.cpp PRE-CREATION kdeui/widgets/kdatetimeedit.ui PRE-CREATION kdeui/widgets/ktimecombobox.h PRE-CREATION kdeui/widgets/ktimecombobox.cpp PRE-CREATION kdewidgets/kde.widgets 9040538 Diff: http://git.reviewboard.kde.org/r/101575/diff Testing --- Unit tests written for non-gui functionality. Gui functionality tested in Qt Designer. KDateTimeEdit still has a couple of minor bugs, but I didn't want to hold the review up any longer. Screenshots --- Qt Designer Preview http://git.reviewboard.kde.org/r/101575/s/180/ KDateComboBox http://git.reviewboard.kde.org/r/101575/s/181/ KTimeComboBox http://git.reviewboard.kde.org/r/101575/s/182/ Thanks, John
