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 : > 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 "QMap 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 wrote: > > On 4 August 2011 07:27, George Spelvin 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: Formal complaint concerning the use of the name "System Settings" by GNOME
If anyone is interested in my proposal for DE-specific keys, I've written a proposal for how the Desktop Entry Specification could be updated. This support could be used to implement the naming mentioned, that is calling it "System Settings" in KDE, and "KDE System Settings" elsewhere - without new desktop files. I'm attaching the proposal. However, I do not have the time or willpower to argue for it. If someone finds it useful, feel free to make something out of it. (implementing it, however, is trivial) For my original suggestion, see http://lists.kde.org/?l=kde-core-devel&m=131160689716557&w=2 (but the example there is accidentally inverted). On Thu, Aug 11, 2011 at 7:48 PM, Shaun McCance wrote: > On Wed, 2011-08-10 at 13:47 +0200, todd rme wrote: >> On Wed, Aug 10, 2011 at 1:42 PM, Richard Hughes wrote: >> > On 4 August 2011 07:27, George Spelvin 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 > > > > desktop-spec-update2 Description: Binary data
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 : > > 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 "QMap 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 > >
Names to use for 'more mouse buttons' ?
As you know already, here is the data field scheme: There are two "available" bits within the current enum and flags. (Total width 16 bits; 15 usable without creating a risk of interpretation as a "sign" bit under certain compilers.) The first of these bits (x2000) is used for raw Button #10, AKA the "Task" Button. But the second available bit x4000, will be used to repesent a special value of "button": "HigherButtonNumber". This value indicates that (A) the event was caused by a "raw" Button number of 11, OR GREATER; and (B) the 32-bit Button State Mask contains AT LEAST one such button. But the Qt programmer will not have the actual Button number yet -- it must be obtained by calling a new get() function, because QMouseEvent::button() contains only "HigherButtonNumber." ---> What should be the name of this "upgraded" Qt::MouseButton enum, and it's corresponding flags? (It's 32 bits wide, and programmers COULD use the new one exclusively- the enum and function will handle all buttons, #0 thru #31. But for BC purposes, it has to be a different enum.) ---> How do I add corresponding 'buttonByNumber() functions? (getter and setter for use in test code). Or maybe -- as a matter of policy, does Qt want to insist on a wordy enumeration, instead of integer math?? If it is desirable what should the field name and function prototypes look like? Do we agree that 3 mouse buttons in Qt5 is the WRONG roadmap, and that you'd like me to continue trying to work through this?? If so, I feel that 4.9 constitutes a good target. Once we have the buttons, we can do some awesome shortcut tools, and create impressive and UI Kewl-ness. Both within KDE, and within usercode written against the Qt and KDE libraries. If you all think that we're already "world class" with only 3 buttons, or 5 buttons, then please TELL ME: I'll shut up, go away, and stop wasting everyone's time with this "issue." I've asked for some coaching assistance several times, and the silence has been deafening -- if that's been intended as a message, please tell me the message more directly. Thanks either way!
