Re: Some questions concerning virtual keyboard
Am Mittwoch 19 August 2009 23:08:22 schrieb Björn Ruberg: Hello! I moved my virtual keyboard plasmoid to kdelibs-addons some days ago. So far so good. As my university studis start again in mid of october I want to do all missing work until then. Now I have time for it. I have some questions for that. 1. Bad translations: The keys on the keyboard are translated. In some cases the translations is wrong. The home-key for example is labeled wrong in German translation. It's translated to personal folder. Obviously plasmaboard needs its own translation. What can I do about that? svn up l10n-kde4/de/messages and install language de. Then you will notice the common problem, that translated strings are sometimes longer than the english ones... -- Burkhard Lück ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: [Kde-dashboard] Failed 4.4/kdebase-workspace r1013206
On Wednesday 19 August 2009 18:23:28 David Faure wrote: I got the same error as the one forwarded below, when compiling plasma with unit-tests enabled, here. The problem is that the unittest in common/tests uses header files from desktop/, which use generated headers (ui_MousePlugins.h). In a clean build, the generated header doesn't exist, and the build fails in common. We had a code drop there because of some GSoC work, I committed a build fix in r1012817 on tuesday. But indeed I missed the ui file which didn't fix it for clean builds. Gary Greene just committed r1013492 which should fix that. I assume that desktop depends on common anyway, so adding dependencies seems a bit tricky. If the unittest needs to link to the lib created by desktop/, then even forward-declaring Ui::MousePlugins and moving the include to the .cpp won't help. Sounds more like the unittest should move to desktop/, if I'm right that desktop depends on common and not the other way round? That's what would look the most sensible to me in the case of the background test. It mainly uses classes from desktop right now. Alternative would be to move the relevant parts from desktop to common as I can foresee them being used in other shells (netbook one for instance). Regards. -- Kévin 'ervin' Ottens, http://ervin.ipsquad.net Ni le maître sans disciple, Ni le disciple sans maître, Ne font reculer l'ignorance. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Some dates on Tokamak3
On Monday 17 August 2009, Ana Cecília Martins Barbosa wrote: so, I may need both jeans and shorts. but no woolly sweaters. while I may need thick jeans and 3 layers of woolly sweaters :) it's how we will be able to tell the canadians apart from the brazilians. :P -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: PopupApplet and setFocus() behaviour
On Tuesday 18 August 2009, Dmitry Suzdalev wrote: Would be nice I think. But we'll need to ensure that focus gets set only after d-dialog inside a popupapplet will be activated. Or any other possible (temporary or offscreen for ex) widget on the scene. That is we don't wont a focusOut event coming to the widget right after we told it to focusIn :) want to give it a try in PopupApplet? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] BUG 203716 give user a hint when adding same application into quicklaunch
Lukas Appelhans 写道: Am Donnerstag 20 August 2009 04:44:29 schrieb 潘卫平(Peter Pan): Lukas Appelhans 写道: Am Mittwoch 19 August 2009 15:51:18 schrieb 潘卫平(Peter Pan): Lukas Appelhans 写道: Am Mittwoch 19 August 2009 14:25:09 schrieb 潘卫平(Peter Pan): Lukas Appelhans 写道: Am Mittwoch 19 August 2009 05:50:08 schrieb 潘卫平(Peter Pan): 潘卫平(Peter Pan) 写道: Aaron J. Seigo 写道: On Friday 14 August 2009, 潘卫平(Peter Pan) wrote: svn r 1011382 there are a couple issues with this patch, unfortunately. first, it introduces a modal dialog. that will block the rest of plasma. not good. :/ That's really not good. second, the button names are just Ok and Cancel, they should be changed to having meaningful labels that say _what_ will happen if Ok or Cancel is pressed. but that's a moot point, because we really can't have a modal dialog here. is there any use case where it makes sense to have more than one icon for the _same_ application or file? i can't think of one. so i'd suggest just silently dropping duplicates. I prefer to show user a warning message rather than drop it silently. -- -- -- -- ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Every time you want to add an application, call checkDuplicateUrls() first.In this function, I give user a hint when we find duplicate URLs, then ignore them. And setModal(false) for KMessageBox. Regards Mmh, I don't like that we iterate through the list 2 times, we should just remove the iteration for checkin duplicates in the addProgram() method imo... I prefer to make the applications in quicklaunch unique, not allow duplicating. Because I don't like that quicklaunch is too wide. Yeah, sure, but why do we iterate through the list 2 times? One time to show the dialog and one time to remove duplicates? that doesn't make much sense to me... :/ oh, because KDialog-show() will return immediately, so first time, I prepare a message for KMessageBox. If we checkin duplicates in addProgram()'s iteration, only the last duplicate application will be shown. And second time iteration, remove duplicates. Well why not let checkDuplicates() return a cleared KUrl::List where all duplicates are removed? I got it. :) This patch looks nice to me... although I think a native english speaker should have a look at the string used in the dialog... but ok, from coding side this patch is ready to go into trunk I think... Thank you for your help. Lukas Lukas Also the KDialog way seems a bit too much to me, isn't there a way to just get a KMessageBox like the command we got before? KMessageBox needs a KDialog parameter. I can't find another way if we use KMessageBox. Okee then leave it that way :) Lukas Lukas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Regards ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Regards ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Regards -- 潘卫平(Peter Pan) Red Flag Software Co., Ltd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Some questions concerning virtual keyboard
On Thursday 20 August 2009 08:31:54 Burkhard Lück wrote: svn up l10n-kde4/de/messages and install language de. Then you will notice the common problem, that translated strings are sometimes longer than the english ones... Which is actually a problem with the app-author because of using fixed layouts depending on the size of the english text. There are languages out there where the translation has to be longer. And there are places where the typical programmers-english is to short for normal users to understand... Arnold signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Some questions concerning virtual keyboard
On Donnerstag 20 August 2009, Burkhard Lück wrote: Am Mittwoch 19 August 2009 23:08:22 schrieb Björn Ruberg: Hello! I moved my virtual keyboard plasmoid to kdelibs-addons some days ago. So far so good. As my university studis start again in mid of october I want to do all missing work until then. Now I have time for it. I have some questions for that. 1. Bad translations: The keys on the keyboard are translated. In some cases the translations is wrong. The home-key for example is labeled wrong in German translation. It's translated to personal folder. Obviously plasmaboard needs its own translation. What can I do about that? svn up l10n-kde4/de/messages and install language de. Then you will notice the common problem, that translated strings are sometimes longer than the english ones... You missunderstood. The Home-Key must be translated in German in Pos1. Personal folder is not too long, it is just wrong. Instead of translating the labels they must be replaced by the words the translator has on his keyboard. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: kate session applet: allow keyboard only usage
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1358/ --- Review request for Kate and Plasma. Summary --- The Kate session applet can be configured to pop up via a keyboard shortcut and the listed session can be navigated via the up and down arrow keys. Yet, a session can not be started by means of using the keyboard, a mouse click is currently required. The attached patch fixes the problem by using the QTreeView::activated signal instead of the clicked signal. This also elegantly handles the single/double click issue. This addresses bug 203546. https://bugs.kde.org/show_bug.cgi?id=203546 Diffs - /trunk/KDE/kdesdk/kate/plasma/session/katesessionapplet.cpp 1009608 Diff: http://reviewboard.kde.org/r/1358/diff Testing --- I compiled and installed it on my system and it behaves as expected. Notably, it still obeys the system wide single/double click setting. Thanks, Conrad ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix a wrong source update when mounting a StorageVolume
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1352/#review2090 --- trunk/KDE/kdebase/workspace/plasma/dataengines/soliddevice/soliddeviceengine.cpp http://reviewboard.kde.org/r/1352/#comment1413 that's going to call updateSourceEvent on ALL of the sources; i don't think that's what's wanted here. the scheduleSourcesUpdated() call shouldn't be necessary in any case since setData always results in a call to that if appropriate. in the engine, updateSourceEvent has this code in it: bool update1 = updateFreeSpace(source); bool update2 = updateHardDiskTemperature(source); so obviously what's needed here is a call not to updateAllSources, but: updateFreeSpace(udi); updateHardDiskTemparature(udi); - Aaron On 2009-08-18 15:06:57, Alessandro Diaferia wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1352/ --- (Updated 2009-08-18 15:06:57) Review request for Plasma, Sebastian Kügler and Christopher Blauvelt. Summary --- This patch fixes a missing update specifically for the Free Space key for the data associated with the source of the StorageVolume. I don't know if the missing update is due to the recent changes in Plasma::DataEngine but this patch seems to solve the problem I've pointed out in the free space indicator patch (http://reviewboard.kde.org/r/632/#review2065). As from the docs there's no need to call scheduleSourcesUpdate() when using DataEngine::setData, but i found the need to call updateAllSources in order to correctly update the Free Space data. Diffs - trunk/KDE/kdebase/workspace/plasma/dataengines/soliddevice/soliddeviceengine.cpp 1012848 Diff: http://reviewboard.kde.org/r/1352/diff Testing --- Thanks, Alessandro ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Querying the dict dataengine
On Monday 17 August 2009, alan moore wrote: The delay wasn't really the problem, but rather the initial bogus output. I guess I'm thinking of this like a database query -- ask a question, wait a bit, get an answer. I can see how connectSource() makes sense in a situation where you have a constant stream of data you want to tap into and pipe out to a widget, but is there not a mechanism for simply doing a one-off query? I thought that's what the query() method was for, but that wasn't working out either. well, no. because in this case the result is fetched asynchronously. which means the only way to do what you want would be to block all of plasma to wait for the data. that's obviously not good :) query() doesn't _really_ provide a synchronous interface, it just provides synchronous access to data that already exists. not great in that sense, but useful at times. another thing that's a bit annoying is that we have no way to tell currently between between empty set of data is the correct answer and empty set of data right now, will be filled in later, so in the case of the async call there's always a first call with an empty data set. i think i'm going to try a patch in trunk where we don't send the initial data out if the data set is empty on creation and see if that trips anything up. i think it will probably match people's expectations better. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: About containmentactions
On Tuesday 18 August 2009, Albert Astals Cid wrote: Please check that containmentactions properly support i18n, i see they did not have Messages.sh and Laurent has added them, but this does not guarantee the catalogs are being properly loaded. i just checked them all over and the necessary catalogs are being correctly generated. P.S: kdereview?¿ the bulk of this work was actually a set of modifications to libplasma and done using git-svn, which made putting the plugins in kdereview pretty difficult. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add setSubTitlePolicy() method to Plasma::Delegate
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/#review2091 --- why isn't the model returning an appropriate negative value for the subtitle? - Aaron On 2009-08-18 21:59:39, Dmitry Suzdalev wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/ --- (Updated 2009-08-18 21:59:39) Review request for Plasma and Aaron Seigo. Summary --- This adds more control of showing subtitles with Plasma::Delegate by adding a setSubtitlePolicy() method to its API. Discussed briefly on #plasma with notmart, now on to review :) Diffs - trunk/KDE/kdelibs/plasma/delegate.h 1011618 trunk/KDE/kdelibs/plasma/delegate.cpp 1011618 Diff: http://reviewboard.kde.org/r/1357/diff Testing --- Tested with klipper applet by putting it in all modes possible (at least all i can come up with :)) Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: kate session applet: allow keyboard only usage
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1358/#review2092 --- Ship it! feel like doing the same thing for the konsole sessions plugin? :) - Aaron On 2009-08-19 13:28:48, Conrad Hoffmann wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1358/ --- (Updated 2009-08-19 13:28:48) Review request for Kate and Plasma. Summary --- The Kate session applet can be configured to pop up via a keyboard shortcut and the listed session can be navigated via the up and down arrow keys. Yet, a session can not be started by means of using the keyboard, a mouse click is currently required. The attached patch fixes the problem by using the QTreeView::activated signal instead of the clicked signal. This also elegantly handles the single/double click issue. This addresses bug 203546. https://bugs.kde.org/show_bug.cgi?id=203546 Diffs - /trunk/KDE/kdesdk/kate/plasma/session/katesessionapplet.cpp 1009608 Diff: http://reviewboard.kde.org/r/1358/diff Testing --- I compiled and installed it on my system and it behaves as expected. Notably, it still obeys the system wide single/double click setting. Thanks, Conrad ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasmoidviewer license
On Wednesday 19 August 2009, Marco Martin wrote: Hi all, i just noticed that the license of plasmoidviewer is.. BSD is this an acceptable thing? should be tried to be changed? (is Frerich BSD is just fine. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Adding a runner to KDE
static const char * CONFIG_QUIT com_quit; Could it be, that you forgot the '='? static const char * CONFIG_QUIT = com_quit; I haven't got so much time at the moment, but I'll try to implement it, when I've got time again. I've done and committed it. Oh, I will correct it, I'm German and I didn't know the words before, sorry. That's done, too (if I have found everything) Cheers, Jan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Question regarding folderview Flow option
On Wednesday 19 August 2009, Shantanu Tushar Jha wrote: Recently while working on the FolderView applet, I got the question that why isn't the user allowed to change the flow when used as a normal applet ? I've observed that when folderview used as the desktop Type, the flow options can be changed. But, these options can also be useful when used as an applet imho. sure, i don't see the harm. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Some questions concerning virtual keyboard
On Wednesday 19 August 2009, Björn Ruberg wrote: 1. Bad translations: The keys on the keyboard are translated. In some cases the translations is wrong. The home-key for example is labeled wrong in German translation. It's translated to personal folder. Obviously plasmaboard needs its own translation. What can I do about that? use i18nc, e.g.: i18nc(The 'Home' key on a keyboard, Home); 2. Keyboard on the desktop: It is not possible to use the keyboard from the desktop because the window you are working on automatically looses focus when you click on the keyboard. Some users are confused by that. Question: Can I forbid the popup being dragged on the desktop? Or better: Instead the board the panel icon can be used on the desktop. Clicking on it would open the keyboard - which should be useable in this case. Is that doable? doable, probably, but will require some modifications to plasma-desktop and/or even in libplasma. something to explore/look into. 3. Keyboard as panel? Currently the keyboard is displayed above windows. I find it useful to be able to make some kind of a panel out of it. I want that a maximized window not overlaps with the keyboard. Is that possible? this should be possible with one of the panel hiding modes already supported, no? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Some questions concerning virtual keyboard
Am Donnerstag 20 August 2009 11:11:01 schrieb Björn Ruberg: On Donnerstag 20 August 2009, Burkhard Lück wrote: Am Mittwoch 19 August 2009 23:08:22 schrieb Björn Ruberg: Hello! I moved my virtual keyboard plasmoid to kdelibs-addons some days ago. So far so good. As my university studis start again in mid of october I want to do all missing work until then. Now I have time for it. I have some questions for that. 1. Bad translations: The keys on the keyboard are translated. In some cases the translations is wrong. The home-key for example is labeled wrong in German translation. It's translated to personal folder. Obviously plasmaboard needs its own translation. What can I do about that? svn up l10n-kde4/de/messages and install language de. Then you will notice the common problem, that translated strings are sometimes longer than the english ones... You missunderstood. The Home-Key must be translated in German in Pos1. It is translated to Pos1 here and that is not too long, but Eingabe, Bild ab, Bild auf are longer than the english text... -- Burkhard Lück ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Allow keyboard only usage of the Konsole Session Applet
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1366/ --- Review request for Plasma. Summary --- The Konsole session applet can be configured to pop up via a keyboard shortcut and the listed session can be navigated via the up and down arrow keys. Yet, a session can not be started by means of using the keyboard, a mouse click is currently required. The attached patch fixes the problem by using the QTreeView::activated signal instead of the clicked signal. This also elegantly handles the single/double click issue. As requested here: http://reviewboard.kde.org/r/1358/ Diffs - /trunk/KDE/kdeplasma-addons/applets/konsoleprofiles/konsoleprofilesapplet.cpp 1013640 Diff: http://reviewboard.kde.org/r/1366/diff Testing --- This is the exact same change as in http://reviewboard.kde.org/r/1358/ . Nevertheless, I have compiled and installed it on my system and verified that it works as expected. Notably, it still obeys the system wide single/double click setting. Thanks, Conrad ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Konqeror Session Applet: Allow Keyboard only usage
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1367/ --- Review request for Plasma. Summary --- Same as http://reviewboard.kde.org/r/1358/ and http://reviewboard.kde.org/r/1366/ but for the Konqueror Session Applet Sorry, I hope this isn't bas practice, but I am repeating myself :) Diffs - /trunk/KDE/kdeplasma-addons/applets/konqprofiles/konqprofilesapplet.cpp 1013640 Diff: http://reviewboard.kde.org/r/1367/diff Testing --- See http://reviewboard.kde.org/r/1358/ and http://reviewboard.kde.org/r/1366/ Thanks, Conrad ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Allow keyboard only usage of the Konsole Session Applet
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1366/#review2095 --- Ship it! yes, same fix, same answer .. :) these kinds of fixes can just go directly into svn, really. they are trivial enough to be caught on the commit log mailing list. of course, if you want the confirmation i'm sure we're more than happy to review whatever you put up :) - Aaron On 2009-08-20 12:17:04, Conrad Hoffmann wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1366/ --- (Updated 2009-08-20 12:17:04) Review request for Plasma. Summary --- The Konsole session applet can be configured to pop up via a keyboard shortcut and the listed session can be navigated via the up and down arrow keys. Yet, a session can not be started by means of using the keyboard, a mouse click is currently required. The attached patch fixes the problem by using the QTreeView::activated signal instead of the clicked signal. This also elegantly handles the single/double click issue. As requested here: http://reviewboard.kde.org/r/1358/ Diffs - /trunk/KDE/kdeplasma-addons/applets/konsoleprofiles/konsoleprofilesapplet.cpp 1013640 Diff: http://reviewboard.kde.org/r/1366/diff Testing --- This is the exact same change as in http://reviewboard.kde.org/r/1358/ . Nevertheless, I have compiled and installed it on my system and verified that it works as expected. Notably, it still obeys the system wide single/double click setting. Thanks, Conrad ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
A contact's plasmoid video
Dear friends I and Igor Oliveira have being working on a PoC (Proof of Concept) plasmoid for contacts. The idea is to write a plasmoid that could integrate information for user's contacts, providing quick access to it and allowing to integrate with other KDE services and applications (akonadi and nepomuk comes to mind). At this moment, it is really more an exercise with Qt animation and plasma. The code is still pretty much a mess and definitely needs quite a lot of cleanup before being made public. Maybe after this cleanup we could host it in playground? Anyway, here goes the video: http://blip.tv/file/2488108/ (advisable to watch it in full screen). We are hoping for comments and suggestions about how this effort could better serve plasma desktop users. Best regards Adenilson Cavalcanti a.k.a. Savago ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add setSubTitlePolicy() method to Plasma::Delegate
On 2009-08-20 10:03:58, Aaron Seigo wrote: why isn't the model returning an appropriate negative value for the subtitle? This whole discussion raised because of this: by default, Plasma::Delegate has the policy of automatically adding subtitles if two adjasent items are of the same content. I questioned why this should be the default - for example while writing a klipper plasmoid I found this as a surprise - and we discussed the addition of such api. Though later (after i published the review), me and mart agreed that maybe it's not really necessary to have the api changed, maybe the only change in the end would be the addition of that part of logic which would not try to be that clever if QVariant() is returned for SubTitleMandatoryRole (i.e. if model doesn't implement returning something for this role). Otherwise it appears that model cannot have exact control where to show and where not to show title. For example, even if it implements returning 'true' for some items and 'false' for other items, the items with 'false' will still be auto-disambiguated inside a delegate. So the main point now is to leave only checking for data validity of SubTitleMandatoryRole, and do disambiguating *only* if model doesn't care. I've yet to update this review with the actual patch. - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/#review2091 --- On 2009-08-18 21:59:39, Dmitry Suzdalev wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/ --- (Updated 2009-08-18 21:59:39) Review request for Plasma and Aaron Seigo. Summary --- This adds more control of showing subtitles with Plasma::Delegate by adding a setSubtitlePolicy() method to its API. Discussed briefly on #plasma with notmart, now on to review :) Diffs - trunk/KDE/kdelibs/plasma/delegate.h 1011618 trunk/KDE/kdelibs/plasma/delegate.cpp 1011618 Diff: http://reviewboard.kde.org/r/1357/diff Testing --- Tested with klipper applet by putting it in all modes possible (at least all i can come up with :)) Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: big revamp of Device Notifier
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1370/ --- Review request for Plasma. Summary --- This is a patch that modifies quite heavily the behaviour of the Device Notifier. It comes from here: http://kde-look.org/content/show.php/Device+Manager?content=106051 It can show the not removable devices too, it can mount them automatically or with a click, since the eject button is a mount button when the volume is umounted. So that guy on the dot will be ok. It can hide some items in the same way as Dolphin's places (hide item/ show all). Finally, it shows the various opening actions under the device instead of calling that xp-ish window. Diffs - /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/CMakeLists.txt 1010116 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/configurationpage.ui PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.h 1010116 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp 1010116 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicespaceinfodelegate.h PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicespaceinfodelegate.cpp PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierdialog.h 1010116 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierdialog.cpp 1010116 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierview.h 1010116 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierview.cpp 1010116 Diff: http://reviewboard.kde.org/r/1370/diff Testing --- I'm using it every day since I released 0.1 on Kde-look. I tried all the options on my pc and they work. Some people on kde-look posted some comments about some problems, but it seems to me they are very particular cases, so in my opinion it is quite stable to go in trunk, but anyway review it! :) Screenshots --- screen http://reviewboard.kde.org/r/1370/s/183/ Thanks, Giulio ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: big revamp of Device Notifier
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1370/#review2100
---
First of all thanks for undertaking the difficult task to improve the device
notifier. It's far from trivial.
Now, I'm not the device-notifier maintainer so I can't comment on some bits of
the patch, which is quite big and makes it cumbersome to review (to be expected
when you fork for a while then try to merge back). So I couldn't really comment
on the delegate and notifier popup bits.
That said, I attached comments where I could. The issues found range from minor
style or whitespace related issues to major architectural problems (if you take
the workspace as a whole). As is I'd say it jeopardizes the stability of the
workspace by inducing potential hard to fix bugs. The first big change to
tackle are to remove anything related to automounting, and remove anything
trying to talk to HAL directly.
More details in the comments of this review.
Cheers!
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/configurationpage.ui
http://reviewboard.kde.org/r/1370/#comment1414
Anything related to automounting should be removed. It is currently worked
on independently of Plasma (this feature shouldn't be attached to such an
applet anyway).
The upcoming automounter is likely to be part of the 4.4 release.
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.h
http://reviewboard.kde.org/r/1370/#comment1415
Careful with your whitespaces... There's quite a few of those through the
patch, I'm not going to comment on them all but that needs to be cleaned up.
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp
http://reviewboard.kde.org/r/1370/#comment1416
Uh-oh... doesn't look too good, I wonder what you need that for.
Ideally the applet should always go through the data engine or solid.
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp
http://reviewboard.kde.org/r/1370/#comment1417
This line and the following could go in the if.
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp
http://reviewboard.kde.org/r/1370/#comment1418
Should be } else { (on the same line) to respect the style.
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp
http://reviewboard.kde.org/r/1370/#comment1419
As above: } else {
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp
http://reviewboard.kde.org/r/1370/#comment1420
Urgh! Please no!
You're hard depending on HAL now. It's doomed to fail if HAL behavior
changes a bit, or if distros move away from it in favor of something else.
We have the solid layer exactly to cope up with those changes. Please use
it.
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp
http://reviewboard.kde.org/r/1370/#comment1421
Moreover you're making it a sync call...
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp
http://reviewboard.kde.org/r/1370/#comment1422
And what will happen for computers faster/slower than your? You should
probably wait for a notification instead of using a timer with a magic value.
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierview.cpp
http://reviewboard.kde.org/r/1370/#comment1423
Please use C++ style casts. In this case should probably be a static_cast.
- Kevin
On 2009-08-20 17:26:01, Giulio Camuffo wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1370/
---
(Updated 2009-08-20 17:26:01)
Review request for Plasma.
Summary
---
This is a patch that modifies quite heavily the behaviour of the Device
Notifier.
It comes from here:
http://kde-look.org/content/show.php/Device+Manager?content=106051
It can show the not removable devices too, it can mount them automatically or
with a click, since the eject button is a mount button when the volume is
umounted. So that guy on the dot will be ok.
It can hide some items in the same way as Dolphin's places (hide item/ show
all).
Finally, it shows the various opening actions under the device instead of
calling that xp-ish window.
Diffs
-
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/CMakeLists.txt
1010116
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/configurationpage.ui
PRE-CREATION
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.h
1010116
/trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp
1010116
Re: Question regarding folderview Flow option
On Fri, Aug 21, 2009 at 2:18 AM, Fredrik Höglund fred...@kde.org wrote: On Thursday 20 August 2009, Shantanu Tushar Jha wrote: Recently while working on the FolderView applet, I got the question that why isn't the user allowed to change the flow when used as a normal applet ? I've observed that when folderview used as the desktop Type, the flow options can be changed. But, these options can also be useful when used as an applet imho. What do you guys think? Or has this been discussed already? There are two reasons why that option is only available in the containment. The first is that the flow controls which edge of the screen the icons are lined up against, and I thought that option didn't make much sense when folderview is used as an applet, since you can resize it and move it to where you want it on the screen. Left-to-right or right-to-left is also decided automatically in this case depending on the user's locale. Oh, thats what I didn't notice. If those are decided automatically using locale its fine. So that option is hidden to keep the display section of the dialog box (which is quite large already) from being cluttered with options where the default should be good enough. Agreed. The second reason is that folderview currently doesn't support showing a horizontal scrollbar, so if the user switches the flow to top-to-bottom, the user simply won't be able to access all the files in the folder when there are more files than will fit in the view. I noticed this when testing the top-to-bottom flow in the applet, but thought it might be a temporary runtime problem at that time. Thanks for the clarifications :) Regards, Fredrik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
